Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Schrom, Brian T (brian.schrom_at_[hidden])
Date: 2010-03-22 12:43:20

David Abrahams wrote:
[snip]
>Vladimir Prus wrote:
>> 
>> 
>> Hello,
>> 
>> in a recent post, Dave listed a few things that he thinks are wrong 
>> with Boost development, at present, quoting:
>> 
>> 	I know I'm not the first person to notice that, as Boost has grown, it
>> 	has become harder and harder to manage, Subversion is getting slow,
>> 	our issue tracker is full to overflowing, and the release process is a
>> 	full-time job.
>> 
>> It seems to be important, right now, to discuss whether this problems 
>> are real, and what problems are most important.
>
>This is a great discussion to have; I encourage it for those that are so inclined.  
>IIUC, we're also going to have a talk about that topic from Robert Ramey at BoostCon.  
>If you don't see me participating this time around, don't take it as a lack of 
>support or interest-it's only because I'm too busy working on (partial) solutions 
>to the problems-as-I-see-them and having them ready for BoostCon.

[snip]

[1]
As a Boost user, I primarily expect libraries in Boost are ones that are
being proposed, developed, or tested for possible inclusion into a
future C++ Standard.  To me, this means that the API will be
continuously changing and refined as the libraries receive review and
feedback on their use.  This is what I get from the vision statement and am
grateful that the authors allow me to use their exceptionally high
quality libraries in my own projects.

I use these libraries at my own risk, my own maintenance, my own
quality control, etc.  (and hopefully, I report my results back to them.)

This is my understanding from the Boost vision statement and the origins
of Boost.  I think that Boost.Threads and the locking libraries are
excellent examples of this evolutionary process.  I thought that
providing an early adopter TR1 implementation was quite appropriate
too.

However, because of a few outstanding libraries (serialization, lexical,
gil, soci, etc), I've started to like to use / depend on Boost libraries
whenever I can because Boost libraries are usually very efficient and
well thought out and support generic programming (and already part of my
build tree).  I think there is another category of libraries that are
very useful, but realistically, will never be considered for inclusion
into a C++ standard.  A question is whether Boost should host these
libraries or not.

In a nutshell, I believe that the Boost Vision statement needs to be
revisited and determine what Boost is.  To me, it seems to have wandered
a bit away from it's originally established goals.  If I could have my
cake and eat it too, I would like to see Boost divided into three
subprojects:  1)  Research and development of C++ Standards and
libraries, 2)  Repository for complementary (and integrated) but non
standards bound libraries, and 3) sandbox projects.  Within 1 and 2,
there should be unstable, testing, and stable libraries.  I believe this
would set user's expectations appropriately.

BoostBuild is a tremendous tool and I would be very sad to see it get
totally replaced by a Make based system.  To me, the greatest problem
with BoostBuild is lack of user education, and that from lacking the right
obviously accessible documentation.  When BoostBuild works, it is magic
and it works great.  When it doesn't, you're committed to multiple hours
of pouring through Jamfiles and Googling.  After you've done that a few
times and figured things out, you only spend minutes when things blow
up...  Someone said, "Using Unix/Linux is easy, learning it is hard."  I
think the same applies to C++ and to Boost Build.  Once you learn it, you
have versatile and problem solving tools.

I'm quite excited by the Ryppl page and development.  I'm anxiously
following it's development and waiting for the testing candidate.