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.