Fwd: closing out old bugs of unmaintained releases

Andrew Farris lordmorgul at gmail.com
Fri Jan 4 21:49:14 UTC 2008


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 at gmail.com> <ajfarris at 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
----                                                                       ----




More information about the fedora-devel-list mailing list