Stable vs. Release vs Devel Was: KDE update - no testing period?

Don Springall don_springall at hotmail.com
Tue Feb 14 19:52:34 UTC 2006


>From: Jeff Spaleta <jspaleta at gmail.com>
>Reply-To: For testers of Fedora Core development releases 
><fedora-test-list at redhat.com>
>To: For testers of Fedora Core development releases 
><fedora-test-list at redhat.com>
>Subject: Re: Stable vs. Release vs Devel Was: KDE update - no testing 
>period?
>Date: Tue, 14 Feb 2006 12:18:16 -0500

>There is no deep contradiction in Fedora's goals. The rate of
>development across the open source software stack is rapid. Fedora
>Core's goals invovlement incorporating those rapid upstream advances
>into a usable general purpose operating system to a large number of
>people on a time scale that is relevant to the upstream development
>work.  Yes.. some of those relevant upstream development work involves
>focusing on a desktop experience that is incrementally better with
>every release... and as a result new desktop-user oriented development
>work will be incorporated into Fedora.
>
The problem is not that there are rapid upstream advances. The problem is 
that when things like udev, hal  or xserver breaks it exceeds the experience 
level of a large segment of testers and users to recover from.

Here are my thoughts on what I think may help:
1. A daily blog from Redhat explaining how to get around today's  oops. 
Something that is tided to that days build report and updated as the day 
goes along if the initial solution is wrong or some better workaround is 
found. Something which is as proactive as time allows. Perhaps with an RSS 
feed for that post.
2. Tutorials in online documentation on how to:
- use the recovery CD
- how to boot into runlevel 3 to start x manually
- how to run a trace in Gnome and KDE
- how to build a exclude list for yum update based on rpm queries on your 
system
- IE a trouble shooting guide specific to Fedora that keeps up with the 
changes in rawhide
3. A utility that everyone runs and attaches the output from to their posts 
about bugs that captures your kernel version, default window manager and 
release level, your chipset, Video card, network card and other essential 
hardware info to speed debuging.
4. A rapid move to virtulization so rawhide is only run as a guest OS and 
nuked when badly broken unless you are an experienced kernel level developer 
with years of experience.





More information about the fedora-test-list mailing list