[Date Prev][Date Next] [Thread Prev][Thread Next]
- From: Mike McGrath <mmcgrath redhat com>
- To: fedora-advisory-board redhat com
- Subject: Desktop Proposal
- Date: Mon, 12 Oct 2009 09:06:50 -0500 (CDT)
I put this proposal together based on the various emails I read on this
list, other lists and some private emails. The changes listed are
entirely around having a more usable, stable desktop environment as that
was the most common view I've observed.
It's also worthy of note that all of the solutions suggested do not
involve me in any way. So view this proposal either as coming from
someone who has no idea what they're talking about, or someone who has
intimate knowledge of Fedora but is not directly on the front lines of
developing the actual operating system. You'll notice the
implementation details are left up to the various teams in charge of such
a thing. Questions and comments welcome, actions even more so.
-Mike, happy Monday.
= 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
= 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:
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
= Mission Change =
Right now our mission statements, as listed on the overview page are:
* 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
== Solution 1: Define an additional mission ==
Adopt a new mission worded in an agreeable way similar to:
"Produce a usable, general purpose desktop 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
= 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.
[Date Prev][Date Next] [Thread Prev][Thread Next]