Re: [boost] Community Maintenance Team and neglected libraries

On April 23, 2014 7:36:31 AM EDT, Ben Pope wrote:

On Wednesday, April 23, 2014 05:17 PM, Rob Stewart wrote:

...

On April 22, 2014 10:46:55 PM EDT, Ben Pope 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)