Proposal for the future of Fedora

[Greg DeKoenigsberg]

This is the kind of concrete proposal I like to see.

The critical path then becomes building and sustaining a strong community of
proventesters.  Which is the sort of thing I would love to see Fedora excel
at.

It seems to me that testing tools are extremely high leverage.  What tools
and processes need to be in place to make it easy and fun and cool to be a
tester, and once those are in place, what becomes possible?

--g

On Aug 18, 2010 10:32 AM, "Stephen Gallagher" <sgallagh at fedoraproject.org>
wrote:

-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxr7wkACgkQeiVVYja6o6MkkwCdG93XCYB23YhGI18blWhL5wsA
c54An1BTRMeHU9Mwd5afnVGHbThOSA5M
=es4h
-----END PGP SIGNATURE-----
_______________________________________________
advisory-board mailing list
advisory-board at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100818/d40a38c7/attachment.html