On Friday, July 31, 2015 09:55:30 PM Thomas Lübking wrote: > On Freitag, 31. Juli 2015 19:29:53 CEST, Ingo Klöcker wrote: > > I also do not see the point in nagging the user after a certain period of > > time if nobody else ever cared to comment on the bug. Feels a bit like > > little kids asking "Are we there yet?" over and over again. > > The idea is not only to get rid of cruft (bugs which "auto-fixed" either > implicitly by eg. code cleanups or as dupes) but also to remind developers > by resubmission (eg. when a bug fell off the table during high activity > periods) > > I do see the point in Daniel's proposal because the time a release goes > > EOL > > feels like a sensible point in time for asking whether the bug still > > exists. > - when do "unspecified" version bugs EOL?
"Unspecified" version is IMO a silly thing in the first place. How is
developer supposed to fix a bug if he does not know what version it happens
with? I can see the point of it for wishes, but there I think it was agreed
above that auto-closing should not affect those.
> - when do "git" version bugs EOL?
Hmm, good question. Maybe when a new version is released, all "git" bug
reports should be moved to that version?
> - what defines EOL? supported versions in bugzilla?
Could be. That of course assumes someone maintains the list.
> - What if a user reports a bug against a version that turns EOL next week?
Then either the bug can be reproduced in newer version too and should be
reassigned, or it has already been fixed and will be closed. If your concern
is that the bug report would not get the "about to go EOL" notification, I see
two ways:
1) there's a bot watching for new bugs and it will add the "this
version is
about to go EOL on $data" comment automatically,
2) or we explain the situation again in the final closing comment so
that
users know they still can reassign to newer version and reopen
> - Do we want bugs to be forgotton for 3 years or more and then tell the
> reporter: "we're now dropping support, sorry that nobody ever cared. if you
> want this to go unnoticed for another three years, please reopen the bug"?
>
> A friendly reminder for user and developer (eg. until the bug could be
> CONFIRMED) to keep bugreports alive seems the better - and half a year is
> not exactly "nagging", but will also typically cross many distro updates.
I like the idea of a nag and I don't think it necesarily conflicts with the
ideas above. Having a weekly/bi-weekly nags to developers would IMO work
("hey, you have 10 new bugs this week that you did not comment on or confirmed
yet, please look at them asap"). If the developer ignores the bugs even after
that then it becomes a different problem, but that I don't know how to solve.
Dan
>
> Cheers,
> Thomas
--
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc
Description: This is a digitally signed message part.
