Boost logo

Boost Users :

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]

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at