Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)

Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-02-24 07:56:30

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
Behalf Of
> Mathias Gaunard
> Sent: Tuesday, February 23, 2010 5:01 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc]
rcpp)
> 
<snip>

> So you can see, indeed, that this is fairly concerning.

Agree.
 
> I think this is mostly the case for specialized libraries, though. The
> more precise the domain, the more little people know about it; and you
> wouldn't want people that know very little about something to review it.

Agree -

But you do *ALSO* want ' little people - mere users' to say if they find the
presentation and documentation are good enough that they could use it.

> > What do you propose to improve it?
> 
> I don't claim to have a solution, but I've got what I think may be an
> idea worth investigating.
> 
> What I suggest is creating an unstable branch where all libraries that
> satisfy simple quality criteria can be added, with the same layout as
> the trunk, with some automatic tests being run, a bug tracker etc.
> That way they get exposure, usage, and thus become easier to review
> later on. Authors also feel more involved, and work is not done in
> isolation as the branch contains the whole of boost.
> A library may then get elected to the stable branch, which means you
> simply have to merge it to the trunk.
> 
> It could be said it is just a glorified sandbox, but I believe the
> changes from the sandbox are enough to make it significantly different.
> 
> What the "simple quality criteria" are remains to be defined, but it
> should be something that only requires review from one single person
> within the pool of approved reviewers and that isn't too time-consuming.
> You would also probably need a community coordinator to make sure the
> unstable branch doesn't become too much of a mess.

This is in essence what I have been muttering about for some time - a collection
of what one might describe as 'candidate libraries'.

Libraries that have passed a first hurdle - being in a useful, usable state.

(Their documentation might use a 'Proposed for Boost' or 'Candidate for Boost'
logo? -see attached.)

This has the considerable potential advantage - encouraging a user base.

Users (both naive and expert) will smoke out many bugs and weaknesses in design
and implementation.  And allow those users to provide informed full reviews
later.

I also believe that  this will encourage developers to work on documentation, if
only to reduce the burden of responding to user queries.

But those who manage the sandbox and trunk, and testing, might regard it as too
much work?

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow_at_[hidden]