On Thursday 31 October 2013 14:28:24 Niall Douglas wrote:
On 31 Oct 2013 at 22:13, Andrey Semashev wrote:
I do not see a single good thing in such approach. Developers get frustrated because they are forced to do something even if they don't have resources for it. "Go fix bugs right now or we flush your work to drain" doesn't sound like an encouragement to me.
No work gets flushed. It simply loses peer review approval and reenters sandbox, and therefore ceases to be an officially endorsed part of Boost. To reenter Boost, it can use the fast track peer review process rather than full peer review.
That basically means flushing. Do you know any major (or not) distribution that provides components from Boost sandbox? Do these components receive testing and review? Even if a library is unmaintained, it is still tested with the officially supported compilers, with the actual Boost and third party dependencies, if any. Should the breakage occur, it will eventually be fixed by some volunteer who probably uses the library and cares for it. That someone may not be prepared to become a maintainer, though.
Users get frustrated because the libraries they use disappear all of a sudden. And they may not be affected by the long standing bugs that no one fixes.
As a collection of libraries grows, eventually at some stage some pruning rules have to come into play. I wish we had more pruning in the ISO C++ standard for example, but hey it's hard enough adding things let alone removing them.
I see no need for that, at least not if Boost gets modularized.
Release managers are annoyed by having to watch if a given library has reached its "inactivity timeout".
This can be highly automated. A quick query of the issue tracker database will produce a useful shortlist. Automated emails could even be sent and another query to check if the maintainer does anything after an automated email.
I feel skeptical about such automated decision making systems. Anyway, I still don't see a single upside of this strategy. Rather than employing such a destructive approach, I'd suggest being more constructive and involved. If you have a favorite bug that you trip on every day for several years then go ahead and fix it. Suggest a patch and make it into Boost instead of slicing off the library and declare it a second class component. "Show me the code", as someone said [1]. [1] http://en.wikiquote.org/wiki/Linus_Torvalds