Re: [Boost-users] [boost] Boost 1_59_0_b1_rc1 is available for testing

Subject: Re: [Boost-users] [boost] Boost 1_59_0_b1_rc1 is available for testing
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-07-15 11:21:21

On 7/14/15 9:20 PM, Gavin Lambert wrote:
> On 15/07/2015 14:59, Edward Diener wrote:
>> Because MPL is so central to everything it seems it is too late to get
>> these fixes into 'master', have the regression tested on 'master' and
>> into the upcoming release at this point.
>
> Take this with a grain of salt, since I'm not a library maintainer or
> release manager, but:
>
> Since it's still at a beta release stage (if I'm understanding
> correctly), this seems to me like the perfect time to merge bugfixes,
> especially ones that have already been tested on develop.
>
> Part of the point of having a beta cycle is to discover these
> accidentally-left-out elements and correct them.
>
> In my view it's far better to delay the release slightly (if that would
> even happen in this case, which it might not) than to ship with known
> bugs for which fixes are already committed.  (When fixes are yet to be
> developed, it's a different story, of course.)
>
> Again, this view might change a little if the fixes are breaking
> changes, but I presume this is not the case since they're tested on
> develop.  Or it just means a few more fixes might need to be merged as
> well.

The problem with this viewpoint is that it fails to recognize the 
division of responsibility between the release manager and the library 
maintainer.

The library maintainer is responsible for making changes, pushing them 
to the develop branch, watching the branch and a short time later, 
merging develop into master.

The release manager is responsible for generating the release and making 
the candidates so that any so far undetected bugs/compatibilities are 
detected before a final release - which he is also responsible for.

You can't hold the release manager for some failure on the part of the 
library maintainer.

You can't add more duties to the job of library maintainer.

Sooooooo... if one is unhappy with the fact that there are changes on 
the develop branch which have not yet been rolled into the release, the 
the person to get after is the library maintainer.

I'm not totally unsympathetic to your plight.  But I would suggest that 
we give library maintainers more of a heads up that the release is 
comming.  Ideally we would send a private email to the official library 
maintainer.  Another thing we could do is run some sort of script that 
would flag libraries whose develop branch contains unmerged changes. 
Ideally this would flag libraries who have unmerged changes over a weak 
old.  This would address the source of the problem and I believe 
shouldn't be all that hard to implement.

Robert Ramey