Felix Miata <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], 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
pgpe1WsVl3NNq.pgp
Description: PGP signature
