-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 3 Mar 2010, Chris Lumens wrote:
I like this idea, but I'm at least a little bit inclined to take it
further. Given the pile-up caused by rhel6-beta1 and now f13-alpha, I'm
wondering if we should also create a branch off of each product/release
(eg: f13, rhel6) branch for each of the lead-up releases (f13-alpha,
rhel6-beta1). We still put everything on master and cherry-pick to all
applicable product/release branches, but we also only cherry-pick
blocker-fixes onto the alpha/beta/rc branches.
master
|- f13-branch
| |- f13-alpha
| \- f13-beta
\- rhel6-branch
|- rhel6-beta1
|- rhel6-beta2
\- rhel6-rc1
Yeah, it's a lot of branches, but only one alpha/beta/rc branch will
ever be active for a given product/release.
It's a lot of branches, but we already have a lot of branches and git's
supposed to make this easy, right?
Do we really want only one branch active for a given product/release, or
do we want to have the alpha and beta branches open at the same time so
bugs marked as beta blockers can still be committed? No, probably not -
that'll only result in an enormous build immediately after the alpha
goes out. We might get that anyway but we probably don't want to codify
the practice.
I don't think it would be that bad, so long as we stick with a release
gatekeeper and enforce that.
We branch off master at a given point in time once development of fX starts.
We call that fX-branch. A gatekeeper is appointed to handle the builds for
that release of Fedora and to keep track of the branches and patch management.
At some point in time, fX-alpha is created off of fX-branch to allow for
stabilization for the alpha release. fX-branch is left open for commits for
bug fixes not intended for the alpha release. Alpha can stabilize while at
the same time not blocking us from working on non-alpha blocker bugs.
For the next branch, fX-beta, I say it be created off of fX-alpha and the
gatekeeper do a git merge from fX-branch on to fX-beta to gather non-alpha
changes done while fX-alpha was in the works, but also to include any last
minute fixes that were done on fX-alpha and not fX-branch.
master
\- fX-branch -->--->---+->-+ <----<---<---+
\- fX-alpha | | TIME |
\- fX-beta <- merge -+ | PASSES |
\- fX-rc <- merge -+ ->- merge ->-+
My thought here is that everyone is doing work on fX-branch and the gatekeeper
is responsible for the alpha, beta, rc branches and the merges from the main
branch. Everyone concentrates on doing their work on fX-branch and the sub
branches represent the work in progress aspect of stabilizing the release.
For the final build, fX-branch should be merged with fX-rc or the last sub
branch made and the release built from fX-branch. The branches then represent
the history of the development of that fX release and fX-branch is the current
build. And for Fedora, that means we're done at that point.
What do we get out of having multiple branches for a given
product/release, but only have one active at a given time?
Allowing patches intended for different milestones to be committed to the
repository without disrupting a stabilization effort.
The release lead could be responsible for cherry-picking fixes onto the
alpha/beta/rc branches (or at least auditing the branch prior to build)
in the extension I propose above.
I like the idea of a single person being the only one who is empowered
to cherry-pick fixes onto a release branch. Makes for less of a
gigantic mess.
Definitely. On a rotating basis, so everyone gets a turn.
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkuOjRsACgkQ5hsjjIy1VklG7QCfS6/tOQUWRArE80hcW8jXCd3g
EaoAn1Um4o6joWFgKp0X7b/W80+QWKC3
=owuE
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
