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