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: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-11-18 20:26:22

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".

> 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 believe they can and should coexist because I don't think any of the libraries 
> is good enough at the realization of a truly generic common base, yet they offer 
> somewhat complementary views to it.
>
> I can picture a future where the *experience* of these two proposals being used 
> by many people with totally separate expectations and requirements will light 
> some insight into what it takes to have a really common and generic geometric 
> playground.

Yuk :-(

I would really like a single common set of basic concepts to code to.  
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.

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.

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.

Regards,  Phil.