Felix Miata
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