On Wed, 2010-03-03 at 07:15 -1000, David Cantrell wrote: > -----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 I think we want an organized approach from the start so we don't have to deal with patches on fX-beta that didn't go to master and fX-branch first. I can't think of any reason we'd want the alpha/beta/rc branches to diverge from fX-branch in any case. It will just lead to a mess. > 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. This sounds potentially very error-prone to me. In terms of flow (of commits and releases) it is very roundabout. It makes me nervous. Maybe I just don't get it. > > 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 think developers should commit to master (if applicable) and any appropriate product branches, just like we do now. The release lead for each product branch then decides whether the commit should be pulled onto any active alpha/beta/rc branch. I can possibly see some argument for having the fX release lead do all cherry-picks onto fX-branch, but I think that part of what we do now works fairly well (having the developers handle that part). > > I'm not sure what will work best in practice. > Me either. Dave > - -- > 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
