FC2 test2 is a BAD joke

[Ernest L. Williams Jr.]

On Tue, 2004-03-30 at 09:42, Lamar Owen wrote:
> [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.]

I also am interesting in Fedora being the best.  With the tight schedule
wasting time on not getting the installation CDs correct "out of door"
does not make sense.
However, I will rant no more; the points you make below are well taken.
I am proceeding with FC2T2 on more of my test machines and indeed will
use bugzilla.



> 
> > 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
-- 
Ernest L. Williams Jr. <ernesto at ornl.gov>