On 06/10/23 15:21 (GMT-0400) Andreas Jaeger apparently typed:

Felix Miata writes:

...

...

https://bugzilla.novell.com/show_bug.cgi?id=204324

...

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