Boost logo

Boost :

Subject: Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-11-19 13:13:24

Andreas Huber wrote:
> According to the schedule, John Torjo's Log2 library will be reviewed
> soon (currently 3rd in the queue). There's another logging proposal by
> Andrey Semashev (currently 13th in the queue).
> It seems to me that these proposals are sufficiently close in
> functionality that only one of them should be accepted into Boost.
> Therefore, wouldn't it make sense to review both libraries in one
> (longer) formal review?


It's a shame I'm joining the discussion at this late stage. I'll try to
post my answers as original posts came.

First, I'm not against a dual review. Actually, some time ago I thought
it would be a good idea. However, I recognize that the undertaking for
the reviewers would double at least, so I fear that the quality of such
review would suffer. Potential reviewers may actually be pushed away by
the amount of work they would have to do, and I must say, my lib is
already quite scaled by itself. John's experience that he expressed
later in this thread seems to confirm it. On the other hand, if we have
two candidates, it would be strange not to compare them between each
other, at least in some informal way. I don't have a general solution to
this dilemma, but in case of logging we have users that have had
experience with both libraries. I would be most grateful if they
participated the review, whatever form the review may take.

Second, regarding the "duplicate" libraries in Boost. My opinion is that
we should avoid duplicates as much as reasonable. There are cases in
Boost when one library is a superset over the other, in terms of
features. I think, such duplications don't give much benefit to the
users and should not be encouraged. However, there are cases when one
library does something significantly better, while this particular
feature cannot be equivalently improved in its analogues. In this case
the library has a right to live side by side with other implementations.

The point of the review (or separate reviews) is to detect how much
overlap there is between the libraries and if there are applications
where one library performs significantly better than others. If library
A has its unique killer features that cannot be imported in library B
(which may be in review queue or in Boost already) then I don't see why
it should not be accepted.

Boost list run by bdawes at, gregod at, cpdaniel at, john at