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

[Jeff Spaleta]

On 2/14/06, Don Springall <don_springall at hotmail.com> 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