On 2/14/06, Don Springall <don_springall@xxxxxxxxxxx> wrote: > Here are my thoughts on what I think may help: > 1. A daily blog from Redhat explaining how to get around today's >oops. Don't you mean yesterday's oops? How exactly do we know they are oops until people experience them? I don't see how you can pre-emptively cover expected problems before rawhide consumers hit them. I really don't think you gain much from this, but you are certaintly free to attempt organization of this sort of thing. If all the Core developers had blogs that exported a special "Rawhide ate my baby" category.. you could easily aggregate a feed for this specific purpose. But you'd have to convince them to consistently use their blog and I'm not sure how you do that. > 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. I think you'll have to start this as a breaking news item from the lists and forums and run it as a community blog initially and invite developers to add their own "Rawhide ate my baby" feeds over time. > 2. Tutorials in online documentation on how to: > - use the recovery CD There's a docs subproject... care to start writing that document? > - how to boot into runlevel 3 to start x manually There's a docs subproject... care to start writting that document? > - how to run a trace in Gnome and KDE That exists to some degree... http://www.fedoraproject.org/wiki/StackTraces Feel free to add to it. > - how to build a exclude list for yum update based on rpm queries on > your system Feel free to add additional items under Tips and Tricks in: http://www.fedoraproject.org/wiki/Tools/yum > - IE a trouble shooting guide specific to Fedora that keeps up with the > changes in rawhide I wrote a personal manifesto at one point concerning testing...but a much more organized attempt has been started in the meantime. Feel free to help with... http://www.fedoraproject.org/wiki/Docs/Drafts/TestingGuide > 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. Already discussed in -test-list... are you volunteering to write it? Many people think this is a good idea... someone has to volunteer their time to make it happen. Are you that person? > 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. The pace of integration of xen into fedora isn't fast enough for you? Would you prefer xen stay out of the "stable" tree until its more polished and better documented? I sense some deep contradicts in you opinions as to where Fedora should draw the line between being aggressive about introducing technologies and being conservative in their introduction to save users/testers the pain of learning new technologies. You can't have it both ways. I look forward to your contribution to the Fedora Docs subproject since you seem to have identified some particular new items to contribute there. Thank you for volunteering your time and helping to write better documentation for all the testers and users out there! -jef -jef"Virtualization is nice and all for certain things...but unless testers run rawhide on actual hardware can you be sure hardware specific bugs that affect non-virtualized installs are going to bite and bite hard when the final release is unveiled."spaleta -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list