ABSTRACT
The goal of these proposals is to provide possible solutions to the various ideas and concerns expressed over the last couple of weeks. Being a general antagonist in this discussion I've had several of my own arguments disputed by what seems like a pretty solid majority. This proposal lists the most common concerns and desires and presents some actionable items. Each item is presented individually and the proposal itself should not be viewed as all or nothing.
The general focus of each of the topics below is to provide a more stable, usable desktop. Many of the solutions suggested are from ideas of many. Also check back for updates, I'll be making changes as suggestions come in.
The Desktop
The most common stance on the desktop is that people, regardless of expertise or experience, generally want a stable environment in which to work. There has also been a general opinion that Fedora is not as stable as it could be. Both in terms of rawhide and the GA releases. For a simple definition of stable I'm using: "Works as expected".
For the purposes of clarity I'll be discussing Firefox in these examples as initially mentioned in this thread:
https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00161.html
Ignore my response to that email, instead focus on the original which for some reason isn't showing up in the archives.
I pick this package for a couple of reasons. It's used by a majority of our users. Also, the problems encountered wouldn't be detected by any systems we have in place nor that are currently planned (AutoQA wouldn't have detected this).
Problem 1: If it gets in rawhide, it gets in the GA
Once firefox-3.5-0.20.beta4.fc11.i586 made it in to rawhide. There was literally no turning back. We have no procedure in place to identify it as a problem and no procedure to remove or revert this package for the final release.
This means that, in some ways, rawhide isn't a development version of what will be a general release. Instead it is a rolling preview of what _will_ be in the final release. This leaves no room for mistakes during the rawhide process because every update is a commitment.
Soultion 1: An experimental repo
Have FESCo, Release Engineering and the Packaging Committee examine the possibility of an additional repo that is not enabled by default for rawhide and general releases. This repo would contain newer and not yet proven versions, especially those considered to be a common use package. I'd consider these things like web browsers, email clients, window managers, etc. This repo would function similar to the old extras repo did but possibly allowing overriding of packages in the core repositories allowing for smooth upgrade paths.
There are several obvious drawbacks here in terms of additional work and complexity but it would aid in the end goal of having a more stable, usable desktop environment. It would also allow us to ship these newer packages thereby not directly conflicting with our first mission statement of being first and a leader.
Solution 2: The revert
As far as I know, there is no way to revert to a previous package once it's in rawhide. This is mostly concerning packages for which we are not the upstream. If Firefox 3.5 was determined to be a turd after a month of rawhide use, there should be some procedure in place to revert, possibly by nomination. I'd suggest FESCo and the packaging committee look at possible technical solutions as well as a procedure to do a revert to see if it is even feasible. Hopefully something cleaner than an epoch, no one wants a Firefox with an epoch.
Problem 2: Major version updates mid release
When updates in the middle of a release break previous functionality or change it in a fundamental way, it causes pain for everyone. This is evident in several fedora-list and fedora-devel threads. One recent thread worty of note is titled "thunderbird upgrade - wtf?".
Solution 1: Don't do it
Have FESCo look at requiring approval for major version updates in the middle of a release or possibly banning them outright. This also has a side effect of fewer updates which many find desirable. This may end up working on the honor system but should be possible while not compromising our first mission objective.
This could also be coupled with the experimental repo mentioned above to bring new packages to stable releases but only to those who accept the potential consequences and have enabled such a repo.
Notes on these solutions
Each of the above solutions will create more complex release environments and put more stress on the packagers. Especially those who maintain some fast moving but still common use packages like Firefox. This may be a welcome change for them but will ultimately require more work from several people.
Mission Change
Right now our mission statements, as listed on the overview page are:
http://fedoraproject.org/wiki/Overview#Our_Mission
* The Fedora Project always strives to lead, not follow.
* The Fedora Project consistently seeks to create, improve, and spread
free/libre code and content.
* The Fedora Project succeeds through shared action on the part of many
people throughout our community.
Problem 1: Too broad
The objectives above are incredibly broad. It's not even clear that we produce a Linux based distribution. Even though the Fedora Project does much more, our biggest feat at this time is the production of the Fedora operating system.
Solution 1: Define an additional mission
Adopt a new mission worded in an agreeable way similar to:
"Produce a usable, general purpose operating system"
I feel this fundamental shift on the mission page is required. Our teams all do lots of different and valuable work. All of these teams are on a schedule based around our regular releases of the operating system. This will also give our contributors and leaders the ability to ask themselves:
"Does this change/feature/task help produce a usable, general purpose desktop operating system?"
If the answer to that question is no, perhaps it's worth re-thinking this change/feature/task.
QA
Noticeably absent from this document has been the mention of QA. This is because QA as a team and as a function are undergoing significant changes at this time. It seems inappropriate to comment on a system that is not yet in place.