Proposal for the future of Fedora
sgallagh at redhat.com
Wed Sep 29 17:09:47 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 09/29/2010 12:56 PM, Jesse Keating wrote:
> 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.
I'm no stranger to git branching. However, there is really no advantage
to doing this versus keeping a separate build system for your project.
The advantage of Rawhide is that it's automagically added to a repo that
is part of a distribution (albeit a wildly unpredictable distribution)
Being able to present your *packaged* work-in-progress to a wide
community is the strength of Rawhide, and we weaken that by forcing
Rawhide packages to be wary of release branches.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----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