Phil Endecott wrote:
John Phillips wrote:
Jose wrote:
The community objective is to get a generic library were multiple authors can eventually contribute their algorithms, like Boost BGL or the competing CGAL. This situation is one of the cases were cooperating is justified and worthwhile for everybody.
I don't recall a single reviewer stating the ability of multiple authors to contribute algorithms as an objective for them.
Well I ceartainly do, but didn't think that it was necessary to explicitly state this. Boost is an open source project after all, and - at least IMHO - "multiple authors contributing" is what open source is all about.
I may be forgetting something, so please point me to it in the archives if so. If not, then I do not consider this a community objective. Historically, I see no evidence for it as a standard Boost concern, either. Again, please correct me if I'm missing something.
I agree that this openness to contributions is not something that often happens in Boost libraries,
This is certainly true, but I always thought that this is just an unfortunate side effect of the strong library ownership and the general boost process, but not a explicit goal. I cannot state this strongly enough, but I believe that boost should go out of its way to foster contributions, since this is the heart and soul of great open source projects.
" In view of all this, I suggest that this library should be rejected for now. This will tell Barend that he still has an opportunity to present his library for review, and that it will be considered on a level playing field. If Barend's library is reviewed and found to be more complete, more performant and at least as usable as this library, then it should be accepted. On the other hand, if Barend's library is found to be deficient in some way (or is not submitted for review), then Luke will have an opportunity to resubmit an updated version of this library, which I anticipate should be accepted. "
For me the completeness argument is the most important. I didn't submit a review for boost.polygon because I wasn't particular interested in it as all prior communication already hinted that it would only do 2d with a focus towards VLSI, and that another library with much more interessting scope was about to be reviewed. I assumed that there would be some discussion on which library would be included or how they can be merged before final acceptance, like there was for threading (wrong thinking on my part, obviously, so no one to blame but myself). Quote from John Philips:
How are we supposed to determine whether the correct way to solve a broad problem is a single library that tries to satisfy everyone, or a few different libraries that are more focused on specific tasks?
Someone (IMO the Review Manager) should rise this exact question. This could even be a Question in the default "Review Questionnaire" (i.e. Is this library broad enough in scope / is it to broad? or something along this lines.) Regards Fabio