Proposal for the future of Fedora
sgallagh at redhat.com
Wed Sep 29 11:26:17 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
I would like to add my two cents to the new Updates Policy
(https://fedoraproject.org/wiki/Updates_Policy), keeping in mind the new
(Yes, I'm replying to my own original post to highlight the parts that
are included, or not, in the new Updates Policy)
On 08/18/2010 10:32 AM, Stephen Gallagher wrote:
> 1) We need to define and enforce a set of rules as to what changes are
> permissible in a released Fedora. This is going to be the hardest part,
> I think. It's easy to say "Major desktop environment releases are not
> allowed" and "No ABI changes", but where do we draw the line on other
> enhancements? This is a question that will have to be answered by the
> Board and FESCo.
This seems to be pretty much agreed upon in the new policy. I approve :)
> I also propose that the method of enforcement should be similar to that
> of the current critpath system: Any bug marked "Enhancement" must be
> given karma by a proventester in order to make it into a released
> Fedora. Proventesters would be expected to understand the guidelines set
> down as above. Failure to follow those guidelines (green-lighting a new
> major XFCE release, for example) would have to result in a loss of
> proventester status (with opportunity to reapply in the future).
This was not addressed. I genuinely feel that there needs to be some
gatekeeping policy to ensure that contributors don't ignore the Updates
Policy (either willfully, accidentally or unknowingly). My view remains
that proventester approval should be required for all updates marked
"Enhancement". Bugfixes and security patches should be left as-is.
> 2) We need a new policy regarding branching. Currently, the new and
> upcoming version of Fedora is branched from Rawhide at the moment that
> development begins on it. This needs to change.
> Instead of branching from Rawhide, I think Fedora N+1 should be branched
> from Fedora N. Rawhide should remain an exciting think-tank of
> in-development features, but we should always plan for Fedora N+1 to be
> a more stable environment. In this way, it should be first of all easy
> for developers to upgrade their system into Fedora Branched.
This is, I feel, the most important part of my proposal here. If nothing
else from this email is addressed, I think this needs to be.
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.
> Fedora Branched should relax the proventester restriction on enhancement
> updates mentioned above for released Fedoras. The expectation of
> packagers for Branched would be that it's a place to move your packages
> when you're ready for having real-world testing. More trust would be
> placed in the packagers to police themselves in Branched.
> I also propose that we should add features into Bodhi so that any update
> placed into Fedora N should also be automatically included in Fedora
> Branched (provided that the packages have not diverged). This way we can
> keep Fedora Branched as an upgrade path from Fedora N.
> These are my thoughts. Please give this proposal due consideration.
advisory-board mailing list
advisory-board at lists.fedoraproject.org
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