Boost logo

Boost :

Subject: Re: [boost] Process discussions
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-01-31 12:04:53


John Maddock wrote:
>> Maybe I suggest that for some time, we outright ban freeform
>> discussion about
>> process, and instead, we restrict them to threads started by a Boost
>> developers
>> and saying this: "I am maintainer of X, and had N commits and M trac
>> changes
>> in the last year. I most hate P1, P2 and P3. I would propose that we
>> use T1,
>> T2, and T3 to fix that". Then, everybody could join to suggest better
>> way of fixing P1, P2 and P3 -- without making up other supposed
>> problems.
>
> OK let me give my pet hates:
>
> * The only tool comment I have is that SVN is awfully slow for big
> merges (Math lib docs for example), I probably need to find a better
> way of using the tool better though.

+1

> * 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 of course,

> * I think the release branch is closed for stabilization for too
> long, and that beta's are too short.

I would hope that implementing the above would make this a non-issue.

> Here's a concrete suggestion for how the testing workflow might work:
>
> * Test machine pulls changes for lib X from version control (whatever
> tool that is).
> * Iff there are changes (either to lib X or to release), only then
> run the tests for that library against current release branch.
> * The testers machine builds it's own test results pages - ideally
> these should go into some form of version control as well so we can
> roll back and see what broke when.
> * When a tester first starts testing they would add a short
> meta-description to a script, and run the script to generate the test
> results index pages. ie there would be no need for a separate machine
> collecting and
> processing the results.
> * The test script should run much of the above *in parallel* if
> requested.

> 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).
>
+1 to all of the above.

> 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/
>
> And yes, Trunk/Mylib could be an alias for some DVCS somewhere "out
> there", I don't care, it's simply not part of the suggestion, it would
> work
> with what we have now or some omnipotent VCS of the future.

Let's divide this into three questions to be separately considered:

a) adjust testing script to the above model
b) movement from one VCS to alternative one
c) restructuring of directories and/or namespaces (modularization)

And if implemented, do them one at a time.

> I have one concern about this model - from time to time my stuff
> depends upon some bleeding edge feature from another library or Boost
> tool -
> sometimes too development of that new feature goes hand in hand with
> my usage - which is to say it's developed specifically to handle problem
> X, and the only way to really shake down the new feature is to put it
> to work. For example Boost.Build's "check-target-builds" rule was
> developed for and tested with Boost.Regex's ICU usage requirements.
> Development of the
> Boost.Build and Regex went hand in hand. Not sure how we deal with
> this in the new model?

They way I do this on my own machine is to use a release tree. The
directories
of those libraries which are of interest to me I switch to the trunk.
Usually this is just the serialization libraries, but occasionally I might
do
it with some other library.

> ~~~~~
>
> Release process:
>
> How about if once the release is frozen we branch the release branch
> to "Version-whatever" and then immediately reopen release. Late
> changes could be added to "version-whatever" via special pleading as
> before, but normal Boost development (including merges to release)
> would continue unabated. That would also allow for a slightly longer beta
> test time before
> release.

Fine by me, but I would hope that the need for this would dimish
with an update to the testing regimen.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk