Re: [boost] Community Maintenance Team and neglected libraries
On 4/22/2014 12:29 PM, Ben Pope wrote:
These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved.
On Wednesday, April 23, 2014 04:08 AM, Edward Diener 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. 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. Can I ever commit that change to master? Must I really go through a several-version deprecation procedure for every change that could possible break any other library? If a library author is unresponsive, through what mechanism can we prevent that library from rotting? Through what mechanism can we prevent that library from breaking other libraries that depend on it? Through what mechanism can we prevent that library from holding back the improvement of other libraries? The answer must be to grant write access to the CMT for that library for the purpose of maintenance. How do we define unresponsive? How big a change should be allowed? 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. That sounds like a small and entirely reasonable cost for having been unresponsive. The advantage is that whilst they were away, their library compiled, the test matrix was clean, libraries that depend on that library continue to build, libraries that that library depends on can be changed. The rest of Boost can continue in the absence of that author. Ben
On April 22, 2014 10:46:55 PM EDT, Ben Pope <benpope81@gmail.com> wrote:
That barrier is also a hallmark of Boost: the library maintainer has ownership until another maintainer is assigned.
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.
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.
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.
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. 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. ___ Rob (Sent from my portable computation engine)
On Wednesday, April 23, 2014 05:17 PM, Rob Stewart wrote:
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?
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.
Perhaps, I can't find it. Google-fu fail on my part.
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
On April 23, 2014 7:36:31 AM EDT, Ben Pope <benpope81@gmail.com> wrote:
It can also be crazy if various people start submitting changes to a library that the maintainer hasn't vetted.
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).
Honoring the maintainer's ownership is appropriate. We expect more responsiveness than you imply. When that isn't the case, it indicates bigger problems.
We choose to leave that on the maintainer's control, at least so far.
I meant to write that conclusion is not the only possible one for the situation.
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.
Agreed
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)
On 30 Apr 2014 at 5:13, Rob Stewart wrote:
It should also be mentioned that being maintainer for a Boost library is a thankless, time consuming, financially unsustainable role with very little reward and an awful lot of grief. The fact anyone does it - let alone volunteers to do it - is surprising. Historically, one of the things granted to those willing to invest the considerable resources in acting as a maintainer is total and absolute control and discretion in all matters relating to maintaining that library. I think that is one of the few good reasons people volunteer to maintain - they get to enact their personal vision for a library. And that definitely means giving pause to "simple" bug fixes. As a quick example of why pondering and delaying applying bug fixes is important, I recently ripped out over 120 lines recently added to a major Boost library to fix a bug no one ever had a real problem with but which broke compilation on a major toolset. I replaced that code with 15 lines fixing the non-bug and restoring the ability to compile. The original patch was well intentioned and competently written, but was written more as C than C++ and spammed many source files with #ifdef's when a type with a call operator let the compiler switch implementation for you. It's small stuff like that which is important. I should add, if anyone has a problem with the slow pace of bug fixes being applied in Boost, they can feel absolutely free to volunteer to help a maintainer in general maintainance of a library. I am very sure that few maintainers will turn down high quality help. If you really need some bug fixed, try fixing ten bugs earlier in the submission queue, and I think you'll find that your bug will usually get seen to quicker. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Tue, Apr 22, 2014 at 8:46 PM, Ben Pope <benpope81@gmail.com> wrote:
The context of those goals is the libraries maintained by the CMT, not all Boost libraries. We are expanding the responsibility of the CMT to field queries about pull requests and eventually other maintenance requests where the library maintainer isn't responding, but we are certainly are not asking the CMT to get involved in libraries with active, responsive maintainers. --Beman
On Tue, Apr 22, 2014 at 2:08 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
Right.
Hopefully the developers who do have write access to these libraries will look at the issues involved.
Right, but what we are now saying is that if the maintainers for those libraries don't respond, the submitters can ask on the CMT mailing list ( http://lists.boost.org/mailman/listinfo.cgi/boost-maint) for a response. The CMT may concentrate on pull requests initially, but as they gear up then other forms of support requests will be dealt with by the CMT but only when there is no response from a library maintainer. --Beman
participants (5)
-
Beman Dawes -
Ben Pope -
Edward Diener -
Niall Douglas -
Rob Stewart