Re: [boost] [future] @Tom -> review result?

Subject: Re: [boost] [future] @Tom -> review result?
From: Johannes Brunen (JBrunen_at_[hidden])
Date: 2009-02-13 05:16:46

Hello Tom,

"Tom Brinkman" <reportbase_at_[hidden]> schrieb im Newsbeitrag 
news:30f04db60902121513m2a7f9953nbd6d4a0a23dbc56d_at_mail.gmail.com...
> In fact, most utility libraries are added to boost by slipping them
> into other boost libraries.

Maybe, but it is unfortunate, isn't it? If I build a skyscraper, I start at 
the bottom not at the top.

> There is a certain priviledge to being a top-level boost library.
> It needs to be reserved for libraries that have received the
> appropriate amount of peer review.
> That cleary did not occur here.

But that is the whole point of this review. We like to see one future 
library part of boost. And Vicente (if I understand correctly) likes to 
build on such a foundation.

>
> I agree that if a "review" does not generate enough reviews, than it
> should be scheduled again, with refined
> review criteria to attract more reviewers the next time.  That is how
> I am inclined to proceed.
>

Maybe we should discuss openly the review criteria first?
One danger I can see is to lose attention in such a process. Better is to 
define the criteria at the edge the first time.

> Adding concurrent programming libraries to boost without lots and lots
> of peer review is a mistake.  It is an extremely
> difficult subject.

Yes and no. Yes is is not good, IMHO, if we have a multitude of similar 
libraries or of libraries with imperfect interfaces. No, however, I do think 
that we should not aim for the holy grail interface for a particular 
library. This is the business of the standard committee (smiling). 
Interfaces could/should evolve over time and gained experiences. We see lots 
of examples for this in boost.

One last sentence, we should not forget that the interface of the future 
library has already gone through the standard committe. This does set the 
criteria into quite a different perspective.

Best,
Johannes