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)