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: 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?

Hi,

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.