Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review

Subject: Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
From: Vladimir Batov (vladimir.batov_at_[hidden])
Date: 2009-11-19 22:44:34

> Tom Brinkman <reportbase <at> gmail.com> writes:
> ...
> It seems to me that you are trying to make boost into something its not.

>From my mole-hill I feel that Boost has long grown out of its
"academic/experimental" phase and went out to the masses. And the masses have
different priorities/interests. Like the public did not exactly appreciate
superior but "experimental" (late to the market with no sufficient support
base) Betamax and favored VHS. 

> Boost has never been in the business of picking the best
> library in a particular domain.  

Like it or not I do not believe it is how Boost is seen at large. Boost is
known and valued for the high quality of its code. And the existing
peer-review processes make sure it is continued tradition. Ultimately, a Boost
library is the choice second only to the std. library. I.e. regardless if
Boost has or has not been in the "business", the users made the choice that
it is.

> Its a place where promising
> libraries can live for a while, get used, and inspire new ideas and
> approaches.  Some of these might make into the c++ standard.

Yes, it might well be how Boost started. However, IMO it has outgrown this
vision years ago. If at large Boost was still considered an experimental
playground for brainiacs (in good sense), then no commercial project would
get close touching it. Instead countless number of commercial projects bet
their money on Boost, i.e. its continued presence, relevance, quality,
support, etc. (all the "boring" stuff that academic proof-of-concept projects
can often afford not to be concerned with).

> Ten years from now, its highly likely that boost will become too large
> to manage.

IMO it is already. However, it is still quite well managed and that allows
people to deliver their commercial products with only Boost subsets.

> People will eventually start asking to distribute boost in parts, where
> the "core" libraries are separated from the "experimental" libraries.

Isn't it already the case? Just put yourself into the shoes of a project
manager facing overruns, deadlines, etc. I -- an excited s/w eng. -- come
over and say -- there is a library that does what we want. Your first
questions will be 1) quality? 2) will the lib. around long enough? 3) will
the interface be stable enough? 4) etc.

In that setting I suspect you'll steer clear from anything
"inspirational-only".

> For boost to remain popular and successful, this issue will eventually
> have to be addressed.  Fortunately, it probably does not need to be
> addressed for a few years.

I'll probably have to disagree. I'd be more likely leaning towards
"addressed now".

All IMO of course,
V.