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

On 7/15/2015 12:28 PM, Michael Powell wrote:

On Wed, Jul 15, 2015 at 11:21 AM, Robert Ramey 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?

Part of what gives is that there are Boost libraries for which no official maintainer(s) exist. For instance I am not the official maintainer of the MPL library, although I have been empowered to make changes to the library, and others, most noticeably the Boost community maintenance team, are also empowered to make changes to the MPL library. But essentially MPL has no official maintainer(s). The MPL library is not alone in this regard, as a number of other libraries are in the same predicament. What Boost needs in this respect is for someone to track which libraries really do not have an official maintainer(s) so that when someone on the mailing list expresses an interest in working with Boost as a developer we can at least suggest to that person Boost libraries which need help and eventually perhaps an official maintainer in that person. But no one has volunteered to do this and take on this responsibility. Another part of the problem is just human error on my own part as well as others. I was not paying attention to the cycle of merging 'develop' to 'master' for changes which have repeatedly passed regression tests on 'develop'. I should have many weeks ago merged the MPL 'develop' fixes to 'master' and let the regression tests for them on 'master' run. The only excuse I will make, other than the above that I am not the official maintainer(s) of MPL, is that I have been concentrating on my own VMD library's regression tests on 'develop' and have let the ball drop for a number of other libraries, including MPL, for which I have approved PRs or made changes myself on 'develop' without merging to 'master' for the next release. But similar to MPL I am not the official maintainer(s) of any of those other libraries either ( OK I am a semi-official maintainer of Boost PP ). The overall problem is that there are many less people willing to actively maintain Boost libraries than there are Boost libraries themselves. The only solution to this simple fact is to have more people willing to be maintainer(s) of Boost libraries which they themselves did not originally author.

...

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.