FC2 test2 is a BAD joke

[Lamar Owen]

[I may regret this, but.....]
On Tuesday 30 March 2004 07:47 am, Williams Jr, Ernest L. wrote:
> Sorry, I won't be so nice.
> I see this as plain negligence!!
> Who is in charge of Q/A??

We are. You don't like that?  Unsubscribe from this list.  [Note: I do not 
work for Red Hat.  I do however use Fedora Core in production on critical 
systems and have a great interest in seeing Core 2 be the best that it can 
be.  Useless rants don't help Fedora be the best it can be.]

> And don't give the excuse that this is a test release, I am tired of
> hearing that excuse.

Then don't try to install a test release.  Wait on the official release.

I am tired of hearing from people who apparently have no business attempting 
to install a test release.  Test releases are not for newbies and they are 
not for the faint of heart or for the quick to anger.  They are for the 
patient.  If you are not patient do not install the test releases.

Ok, so it didn't install.  Do something useful:
1.)	File a Bugzilla report with your exact hardware, the exact procedure, and 
all those nice things that Bugzilla asks you for.  Be sure to search on 
various terms for the bug you are describing; spend a little time to save the 
developers some time and make them more productive.  Duplicate bugs yeild 
less developer productivity.  After all, you are installing the test to help 
the developers, right?

2.)	If you don't know how to use Red Hat's bugzilla, then learn how to use Red 
Hat's bugzilla before you throw a useless rant onto an already crowded 
mailing list.  Continue throwing useless reports on the list and you will 
find your way into people's killfiles (so that they will simply not see your 
postings).  Perhaps I may be in some people's killfiles already, but I 
digress... :-)

3.)	Remember rule number one: if it isn't in bugzilla, then it isn't a bug.  
You find a bug; you get to file it.  You don't want to spend the time to file 
it?  Don't go bug hunting.  Installing the test release is implicit 
confirmation that you intend to go bug hunting; ergo, if you don't want that 
responsibility, don't install the test.  Pretty simple, no?

4.)	If it eats your data, it is your fault for installing it.  The 
announcement is plain and clear (and inimitably funny, thanks to some, ah, 
'Interesting' humor interjected by Bill N.); do not install on a machine on 
which you care about the data.  You ignore that warning at your own peril; if 
you don't like that, then don't install the test.

5.) 	If you can, investigate what went wrong.  Start checking various pieces 
of hardware; as an example, I had a machine with a generic 52x CDROM, and 
needed to install Win98.  I was using the CD that came with the box, which is 
a Dell.  The CD drive was not original; the original drive had broken.  The 
install went smoothly up to the first reboot, at which point Win98 gave the 
wonderfully helpful 'Windows Protection Error' screen.  Mind you, this is 
after all the files have been copied off the CD.  The short of it is that 
Win98's 32bit IDE driver would not work with that CD-ROM drive (the install 
process uses the real mode driver which works fine); I had to find an older 
drive.  The 52X CD drive works great with Win2k and SuSE 9.0.

6.)	Think before you post acerbic messages to a publicly archived mailing 
list, where it can come back to haunt you.

7.)	If you fail to heed these simple guidelines, understand that your posting 
of trash such as this whole thread is counterproductive and hurts the 
project.  But maybe that's the intention.

For the original poster, you really need to firm up your bug postings.  The 
original posting had way too little detail to help anyone find the bug; how 
can you sanely expect the Red Hat developers to have your exact hardware 
configuration?  Just because you have it doesn't mean anyone else has it.  
Likewise, do you really think Red Hat would release something without ANY 
internal QA into installation?  FC2 Test2 actually does install for some 
people.  The challenge is finding out why it didn't for you, and for a 
developer that doesn't have your hardware to be able to do that you must 
provide a constructive report as to your exact hardware configuration.

You said _IDE_ CDROM a number of times; you do realize that IDE!=IDE, right?  
That is, not all IDE controllers are created equal.  To verify that, check 
the IDE driver source in the kernel.  So the nForce2 IDE controller and the 
Intel 845 IDE controller, to pick two fairly popular examples, might require 
entirely different kernel initialization.  Once initialized, they are still a 
little different and might require different code paths in the driver.  What 
does that mean to you?  It means that it might work on my Pentium 4 with the 
845 and not with your Athlon with the nForce 2.  It would entirely depend 
upon the modules compiled for the BOOT kernel and the initrd that that kernel 
loads; if the right drivers are not there, then 'it no workee!' And since the 
CD boots the BOOT kernel, and the BOOT kernel and the installed kernel are 
compiled differently, then it might install but not reboot!  (I have HAD that 
to happen on my Athlon laptop back in pre-7.something days; there was a code 
optimization that broke pretty badly on the Athlon at that time.  BTW, that 
was when I learned not to install a test release on my production 
hardware.... :-)).

FWIW I intend to install the test on several machines; unfortunately not my 
Athlon laptop (which is my production box) nor my good servers.  I may get 
time to try it on my slightly older AthlonXP box and my socket370 P3-S 1.3G 
box, but probably not on my ServerWorksIII Xeon box (as it's production and 
mission-critical).  Use some common sense; that's all.  Is that too much to 
ask of testers?  

ISTM that Red Hat would have a much smaller headache if they went back to the 
old private beta/public beta scheme.  Not to brag or anything (since I was a 
part of the old private beta team), but Red Hat's private beta program was 
more than a little bit responsible for the solidity of past beta and 
production releases.  Open development is a two-edged sword, and cuts coming 
and a-going.

As to there being a respin, sure, there will be a respin.  It's called test 3.  
Until then, try to find the problem or a workaround.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu