-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 3 Mar 2010, David Lehman wrote:
On Wed, 2010-03-03 at 06:23 -1000, David Cantrell wrote:
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.
Good explanation -- very much what I had in mind.
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.
Why the merges, though? Any patch that went onto fX-alpha also went onto
fX-branch, so we can just create fX-beta off of fX-branch. Or am I
missing something?
It's hierarchical, like a series of successively finer-grained filters
for any given commit, eg: master? yes. fX-branch? yes. fX-alpha? no.
This is more of an alternative idea proposal. Rather than make each sub
branch off of fX-branch, you make it off the previous. That ensures you pick
up any patches that went on to fX-alpha or fX-beta and did not go on fX-branch
first. Once you make the new branch, you merge in fX-branch to pick up all of
the new stuff that was intended for the next milestone. The idea being that
the fX-alpha, fX-beta, and fX-rc branches are not working branches for
development, but rather branches meant for making the releases. The merges
avoid having to do a lot of cherry picking and dual commits.
The final merge in the example is intended to make fX-branch represent the
latest anaconda in that Fedora release.
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.
Again, I'm not sure why the merge is needed at all.
It depends on how we want to manage the workload. Force all developers to
commit to the correct branches or have everyone commit to a working branch
for a release and have the gatekeeper roll up changes when appropriate. And
the merges do not have to come from fX-branch either, they could come from
master.
I'm not sure what will work best in practice.
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkuOmTsACgkQ5hsjjIy1VkkYHgCfTuL09xNSU9rCjS9cjb+SPCOJ
0K8AoKcfAnZ/N2K+hi9ERTsJvRsZYgca
=c/AB
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
