On Wed, 2010-03-03 at 10:32 -0500, 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. Anything that goes on f13-branch during f13-alpha development would be beta-bound. The f13-beta-branch would be created when we start trying to finalize the beta. > > What do we get out of having multiple branches for a given > product/release, but only have one active at a given time? What I meant was that we'd have the product/release branch and, at most, one of the alpha/beta/rc branches open at any given time. Taking f13-branch as an example, I was thinking that f13-branch would continually accept patches. Currently, we'd be applying patches to f13-branch and only alpha blocker fixes to f13-alpha-branch. Once f13-alpha ships, we're done with f13-alpha-branch -- it's now a snapshot of the alpha for what that's worth. Once we decide to tighten up for the beta, we'd make f13-beta-branch. Does that make things any clearer? Dave > > > 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. > > - Chris > > _______________________________________________ > 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
