[boost] Repository Layout

From: Frank Birbacher (bloodymir.crap_at_[hidden])
Date: 2007-09-08 05:46:53

Hi!

I'm trying to think of a usable repository layout. The features it
should provide IMHO:

(1) release-ready branch, which is updated by the release manager/team
and includes latest additions for the next release as well as bug fixes
from the last release. this one is to prepare for a major release
(2) release-fixing branch, which is updated by the release manager/team
and only gets bug fixes. this one is to provide support/fixes for the
last release
(3) a main development branch for each library in boost. this would be
updated by the library maintainer. this directory should hold changesets
which the release manager/team merges into (1)
(4) testing branches for each library which can hold various bugfixes
and which are used for testing the changes before they are merged into
the release-ready (1) and release-fixing branches (2).
(5) possibly branches for each library which are "private" to the
library and used by the maintainer as she likes

To keep (3), (4), and (5) together, I think the following directory
structre would do:

/libraries
        /iostreams
                /trunk	(3)
                /branches
                        /testing_bug143	(4)
                        /trying_refactor (5)
        /serialization
                /trunk	(3)
                /branches
                        /...
                /tags
                        /...	(also 5)
        /...
/release
        /release-1-35-ready	(1)
        /release-1-34-fixing	(2)
/tags
        /release-1-34
        /release-1-34-1
        /...

Library work flow:

Bring /library/foo/trunk in sync with last release. Fix bugs in this
trunk. Report to release manager/team: "please include
/libraries/foo/trunk -c 39042 into release, its a bug fix for ticket
#374". Maybe branch off from trunk of foo or from latest release in
order to develop new feature. Use this branch for heavy testing, too.
When ready, report: "please include /libraries/foo/branches/new_feature
-r 40000:42000 into release-ready, its a new feature requested in #845".

Release work flow:

When receiving a "bug fix report" merge it into working copy of the
release-fixing branch and do local testing. maybe include some more
requests. After that "commit" and create a tarball for external testing.
Committing the only locally tested state will preserve this exact state
in the subversion. I think this is needed to provide a tarball and an
identical copy in repository. If tests are successful try the same bug
fix in release-ready branch and do the same testing.

Ok. I currently don't know how testing is done exactly, but other
messages on the list indicated testing each bug fix as it is merged into
the release branch. This seemed to require building a tarball and giving
it away for testing. I think this is a process which takes days. So how
long would it take to include a couple of fixes into the release-fixing
branch? How much testing is done up to today?

Frank