Proposal for the future of Fedora

Thu Aug 19 07:59:20 UTC 2010

On Wednesday, August 18, 2010 04:32:41 pm Stephen Gallagher wrote:
> 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.

The question number one - what does stable means? Everyone talking about "to be 
stable", I like it, I want stable OS - but everyone understands it differently. 
For me - stable is - it boots and does not crash, I can use it, for others it's 
stable environment, for another one it's RHEL like system and so on. So firts - 
we have to be concrete what we want, "stable" is not enough.
Is it unstable to update DE with major release? In terms of bugfixing - it's not, 
it's stable, in the meaning of UI changes, it isn't. Where's the line? Is it 
unstable to force people update to something completely new every 6/12 months? 
Yes, every new Fedora contains so many new nice features that are not usually 
very stable at that time but offers nice functionality that makes Fedora best OS.

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

Exactly! We can and we nearly have both!!! We have two releases in the wild and 
I've already commented it several time (even I started proposal and never 
finished it, sorry, a lot of people asked me to do it but I was quite 
dissapointed that time) - why not use this as our strength? Fn as progressive 
release slowing down towards time it becomes Fn-1 with critical bugfixes only! 
This leads to "stable" (in all meanings I understand stable) but still very 
fresh one release for our users and all new features settle down by the time => 
WIN!

Jaroslav

> 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.
> _______________________________________________
> advisory-board mailing list
> advisory-board at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board

-- 
Jaroslav Řezník <jreznik at redhat.com>
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.                               http://cz.redhat.com/