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. 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 short 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 tester wants to - but it will really only be necessary when a developer requests it. The current testing on the "Current Release" can remain unchanged - though its usually interesting only to the release manager.
d) At the discretion of the release manager, Development branches are merged into the "Current Release" and the whole system is tested.
Does this imply that each individual feature (as defined by something that is meant to be merged into 'stable' as a whole) will be developed in isolation, on its own branch ? I'm not sure how practical that would be.
LOL - one hell of a lot more practical than the current system whereby everythign changes at once. I believe that this is the most widely accepted manner of using a system such as SVN. Failure to employ this practice has made life much more dificult than it has to be.
In any case, I agree to the point that there should be relatively few, but coarse grained, checkins on the 'stable' branch,
Good
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.
e) Each time the "Current Release" test passes more tests than the previous one, A tag is added by the release manager and a new download package is automatically created. I would anticipate this happing about once/month.
As above, I'm not sure what the tag is good for, with a repository that has atomic / global revisions. Just remembering the revision number that contains a new feature the first time should be sufficient.
For you perhaps. By my memory is fading as I get older. Its much easier for me to remember boost 1.36 than 3.1415917872348376485 But basically you're correct - a tag is a convenient naming device to bridge the gap between our feeble brains and the computer systems we use.
Packaging automatically (after a successful test run) can and should be automated with buildbot, too.
I don't know what build bot is - but it sounds like you're agreing that packaging the release should be an automatic process which is run affter the global test on the current release. If that's what your suggesting I'm sure everyone will agree
So, in this light, the release manager's job would be to decide which patches / features to merge from development branches to stable, based on the current release's life cycle.
Correct - upon request from a library developer. The release manager would review the requests from developers, select the order he want's to merge them in, and for each one, merge in the developer branch, request the global testing, and invoke the release build script if he's statisfied.
If you had nothing else to do, you could make the "Current Release" /main/trunk etc ONLY updateable by the release manager. Who would do this by merging in branches which have passed their tests. Then we'd be in business
Actually I don't think it is practical to have a single person do all this.
What's impractical is what is being done now. Thomas's accomplishment of getting all of boost and a new build system through the eye of a needle - all at the same time - was a heroic accomplishment. It is the last time that it can ever be done.
That would create a huge bottleneck.
Its the current system which is a huge bottleneck.
The most important thing to do is formalize the development process as far as version management is concerned,
That's what I'm trying to accomplish.
to be able to easily and quickly rollback anything that risks to destabilize the stable / release branch.
Totally, Totally wrong here. The only way to make things work is to integrate pieces in one at a time in digestble chunks. Note that all this has been discussed in quite a bit of detail. Beman made a pretty clear proposal along these lines and after quite a bit of discussion, it seemed to have reached a consensus. All the points made above have been made in previous posts. I'm sure you can find them if you're interested. Robert Ramey