On Jan 5, 2008 11:47 AM, Michael Schwendt <mschwendt.tmp0701.nospam@xxxxxxxx> wrote: > Better? I doubt that. Many a bug reporter will be annoyed when after > months or a year of ignoring a ticket and not fixing the bug somebody > comes along and puts pressure on the reporter to allocate time for > retesting. That exact phenomenon is what led me down this road (not this particular course of action, but the realization that something had to be done). [1]. I was bound and determined to end that cycle, and have more instances like [2]. > t is even more rude to close such old bugs as WONTFIX or > INSUFFICIENT_DATA. When only after the EOL of a distribution version there > is activity within a ticket, that is like saying "we didn't care about > your bug report this time, and we don't promise either that we look into > the issue this time". Is there some other reasonable course of action? I'm sure that there will be people with that perception, but I'm not sure what to do about it. I'm remembering back to my high school days now, when a teacher used to tell me (and attributed it to someone else, but I can't for the life of me remember who) "you can please some of the people all the time, you can please all of the people some of the time, but you can't please all the people all the time". > Actually a reporter expects a package maintainer to > evaluate a new report ASAP and make use of NEEDINFO states ASAP, so > _sufficient data_ could be provided while the issue is _hot_. The packager > ought to tell whether the provided data are insufficient and whether the > problem is reproducible. Either that or a triager to do the same. People do not expect their bugs to be magically fixed (some do, but those people are unreasonable IM[NS]HO). What they expect is someone to say "yes, we have received this report. Your voice is heard. Maybe I'll poke a developer about this". Part of the job of a good triage team is maintainer/developer interaction. > When however it takes too long for the packager > to handle a bug report, that increases the risk that the reporter moves on > with different sofware/release or abandoning to use the software that > causes trouble. See [1] > Please don't forget that bug reporters have limited time only, too. Agreed. Which is why mass-closing is such an appealing thing from both sides of the fence. It's been mentioned in this thread (not sure if on this list or another, I'll go back and look), that the message used to mass-close should basically admit the fact that we know that we have a problem, and that we are taking action to fix the problem in the future so that we don't get into this state again. > Bug triagers should focus on filling a queue with tickets, where package > maintainers commit to taking a serious look at those tickets. I think that one of my proposals is going to be a fedora-triage flag or something similar. Maintainers can look at that and know that the bug has been reviewed by a triager, that it's not a duplicate, and that the priority/version/component settings on the bug are sane. > The NEEDINFO > state should be used when there is committment to moving forward with a > ticket, not just to give the reporter something to do after a long of no > interest in the report. Are you saying that triagers should not use NEEDINFO for current bugs? At that point, there's not developer commitment, there is triager commitment. [1] https://bugzilla.redhat.com/show_bug.cgi?id=204883 [2] https://bugzilla.redhat.com/show_bug.cgi?id=427157 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
