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@xxxxxxxxx> <ajfarris@xxxxxxxxx>
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
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
