Hi
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.
The workarounds if any are posted and discussed in this list and
fedora-devel list already. If anyone wishes to blog about them sign up
in http://fedoraproject.org/people.
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
Can you help with any of these?. Kindly get involved in
http://fedoraproject.org/wiki/DocsProject. There are already several
drafts and ideas you can help with and improve.
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.
On progress. http://fedoraproject.org/wiki/Infrastructure/Schedule
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.
On progress. http://fedoraproject.org/wiki/Tools/xen
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list