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

[Don Springall]

>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 16:20:59 -0500
>
>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.
>
Good morning Jeff,
http://lkml.org/ forum has an rss feed for some posters. They could follow 
that format if they don't like to blog. And I am not expecting them to be 
prescient. Just to update when they can. I think as a community
if we could get those on the east coast to give us the yum update --exclude 
{ } list as they experince it ,we could save time for those of us on 
Mountain  or Pacific time. It often takes a couple of tries of the update to 
get your list correct. As you exclude one thing, something else pops up 
which must be added to the list.

> > 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?
I would if I was not such a klutz at it. I frequently hit a wall when I try 
to run an rpm update when the script fails.

>
> > - how to boot into runlevel 3 to start x manually
>There's a docs subproject... care to start writting that document?
That I could handle, Where do I sign up ?

>
> > - 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
Ok, as an example the kernel compile notes say do this and follow your text 
book. Your texbook says to run make bzImage. It is now make followed by make 
install_modules, make install.
>
> > 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?
What script language do you suggest I use and what list should I be on to 
solicit suggestions  ?

>
> > 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.
If we loose the guest OS who cares. We still have the stable to fall back to 
once core 5 is final. At least that way we have two OS's minimum on each 
system and it is no big deal if rawhide breaks as a guest OS. Not eveyone 
needs to test hadware or has the skills to do it properly. We just download 
the latest image once it is working again and test away. Plenty of 
applications out there to test.  I am a application programmer by trade. Not 
expeienced enough to do system level programming. My background is mostly in 
MVS/ESA, VM/CMS and OS/390 (twenty years) and am new to Linux (two years).

>
>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