FC2 test2 is a BAD joke
Ernest L. Williams Jr.
ernesto at ornl.gov
Wed Mar 31 04:08:26 UTC 2004
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>
More information about the test
mailing list