On Wed, 2010-03-03 at 06:23 -1000, David Cantrell wrote: > -----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. 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. > > 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. Dave > > > 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
