Proposal for the future of Fedora

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/18/2010 11:48 AM, Jared K. Smith wrote:
> 1) What is the problem with the current way of doing things that your
> proposal is attempting to fix?

The problem is that Fedora N at the end of its lifecycle is often
completely unlike Fedora N at the beginning of its lifecycle. Users have
no expectation that a particular Fedora release will remain stable in
terms of what packages are available at any given point in its lifecycle.

I've heard more than one (non-developer) utter the phrase "Fedora is the
only Linux distribution I've ever used that doesn't put any effort into
ensuring that it works".

Fedora right now is a developer's play-pen. As much as the next
engineer, I certainly appreciate being able to play with the
latest-and-greatest technology, but I don't think waiting a few months
for the next release is a terribly big issue. There's always rawhide or
build-your-own if you absolutely cannot wait for something.

There are certain things that should never happen in a Fedora stable
release without express exception by a ruling body:
1) A major or minor release of a desktop environment should never within
a Fedora release. (Bugfix point releases are certainly fine)
2) There should never be a SOname bump in a released Fedora. This is
also partly for the benefit of the developers, as SOname bumps tend to
cause provenpackagers to do mass-rebuilds, which do not always work
properly.
3) No key piece of internet browsing functionality should see a major
upgrade during a Fedora release.

> 2) How does this change affect our target audience?
It's difficult to peg our "target audience", and that's a piece that the
Fedora Board needs to decide on. Is our target developers, end-users,
corporations? Some combination of the above?

I will say that for all of the above targets, having a stable release
vision is a major benefit. Knowing that the set of package versions
present in Fedora at release will be consistent for its entire lifecycle
(assuming no exceptional circumstances) will encourage participation
from those who might otherwise turn to other distributions that already
have similar stable release visions implemented.


> 3) How does this change affect our packagers and developers?  Are they
> more or less likely to contribute to Fedora because of this change?

I dislike prognosticating, but I will attempt to enumerate the pros and
cons from a developer perspective.

Pros:
A stable release means that it will always be possible to develop
against the existing packages and know that you won't be putting in any
late nights trying to rebuild against the latest e.g. Boost libraries
because it no longer behaves the way it used to.

Cons:
It adds a more controlled process to a culture that thrives on
independent design. The added requirement for proventester review of
enhancement requests (as well as the possibility that The Man will
decide that a new enhancement is too disruptive for the stable release)
could discourage some developers from playing.


I think we can work around the cons somewhat by working to facilitate
the existence of public yum repositories through Fedora People and/or
Fedora Hosted services. The idea would be that Fedora itself would
remain a stable system, but for those developers who really want to push
(e.g. XFCE N+1) along, they can provide a yum repository that is
compatible with the base Fedora. These repositories would have to be
publicized somewhere on Fedora's web presence.

> 4) Have their been other attempts over the past couple of years to
> solve this same problem?  Can you identify where or why they failed?
> 

Answering this question might be impolitic. There have been a few other
attempts to do similar in the past. The largest obstacle I've seen to a
stable release vision has always been the vocal minority of the groups
that are "hurt" by such decisions. I refuse to identify by name or
implication any of these groups, but I think at some point we simply
need to decide whether it's more important to Fedora as a project and as
a distribution and operating system whether it's more important to have
a product that works, or a product that's constantly lurching towards
the next big thing.


>> 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.
> 
> While I certainly agree that you've hit *part* of what Fedora should
> be, I think our vision has to be a bit wider than that.  Fedora is
> more than just a operating system for building the next version of the
> Fedora distribution.  Fedora is a community first, and the primary
> fruit of that community is the distribution.  The Board is currently
> working on a vision statement for Fedora.(mizmo posted her version to
> the list earlier this morning, and I'm working on my own version too
> -- we'll be discussing this in our Board meeting on Friday.)  Once
> that's agreed upon by the Board, we'll then work with FESCo to
> evaluate your proposals and give them the attention and discussion
> they deserve.

Please see the word "succinctly". I was summarizing my views on this
particular topic. I agree completely with your assertions about
community first. I would like to remind the Board that with communities
larger than about three members, it is impossible to please everyone all
of the time. Sooner or later, a stand must be taken to decide the
future. Not everyone is going to like it, and some will protest loudly
and [metaphorically] violently. Some will even have a tantrum and then
take their toys and go home. I ask: are those the people Fedora wants?

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxyZDsACgkQeiVVYja6o6MBnwCfROMpYCHxkP/PRM8uAzJMR34K
jqgAnimm4bRYiKif0XSwBJXc5bVPKHwy
=04Mh
-----END PGP SIGNATURE-----