Re: [boost] Community Maintenance Team and neglected libraries
On 4/22/2014 12:29 PM, Ben Pope wrote:
In case you haven't heard of the CMT: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
I'm also interested in getting the test results less yellow and more green, I don't have a lot of time, I'm sure I'm not alone.
There are quite a few places where the library code is probably fine, but the failure is in the test itself, the fix is often simple and uncontroversial.
Without picking on any particular library or author, here are some examples:
* Link the tests with boost::system http://thread.gmane.org/gmane.comp.lib.boost.maint/92 * Merge existing fixes in develop to master http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 * Fight with casts http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 * Disambiguate a type https://svn.boost.org/trac/boost/ticket/9540
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:
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.
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:
On Wednesday, April 23, 2014 04:08 AM, Edward Diener wrote:
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.
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.
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.
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. 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:
On April 22, 2014 10:46:55 PM EDT, Ben Pope <benpope81@gmail.com> 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
On April 23, 2014 7:36:31 AM EDT, Ben Pope <benpope81@gmail.com> wrote:
On Wednesday, April 23, 2014 05:17 PM, Rob Stewart wrote:
On April 22, 2014 10:46:55 PM EDT, Ben Pope <benpope81@gmail.com> 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)
On 30 Apr 2014 at 5:13, Rob Stewart wrote:
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.
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:
On Wednesday, April 23, 2014 04:08 AM, Edward Diener wrote:
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.
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.
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:
On 4/22/2014 12:29 PM, Ben Pope wrote:
In case you haven't heard of the CMT: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance
I'm also interested in getting the test results less yellow and more green, I don't have a lot of time, I'm sure I'm not alone.
There are quite a few places where the library code is probably fine, but the failure is in the test itself, the fix is often simple and uncontroversial.
Without picking on any particular library or author, here are some examples:
* Link the tests with boost::system http://thread.gmane.org/gmane.comp.lib.boost.maint/92 * Merge existing fixes in develop to master http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 * Fight with casts http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 * Disambiguate a type https://svn.boost.org/trac/boost/ticket/9540
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.
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