On Wed, Jul 15, 2015 at 11:21 AM, Robert Ramey
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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users