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 fedora-list?) 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 fix it: * 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 project. ****** I am interested in hearing the thoughts of others around these ideas. ~spot _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
