Re: [boost] [1.45] Where are we in the release process?

Subject: Re: [boost] [1.45] Where are we in the release process?
From: Jim Bell (Jim_at_[hidden])
Date: 2010-10-30 10:22:23

On 1:59 PM, Vladimir Prus wrote:
> Eric Niebler wrote:
>
>> On 10/29/2010 5:03 AM, John Maddock wrote:
>> [...]
>>> We really need to figure out a better way of dealing with this...
>> It currently requires a lot of discipline from each developer to make
>> sure every change they apply to trunk also ends up in release. I wonder
>> if commits to trunk to schedule a nag mail to be sent to the submitter a
>> week later that says, "Did you check the tests? Did you merge to
>> release?" Or open a track ticket that says, "merge changelist xxx to
>> release."
> I guess it's better to nag the maintainer of a library, given that 
> merging just once is a sensible strategy.

This seems like another thing that a group of volunteers could do. It
doesn't require intimate familiarity with the library, but a careful eye
comparing regression tests: trunk vs release . If trunk passes more than
release with no new mysteries introduced, all trunk changes can be merged.

The volunteers, then, would inspect and certify to the release manager
that this was the case, and the manager do the merge with confidence.

Minimal work for the release manager. No special permissions for the
volunteers (i.e., a larger group of folks whose work you're much-less
familiar with wouldn't be given power to make changes). Even teams of
two volunteers, checking each others' work.

Reasonable?

> On which note -- do we have up-to-date list of maintainers? Or,
> do we know the maintainer of libs/maintainers.txt? It appears to
> contain entries where a different person is know to maintain that
> library recently, or where the listed maintainer is known to be MIA,
> or have officially declared he's not maintaining that library.

Particularly valuable when the maintainer is MIA.