Re: [boost] Improving the Boost Review process

From: Jose (jmalv04_at_[hidden])
Date: 2006-04-21 12:05:18

On 4/21/06, David Abrahams <dave_at_[hidden]> wrote:
>
> Jose <jmalv04_at_[hidden]> writes:
> > 1. Have a priority list with the new libraries that boost users need
> >
> ----------------------------------------------------------------------------------------------
> > a) must have libraries
> > b) nice to have
> > c) interesting
> >
> > e.g. is Boost.SQL a nice to have or a must have ? is a Boost.Relational(
> e.g.
> > RTL-like) a nice to have or a must have ?
>
> And who's going to make those decisions?

This could be done via the list, assuming the criteria for making the
decisions is clearly stated. I take as rough Boost goals (from the home
page) as to develop libraries that: a) work well with the standard c++
library b) are widely useful c) establish "existing practice" and provide
reference implementations

So using these goals, all specialized libraries are in group c) as they are
by definition not widely useful. Also a Boost.SQL is widely useful but not
state of the art, so is probably a nice to have. The whole point of this
step is that once some list is available it is easier to encourage people to
identify what to work on (I am not trying to create the list here)

> > e.g. the current Property List library being reviewed:
> > - shouldn't it be part of the existing program options library (if its
> > intended usage is similar to program options library vs a generic tree
> > container) ?
>
> How is this related to library priority?
> How is this related to improving the review process ?

Sorry. This was stated in the wrong section. It meant to be in section 2 wrt
having a high level review. I think it would be easier to discuss first what
the library goals are or how it relates to other Boost libraries before
going into the detailed technical review. Also, more people can contribute
to the high level review but might not have time to go into the technical
review.

> This would help people working on related libraries to focus their

> > effort or even contribute when they were not planning to. Also,
> > review time will be optimized and the review queue can be
> > prioritized based on this list. The names can be proposed at this
> > stage so that they are general as intended.
> >
> > This could also help identify existing libraries that need to
> > evolve, like the ongoing effort in Boost.Threads
>
> How?

E.g. in the mailing list some people have previously identified shortcomings
(or new feature requests) in the Property Options lib. but now there is a
review for the PT library that has some overlap and also a broad feature
set. I am suggesting there should be a way to handle these tradeoffs

> 2. Have a high level review before a detailed review
> >
> --------------------------------------------------------------------------
>
> Everything you're proposing sounds like it adds more process, which
> can be extremely hard to manage and will probably slow things down.

 No, just have two mailing list threads, one that agrees on the goals,
relations to other libraries, ... and then go into the the normal review.
It's just hard to mix both high level and low level discussions and I think
many valuable contributors don't have the time to follow the high level
issues buried within the technical discussion

> a) Is the library in the priority list ?
>
> And what if it isn't?

1) It is not because we missed it, 2) it is not because it is a specialized
library  or 3) it is not b/c it shouldn't be If 1) or 2) then ok . The
priority list is not bureaucracy it is just a way to help others frame their
opinions

> b) Should it be a separate library or merge with an existing one ? There
> can
> > be lots of small libraries but many might not continue to evolve or be
> > world-class.
>
> The list is pretty self-regulating in this regard.  By the time a
> library comes up for formal review, there should have been plenty of
> discussion on the list already.  Have you read the process carefully?

I read it a while ago but you are right. Actually I am not an expert here, I
am
coming from the angle of a library user that wants more Boost libraries to
solve
a broader set of problems and not have to rely on corporate libraries.

> c) Is the library really world-class or broadly useful?
>
> That's the job of the review.  If we do that in the "high level
> review" what's the point in having the "detailed review?"

 Yes, but the current review is focused on just the technical merits, but
why not look at the libraries also from a competitive standpoint, i.e.
comparing more with other GNU and commercial ones (whenever possible).

Also, I find a library could be world-class design and implementation but it
is not "world-class" if is not tackling the right problems, even when using
state of the art techniques. Hard to explain this succintly

> The priority should be to add libraries that are designed with the
> > intent of becoming a world-class library (even if they offer limited
> > functionality when reviewed). The outcome of the high level review
> > should be whether to engage in a detailed review or wait till some
> > conditions are met.

How would this improve anything?

Many smart people are working on GNU libraries and some are willing
to change the license and go through a review but nobody is contacting
them b/c we are assuming that they have to request a review (and we
are not clear how prioritary is to add such library)

> 3. Encourage specialized libraries
> > -------------------------------------------------
>
> Who would do that encouraging, and how would he/she do it?
>
> > There are many libraries that have a smaller audience but if they
> > are designed to be world-class then they bring value to boost.
>
> Of couse.  They aren't discouraged today.

But they are not encouraged. (just from looking at the goals in the home
page)

> Also, there has to be a process so that libraries can continue to
> > evolve once they are part of boost, considering that in many cases
> > the original authors may not be available to contribute.
>
> That's something we could use help in developing.

Yes. This is probably higher priority than  my initial idea.  A practical
process is needed
and am happy to contribute my ideas.

> This needs thinking but it would be good to get more people to
> > contribute to libraries in which they were not the original authors.
>
> Who would get those people to contribute, and how would he/she do it?

If there is a practical process at least more people would consider
contributing
without being asked. This I haven't thought enough about it to give some
useful ideas.

As I said before, my viewpoint is of the newbie user and not library
developer

regards