Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Jose (jmalv04_at_[hidden])
Date: 2009-11-17 13:35:55

On Tue, Nov 17, 2009 at 5:11 PM, John Phillips
<phillips_at_[hidden]> 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.