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: Edward Diener (eldiener_at_[hidden])
Date: 2015-07-15 17:47:04

On 7/15/2015 12:28 PM, Michael Powell wrote:
> 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?

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.