Testing Fedora - small (?) suggestion.

[Horst H. von Brand]

Gilboa Davara <gilboad at gmail.com> wrote:
> I use Fedora daily, and I have a vested interest in -actively- helping
> Fedora (and in-turn RHEL) become a better product.

Report problems as you find them. Check out test packages for stuff you
care about.

> I don't have a dedicated Rawhide machine, I do play with it from time to
> time using VMWare Server, but this is fairly light testing as I'm pretty
> short on time. (Just to see what's new)
> I -do- try to install (at least on a VM machine) every test release and
> give it a day or two of testing - but even this is hardly enough.

It will help weed out DOA problems, so it does help.

> FC6 was a good release, but certain managed to slip through... some of
> them rather critical (i586 kernel springs to mind) which should have
> been found by us. (Read: testers)

Need more of that stuff. Right.

> As I see it, there's not enough Rawhide users to reduce the release bug
> count, mainly because:
> A. In my experience, 1 out of 2 rawhide installs break due to missing
> dependencies - and spending four hours (and ~1+GB of bandwidth) just to
> watch Anaconda choke on missing pygtk package is very frustrating.

I'm running rawhide, udated (almost) daily by yum. When stuff doesn't
update OK, it is usually enough to add it with --exclude and try
again. Luckily, yum keeps what it's got already in cache, so...

> B. Rawhide tends to break, a-lot.

Not in my experience... yes, packages do break (sometimes), but on the
whole it works just fine (for me).

> C. As much as I disagree with this notion, people view Fedora as RHEL's
> Alpha and view Rawhide as "experimental Alpha".

Can't change that perception easily...

> More then anything FC6 proved that 3 test releases may not be enough to
> get a bug free release,

A 100 test releases won't, so...

>                         so let me suggest the following:
> A. Create more mile-stone releases. Once the tree reaches build
> integrity (no missing packages), spin a test release. (Fixes P1, P2)

Test 1 should (at the very least) be there, and so should the others.

> B. Change the terms that are being used to describe each test release.
> Whether we like it or not, people are used to the "Alpha", "Beta" and
> "RC" terms, and tend to consider "Test release" as "Alpha release". I
> understand that the term "Test" was used to differentiate the
> ever-rolling Fedora from the release-based RHEL, but Fedora has aged
> enough to be viewed as an entity by itself and we can drop the "Test"
> term.

Yep. 

Alpha == don't ever use it if you aren't downright suicidal
Beta  == Use only when you don't care one bit for your data/machine/sanity
RC    == Let's wait until it is there "for real", let others get burned

> Using "normal" terms should help combat the "RHEL Alpha" and 'RHEL Alpha
> experimental" image problem (Fixes P3). 

Fedora users /should/ have gotten the message by now...

> C. Once Fedora hits RC, only bug fixes go into the tree. No last minute
> 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the
> release. Nada. New features can always enter the tree as updates once
> the release ISOs have been sent.

Look at the roadmaps that have been published for, e.g., Fedora 5 and 6...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513