On Sat, 05 Jan 2008 13:28:07 +0100, Till Maas wrote: > I would like it more when first every bug gets marked NEEDINFO_REPORTER and > ask him whether or not the problem still exists and in case it does, to > adjust the version of the Bug report or close it with e.g. currentrelease. In > case the reporter did not respond within two weeks, ping him via bugzilla and > then another two weeks later, close the bug with WONTFIX or INSUFFICANT_DATA. > This is at least a little better bug reporter experience. 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. It 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". 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. 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. > This is more or less > what I did when I started to comaintain some packages, that had several bugs > and the maintainers too little time. Please don't forget that bug reporters have limited time only, too. Bug triagers should focus on filling a queue with tickets, where package maintainers commit to taking a serious look at those tickets. 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
