Boost logo

Boost :

Subject: Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: John Phillips (phillips_at_[hidden])
Date: 2009-11-16 15:02:35

Jose wrote:
> I propose these 3 changes (starting with the word ADD: below) to the
> current review policy in
> I realize that there is no mention to the word "vote" in the review
> policy, just "review comments". See message below for rationale on why
> these may be good changes.
> ...
> regards
> jose

   As promised, a reply with my personal opinions.

   I think the discretion of the review manager is an important
component in the process. In some of the reviews I have managed or
participated in there are examples of objections that I consider
invalid. Part of the job of the manager is to understand that and weigh
the review with it in mind. This is part of why the policy refers to the
comments instead of to votes. If the only issue were counting votes,
there would be no need for a manager at all. Anyone who wants to can
look at the discussion thread and count the votes, after all.

   I also don't think Boost is a good place for centralized design
decisions. Our goal is to promote creative and innovative solutions from
across the community and to assure certain quality standards are met by
them. If Boost decided as a group that we needed a recursive descent
parser and because there are many possibilities already in existence
that we needed to decide the allowed design before allowing a review,
then it is unlikely that the design of Spirit would have been chosen.
Even if it was, the later work to create Spirit 2 would then have needed
further community discussion. I personally liked Spirit, and think
Spirit 2 is a substantial improvement so I think a process that makes
its development and inclusion unlikely is a mistake.

   As for whether the Polygon review decision was a mistake, I do not
think so. One of the things I do as a Wizard is monitor review
discussions. I think Fernando's result was a reasonable response to that
discussion when placed in the context of the expectations for the
library. It is not a complete solution to every geometry issue, but it
is a strong solution to some such problems and it is an established
solution for a respected collection of groups who use it. I'm not sure
if I would have made the same decision if I were running the review (I'm
really not sure. I have not spent the time thinking about the details to
form a strong opinion.), but I also lack Fernando's expertise in the
problem domain.

   I also do not think that the inclusion of Polygon in Boost should
then exclude GGL. They overlap, but do not have the same set of useful
cases. However, if GGL is also included I do have a preferred future
for the libraries. I would like the developers to work together to
answer the questions of whether a combination of the solutions that
applies across both domains (and hopefully even more) is feasible. This
will include looking at compile time efficiency, run time efficiency,
correctness, robustness, and quality of the abstractions. My hope is
that such a combination can learn important lessons from both designs
and from use by the Boost community to produce something better than
just the sum of the parts similar to what has been happening with Lambda
and Phoenix.

   I can imagine situations where the Wizards have to step in and set
aside a decision, but this is not one. (To my knowledge, this has not
happened to date.)

   Thanks again for starting this discussion and for everyones
participation in it.


Boost list run by bdawes at, gregod at, cpdaniel at, john at