On Tue, 2010-03-02 at 17:49 -0500, Chris Lumens wrote:
> For F14 and later, I'd like to try an experiment with our git branches.
>
> Right now, we create a new release branch in git at some point during
> the development cycle. One advantage to this is that right around the
> alpha, most of our work ends up being fixing alpha bugs so it saves a
> lot of git branch management. One disadvantage to this is that it also
> makes controlling what goes into each build more difficult - for a
> while, stabilizing for a Fedora release and doing new development
> happens in the same remote tree.
>
> Now it's not quite that bad. For the most part, we all stop pushing new
> stuff and only do it locally. However, patches always manage to sneak
> in that shouldn't. So for the next release, I would like to try
> something different.
>
> At some yet-to-be-determined point leading up to F14, we create a
> f14-branch in git. I imagine this point is at the freeze for the alpha
> or something similar. At this point, all new development continues
> along on the master branch. f14-branch gets no new stuff. Fixes marked
> as F14Blocker get developed on master, talked about on the list, pushed
> to master, and then cherry-picked to f14-branch.
>
> F14 alpha, beta, RCs, and anything else they want to come up with then
> all happen from this branch. master continues along as if nothing ever
> happened. It's really that simple of a proposal.
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.
>
> Advantages:
>
> * All bug fixing happens on master first, so we don't end up losing
> patches and causing regressions.
> * There's tighter control over what makes it into a build for a Fedora
> release.
> * Development of crazy new things does not have to stop, though I would
> expect it to slow down as people's time is more consumed with bug
> fixing. At the least, we have a place to continue pushing new things
> instead of letting them pile up locally.
>
> Disadvantages:
>
> * We have to get a lot more particular about pulling fixes onto the
> release branches and making sure they all have associated bugs.
> * There's a lot more git branch wrangling to deal with, and everyone
> will need to be much more aware of where they are and what they're
> doing.
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.
>
> Your thoughts?
>
> - 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
