Re: The Future of Boost - deprecating libraries

From: John Maddock (jz.maddock_at_[hidden])
Date: 2023-05-08 18:08:14

> Stagnation
> * There are fewer new libraries proposed.
> * Formal reviews get less participation.
> * Review managers are typically scarce now.
> * The mailing list volume is thinning; younger folks don’t use lists.
> * There is no second order effect: new libraries rarely use Boost.
>
> Quality
> * Some libraries are unmaintained and create a negative user experience.
> * Users open issues, and no one replies to them.
> * Pull requests are submitted to abandoned repositories.
> * Scant financial resources for infrastructure or staff.

I think this is correct.  I have somewhat suggested this before (as 
others have suggested a Boost-2), and for various perfectly good reasons 
nothing has ever happened.

I think at this point we should be somewhat aggressive in deprecating 
and then removing libraries which are unmaintained and no longer up to 
scratch.  Call it a once in a decade spring clean ;)

So far I think we have only removed one library - one of mine (TR1) 
under my direction and even getting that done was a bit of a rigmarole 
as I remember :(

So, how about something like this:

We have three categories:

"Deprecated" libraries are marked for removal at some specific future 
date in time.  This gives users/developers who care about those 
libraries time to step up to the plate and a) complain, and b) do some 
actual maintenance.  After deprecation, libraries that are actually 
removed go into a separate zip, probably on their own github page, and 
this is the last release they ever get.

"Zombie" libraries are deprecated, but are still used within Boost.  A 
good example would be static_assert, which should not now be used in new 
libraries, but may still be needed by existing code.  Zombie libraries 
would still be shipped with Boost, but their documentation would not be 
listed in our main index.  We might however, have a separate index for 
them just in case anyone still needs to find them.  Should we have a new 
Boost.Compat there could be quite a few of these in time.

"Unmaintained": speaks for itself, the library is important enough to 
keep around, but has no maintainer.  We need a procedure for acquiring 
new maintainers, but traditionally we've recruited from existing authors 
who are a small, and rather busy pool of people.  The alternative is to 
recruit from outside, but we often get enthusiastic, but not very 
experienced people coming forward. Getting them to submit PR's and 
having an experienced old hand check them through is very time consuming 
and unsatisfactory for both parties.  So how about this: anyone that 
wants to step up and enhance/maintain an unmaintained library can do so 
- *in their own fork of the github repro* - then when they're ready for 
a release, they ask for something akin to a mini-review - if it's 
positive they get to merge to Boost and become an official maintainer, 
if not they get feedback on what they need to change.  Who knows, maybe 
this will even stimulate some discussion and innovation again as well as 
bringing in new blood?

Just thinking out loud here, John.