Proposal for the future of Fedora
jkeating at redhat.com
Wed Sep 29 16:56:30 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 09/29/2010 04:26 AM, Stephen Gallagher wrote:
> Rawhide CANNOT function as a rapid development environment if it is
> regularly Branched. There are many projects that benefit from the
> ability to use Rawhide for long periods of time to stabilize a new
> feature before it belongs in a stable release.
> Currently, such contributors have only two options:
> 1) Keep an eye out for when Rawhide is going to branch and unpush their
> packages until after the branch is done, then re-create them.
> 2) After the branch is done, bump the epoch on their package in the
> Branch and revert it to a known good state (or pull it completely from
> the Branch, if it's a new package)
> Both of these approaches are highly disruptive to a working development
> I think that it really only makes sense for development to branch from
> the previous STABLE release (plus updates). It should be the
> responsibility of package maintainers to manually move rawhide packages
> into the Branch at that time. Then they can more easily decide when
> development is truly ready for inclusion in a stable release.
There is a third option.
When you are working on something that will span many releases and you
don't want it to show up in the next Branched release, simply make a git
branch yourself from master and work on it there. When we branch for
the release, we branch from master, so if you haven't merged your long
term work over to master it won't show up in the branched repo. (of
course, you'll have to manually do a build one the repo has branched to
prevent the "rawhide" build in koji from being "latest" in the branched
I totally understand how this could be confusing, and I wish I had a
white board. But basically SCM branches are much cheaper and easier
with git, so that you can collaborate and work on a long term feature on
an SCM branch without disrupting master and without that work winding up
on the release branch.
Fedora -- Freedom² is a feature!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the advisory-board