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: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-11-18 21:10:51

Hi Phil,

> Fernando Cacciola wrote:
>> Hi Phil,
>>>
>>> In the review result announcement, Fernando listed many of my minor 
>>> complaints about the library but did not address this suggestion, or 
>>> the existence of GGL "in the wings", at all.
>>>
>> You are correct... as I said in another post I really intended to 
>> address all objections but as GGL review started I had to compromise.
> 
> I understand.  I posted that comment primarily in reply to John 
> Phillips' claim that "[we] were also all quite conscious of the 
> existence of GGL. This existence was not considered a show stopper in 
> any of the reviews posted".
> 
OK

>> So, FWIW, I totally agreed with Luke's own response to your 
>> suggestion: that there is absolutely no need to reject Boost.Polygon 
>> as a mean to make sure GGL has a chance to be accepted.
>>
>> The one thing that I could not state on my results is this: I had 
>> followed GGL from the begging, as I did GTL, and I know enough of both 
>> to be certain that both *can* coexist within Boost, even in spite of 
>> their high impedance in some region of the fundamental base level.
> 
> I'm not sure what you mean by "high impedance"...
> 
I meant differences that are theoretically fixable but practically not quite 
without significant effort.

> 
> Yuk :-(
> 
> I would really like a single common set of basic concepts to code to.  

I think we all do.

> As I wrote in my GGL review, there are gratuitous differences in 
> terminology like "within" vs. "contains".  I have seen no discussion of 
> whether we think this should be fixed, can be fixed, will be fixed etc.  
> Let alone who should "cede ground" in order to arrive at a compromise, 
> or any technical discussion of how e.g. the point concepts could 
> inter-operate.
> 

OK, here is another bit of the rationale I intended to include in the results:

One of the things I considered when deciding on the Boost.Polygon results was 
the fact that the relative ordering of the reviews will neccesarily force GGL to 
adapat to Boost.Polygon.

IMNSHO, GGL *must* adapt now and remove all such gratuitous differences and keep 
its own version of things *only* when there is enough justification.

I do fully realized all this and considered the amount of additional work it 
requires for GGL. I also realized and considered that the requirement could be 
considered unfair.

However, I don't think it really is unfair because both libraries had coexisted 
in parallel for years, yet they never merged before.
Say I reject(ed) Polygon (GTL) then we accept GGL.  Do we accept Polgon later on 
and require *that one* to adapt? Or do we just loose GTL for good?

The way I saw it, the only way to make sure that the *community* would benefit 
from the best of both (and both have *great* things to offer) was to avoid 
rejection on the basis of future incompatibilities even at the expense of 
requiring the second comer to adapt back or rationally argue that Polygon should 
change so as to set the record that the incompatibility is considered to the 
Polygon's fault and justify that way the burden put on users.

Accepted libraries are not set on stone. Many have evolved a long way from the 
fist accepted version and I don't imagine Luke erroneously believing that, since 
his library was accepted first, he doesn't have to do corrections on the light 
of GGL and for the sake of the community.

If fairness is to be considered, I guess one could argue that the first one to 
had been ready deserved the right to set the reference. Specially if we consider 
that GGL was not ready for review when Polygon was, so it is not that they ended 
up with such a relative ordering due to arbitrary scheduling. That could have 
made the current GGL burden unfair, but it's not how it happened.

> Personally I'm totally unmotivated to contribute to "Boost.Geometry" if 
> I have to either do everything twice or gamble on which one is going to 
> "win" in the end.
> 
Of course, but rejecting one of the libraries is not neccessarily the best way 
to avoid ending up with competing choices. Sometimes, getting cooperation 
rolling requires a small push.

> I would really like to see some discussion of this before this review 
> ends, though sadly I will be going away tomorrow and may not be able to 
> take part in much of the remaining discussion.
> 
> Changing the subject slightly, I have also wondered over the last few 
> days about acceptance criteria.  Many of Barend's emails mention things 
> that have not yet been implemented or are planned.  I wonder whether we 
> are, or should be, judging the library in terms of what has been 
> submitted for review, or what we believe that the authors will 
> eventually deliver?  Based on previous proposals where "fully formed" 
> libraries have been presented, and some comments from review managers / 
> wizards(?) that "the library being reviewed is the one submitted", I 
> have always assumed the former.  In this case, I think that some 
> reviewers are assuming the latter.
> 
FWIW I definitely accepted Boost.Polygon on the basis of what it is *now*, not 
what it could become. Yet at the same time, I also considered how, IMO, things 
would make sense to play out with GGL in the future, which I just outlined above.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com