Testing test releases: do not update

[Robert P. J. Day]

On Sun, 22 Feb 2004, Alan Cox wrote:

> On Sun, Feb 22, 2004 at 03:57:58PM -0500, Robert P. J. Day wrote:
> > from what i've read so far, the consensus is that testers are encouraged
> > to update against rawhide and to file bug reports on all of those updates.  
> > i think that's a silly idea.  it's silly because rawhide is defined as the 
> > repository for the latest, greatest, still-wet releases of software that 
> > have absolutely no guarantee of working and, IMHO, it's does a disservice 
> > to testers to ask for their time to test, and then give them what is 
> > essentially a moving target.
> 
> Rawhide is the current edge of the wave. Without people testing stuff that
> hits rawhide everyone just gets stuck at the bugs which may already have
> been fixed, or files reports on fixed problems.

argh!  is it too much to ask that people respond to what i actually 
*wrote* rather than what they *imagine* i wrote.  i never said that people 
should never update against rawhide -- feel free to go back and find a 
single posting where i discourage that.

what i was suggesting is that testers have the *choice* as to whether they 
want to update against rawhide.  if you're feeling gung-ho and ready to 
rock and want to take the stuff in rawhide for a spin, then by all means, 
go wild.

but for those who aren't quite so devil-may-care, i still don't think it's 
out of line to give *those* folks a more stable update channel which 
represents just those things that are clearly broken.  how many times do i 
have to type that sentiment before people understand it?  should i type 
more slowly?  what?

let's understand something pretty fundamental about the historical RH 
testing process.  as we all know, RH has massive disclaimers about test 
releases -- don't use them for serious, mission-critical stuff, they're 
almost guaranteed to be a bit flaky, etc, etc.  the standard 
recommendation is, of course, to install a test release perhaps in a 
*second* partition, dual boot to it when you want to test, *don't* fer 
cryin' out loud use it in a production environment.  you get the idea.

but let's face it, it doesn't quite happen that way.  given that even test
releases of RH are, for the most part, pretty solid, a lot of people (moi
included) *will* install it on our desktops.  in short, despite all the
warnings that it's alpha, many of us will in fact bite the bullet, take a
deep breath, and load that baby.  we *know* we'll run into bugs, we *know*
we're going to have to work around glitches, but we're prepared to pay the
price to play with the latest and greatest.

and, you'll notice, it's from those testers that RH will get the most
useful feedback.  not from the occasional, 
pop-into-test-release-for-a-while-and-dick-around testers, but from the 
aforementioned, damn-the-torpedoes, here we go with the alpha release,
24x7, "i'm going to immerse myself in it and live with the consequences no 
matter what" testers.  these are the people who are making a fair 
sacrifice taking that kind of chance and putting up with the inevitable 
bugs and reporting them.  and in return, what do they get?

i submit, what they get is being treated like crap by red hat.

if i'm prepared to install and live with an alpha release and its initial
bugs, the one consolation i might get is that, as time goes by and bugs
are reported and patches and updates issues, i can at least look forward
to my system getting more and more stable, having to deal with fewer and
fewer bugs (at least until the next test release).  i can live with the
initial pain because i can look forward to life, slowly but surely,
getting better and better.  and as things get better, i might even start
re-customizing my working environment, getting back to where it was
before, life mercifully returning to something resembling normal.

but this won't happen as long as the only update channel is rawhide since, 
if i update against rawhide, *by* *definition*, i know that i'll get not 
only the patches i want, but all of the other untested, bleeding-edge 
development crud that's been dumped in there that red hat would like 
people to play with.  in short, while part of my system is being fixed, 
almost guaranteed, some other part is now broken.  one step forward, one 
step back?

so what's in it for the tester?  just the guarantee that, as some bugs are 
fixed, others are introduced.  who would want to live in that kind of 
environment 24x7?  (and keep in mind, i'm addressing specifically that 
population of testers who are making the sacrifice to immerse themselves 
in the test release and from whom RH is undoubtedly getting the most 
feedback.  giving them nothing but rawhide is basically telling them,
"for all of your hard work and sacrifice and commitment, we're going to 
treat you like a guinea pig and load your machine with stuff that we 
haven't had time to really look at yet.  let us know if something 
explodes.  thanks.")

oh, and let's not forget the most pernicious argument of all.  at least a 
few posters have suggested that having two update channels -- one for 
straight fixes, the other being rawhide -- is just, well, too much work, 
it's infeasible, how would you implement it?

gee, i don't know -- perhaps the same way that RH implements the various 
channels for its production releases: base, updates, testing-updates and,
finally, rawhide.  apparently, *someone* at RH understands the concept of 
different quality levels of download channels.  so what's the problem?

anyway, i've spent way too much time on this.  used to be, i always looked 
forward to a new RH/fedora release, even knowing the glitches i'd have to 
put up with.

but if RH's approach to automatic updates and bug fixes for test releases 
is to simply cram onto my machine all of the untested, buggy stuff from 
rawhide, well, that kind of loses its appeal.

rday