________________________________
From: fedora-test-list-bounces@redhat.com on behalf of Robert P. J. Day Sent: Tue 3/30/2004 6:59 AM To: For testers of Fedora Core development releases Subject: Re: FC2 test2 is a BAD joke
On Tue, 30 Mar 2004, Douglas Furlong wrote:
On Tue, 2004-03-30 at 09:55, Manu Abraham wrote:
It is not just the developer alone. Consider the people who download the ISO's over relatively slow links and try it on their machines, just to find their data just vanished.
I seem to sense a level of sarcasm in this particular sentence.
These people that are downloading a test release over an extremely slow link would have to have a fairly large desire to use a test release. for what ever reason. I would have thought they would do this knowing that it was a test release and as such may not work for every one.
i have some sympathy with mr. abraham in this instance. there's nothing wrong with bugs in a beta/test release, and everyone realizes that. so we download it, install it, test it, find bugs, and keep updating as those bugs get shaken out.
but all of that assumes you can get the software onto your machine in the first place. this suggests that, more than anything else, the installation procedure has to be flogged pretty hard before getting out the door to make sure it works.
it's one thing to help test software once you get it onto your system. it's somewhat more serious to not even be able to get it onto your system to begin with, which goes a certain distance in explaining some folks' frustration level.
======================================================================
Sorry, I won't be so nice.
I see this as plain negligence!!
Who is in charge of Q/A??
And don't give the excuse that this is a test release, I am tired of hearing that excuse.
=======================================================================
rday
p.s. it's for precisely that reason that i asked previously, will there be a respin once this issue is resolved? under the circumstances, i don't see how there can't be. just my $0.02 canadian. (which, these days, is getting dangerously close to being $0.02 US. :-)
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
[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.
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
On Tuesday 30 March 2004 10:21 am, Christian B. Ellsworth Capo wrote:
Stoping the flame....
Digging a little deeper in steps, eh? (Stoping is stepwise strip-mining, but I'm sure you meant stopping... ;-)). (OT: a man got out of a ticket in the US one time due to that misspelling: the sign said 'No Stoping', he stopped at the sign, got a ticket, and beat it in court because he was not 'stoping' -- that is, strip mining -- in front of the sign. English is a very broken language, no?)
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
Good news.
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
On Tue, 2004-03-30 at 07:47 -0500, Williams Jr, Ernest L. wrote:
I see this as plain negligence!!
I'm sorry. Consider this a refund of all the money you spent on this test release. :P
I suppose it was inevitable that people would complain once they had access to all the betas. Betas break, often in weird and mysterious ways. Red Hat does care, we will do our best to fix the bugs you find (and file in bugzilla), we don't intentionally ship broken code so that we can giggle as errors scroll down your screen. Just because its called a "test" release doesn't make it any less beta.
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader
"The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley's "Brave New World"
Everyone:
I have tried this on a 2 desktops with Lite-On and Philips Cd drives and also a Thinkpad T30. Both desktops have high-end Gigabyte p4 motherboards and have never given me the slightest problem.
I can't seem to get yum 2.61 to work, even though it tells me it has de-installed 2.60 yum it still seems to run though from what I am reading that makes no difference.
Anyone have any OTHER way I can get this thing to install?
thanks, Lee mail@Lotus-Notes.Net
----- Original Message ----- From: "Tom 'spot' Callaway" tcallawa@redhat.com To: fedora-test-list@redhat.com Sent: Tuesday, March 30, 2004 10:16 AM Subject: RE: FC2 test2 is a BAD joke
On Tue, 2004-03-30 at 07:47 -0500, Williams Jr, Ernest L. wrote:
I see this as plain negligence!!
I'm sorry. Consider this a refund of all the money you spent on this test release. :P
I suppose it was inevitable that people would complain once they had access to all the betas. Betas break, often in weird and mysterious ways. Red Hat does care, we will do our best to fix the bugs you find (and file in bugzilla), we don't intentionally ship broken code so that we can giggle as errors scroll down your screen. Just because its called a "test" release doesn't make it any less beta.
~spot
Tom "spot" Callaway <tcallawa(a)redhat*com> LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader
"The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley's "Brave New World"
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
-
Christian B. Ellsworth Capo -
Ernest L. Williams Jr. -
Lamar Owen -
mail＠lotus-notes.net -
Tom Callaway