[opensuse-factory] Re: [Bug 204324] Broken vesa driver
On 06/10/23 08:47 (GMT-0400) bugzilla_noreply@novell.com apparently typed:
sndirsch@... changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |mrmazda@...
------- Comment #50 from sndirsch@... 2006-10-23 06:47 MST ------- Please retest with Beta1 - to be releaesd this week - by installing from a CD, since this is an installation, which we can reproduce.
Either Dirsch or I seem to be misunderstanding what factory ftp is and/or is for. Why does Dirsch seem to think I need to waste my time burning and installing from CD instead of just installing from FTP? Does Dirsch not understand that even after 10.2 is released that FTP installs will need to succeed? Does Dirsch not understand that retests only from DVD or CD mean that retests get delayed and could prevent a fix from being found and verified prior to release date? Is Dirsch the only Novell person capable of trying to recreate this bug or verify a fix? From Dirsch's comments in this and other bugs it seems he has limited resources at his disposal. Aren't i81x chipsets rather common? Why has this bug been open so long? -- "The Lord is my strength and my shield; my heart trusts in him, and I am helped." Psalm 28:7 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 23 October 2006 08:19, Felix Miata wrote:
Either Dirsch or I seem to be misunderstanding what factory ftp is and/or is for. Why does Dirsch seem to think I need to waste my time burning and installing from CD instead of just installing from FTP? Does Dirsch not
It seems to me that he's explained why he asks for the Beta1 install. The CDs are set milestones which he tests. I don't think he's saying you can't do an FTP install, but he wants it done on a milestone release. I don't know why he wants it done on a milestone release rather than factory, other than maybe RPM versions will be consistent. With Beta1 being released this week, I don't think Stefan is out of line for asking you test with that.
understand that even after 10.2 is released that FTP installs will need to succeed? Does Dirsch not understand that retests only from DVD or CD mean that retests get delayed and could prevent a fix from being found and verified prior to release date? Is Dirsch the only Novell person capable of trying to recreate this bug or verify a fix? From Dirsch's comments in this
Stefan is the Video / Display expert.
and other bugs it seems he has limited resources at his disposal. Aren't i81x chipsets rather common? Why has this bug been open so long?
Don't we all wish we had unlimited hardware resources? I do, at least. I think that's one of the reasons the opensuse development model exists -- People like yourself have hardware the SUSE labs may not have, and thus more problems can be identified & addressed. My guess is that Stefan (and the other SUSE developers) all have several issues that they're trying to address, some more critical than others. We don't see their queue of issues they need to get addressed each day. I commend them for accomplishing all that they do. - Chad --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Felix Miata <mrmazda@ij.net> writes:
On 06/10/23 08:47 (GMT-0400) bugzilla_noreply@novell.com apparently typed:
sndirsch@... changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |mrmazda@...
------- Comment #50 from sndirsch@... 2006-10-23 06:47 MST ------- Please retest with Beta1 - to be releaesd this week - by installing from a CD, since this is an installation, which we can reproduce.
Either Dirsch or I seem to be misunderstanding what factory ftp is and/or is for. Why does Dirsch seem to think I need to waste my time burning and installing from CD instead of just installing from FTP? Does Dirsch not understand that even after 10.2 is released that FTP installs will need to succeed? Does Dirsch not understand that retests only from DVD or CD mean that retests get delayed and could prevent a fix from being found and verified prior to release date? Is Dirsch the only Novell person capable of trying to recreate this bug or verify a fix? From Dirsch's comments in this and other bugs it seems he has limited resources at his disposal. Aren't i81x chipsets rather common? Why has this bug been open so long?
Stefan is a capable software engineer that is working full time on X11 - as part of a team. None of our engineers has unlimited resources in time or hardware but they do an excellent job with what they have. With hardware it's always a problem to reproduce what you have. Looking at the whole bugzilla entry, I see that Stefan tried his best to fix the problem with the available hardware he has and he managed that with similar card. But graphics cards are so varied that this sometimes does not help. You miss a subtile difference between ftp installs and our factory tree. For openSUSE 10.2 final, we will have a ftp installation tree that is fixed and has the same sources like our ISOs. The factory tree is in constant flux since it's synced out several times a week. Nobody knows exactly what state that tree is in at any time since it changes the whole team. For testing difficult things we sometimes need a fix point where we know that everything works together. That's why Stefan asked you to test such a fix point - beta 1 - so that he knows you have a consistent distribution and he has exactly the same tree for his testing. We do take in general bug reports for the factory distribution but sometimes its permanent changing state is not what you need to debug. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 06/10/23 15:21 (GMT-0400) Andreas Jaeger apparently typed:
Felix Miata <mrmazda@ij.net> writes:
Either Dirsch or I seem to be misunderstanding what factory ftp is and/or is for....
Stefan is a capable software engineer that is working full time on X11 - as part of a team. None of our engineers has unlimited resources....
You miss a subtile difference between ftp installs and our factory tree. For openSUSE 10.2 final, we will have a ftp installation tree that is fixed and has the same sources like our ISOs. The factory tree is in constant flux since it's synced out several times a week. Nobody knows exactly what state that tree is in at any time since it changes the whole team. For testing difficult things we sometimes need a fix point where we know that everything works together. That's why Stefan asked you to test such a fix point - beta 1 - so that he knows you have a consistent distribution and he has exactly the same tree for his testing. We do take in general bug reports for the factory distribution but sometimes its permanent changing state is not what you need to debug.
I think maybe those who responded to my post are missing the reason why I posted. I have no doubt Dirsch is good. If he wasn't, Novell wouldn't have him on its payroll. This is not about Dirsh. It's about the SUSE developement system. I'm not a software engineer, but I am a somewhat advanced beta tester. I filed my first open source software bug in February of 2001, against the Mozilla Web Suite. I've filed a total of 276 bugs in Mozilla's Bugzilla system. In November of 2002 I filed my first Mandriva (as Mandrake) bug, and have filed a total of 70 in that Bugzilla system. In both, I do what I can to assist in various phases of QA, mostly trying to confirm or dupe recently filed bugs. I've also filed bugs in the Samba, Fedora, KDE, and Ubuntu bug tracking systems, among others. My current count of working systems is now 19, ranging from one ancient 486DX66, through P55MMX and K6* socket 7 systems @ 233-550 MHz, various PII, PIII & Celeron Slot 1 and Socket 370 systems from 350 MHz up to 933 MHz, and three K7 P4 & Celeron systems running upwards of 1.6 GHz. My 5 fastest have 512M or more RAM. 9 have 256M. Several have (LSI Logic) SCSI. Few have burners or DVD readers or sound chips/cards. Most have video that anyone around such equipment at least 10 years is familiar with, Tseng PCI in about 7, Matrox AGP in about 5, Intel onboard in a few, and mostly ATI AGP in the rest. Most have 3 or more operating systems installed, some upwards of 10. Most that have any Linux installed have at least one version of SUSE installed. All but one of my SUSEs were installed via FTP (as most of my Linux installs), and that one only because of Dirsch's request. I may be wrong, but I think a professional development team should have a considerably wider range of available hardware to test on than I have. When I see a developer make a claim in a bug that "he" is unable to reproduce, I get the impression that this is not the case, as "he", being a member of a "team", is ostensibly speaking for the whole team, and thus if "he" cannot reproduce a reported problem, the whole team cannot reproduce. As a relatively new participant in the relatively newly open source version of the SUSE development process I can't help but compare that process to that of Mandriva's Cooker, in which I've been participating far longer. In Cooker, bug owners rarely recommend reporters and other bug observers wait until an iso milestone to confirm or deny that a bug reportedly fixed has indeed been fixed. Like the Factory mirrors, the Cooker mirrors are in a virtually constant state of flux. It too will freeze briefly in order to ensure good isos when the times come for them. But bug owners there generally want to see to it that bugs they are working on get tested ASAP. When they provide a fix, they ask for immediate testing, not testing in some future milestone. This is normally easily accomplished, by doing 'urpmi update; urpmi --auto-select', which if done daily, usually takes maybe 10-15 minutes, and if weekly, well under an hour. Often because of the flux, something breaks, but usually that will be unrelated to whatever bug you're attempting to follow up on and will not impact the evaluation. Expedient follow-up is particularly important with installer issues, which is what bug 204324 is. Doing otherwise invites installation issues to remain uncorrected for long periods of time. There should be nothing about the rest of the contents of some milestone that should impact whether a typical installer bug on legacy mainstream hardware is corrected. I do what I do as time permits. When told to wait, my quite fallible old memory tends to forget things with such inferred unimportance. When I get bugmail that tells me I should do something, but not now, not now tends to last a while. If you want me as a volunteer member of the community to continue to help you, I expect you to avoid having me waste my time or money, just like you expect me to try to avoid wasting yours. That's not what I'm seeing in bug 204324. Maybe I'm mistaken, but that's not the impression I get by being told to wait and test an installer bug after the next iso set is released instead of ASAP. -- "The Lord is my strength and my shield; my heart trusts in him, and I am helped." Psalm 28:7 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Felix Miata <mrmazda@ij.net> writes:
I think maybe those who responded to my post are missing the reason why I posted. I have no doubt Dirsch is good. If he wasn't, Novell wouldn't have him on its payroll. This is not about Dirsh. It's about the SUSE developement system.
Then your message was not clear.
[...] I may be wrong, but I think a professional development team should have a considerably wider range of available hardware to test on than I have. When I see a developer make a claim in a bug that "he" is unable to reproduce, I get the impression that this is not the case, as "he", being a member of a "team", is ostensibly speaking for the whole team, and thus if "he" cannot reproduce a reported problem, the whole team cannot reproduce.
We have a wide range - but we cannot have everything...
As a relatively new participant in the relatively newly open source version of the SUSE development process I can't help but compare that process to that of Mandriva's Cooker, in which I've been participating far longer. In Cooker, bug owners rarely recommend reporters and other bug observers wait until an iso milestone to confirm or deny that a bug reportedly fixed has indeed been fixed.
Like the Factory mirrors, the Cooker mirrors are in a virtually constant state of flux. It too will freeze briefly in order to ensure good isos when the times come for them. But bug owners there generally want to see to it that bugs they are working on get tested ASAP. When they provide a fix, they ask for immediate testing, not testing in some future milestone. This is normally easily accomplished, by doing 'urpmi update; urpmi --auto-select', which if done daily, usually takes maybe 10-15 minutes, and if weekly, well under an hour. Often because of the flux, something breaks, but usually that will be unrelated to whatever bug you're attempting to follow up on and will not impact the evaluation.
This is what we do in general and advise packagers to do - to use our factory tree for our advantage. Just sometimes you need a fixed point...
Expedient follow-up is particularly important with installer issues, which is what bug 204324 is. Doing otherwise invites installation issues to remain uncorrected for long periods of time. There should be nothing about the rest of the contents of some milestone that should impact whether a typical installer bug on legacy mainstream hardware is corrected.
I do what I do as time permits. When told to wait, my quite fallible old memory tends to forget things with such inferred unimportance. When I get bugmail that tells me I should do something, but not now, not now tends to last a while.
If you want me as a volunteer member of the community to continue to help you, I expect you to avoid having me waste my time or money, just like you expect me to try to avoid wasting yours. That's not what I'm seeing in bug 204324. Maybe I'm mistaken, but that's not the impression I get by being told to wait and test an installer bug after the next iso set is released instead of ASAP.
Thanks for the explanation. I hope we can get these resolved and continue learning from each other, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Mon, 23 Oct 2006, Felix Miata wrote:
On 06/10/23 08:47 (GMT-0400) bugzilla_noreply@novell.com apparently typed:
https://bugzilla.novell.com/show_bug.cgi?id=204324 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |mrmazda@...
------- Comment #50 from sndirsch@... 2006-10-23 06:47 MST ------- Please retest with Beta1 - to be releaesd this week - by installing from a CD, since this is an installation, which we can reproduce.
Either Dirsch or I seem to be misunderstanding what factory ftp is and/or is for. Why does Dirsch seem to think I need to waste my time burning and installing from CD instead of just installing from FTP? Does Dirsch not understand that even after 10.2 is released that FTP installs will need to succeed? Does Dirsch not understand that retests only from DVD or CD mean that retests get delayed and could prevent a fix from being found and verified prior to release date? Is Dirsch the only Novell person capable of trying to recreate this bug or verify a fix? From Dirsch's comments in this and other bugs it seems he has limited resources at his disposal. Aren't i81x chipsets rather common? Why has this bug been open so long?
I have worked with Mr Dirsch and I find him very reasonable to work with. I think the point trying to be made is that when beta1 is released this week factory will be frozen for a couple days and that testing during this time will allow a set point that a good comparison can be made. Factory is constantly changing and may be broken at any time. The Beta 1 will be a known working point that things can easily be used to reference and verify/trouble shoot/fix the bug. I do not see the request as being unreasonable to the reasons I have mentioned above. I find all the SuSE developers very willing to fix real problems when they can be verified and replicated so the bugs can be found and fixed. My gratitude goes out to all the People both in an out of Novell working to make this the best distribution. Thanks, -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (4)
-
Andreas Jaeger -
Boyd Lynn Gerber -
Chad Groneman -
Felix Miata