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 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
