Re: Build Boost Back Better

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-04-05 08:17:15

I have no answers, but maybe some things to highlight:

* We've written a lot of stuff, it's mostly well written, sometimes even 
maintained, but the point is we haven't left many obvious "holes" to 
fill, especially holes that could be filled by newcomers.

To pick a random example, type-traits used to generate a steady flow of 
"what about this trait" or "what about this compiler workaround" 
messages.  In the great scheme of things these were not earth shattering 
requests, but they were actually great for getting people engaged, and 
allowing new participants the opportunity to cut their teeth on a tricky 
problem.  Better compilers (no more SFINAE workarounds - yeh!!) and a 
pretty comprehensive set of traits means those kinds of messages just 
don't show up anymore.  This is great for library maintenance, but 
rubbish for group-cohesion.

* "Balkanization" of Boost: For most of the stuff I maintain, messages 
go straight to Github as either PR's or Issues, and discussion takes 
place there.  Now don't get me wrong... I actually like Github's 
workflow, but it does mean that unless you're interested in say Math or 
Multiprecision and choose to follow the issues there, the discussion all 
takes place in our own little group.

* In relation to the above - *everyone* has something to contribute to 
*every* library - let me give you an example - some of Math's 
contributors are keen to explore C++20 modules, the question is, how on 
earth do we go about it and maintain a single code base, plus first 
class module support and backwards compatible headers?   It's something 
that needs a Boost-wide discussion and maybe some guidance and 
experimentation.

Maybe we need a list of open questions - some would relate to new 
compiler features - concepts and modules spring to mind, some would 
relate to missing libraries.

BTW I'm neutral on the whole message-board vs mailing list issue.... to 
me the medium isn't necessarily the problem.

John.