----- Original Message ----- > On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: > > The problem is that no-one seems to come up with an alternative that's > > any better. Leaving bugs on EOL versions open to rot away and be ignored > > is no use. We *could* give everyone privs to re-open closed bugs, I > > guess, and I personally don't think that would end terribly, but it's > > kind of a radical plan. > > I would like to see one of the following, in order of preference: > > 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with > a notice similar to the current one. (Essentially moving the current > warning back a little bit.) > > Step one point five: I believe pretty much anyone can clear the NEEDINFO > flag. > > Step two: when the *next* release hits EOL (and the release under > consideration has been EOL for approximately 6 months), move any bugs > still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a > message similar to the current EOL note. > > EOL wouldn't be visibile as an available status for bugzilla users to > select when closing a bug in the interface, so it does not add to UI > clutter, but also makes it easy for us to do reports distinguishing > between intentional and eol closure. > > This gives a much longer timeframe where we're waiting for input, so by > the time we actually close, the release has been EOL for a decent while > (rather than now, at the "I just got around to updating!" point). > > This does risk some false positives (negatives? whatever) where NEEDINFO > is cleared with "works for me" but the bug not closed, but that seems > like a less serious problem. > > 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or > and add a ClosedEOL keyword automatically. This is uglier than the above > but requires no bugzilla change.
I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for example), even it would be hidden. So keyword looks like much more easier solution. Jaroslav > 3. As #1, but just leave bugs in NEEDINFO state forever. > > This would possibly require maintainers to update their searches / > filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older > releases. > > > Any of these seem pretty easy and I think would improve the situation for > users and bug reporters without badly increasing maintainer burden or being > dishonest about our ability to fix all the things. > > Additionally, but requiring some development, we could add some heuristics > like: don't autoclose bugs with many incoming duplicate pointers, or > possibly (as David suggests) bugs with comments, or bugs which have been > reopened, or (here I get handwavy). > > > -- > Matthew Miller -- Fedora Project -- <mat...@fedoraproject.org> > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
