-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Friday, December 11, 2009 12:25 PM To: boost@lists.boost.org 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 +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com