Boost logo

Boost :

Subject: Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-02 12:26:40


On 03/02/2010 12:18 AM, Gennadiy Rozental wrote:
>
>> I understand, and last thing I would've wanted in this area is being
>> hasty. But that doesn't change the shape of things - the standard is
>> way behind modern tendencies and technologies that are needed on a
>> daily basis. IMHO, by the time C++1x is out, it will be outdated already.
>
> Somehow I do not agree. It will take good several years at best for the
> new features to be implemented and even more to properly being used in
> users' code. On the other hand it depends on what you mean by "modern
> tendencies". Maybe it's good we are behind.

I did not mean the new features that will be standardized in C++1x. They
are great, I'm really anxious to get my hands on many of them. But
that's not enough. Dynamic/static modules, properties, network and
asynchronous IO in general, binary serialization (portable between
different architectures), XML support - for a start. Let alone the holy
grail of GUI, even the most basic one. These things are there for ages,
and they are needed almost all the time. I understand that there are
great libraries, including Boost, but every other library added to the
project adds complexity, which is not required with other languages. For
some things there are no libraries for there's just not enough language
support (modules, for instance).

>> If you want to base the accept/reject decision on practical experience
>> of the library users, then even 6 months is not enough. It becomes a
>> matter of years. But if that is the case I would suggest to drop
>> review practice altogether, at least in its current form. It would be
>> much more practical to follow the idea of separated Boost
>> distributions - the core libraries that were verified by time and
>> other, less mature libraries (perhaps, in individual packages).
>>
>> The barrier for a library to enter the "hall of fame" of core
>> libraries can be rather high, and may require X years of practical
>> usage and include a review. But that review should not be too long
>> since the library itself should be well known already. On the other
>> hand, in order for a library to become a newbie under Boost umbrella,
>> there should not be a requirement of a long usage in the fields. It
>> should be fairly quick and easy to put the library into Boost,
>> provided that formal requirements are met.
>
> IMO Boost.Log is one of those libraries which are rather difficult to do
> right. Primarily due to wast problem domain. This is general purpose
> library with huge variety of different applications with different
> priorities.
>
> IMO week is way below reasonable time to review the library like this. I
> may not hit the use case which is going to be showstopper for me well
> after the review ends.

I agree that Boost.Log in particular is a very large library, and a few
weeks are not enough to fully evaluate it. On the other hand, it is
enough to evaluate the approach and architecture, and overall
implementation quality without diving too much into details.

Like I said in my post, if you're trying to base your decision on the
real world practice with the library, even 6 months of review are not
enough. It becomes not a review, but an active (or not - depends on the
demand in that particular time frame) usage of the library, which is
being held in a hanging state. Other people in this conversation
suggested that the library should be frozen during the review period. Do
you expect an author to be willing to freeze the library for 6 months?
Let alone for years in order to collect real world experience, as you
suggest.

I understand and share your reasoning, but the solution you propose
doesn't look valid for me. It would be interesting to hear what you
think of the idea I expressed in my previous post - divide Boost into
stable core and experimental outskirts, with the accordingly matched
acceptance criteria.

>> I remember cases when a review manager was not able to conclude the
>> review results long after the review ended because he didn't have
>> enough time. It looks like shared/overlapping reviews will honor this
>> situation. I would prefer review managers to be dedicated to a single
>> subject at a time.
>
> This maybe be the case with one review per manager as well. Any person
> here can easily become busy for the period of month or so. And that's
> exactly my point.

Yes, but if the person has several review on his hands, the probability
of such situation gets higher.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk