Re: [boost] [Review][PQS] Concept names?

From: David Greene (greened_at_[hidden])
Date: 2006-06-09 17:57:48

Carlo Wood wrote:
> On Fri, Jun 09, 2006 at 12:13:39PM -0500, David Greene wrote:
> 
>>That said, I very much want to encourage further work on this library.
>>It _is_ very important.  I'm disappointed that Andy does not seem
>>committed to it.  The volume of feedback indicates that there's a
>>lot of interest.
> 
> It is very hard for a volunteer to put a life-time of work into
> a library when he doesn't even know whether or not it will be accepted.

Not every library in Boost has been accepted the first go-'round.
Many prominent libraries such as Serialization had to iterate.

> I've followed the review of PQS with great interest, and was
> amazed by Andy's patience and politeness. Yet, the end result of
> the review is a list of things that are "wrong" with the "currently
> unusable library". No wonder that he wisely thinks: I'm wasting
> my time here. I think it's smart to bail out before wasting MORE time.

Every single message I've seen that points out needed changes has
included specific criteria the author wants improved.  I don't
know how it can get more constructive than that.

All of the messages have encouraged further work on the library,
noting that it is a very important domain to cover.  I have said
this multiple times.

> Here is how I think that a review procedure could be improved:
> 1) It should be devided into at least five votes:
>    A. Is the concept ok? Do we want SUCH a library in boost?

It's pretty clear that the consensus for pqs is "yes."

>    B. Is the presented library a good starting point, or do
>       we think we should start from scratch?

Here it's a little harder to tell.  From what Any has said, it
sounds like the changes can be accommodated without starting
over.  A reviewer often doesn't have the context to make such
as determination.

>    C. Is the presented API of the library on the right track?

There have been some disagreements on this for pqs but again,
people have been very clear about what they're looking for.

>    D. Is the internal implementation on the right track?

Ditto.

>    E. Is the documentation good enough for a boost library?

This has been made very clear and Andy has graciously accepted
the suggested documentation changes.

> 2) If the answer is NO to any of the above questions,
>    then either it should be accompanied with a constructive
>    list of improvements (if *this* was added/there THEN I
>    would vote yes), or the vote shouldn't be counted.
>    Then the author has something to work with.

Every single official review for pqs (and alomst all non-official
reviews) has included exactly these items.  Boost reviewers are
very specific.  Sometimes that's taken as excessive criticism, but
it's not meant to be.  As Dave A. said, it's much better to get a
clear "no" with detailed explanations than a "yes" with vague
statements about areas of improvement.

>    Such a procedure would be a motivation: if I continue
>    to work on it, and add this, improve that, change this,
>    then it WILL be accepted.

I stated such things in my review, as did others.

> 3) A library should be accepted as soon as it is "good enough".
>    Nothing motivates a volunteer open source coder more than
>    having their code already in the CVS repository and starting
>    to build a userbase. 
>    If a library is added when it's at 80%, then you can almost
>    be SURE that as a result the author will carry it to 99% all
>    by himself with needing any 'pressure' from others.

The question, of course, is what is "good enough."  In my view,
pqs is not yet quite "good enough" because it's missing some
important basic functionality.  Andy indicates that it can be
added without starting over.  I'd like to see a little progress
toward that before accepting pqs into Boost.  As I told Andy in
another post, it doesn't have to be a complete implementation
of everything (other unit systems, etc.).  But it does have to
contain the foundation to complete the work.

Oleg has some very good ideas about separating units from
dimensional analysis that are worth considering.  This might
require a more fundamental change to the library.  I actually
prefer pqs' user interface to Oleg's, but some sort of hybrid
might be very interesting indeed.

                           -Dave