On Mon, 2009-04-20 at 09:01 +0800, John Summerfield wrote: > Adam Williamson wrote: > > > > > At present, the status is that these are more or less ignored by > > Bugzappers and most maintainers; some maintainers use and set them for > > their own packages according to their own system. The reason for their > > neglect, as I see it, is that there's been no convention for their use, > > and no overall responsibility in setting them - they're usually set > > arbitrarily by reporters, and thus convey no useful information. > > This is offensive. I am one such user. > > I set fields as thoughtfully as I'm able, given the lack of guidelines. > I've mentioned my thoughts on reasonable values and meanings here before. As I mentioned, I didn't want to go into this topic in too much depth in the mail to developers because it's irrelevant, and it's never a good idea to have meat in a mail that can fuel a debate you really don't want to get started. The fact that there are no agreed definitions of what these fields actually means is enough to make them useless. No matter how thoughtfully you set them, at present, they are not doing anything - you wasted your time. This isn't your fault, it's just the way things are at present :) > I'm the only person able to assess the importance of a bug _to me._ If a > bug in any package, no matter how unimportant it might seem to some > triager, prevents my use of a computer, then that bug is critically > important to me. Here's the news: how important it is to you doesn't matter. That's oversimplifying, but that's the meat. What matters is how important it is to the project. Obviously, how important it is to you feeds into that, but that's the correct status of "how important is this bug to the individual person who reported it": it's *one* of the components that goes into evaluating the importance of the bug as far as the project (and hence the maintainer) is concerned, not the *only* one. A crasher bug which affects only people in Poland running with Turkish locales while facing the moon and howling on alternate Wednesdays is, of course, very important to people in Poland running with Turkish locales while facing the moon and howling on alternate Wednesdays, but is not as important to the project as a crasher bug which affects everyone. The severity/priority fields in Bugzilla evaluate the importance of the bug as far as the project is concerned, not the importance of the bug as far as the reporter is concerned. This is the right way to do things. Bugzilla is a tool whose function is improving the efficiency of development of software. It is not there to massage the ego of those who submit reports to it. Take a step back, and you'll realize this. If there was a bug tracker where a team of hundreds of helpful people helped you file a superb report which encapsulated all your problems in perfect, minute detail, and categorized them in every way according to your own exact desires and evaluations - and then nothing else happened, because no developer ever saw any of the bugs - its value would be precisely zero. Should that make you happy? No, it shouldn't. > Xen proved not to work satisfactorily, and I spent more time fighting > with it than enjoying it. > > Over time, xen dropped from supported Fedora, and KVM appeared. Sadly, > KVM does not work reliably either. > > For me, those are critical problems. Today, the best solution I have is > to run Windows XP on that computer, even though Windows doesn't use all > the RAM. > > A triager might assess problems with those packages as relatively > unimportant "because 90% of people don't use those." This would not be the case. At least one of the two fields will definitely be used, in the proposal, to evaluate the importance of the issue solely in terms of the component in which the issue actually occurs. A bug that stopped KVM from working entirely would of course be a critical bug in the context of KVM. > Another example. > I am one who does not like KDE 4.0. At least, 4.0. I haven't had a > decent chance to play with newer KDE. I've used KDE for years, since 1.x > and GNOME was a contender in my affections, ruled out because of its > lack of reliability. Recent GNOME's reliability is fine, though it has > some annoyances (where's klipper? Heck, I had something of the kind on > OS/2), but basically it gets the job done. So does XFCE, and both are > workable alternatives. From the package perspective, KDE's new design > (IMV) is a serious problem, and I don't normally use it, but it doesn't > prevent my use of the computer, and I don't care _that_ much about it. This is far beyond the scope of any kind of triage, and hence irrelevant to this proposal. > In return, triagers (and maintainers for that matter) should accept that > . Some users know more than they do > . Some bugs are in design. "That's how it's documented to work" isn't > always the right answer. This is a call for developers to make, not triagers. Unless the triager already knows from previous developer feedback, a triager should not make the decision to close a bug because 'that's how it's supposed to be' - it will be passed on to the developer. If a developer closes a bug in this fashion, future discussion should be directed to the appropriate mailing list (or other discussion forum for the project in question), because it's beyond the scope of Bugzilla. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
