Re: [boost] Community Maintenance Team and neglected libraries

Subject: Re: [boost] Community Maintenance Team and neglected libraries
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-04-30 05:13:34

On April 23, 2014 7:36:31 AM EDT, Ben Pope <benpope81_at_[hidden]> wrote:
>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.

It can also be crazy if various people start submitting changes to a library that the maintainer hasn't vetted.

>> 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.

A maintainer can open write access to others, but Boost doesn't do that when the maintainer is still accessible (even if slow to respond).

>>> 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?

Honoring the maintainer's ownership is appropriate. We expect more responsiveness than you imply. When that isn't the case, it indicates bigger problems.

>>> 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.

We choose to leave that on the maintainer's control, at least so far.

>>> The answer must be to grant write access to the CMT for that library
>>> for the purpose of maintenance.
>>
>> That conclusion is required.

I meant to write that conclusion is not the only possible one for the situation.

>>> 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.

http://www.boost.org/development/submissions.html#Lifecycle covers the notion of what we expect of maintainers. There have been past discussions about specific libraries and the actions taken, though we apparently didn't capture the process.

>>> 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
>alters 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.

Agreed

>> 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.

The CMT was formed to take ownership of orphaned libraries, not to fix issues in the rest, unless I'm much mistaken.

___
Rob

(Sent from my portable computation engine)