On Sun, 29 Jan 2012 09:23:19 -0800, AW (Adam) wrote: > On Sat, 2012-01-28 at 20:43 +0100, Michael Schwendt wrote: > > > Then you have misunderstood it, unfortunately. I'm not against EOL ticket > > cleanup procedures in general. I'm against closing tickets repeatedly > > after it has been shown that an issue is still present in the current dist > > and nobody has proven the opposite. Especially, if a problem is due to a > > packaging issue in a specific package (and that has been pointed out > > explicitly), a bug zapper could notice that the package has not been > > modified (beyond automated rebuilds) and _cannot_ fix the issue. > > Ah, sorry: the ones I clicked from your post did not have such comments,
They did, and there are even ones I could come up with, which have had patches attached and "EasyFix" and possibly even "Triaged" set. One of the two explicitly linked examples, https://bugzilla.redhat.com/459206 , mentioned what was wrong in the package, got an EOL warning nevertheless, got updated to a current dist, got another EOL warning a few months later, got closed at EOL because nobody continued to play "that game". For some issues, provenpackager access is a two-side sword. It doesn't make much sense to touch packages, which suffer from lack of maintenance according to the list of open tickets. And if one appears with name and email address in the package %changelog, that leads to some users contacting this person about the package. So, some packages one better doesn't touch. > so I thought you were just complaining about cleanups in general. Nah. Adam, it makes sense to mass-process thousands of old tickets in an attempt to seek for confirmation whether issues are still reproducible with a current dist. I back up this effort. I've done that before in messages (and it's obvious you cannot remember everything someone said on a mailing-list or in other places). The process is flawed, however, if tickets that get updated appropriately, don't result in a higher priority or are not taken off the bug zapper list. At least the bug id (the number) could serve as an early warning-system, because it tells how old the ticket is. > What's needed to be sure the bug doesn't get closed is for the Version > field to be bumped to a release that's not going EOL. A comment may do > the job, but there's usually hundreds of bugs in the list to be EOLed > and it's usually a single person compiling the EOL list; they don't have > time to inspect _every_ ticket manually (the weeding is more along the > lines of 'look through the summary list for bugs that look like they may > be special cases'). qed ;-) Would a special tag in the bug summary be helpful? Or a keyword that would exclude the ticket from the compiled list automatically? If a second search on all tickets with that keyword results in hundreds or thousands of ticket numbers, that should raise an alarm-bell. It's sad to talk to Fedora users (and ex-Fedora users), who have made bad experience in bugzilla related to this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
