On Tue, Nov 17, 2009 at 5:11 PM, John Phillips <phillips@mps.ohio-state.edu> wrote:
Ok, It's a solution, maybe not the best one but I lack the in-depth expertise judge.
I find this comment a little confusing and possibly frustrating. Maybe I'm misunderstanding it so correct me if needed. However, this reads as you saying that you lack the in depth knowledge to know if Fernando made a good decision in accepting the Polygon library. If so, why in the world have you said several times that his decision should be overturned? I would think such a statement can only be made if the person making it has clear technical reasons to back up the assertion.
I missed the to in "expertise TO judge". I mean in technical in-depth experience which is fundamentally important. On the other side, I gave 5 reasons and could give more why the review was flawed (and some people that voted yes to GTL added further comments). The reasons are in the separate thread GTL vs GGL - rationale. I questioned the whole planning of the review and the fact that a combined library should be possible (and the GGL authors actually wanted to make it possible). Also, if you check my replies to Luc, the scope of GTL and the name were changed just before the review, which is ok in general but not ok given that a broader library, with great overlap would be reviewed soon after the first review. Zachary Turner answer at the beginning of this thread summarizes it nicely ----------------------------------------------------------------------------------------- Now we are in the unfortunate situation of either a) having 2 libraries that have massive overlap but each providing something unique, b) withdrawing a library that has already been accepted (although in reality this won't happen), or c) rejecting a library which, if compared directly against the other library may have been preferable if users had initially been asked to choose only one. ------------------------------------------------------------------------------------------ And I agree with him on the "(although in reality this won't happen)" and I think it should happen, because it sets a really bad precedent and I only blame the review policy and the schedule.
First, as I pointed out elsewhere, I did read the reviews and there were some strong opinions both for and against the library. The basis for making a good decision in such a case is an understanding of the technical details and the use cases, combined with careful consideration. If you wish to argue that the decision was wrong, then use these as the basis of your discussion. If you make a good argument of this sort, then you might even get what you want.
Well, I think the points are above and there are technical issues but fundamentally it boils down to a process flaw. Both library authors and Fernando are really experienced in their domain and I am not questioning that. I am saying that this is a broad field like Graphs, Networking or Graphics and does require some coordination, specially when multiple authors want to contribute, but it didn't happen !
However, in my own experience as a review manager I can tell you that there are sometimes very strongly held opinions in reviews that are simply technically wrong. So, just having a strong opinion against the library is not a good argument to overturn the review. (This should not be read to imply that the opinions against Polygon were technically wrong. I have not put the work into the technical details to have an opinion on that.)
Sure, but I don't think this is a list were people are fooled by technically wrong arguments. One piece of evidence in reviews is benchmarks, you publish them and publish the code to run the benchmarks, and the benchmark could still be flawed if nobody cares to check them and run them but it's better that statements about what a library does. Another key piece of evidence is code examples, so you can understand the application domain, what the library does and how it does it. In my own review of GGL I pointed out that the library major design weakness was to address the robustness issues.
You have stated many times that the Wizards (Ron and I) could have canceled the Polygon review. No, we could not unless we can travel backward in time. The review for Polygon ran from late August to early September. At the time of the review, it was the only geometry library that had been submitted for review. Barend had posted many times on the list about the library he was working on and it produced many lively discussions, but the library had not been submitted for review.
Don't want to be unfair with my comments and are not specific to the Wizards but to a process flaw. My argument is that Boost aims for well designed generic libraries (among other things), and there are at least two competent/expert authors in their respective application domains that want to propose a library and for several years they have been advancing/iterating with more or less input from the community but still as separate libraries (everything is ok at this point although it probably would have been better to cooperate - in this case) and then: - the generic library completely changes the scope (reduces to specific algorithms), has a non-consensus review and is accepted (and this would also be ok if there weren't an involvement by the community to achieve a generic library that covers the 2D geometry and that can probably incorporate all the algorithms). This is what's not logical or good! I see three types of libraries: 1) Technically superior or high quality solutions that provide a specific benefit - This includes early Boost libraries that even end up contributing to the standard library 2) Multiple approaches make sense - This makes sense for some language paradigms (Lambda-Phoenix, Spiriti-Spirit II, ...) 3) Generic libraries useful across multiple application domains (the current case) .... Graphs - BGL Networking - asio Images - GIL Geometry - GGL .... Goals: generality, performance, flexibility, extensibility to multiple application domains, compatibility The important point in most libraries in the third group is to actually have a set up where people can contribute algorithms and the library can evolve. It's also key to look at competing libraries !! CGAL, which is focused on computational geometry, and Fernando knows well, ends his philosophy page with this text that is interesting. http://www.cgal.org/philosophy.html -------------------------------------------------- Beyond Robustness Let us conclude by pointing out that guaranteed robustness is not the only (but probably the most important) aspect in which CGAL makes a difference. Another major feature of CGAL is its flexibility. CGAL closely follows the generic programming approach of the C++ Standard Template Library. This for example means that you can feed most CGAL algorithms with your own data: instead of converting them to some CGAL format, you can adapt the algorithm to work directly with your data. Last but not least, CGAL's range of functionality is by now very large, and it's still growing. CGAL offers solutions for almost all basic (and a lot of advanced) problems in computational geometry. CGAL is an open source project with a large number of developers (eventually, you might become one of them). Many of us have tight connections to computational geometry research, and to application domains that involve geometric computing. It is this combination of expertise that we believe makes CGAL unique.