Re: [boost] Review Queue Needs Attention

Subject: Re: [boost] Review Queue Needs Attention
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2009-12-11 08:08:20

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
Behalf Of
> Mathias Gaunard
> Sent: Friday, December 11, 2009 12:25 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Review Queue Needs Attention
> 
> Vladimir Prus wrote:
> > Tim Blechmann wrote:
> >
> >>>>> (And a state not damned with faint praise like 'unstable' - which is
perhaps
> >>>>> better described as 'likely_to_be_improved' rather than actively 'not
stable').
> >>> The apache incubator might be a more appropriate inspiration than
> >>> Debian unstable.
> >> the current sandbox layout has the disadvantage, that single projects
> >> are present as sandbox/mylib, which do not run or compile on their own,
> >> but require a full set of the boost headers. in order to try out one
> >> sandbox library, you need to get the boost checkout/tarball and copy it
> >> to sandbox/mylib or vice versa ...
> >
> > Just to clarify -- what is wrong with starting with checkout of 'main'
> > Boost tree, and then doing 2 "svn co" per any sandbox library you want
> > to try?
> 
> It's not easy to tell the differences between main trunk and the sandbox
> library, it feels like polluting your boost trunk, you probably need to
> have different copies of your trunk lying around with or without certain
> libraries enabled, basically, it's quite a pain to manage.
> 
> I think providing a Jamfile for the sandbox that would allow to "enable"
> sandbox pseudo-branches while trying to compile BOOST_ROOT would be very
> nice.
> That way you would just checkout the sandbox separately and not pollute
> anything else, you just use BOOST_ROOT for reference for what you lack.
> 
> Sure, using actual real branches might be better, but I personally
> believe that makes the barrier to entry quite higher.
> 
> Another thing that would make the sandbox feel more serious or involved
> would be automated tests. I suppose one variant on one platform would be
> enough, it doesn't even need to be as regular as the trunk.

I think this goes to the nub of the problem - the feeling that sandbox stuff
isn't quite 'ready to try' (as opposed to trunk and release which are 'ready to
use').

Don't we need a proper 'ready to try' section which has an identical structure
to trunk, and for which there should be *some* tests and *some* docs (even if
these are placeholders for more complete test and docs)?  The hurdle to getting
into 'ready to try' could be modest, but higher than sandbox or vault - perhaps
needing a sponsor or few?

It would be nice if the tests could be run automatically as trunk, but at least
users could run the tests (and examples and docs) themselves.

We could expect stuff that was claimed to be 'review-ready' to be in this form.
It would help reviews if remarks could specify the revision number.  But most
important it should also mean that far more people have actually used libraries
before review proper.

The 'ready to try' stuff could also be packaged up into a zip, perhaps at the
same time as each proper release, so that those without SVN could also use them.
This would reduce the potential load on the SVN server and make it widely
available.

Paul

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