Re: [boost] Process discussions

Subject: Re: [boost] Process discussions
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-01-31 08:05:18

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of John Maddock
> Sent: Monday, January 31, 2011 10:10 AM
> To: boost_at_[hidden]
> 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.

+1

> * I think the release branch is closed for stabilization for too long, and
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).

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 version control system used would be a tiny part of the above changes,
the
> 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
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
[phone]  07714330204
pbristow_at_[hidden]