Re: [boost] Community Maintenance Team and neglected libraries

Subject: Re: [boost] Community Maintenance Team and neglected libraries
From: Ben Pope (benpope81_at_[hidden])
Date: 2014-04-23 07:36:31

On Wednesday, April 23, 2014 05:17 PM, Rob Stewart wrote:
> On April 22, 2014 10:46:55 PM EDT, Ben Pope <benpope81_at_[hidden]> wrote:
>>
>> Not having write access is the problem, it's a barrier to the CMT
>> achieving their first two goals of keeping boost building and a healthy
>>
>> test matrix.
>
> That barrier is also a hallmark of Boost: the library maintainer has ownership until another maintainer is assigned.
>
>> It's kind of crazy that if I have a library that other libraries depend
>>
>> on, and I want to improve that library with a breaking change, there is
>>
>> no mechanism that allows me to fix that other library.  I commit the
>> change to develop, create pull requests and wait.  Nothing happens.
>
> In the past (pre-git), anyone with SVN write access could commit changes, and did so, particularly if the changes were trivial. We no longer have that kind of universal access.
>
>> If a library author is unresponsive, through what mechanism can we
>> prevent that library from rotting?
>
> If a maintainer is unresponsive for an extended period, despite contact attempts through the list, private e-mail, and any other means at the community's disposal, then we can declare the library orphaned and assign a new maintainer. Until that time, you're stuck.

So for a one line fix to the failing test(s) we should have to jump all 
the way to orphaned status and find somebody willing to maintain the 
entire library for the foreseeable future?  Is that a process that seems 
workable to you?

>> Through what mechanism can we
>> prevent that library from breaking other libraries that depend on it?
>
> There is no mechanism for that yet, in the git era, so far as I know.

I'm not sure I understand.  Limiting or not write permission to a 
submodule to a particular set of maintainers seems to be entirely under 
Boosts control.

>> The answer must be to grant write access to the CMT for that library
>> for the purpose of maintenance.
>
> That conclusion is required.
>
>> How do we define unresponsive?
>
> We have procedures for that. They're on the web site.

Perhaps, I can't find it.  Google-fu fail on my part.

>> Even if a temporarily unresponsive author reappears on the scene and
>> dislikes the changes, we have version control.  They can undo those
>> changes and reimplement them themselves.
>
> No! If changes are committed, they may be released, so users may adjust to them. If the maintainer dislikes the changes and reverts or alerts them, users may be forced to change their code again.

This clearly doesn't apply when the tests all fail because the build 
system doesn't express a dependency.

> I understand that you're frustrated but we must first contact the maintainers and give them a chance to respond. It may be that we need to encourage them to take on co-maintainers to assist. We've done that in the past, too.

It's probably my fault for setting the wrong tone with my posts so far, 
but I was hoping to have a discussion about what changes to existing 
policies would be needed for it to be possible for the CMT to achieve 
its goals.  I guess I just came across wrong.

Ben