branching for future fedora releases
 

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.

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.

Your thoughts?

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

branching for future fedora releases
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/02/2010 03:29 PM, David Lehman wrote:
> On Tue, 2010-03-02 at 17:49 -0500, Chris Lumens wrote:

> 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.

If only one is ever active, why have a different branch for it?

>> Your thoughts?
>>
>> - Chris

I like it.

- --
Brian C. Lane <bcl@redhat.com>
Red Hat / Port Orchard, WA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBS424ihF+jBaO/jp/AQIsowf9GfzHo332px5amflEQLTGJ4z1ay+FYMsp
/I53Mj/sLRb9TYWawBF8+EckCAfVXUKp+nHQ2yGfYnyJTkzwE6HfFPybY 6VFUUR1
L5hA1SNLdHzM/mKiTjInnKG9LQUH3rQDsqduh2YBbP17W1xV/wC9jIWCbyp2keTh
5pYOchcLYFGE0adsw5Hasq+nmD9Cd40/iCduBiEyuRdFG9xJ3vQBZ1zqT7mOm2qh
8q+M8vG02+WcbPAe/SveJ7CFHitcjHvEp+FGkYF57HUYWNwHNKcfPQYcZ6RcrH0N
/3mAhYM11EpTn5nNO7EeHXBBx5hAR0Kxbxs43mbMgsMscr/+7IQW4Q==
=gKFH
-----END PGP SIGNATURE-----

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

branching for future fedora releases
 

On Tue, 2010-03-02 at 17:16 -0800, Brian C. Lane wrote:
> If only one is ever active, why have a different branch for it?

I think he means only one of 13-alpha or 13-beta branches would be
active. the f13-branch would remain active throughout the entire f13
release cycle. The -alpha and -beta branches would be short lived to
provide an even more strict gate upon what changes go into the anaconda
builds during that critical time. Once the -alpha is marked as GOLD,
the branch would no longer be used.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list