Boost logo

Boost :

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


On Thursday 31 October 2013 12:20:03 Niall Douglas wrote:
> On 31 Oct 2013 at 2:08, Ahmed Charles wrote:
> > I'm personally on the fence about this policy. I see some library
> > authors that are responsive and reasonable with their library and I
> > wouldn't want to disenfranchise them one bit. But I also see that it can
> > create an 'old guard' sort of situation that benefits no one. With power
> > should come responsibility and there should be a mechanism that ensures
> > that libraries that stagnate are given new maintainers. I understand
> > that there is a shortage of people signing up to maintain libraries, but
> > I think at least part of that is due to the impression that libraries
> > are only ever 'pried from the hands of their dead maintainers'.
>
> I am personally strongly in favour of libraries getting deprecated
> and removed from releases if they are not maintained - let's say no
> bug fixes by its maintainer in two major release cycles adds them to
> the list of soon to be deprecated libraries, and no bug fixes by its
> maintainer in three major release cycles has them removed from Boost
> central and put into an attic. That encourages new maintainers to
> step forwards, and old maintainers to give up their control if they
> can't keep up due to life commitments.
>
> It would require some political bravery from the SC though, as users
> will get upset. I would also personally count lack of adding direct
> C++11 support as equal to lack of bug fixing, but I appreciate that
> will be controversial (what is C++11 support anyway???) :)

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. 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. Release managers are annoyed by having to watch if a
given library has reached its "inactivity timeout".


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk