Re: [boost] A bike shed (any colour will do) on greener grass...

Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-10-31 18:12:29

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