Proposal for the future of Fedora

Stephen Gallagher sgallagh at
Wed Aug 18 14:32:41 UTC 2010

Hash: SHA1

Yesterday, there was a long discussion held in #fedora-advisory-board.
The topic of discussion was "What is Fedora?" (Or perhaps "What should
Fedora be?")

I would like to make a proposal to the Board regarding this topic.

First of all, I will succinctly say that I feel that Fedora should be: A
stable platform for rapidly developing the next generation of free,
open-source software.

I know that there are several different camps on this topic. On one end
of the spectrum, we have the people who want Fedora to have a longer
support lifetime, to be stable out the door and be stabilized for
long-time use with no changes but bugfixes made to a released version.
At the other end, we have the people who feel that Fedora should be a
Mecca for rapid development and deployment; that Fedora should get the
newest features fastest, and people who are looking for a stable
environment should look elsewhere.

I don't believe that these two goals necessarily need to be at odds. My
proposal is this: We should stabilize released Fedoras, while making it
easy to release exciting new features as quickly as possible.

To that end, I would propose the following changes to the Fedora approach.

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.

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

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.

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.
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the advisory-board mailing list