[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fwd: closing out old bugs of unmaintained releases



Kevin Fenzi wrote:
Note that you might want to wait until after fudcon and until you have
gotten input from everyone before doing anything hasty...

Probably a good idea to not be hasty on a large step like this, but the same problem has been around since FC1 (forever?).

before doing so, I wanted to make sure that our messaging is crystal
clear.  What I had been doing for kernel bugs is placing them in
NEEDINFO_REPORTER and asking if the problem still existed, etc after
manually reviewing the bugs (some I changed to a current release
because it was mentioned in comments, but not in the version
metadata).  However, this won't scale - there's no way that I or
anybody else can reasonably review 3600 bugs for ones that are
incorrectly tagged.

Sure, agreed 100%, but closing them makes less work for us, but makes
anyone who filed them in the past where they were ignored pretty mad.
See: http://www.jwz.org/doc/cadt.html

He may have a point of interest there, but like it or not new code bases get released. This is something the upstream project leads need to consider thoughtfully, not so much those working with the bugs later.

How about instead we move them all up to a current release... Then, the maintainer should ping them or deal with them in some way.
I'm concerned that these sort of mass closings or "clear the deck" just
ends up annoying bug submitters, and doesn't really help us in the long
term since it just happens again a few releases down the road... so all kinds of bugs get filed, ignored, then closed, even when they still do affect current releases.

Eeww, moving bugs across releases is a worse idea than mass closing frankly. The rate that major things change in fedora is too rapid to do this and hope that the bugs can be figured out... the second you try this you've got to go back and ask 'ok which version of xx and xx and xx and xx were installed' when thats not necessarily as important if you know the release. (think changes in gcc and glibc from release to release)

If you want to avoid bug reporter frustration then confusing the hell out of them is a bad idea too. It is far simpler to ask bugs to be refiled or edited to indicate they still apply to new releases after the reporter figures out that they do.

Why cannot the bugs be left open and just simply filtered by non-EOL releases? This would feel a little bit less like your work as a bug reporter is being ignored (while it still is for those bugs). The maintainers would be able to look at open old bugs if they know the code base is still shared, and easily filtered if its not. But at the same time no matter what is done, those bug reporters should be upgrading and identifying if the bugs still exist in new releases, so something should be done to indicate to them that the old bugs are stale.

Would it be possible to choose a preset response for these bugs now, but not apply them in mass closing... then asking bug triage to close those bugs as quickly as possible where 1) the release is EOL, 2) the component has changed major versions from that EOL release to current. Bugs that are for EOL releases but have similar component versions in new releases should be left open as they probably still apply. I suspect closing those alone would have a big impact in the number of bugs still open.

--
Andrew Farris <lordmorgul gmail com> <ajfarris gmail com>
 gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]