-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, January 31, 2011 10:10 AM To: boost@lists.boost.org Subject: Re: [boost] Process discussions
In short - big bang tool changes are disruptive.
+1 (Like Homer, my brain is full ;-)
* I think we could organize the testing more efficiently for faster turnaround and better integration testing, and much to my surprise I'm coming round to Robert Ramey's suggestion that we reorganize testing on a library-by-library basis, with each library tested against the current release/stable branch.
* I think the release branch is closed for stabilization for too long, and
+1 that beta's are MUCH too short. +1 I thought we were trying to move to a 'release early, release often' policy. Are there really showstoppers for more than a few users using a particular library? They can use 'patch' using trunk, or wait for the next release - provided it's soon enough?
The aim would be to speed processing of testing by reducing the cycle time (most libraries most of the time don't need re-testing).
The version control system used would be a tiny part of the above changes,
open question, is whether we would need to reorganize Trunk more like the sandbox on a library by library basis in order to facilitate the new testing script. ie a directory structure more like:
Trunk/ Jamfile // Facilitates integration testing by pointing to other
My experience is that unless one has the full suite of platforms (and who does) testing on just ones favourite development platform isn't enough. There are still too many compiler idiosyncrasies. (Unless we removed old compilers from our testing remit? Personally I would do this, if no other reason to encourage users to upgrade! I am also puzzled at the number of support requests which start with "I'm using Boost 1.3x". Should we not be saying "If you are more than n (=2?) releases behind - Tough! Upgrade before you as again!") the libraries in Release.
MyLib/ libs/mylib/ boost/mylib/
That sounds sensible but very disruptive and a big lot of jamfiling. (And - aside - why it is not Trunk/ Jamfile mylib/ boost/ libs/ Why are there two 'extra' /mylib folders? Is this historical or is/was there some logic to it?) As far as maintenance, the /Guild/MyLib/... structure also sounds a good model for the less experienced/confident to try to fix things and test their 'improvements', without the risk of messing things up big time. The big problem for would-be fixers is this risk? It would be also be good to be able to move from /Sandbox or /Guild to /Trunk 'seamlessly' as soon as code is accepted by some review process. My 2p, FWIW Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com