rawhide and Fedora QA [was Re: why I'm using Ubuntu instead of Fedora ATM]

Karsten Wade kwade at redhat.com
Mon Jun 11 15:20:07 UTC 2007


On Sun, 2007-06-10 at 12:01 +0200, Thorsten Leemhuis wrote:
>  because we IMHO heavily discourage people to run
> rawhide. 

I wonder if this is some kind of leftover Red Hat prejudice?

Ironically, rawhide is more unstable because not enough people are
running it.

Personally, I do all my business work using Fedora.  I can risk a few
hours here and there, but I won't run rawhide if I can't be sure it is
more stable than currently advertised.

> - better documentation for running rawhide

+1

It should include a simple procedure that allows an average user to:

1. Prepare a machine for being a dual F*/rawhide machine;
2. Take a latest release and turn it into a rawhide machine using yum;
3. Rollback to the stable current release (using yum?) if the state of
rawhide is more unstable than a user can risk at that time.

> - I for one would run rawhide on my main machines if it would be a bit
> less known to eat baby's. Maybe we could do that with a trick: maintain
> a second rawhide tree that only once a week (or all two weeks?) gets
> synced with the normal rawhide tree (files get hardlinked to save mirror
> space) when there are no known "baby eating things" and no "switch from
> python 2.(x) to 2.(x+1) in the work"

That's a good idea, and I concur that I would more likely to run rawhide
under those conditions.  Properly advertised, so would a lot of other
people.

Being able to run rawhide most of the time, know it is a week or two
more stable than a nightly, and having an easy way to roll back to F* --
I think that is the magic formula.

Oh, and as Luis says, advertise it. :)

> - make it *easy* for people to update from the last test release to
> final and tell people that that's possible; then maybe more people would
> run test releases

I think this goes hand-in-hand with the ability to rollback from rawhide
to the latest release.

Ironically, once we enable people with these methods and tools, we'll
create a situation where we can more easily predict what is going to
happen to a test release that is updated to final.  Since no one is
officially enabled or encouraged to do that, we lose out on valuable QA
that could turn the untenable into tenable.

- Karsten
-- 
   Karsten Wade, 108 Editor       ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20070611/4ebf3478/attachment.bin 


More information about the advisory-board mailing list