From: Jeff Spaleta <jspaleta@xxxxxxxxx>
Reply-To: For testers of Fedora Core development releases
<fedora-test-list@xxxxxxxxxx>
To: For testers of Fedora Core development releases
<fedora-test-list@xxxxxxxxxx>
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@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.
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
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list