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: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-07-15 12:28:40

On Wed, Jul 15, 2015 at 11:21 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> 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.

Seen as an opportunity, clearly this isn't working. What gives?

> 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
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users