FC2 test2 is a BAD joke

Tue Mar 30 15:21:23 UTC 2004

Stoping the flame....

FC2T2 installs on both of my testbed machines
a HP vectra PC (i440BX) local and thru NFS install
a OEM, Aopen MOBO/Cel1.7, 512 ram, sis chipset, local and thru NFS
install 

On Tue, 2004-03-30 at 10: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.]
> 
> > 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
-- 
Christian B. Ellsworth Capo (k at dicec.cl)
Linux Chief Engineer
RedHat Certified Engineer (RHCE)

DICEC Ltda.
Mariano Sanchez Fontecillas 966b, Las Condes, Santiago, Chile.
Phone (56 2) 2633340
Fax (56 2) 2071820
Mobile (56 9) 4195632

All Your Base Are Belong To Tux