Re: The Future of Boost - deprecating libraries

From: Daniele Lupo (jepessen_at_[hidden])
Date: 2023-05-09 09:51:23

Hi from a lurker.

Just my two cents about deprecation:

I totally agree with deprecation: some libraries are basically not used 
anymore because they were included in the standard libraries, or because 
there are better alternatives. Removing them means more focusing on more 
useful libraries. If a software is stuck with a very old library, they 
will continue to use that version of boost. It's simple. At least it 
should be possible to create a bugfix release if needed (i.e. 1.80.1 if 
the library is removed in 1.81).

It's necessary anyway to set some rule about deprecation, so users can 
handle them properly. The main rule in my opinion is to define the 
number of releases between the deprecation and the deletion of the 
library from boost. I.e. it's possible to say that when a library is 
deprecated, it will be removed from three to five future releases. This 
gives the users a clear view on the future use of that library: "I'm 
finishing the project in six months, so it's ok to continue to use it", 
or "The project will last for three years, maybe is better to remove it 
and find an alternative". I've seen projects that are stucks to very old 
libraries because the were not well organized about deprecation for lack 
of information about them, and then libraries will be removed without 
any warning and people was not able to organize the code to handle the 
deletion of that library in time.

Also, when a library will be deprecated, at least other two information 
will be needed:

* The reason (lack of maintenance, alternatives in modern c++ etc).
* At least one alternative to the library, if any (i.e. use std::thread 
instead of boost::thread).

This will give to us the needed information to handle the deprecated 
library that we are using in our projects.

I don't agree with "zombies" libraries. If a library is deprecated, 
should be deprecated also for boost developers. If you want to remove it 
also boost libraries that use that should be updated as well. If not, 
there's no reason to deprecate a library since it will continue to be 
used. Boost developers can use the deprecation time range defined before 
to organize the switch in order to remove that dependency. If it's not 
possible for any reason, the library should not be deprecated.

Unmantained libraries are also dangerous. If you continue to ship a 
unmaintained library, is possible to find a bug that will last for much 
time, and there's the risk that boost will not be seen as stable as they 
usually are. No library should be marked as "unmaintained": if noone can 
handle it maybe it's better to think to deprecate it (usually a 
unmaintained library is a old one in my experience), or it's better to 
maintain a public bug tracking system in the main site, so everyone can 
contribute with a patch if he wants (also the bugs that are present in a 
specific release should be notified in the changelog).

During the boost development then you can take an eye to the bug 
tracking system, and maybe sometime it's better to stop the development 
of new libraries and features, and focus the effort on a bugfixing 
release. I don't expect that there will be many bugs, because there are 
very few of them at the moment, but there must be a specific time during 
development in which you should decide about what to do on that dozen of 
bugs in "unmaintained" libraries, that no one will fix because there are 
no maintainers.

This is only my point of view. I hope it can help.

Regards

Daniele Lupo

On 08/05/2023 20:15, John Maddock via Boost wrote:
>
>> 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.
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost