-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 2 Mar 2010, 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.
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?
I like this idea.
I think the major advantage we get to this approach is keeping master open for
ongoing upstream development. As has been pointed out, this will keep us from
requiring us to wait before pushing patches since we will always have master
that we can push to.
At certain points during development, it would be nice to have a way to
control what goes in to a build before a certain milestone but still be able
to work on bugs not intended for that milestone (e.g., we're stabilizing for
alpha, but we have patches done that are targeted for beta). dlehman already
posted a proposal for that and I think his idea would work well. More
comments on his posts.
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkuOiLYACgkQ5hsjjIy1VkktJgCeJZVSNrJyDqfXnYX7ddWf31Ke
oocAnR96iYxVkHAi+TZhn8b0nrcrzjmZ
=LkqU
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
