> 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. What do we get out of having multiple branches for a given product/release, but only have one active at a given time? > 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
