"What is the Fedora Project?"
Tom "spot" Callaway
tcallawa at redhat.com
Wed Oct 14 18:30:41 UTC 2009
On 10/14/2009 01:45 PM, Máirín Duffy wrote:
> - Fedora had been the favored Linux distro for both her and many of her
> prominent customers, including well-known government and military
> agencies. Up until FC6. Over the past two years, distros such as CentOS,
> SuSe, Ubuntu, Scientific Linux, and Oracle Linux are showing greater
> stability and thus customer interest has shifted away from Fedora.
There is a certain amount of irony here, as FC6 was the last release
where the core was built, maintained, and updated solely by Red Hat.
In many ways, Red Hat built Fedora internally (in those days) like it
did RHEL. There are obvious pros (and cons) to that approach, but I do
not think it is worthwhile spending too much time reflecting on the past.
I do however, tend to agree with this user's conclusions: Fedora needs a
measure of controlled stability and improved usability.
I think there are a few things that we need to do to accomplish that:
* Fedora needs a dedicated focus on usability. This is something that
requires coordinating the efforts of designers and programmers, along
with usability testing. I'm proud to have been able to take the first
baby step towards that by providing Mo with a portable Usability lab, so
we can begin gathering data and doing research, but there is much that
still needs to be done.
* Fedora needs a dedicated focus on QA. This is something where I feel
confident we are currently making solid progress, especially around
AutoQA, but we are not making enough noise about. The fact that Chris
Aillon (a Board member) was unaware of this initiative illustrates that
failing. :) Our improved Test Days and Bug Triage are wins, but we need
to continue to be more aggressive here, and try to find ways to involve
and incorporate our community.
* Fedora needs to improve how it handles updates. Part of this problem
is defining what merits an update. Some of this is covered by the
Critical Path initiative, but I think we can build upon that foundation.
Just off the top of my head, how about something like this:
* Clearly mark Critical Path packages as such in Fedora infrastructure
* Critical Path packages may not do "enhancement" updates on a
non-rawhide release branch (exceptions permitted only with FESCo approval).
* Critical Path packages must have a QA test plan for updates to ensure
that there is no loss in functionality.
* Where applicable, the user experience should not change for a Critical
Path package as part of an update (with the notable exception of a bug
fix or security hole closed)
* Packages not defined as Critical Path are permitted to do
"enhancement" updates on a non-rawhide release branch, but are strongly
encouraged to minimize the amount and frequency of these updates.
* Any non-Critical Path update which alters the user experience must be
documented as a part of the update announcement, and announced to the
relevant mailing lists (perhaps all "enhancement" updates go out to
FWIW, I also think that "updates-testing", as it is today, does not work
for Fedora. In all of my packages, I am lucky if I can convince even one
individual to provide karma on an update, and I have never managed more
than that, even when I know there are tens/hundreds of users aware of
the bug (and waiting for the update to fix it). A few ideas on how to
* Make a period of time in updates-testing mandatory for all updates.
This can still be overridden by "bodhi karma" votes from testers, but
nothing can be pushed directly to stable. I'm not a fan of this on its
own, as I think it will merely encourage people to game the system, as
we have seen before when individual maintainers have imposed similar
policies on their own packages... but if paired with my other idea...
* Encourage community testing of updates-testing, via "Fedora kudos". If
every package had a list of functionalities and features, and
instructions on how to test those features, every update would be
reasonably testable by a competant Fedora user. Any user who tested an
update and indicated that it:
- No longer illustrated the bug it fixed.
- Functioned as expected and documented
Would receive "a Fedora kudo". (Heck, they'd even get one if they showed
that the update was broken, that's just as useful to know!)
We'd also give out kudos for users who help define the
functionalities/features of a Fedora package (with screenshots, testing
commands to run). Package maintainers can always sanity check these, and
we will also want to encourage folks to be doing peer review of such items.
This requires some infrastructure to be built to enable this, but I
think the payoff potential here is huge. I'm hopeful that we can do this
as part of the next major milestone of the "Fedora Community" Moksha
I am interested in hearing the thoughts of others around these ideas.
More information about the fedora-advisory-board