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