From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-08-01 17:02:07
Robert Ramey wrote:
> Stefan Seefeld wrote:
>> Robert Ramey wrote:
>>> a) designate an branch/trunk as the "Current Release".
>> That's what I'm referring to as 'stable'. The question is
>> what that gets created from, since it doesn't exist, yet.
> Hmmm - actually it does - its the RC_1_34_1 branch. We could
> just designate that as the "Current Release" (or whatever you want
> to call it.
I've also been using the name "stable" for the "release ready" branch.
And, yes, the starting point for "stable" is the current "RC_1_34_1" tag.
> Effort required - 0
>>> b) ALL development occurs on branches.
>> I'm not sure what that means, given how subversion handles
>> branches. The difference between 'trunk' and 'branches/something'
>> is only in the naming.
> So, given how subversion handles branches, the cost/effort
> of creating a branch for each developer's changes is 0
>>> c) Testing is applied to branches as requested.
>> I believe how test runs are triggered most efficiently depends on
>> the usage patterns. Ideally (i.e. with infinite resources), test runs
>> would be triggered on each change. If that isn't possible, alternative
>> approaches can be chosen, such as 'no earlier than x minutes after
>> a checkin', to allow developers to make multiple connected checkins
>> in a row (though with subversion there shouldn't be any need for that,
>> in contrast to cvs). Or, "triggered by checkins but no more frequent
>> than once per day". Etc.
>> (See http://buildbot.net/repos/release/docs/buildbot.html#Schedulers)
> This is the missing piece. I believe it will be available in a relatively
> time. The mechanism will be tests of library x will be run on branch
> y by any tester interested in doing this. Tests can be run whenever a
> wants to - but it will really only be necessary when a developer requests
Right, although as a practical matter most developers will want to test
I've been trying the following procedure for the six or eight weeks:
I've got a working copy "stable" which was checked out from the
RC_1_34_1 tag. I'm doing some Boost.System development on a branch
"c++0x". So I've switched the components involved (.../boost/system,
.../boost/cerrno.hpp, .../libs/system) to the c++0x branch.
I go about testing and development as usual on my Windows machine,
committing c++0x changes every time I want Chris Kohlhoff and Peter
Dimov, who are helping, to be able to access work-in-process.
I've also got a mini Mac and a Linux box set up with "stable" working
copies checked out from RC_1_34_1. I'm running a web server on those
machines (to simulate remote machines out on the Internet.) It has a
"test-on-demand" web page, which fires off a CGI script written in
Python that will switch a particular library to a specified branch, run
bjam, upload four result files to the server, and switch the library
back to the stable branch.
So whenever I want to see if the code is working on the non-Windows, I
sign onto the web sites, request tests be run, and have the results in a
couple of minutes.
Although the process needs a lot of polishing, it already works well
enough to demonstrate the value of the approach. The tools involved are
mainly just Subversion and bjam. The same approach would work with other
The bottom line is that I know that code works *before* it gets merged
into the stable branch. That's the critical point; the exact way the
testing is done is important operationally, but those details don't
matter as far as the big picture goes.
> The current testing on the "Current Release" can remain unchanged - though
> its usually interesting only to the release manager.
>> In any case, I agree to the point that there should be relatively few,
>> but coarse grained, checkins on the 'stable' branch,
>> which can be backed out as a whole if any regressions occur.
> I would not expect regressions of such a drastic nature that the
> above would be necessary.
The point of testing before actually changing the stable branch is that
regressions should become very rare.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk