[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: branching for future fedora releases



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 redhat com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]