Re: RFC: KDE Bugzilla Bugs Expiration
On Monday 03 August 2015 19:36:30 Ben Cooksley wrote: > On Mon, Aug 3, 2015 at 9:19 AM, Ingo Klöcker wrote: > > I'm filtering out all kdepim bug reports (yeah, I could just > > unsubscribe from the list). I'll certainly filter out the nag mails > > as well. > > > > If I was still interested in the bug reports then I'd prefer to > > create my own workflow for handling them without being annoyed by > > some robot that doesn't no anything about how I work. > > Note that behaviour such as the above (aggressive filtering) is one of > the reasons Sysadmin moved away from using Bugzilla for our task > tracking - because our replies effectively got ignored until we > pestered developers via IRC or private email. > > Such filters are extremely disrespectful to the community at large > (including users and all other contributors) and should not be used as > they simply result in important issues being completely neglected. I haven't been active in KDE development (as in writing or committing or reviewing code) for almost 10 years (with a few exceptions during some sprints). Before that I have burned myself reading each and every KMail bug report and fixing many of them for a few years. I don't think I'm behaving disrespectful to anybody by filtering out bug reports. Anyway, I have now unsubscribed from the kdepim-bugs mailing list. I should have done this years ago, but I guess I still hoped that I would become more active again someday. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: RFC: KDE Bugzilla Bugs Expiration
- Original Message - > 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? That's another process we have in Fedora - Rawhide rebase. At the point next release branches, we move all Rawhide bugs (except FutureFeature, RFEs etc.) to the branched version as it was reported during the development of this version. I was running it in Fedora for a few years, there was opposition we can't close bugs as people would not report new bugs, sometimes I go through closed bugs and it's sad when it's something really simple. But we are all humans, with other work to do and I think it's honest to reporters to tell them sorry, we have limited resources. Also it requires some activity from reporter and developer so many bugs are revived and even fixed in this period. The other thing we try is to make reopening bugs as easy as possible, explain what we do and why we do it. Of course, sometimes it's hard but I think it's worth. It keeps Bugzilla clean. https://fedoraproject.org/wiki/Fedora_Program_Management/EOLRebaseSOP Just as Kevin pointed out - it's much more easier in Fedora Bugzilla, as it's one "product" developed at one time. I used simple perl script that processed CSV exported from Bugzilla query. I'm not sure if Bugzilla Rule Engine already hit upstream/KDE Bugzilla but that could be another tool to help with cleanups... Jaroslav
Re: RFC: KDE Bugzilla Bugs Expiration
On Mon, Aug 3, 2015 at 9:19 AM, Ingo Klöcker wrote:
> On Saturday 01 August 2015 01:49:13 Daniel Vrátil wrote:
>> 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.
>
> It certainly wouldn't work for me. I know because I'm nagged all the time by
> mailman that there are n messages in the moderation queue. I know this because
> I also receive each individual moderation request. The nagging is just
> annoying.
>
> I'm filtering out all kdepim bug reports (yeah, I could just unsubscribe from
> the list). I'll certainly filter out the nag mails as well.
>
> If I was still interested in the bug reports then I'd prefer to create my own
> workflow for handling them without being annoyed by some robot that doesn't no
> anything about how I work.
Note that behaviour such as the above (aggressive filtering) is one of
the reasons Sysadmin moved away from using Bugzilla for our task
tracking - because our replies effectively got ignored until we
pestered developers via IRC or private email.
Such filters are extremely disrespectful to the community at large
(including users and all other contributors) and should not be used as
they simply result in important issues being completely neglected.
>
>
> Regards,
> Ingo
Regards,
Ben
Re: RFC: KDE Bugzilla Bugs Expiration
On Saturday 01 August 2015 01:49:13 Daniel Vrátil wrote:
> 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.
It certainly wouldn't work for me. I know because I'm nagged all the time by
mailman that there are n messages in the moderation queue. I know this because
I also receive each individual moderation request. The nagging is just
annoying.
I'm filtering out all kdepim bug reports (yeah, I could just unsubscribe from
the list). I'll certainly filter out the nag mails as well.
If I was still interested in the bug reports then I'd prefer to create my own
workflow for handling them without being annoyed by some robot that doesn't no
anything about how I work.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
Re: RFC: KDE Bugzilla Bugs Expiration
On Saturday 01 August 2015 03:09:14 Kevin Kofler wrote: > Christoph Cullmann wrote: > > I think one of the problems with our current Bugzilla database is that it > > contains a lot of "old" bugs and wishs. > > > > As the manpower is limited and we sometimes not even keep up with the > > incoming new bugs, might it be a good idea to adopt a similar strategy > > like the Qt Project and expire bugs that got not changed since more than > > one year? > > > > The idea would that a scripts closes all bugs that have no activity in the > > last year e.g. on a weekly basis and the closing comment would contain > > some gentle note that if the bug is still an issue, the reporter (or any > > person on CC) can just reopen it again. > > > > I think this would make a lot of time consuming bug triaging much easier. > > IMHO, KDE (as in, everything that uses bugs.kde.org) is too large a project > with too different release cycles and maintainership for it to make sense to > do this with global scripts. Keep in mind that 1. bugs.kde.org is used by > much more than just the former KDE SC and 2. even that SC has now been split > into 3 parts (Frameworks, Plasma, Applications) on different release > schedules. Different policies make sense for different applications. So this > should be done with per-application scripts. I would also strongly argue for > keeping this manual for all applications whose maintainer(s) didn't > explicitly opt in to such an autoclosing policy. Which would be completely fine and also agrees with the initial proposal: If an application / component should not be auto-cleaned-up, then we could blacklist it (or the other way round, whitelist). The proposal doesn't come out of nowhere: KDE has this issue for years already, and for the qt-project this solution works quite well it seems. Greetings, Dominik
Re: RFC: KDE Bugzilla Bugs Expiration
Christoph Cullmann wrote: > I think one of the problems with our current Bugzilla database is that it > contains a lot of "old" bugs and wishs. > > As the manpower is limited and we sometimes not even keep up with the > incoming new bugs, might it be a good idea to adopt a similar strategy > like the Qt Project and expire bugs that got not changed since more than > one year? > > The idea would that a scripts closes all bugs that have no activity in the > last year e.g. on a weekly basis and the closing comment would contain > some gentle note that if the bug is still an issue, the reporter (or any > person on CC) can just reopen it again. > > I think this would make a lot of time consuming bug triaging much easier. IMHO, KDE (as in, everything that uses bugs.kde.org) is too large a project with too different release cycles and maintainership for it to make sense to do this with global scripts. Keep in mind that 1. bugs.kde.org is used by much more than just the former KDE SC and 2. even that SC has now been split into 3 parts (Frameworks, Plasma, Applications) on different release schedules. Different policies make sense for different applications. So this should be done with per-application scripts. I would also strongly argue for keeping this manual for all applications whose maintainer(s) didn't explicitly opt in to such an autoclosing policy. Kevin Kofler
Re: RFC: KDE Bugzilla Bugs Expiration
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.
Re: RFC: KDE Bugzilla Bugs Expiration
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? - when do "git" version bugs EOL? - what defines EOL? supported versions in bugzilla? - What if a user reports a bug against a version that turns EOL next week? - 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. Cheers, Thomas
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday, July 31, 2015 07:29:53 PM Ingo Klöcker wrote: > On Friday 31 July 2015 12:00:22 Allen Winter wrote: > > On Friday, July 31, 2015 04:01:37 PM Thomas Lübking wrote: > > > On Freitag, 31. Juli 2015 14:05:09 CEST, laurent Montel wrote: > > > >> Especially for KDE PIM, given the size of the userbase and the amount > > > >> of > > > >> developers (3), bugs often take more than a year to get to and > > > >> to be fixed. > > > > > > > > +1 > > > > As Daniel wrote we have a lot of bug and a very small team. > > > > So we can't able to fix bug in 1 year. > > > > And I don't want to see all bugs closed after 1 year because it's useful > > > > to > > > > read all bug and sometime it takes me some months/years to fix bugs. > > > > > > Wishes: > > > --- > > > should *never* be closed automatically - either a Human declares them > > > WONTFIX or it's "patches welcome" - they may however be resubmissioned > > > again once a year "is this actually reasonable?" so a developer can say > > > "what a bullshit of an idea" and close it ;-) > > > > > > Bugs: > > > - > > > should get regular (every 6 months after inactivity?) updates like "is > > > this still an issue", setting them "WAITING FOR INFO" and if not > > > responded within the next month (and reopened) be closed "WORKS FOR ME" > > > This will eg. remind developers to "oh, yes - I fixed a dupe of this 3 > > > month ago, totally forgot about this one". > > > > > > > > > Autoclosing a bug that maybe has not ever even been touched by a developer > > > is a blunt offense and teaches users to either start nagging (in fear of > > > getting their bug closed) or being frustrated (to avoid 4-letter words > > > ;-) > > > > > > Also "fixing" issues by ignoring them is really bad style. > > > > agree > > dvartil's suggestion to follow the fedora model, in combination with the > > 6month nag seems pretty good. > > I do not see the point in implementing both. 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. > you're probably right. In any event, I'm against the original proposal. > 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. > > > Regards, > Ingo
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday 31 July 2015 12:00:22 Allen Winter wrote: > On Friday, July 31, 2015 04:01:37 PM Thomas Lübking wrote: > > On Freitag, 31. Juli 2015 14:05:09 CEST, laurent Montel wrote: > > >> Especially for KDE PIM, given the size of the userbase and the amount > > >> of > > >> developers (3), bugs often take more than a year to get to and > > >> to be fixed. > > > > > > +1 > > > As Daniel wrote we have a lot of bug and a very small team. > > > So we can't able to fix bug in 1 year. > > > And I don't want to see all bugs closed after 1 year because it's useful > > > to > > > read all bug and sometime it takes me some months/years to fix bugs. > > > > Wishes: > > --- > > should *never* be closed automatically - either a Human declares them > > WONTFIX or it's "patches welcome" - they may however be resubmissioned > > again once a year "is this actually reasonable?" so a developer can say > > "what a bullshit of an idea" and close it ;-) > > > > Bugs: > > - > > should get regular (every 6 months after inactivity?) updates like "is > > this still an issue", setting them "WAITING FOR INFO" and if not > > responded within the next month (and reopened) be closed "WORKS FOR ME" > > This will eg. remind developers to "oh, yes - I fixed a dupe of this 3 > > month ago, totally forgot about this one". > > > > > > Autoclosing a bug that maybe has not ever even been touched by a developer > > is a blunt offense and teaches users to either start nagging (in fear of > > getting their bug closed) or being frustrated (to avoid 4-letter words > > ;-) > > > > Also "fixing" issues by ignoring them is really bad style. > > agree > dvartil's suggestion to follow the fedora model, in combination with the > 6month nag seems pretty good. I do not see the point in implementing both. 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. 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. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday, July 31, 2015 04:01:37 PM Thomas Lübking wrote: > On Freitag, 31. Juli 2015 14:05:09 CEST, laurent Montel wrote: > > >> Especially for KDE PIM, given the size of the userbase and the amount of > >> developers (3), bugs often take more than a year to get to and > >> to be fixed. > > > > +1 > > As Daniel wrote we have a lot of bug and a very small team. > > So we can't able to fix bug in 1 year. > > And I don't want to see all bugs closed after 1 year because it's useful to > > read all bug and sometime it takes me some months/years to fix bugs. > > Wishes: > --- > should *never* be closed automatically - either a Human declares them WONTFIX > or it's "patches welcome" - they may however be resubmissioned again once a > year "is this actually reasonable?" so a developer can say "what a bullshit > of an idea" and close it ;-) > > Bugs: > - > should get regular (every 6 months after inactivity?) updates like "is this > still an issue", setting them "WAITING FOR INFO" and if not responded within > the next month (and reopened) be closed "WORKS FOR ME" > This will eg. remind developers to "oh, yes - I fixed a dupe of this 3 month > ago, totally forgot about this one". > > > Autoclosing a bug that maybe has not ever even been touched by a developer is > a blunt offense and teaches users to either start nagging (in fear of getting > their bug closed) or being frustrated (to avoid 4-letter words ;-) > > Also "fixing" issues by ignoring them is really bad style. > agree dvartil's suggestion to follow the fedora model, in combination with the 6month nag seems pretty good. I strongly disagree with trashing arbitrarily based on the bug's age.
Re: RFC: KDE Bugzilla Bugs Expiration
On Freitag, 31. Juli 2015 14:05:09 CEST, laurent Montel wrote: Especially for KDE PIM, given the size of the userbase and the amount of developers (3), bugs often take more than a year to get to and to be fixed. +1 As Daniel wrote we have a lot of bug and a very small team. So we can't able to fix bug in 1 year. And I don't want to see all bugs closed after 1 year because it's useful to read all bug and sometime it takes me some months/years to fix bugs. Wishes: --- should *never* be closed automatically - either a Human declares them WONTFIX or it's "patches welcome" - they may however be resubmissioned again once a year "is this actually reasonable?" so a developer can say "what a bullshit of an idea" and close it ;-) Bugs: - should get regular (every 6 months after inactivity?) updates like "is this still an issue", setting them "WAITING FOR INFO" and if not responded within the next month (and reopened) be closed "WORKS FOR ME" This will eg. remind developers to "oh, yes - I fixed a dupe of this 3 month ago, totally forgot about this one". Autoclosing a bug that maybe has not ever even been touched by a developer is a blunt offense and teaches users to either start nagging (in fear of getting their bug closed) or being frustrated (to avoid 4-letter words ;-) Also "fixing" issues by ignoring them is really bad style. /my2¢ Thomas
Re: RFC: KDE Bugzilla Bugs Expiration
Le Friday 31 July 2015, 11:07:54 Daniel Vrátil a écrit : > On Friday, July 31, 2015 10:12:00 AM Christoph Cullmann wrote: > > Hi, > > > > I think one of the problems with our current Bugzilla database is that it > > contains a lot of "old" bugs and wishs. > > True that! > > > As the manpower is limited and we sometimes not even keep up with the > > incoming new bugs, might it be a good idea to adopt a similar strategy > > like > > the Qt Project and expire bugs that got not changed since more than one > > year? > > > > The idea would that a scripts closes all bugs that have no activity in the > > last year e.g. on a weekly basis and the closing comment would contain > > some > > gentle note that if the bug is still an issue, the reporter (or any person > > on CC) can just reopen it again. > > We were actually discussing something similar for KDE PIM but our idea was > based on Fedora, i.e. closing all bugs for given release when the release > goes EOL. There is a comment added by a bot 3 weeks before EOL stating that > the release will go EOL and if user thinks the bug is still valid in > newer/current release, they should re-assign to newer release. When the > release actually goes EOL all bugs still assigned to it are closed. The > advantage of this approach IMO is that it also clears out bugs where the > reporters are no longer available/willing to provide additional info to > devs and at the same time without losing bugs which might be important yet > non-trivial to fix (read: take more than a year for a dev to get there). > > Especially for KDE PIM, given the size of the userbase and the amount of > developers (3), bugs often take more than a year to get to and to be fixed. +1 As Daniel wrote we have a lot of bug and a very small team. So we can't able to fix bug in 1 year. And I don't want to see all bugs closed after 1 year because it's useful to read all bug and sometime it takes me some months/years to fix bugs. Regards > > I think this would make a lot of time consuming bug triaging much easier. > > Cannot agree more :) > > > Cheers, > Daniel > > > Greetings > > Christoph -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: RFC: KDE Bugzilla Bugs Expiration
El Divendres, 31 de juliol de 2015, a les 11:02:44, Dominik Haumann va escriure: > Hi, > > On Fri, Jul 31, 2015 at 10:12 AM, Christoph Cullmann > > wrote: > > Hi, > > > > I think one of the problems with our current Bugzilla database is that it > > contains a lot of "old" bugs and wishs. > > > > As the manpower is limited and we sometimes not even keep up with the > > incoming new bugs, might it be a good idea to adopt a similar strategy > > like the Qt Project and expire bugs that got not changed since more than > > one year? > > > > The idea would that a scripts closes all bugs that have no activity in the > > last year e.g. on a weekly basis and the closing comment would contain > > some gentle note that if the bug is still an issue, the reporter (or any > > person on CC) can just reopen it again. > > > > I think this would make a lot of time consuming bug triaging much easier. > > There was a discussion about this at Akademy one evening, and the general > conclusion is that it seems to work quite well for the Qt Project. > > It is important, though, that the message we send with auto-closing a > bug is nice > and tells the user to just reopen the report to keep it alive. Then I > think this would > be a good solution. > > Of course, some wishes and valid bugs would be automatically closed then, > too. But this is probably not a big issue, since a wish that will never get > implemented > is useful neither for us as developers nor for the users at all. > > And if there are bug reports that from a developer's perspective should not > be auto-closed, then we could attach a custom tag 'no-auto-close' or so to > the bug. Then this script could ignore the tagged ones. > > Comments? Strong objections? ;) As a user I hate it when this happens: 1) I report a bug 2) 2 years go by 3) The bug gets autoclosed because noone bothered to look at it when it can be easily reproduced very easily. This pretty much guarantees i will never report a bug for that project again. I'm all in favour of closing bugs that are waiting for long time for user to answer a question the developer made. Closing bugs that were reported and had 0 answers from us I disagree they should be closed, what should happen is that they should be easily noticeable so more advanced users/triagers can go through them and try to verify/confirm them. Cheers, Albert > Greetings > Dominik
Re: RFC: KDE Bugzilla Bugs Expiration
On Fri, Jul 31, 2015 at 11:02 AM, Dominik Haumann wrote: > > Of course, some wishes and valid bugs would be automatically closed then, > too. > But this is probably not a big issue, since a wish that will never get > implemented > is useful neither for us as developers nor for the users at all. > I'd like to disagree with that^, in kde-telepathy we have many valid bug reports/wishes which we would want to have/implement when there will be that day when you have all the time you need. But we just struggle to find the time. They are useful for developers/maintainers because if a newcomer shows up, you can just tell him "look at all the opened wishes, pick one and work on it" (which we do regularly). It's also useful when you have a free weekend and want to work on some of those opened reports. Which you wouldn't be able if they would be all closed. They are also useful for users so they don't get reported again and again. > And if there are bug reports that from a developer's perspective should > not be > auto-closed, then we could attach a custom tag 'no-auto-close' or so to > the bug. > Then this script could ignore the tagged ones. > Yeah, this would be great. > Comments? Strong objections? ;) > Personally I prefer the Dan's version with the EOL, but in general +1 to the idea. Cheers -- Martin Klapetek | KDE Developer
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday, July 31, 2015 11:02:44 AM Dominik Haumann wrote: > Comments? Strong objections? ;) +1 - I think it's a sensible strategy and something we kind of implemented with introducing a new product for Plasma: thus getting rid of the old cruft. Fun note: I set a bug as RESOLVED FIXED yesterday which is fixed with Plasma 5.4 (on Wayland) and got reported against KDE 3.1. So some of the old bugs are really still valid ;-) Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday, July 31, 2015 10:12:00 AM Christoph Cullmann wrote: > Hi, > > I think one of the problems with our current Bugzilla database is that it > contains a lot of "old" bugs and wishs. True that! > > As the manpower is limited and we sometimes not even keep up with the > incoming new bugs, might it be a good idea to adopt a similar strategy like > the Qt Project and expire bugs that got not changed since more than one > year? > > The idea would that a scripts closes all bugs that have no activity in the > last year e.g. on a weekly basis and the closing comment would contain some > gentle note that if the bug is still an issue, the reporter (or any person > on CC) can just reopen it again. We were actually discussing something similar for KDE PIM but our idea was based on Fedora, i.e. closing all bugs for given release when the release goes EOL. There is a comment added by a bot 3 weeks before EOL stating that the release will go EOL and if user thinks the bug is still valid in newer/current release, they should re-assign to newer release. When the release actually goes EOL all bugs still assigned to it are closed. The advantage of this approach IMO is that it also clears out bugs where the reporters are no longer available/willing to provide additional info to devs and at the same time without losing bugs which might be important yet non-trivial to fix (read: take more than a year for a dev to get there). Especially for KDE PIM, given the size of the userbase and the amount of developers (3), bugs often take more than a year to get to and to be fixed. > I think this would make a lot of time consuming bug triaging much easier. Cannot agree more :) Cheers, Daniel > > Greetings > Christoph -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi)
Re: RFC: KDE Bugzilla Bugs Expiration
Hi, On Fri, Jul 31, 2015 at 10:12 AM, Christoph Cullmann wrote: > Hi, > > I think one of the problems with our current Bugzilla database is that it > contains a lot of "old" bugs and wishs. > > As the manpower is limited and we sometimes not even keep up with the > incoming new bugs, might > it be a good idea to adopt a similar strategy like the Qt Project and expire > bugs that got not changed > since more than one year? > > The idea would that a scripts closes all bugs that have no activity in the > last year e.g. > on a weekly basis and the closing comment would contain some gentle note that > if the bug is still an issue, > the reporter (or any person on CC) can just reopen it again. > > I think this would make a lot of time consuming bug triaging much easier. There was a discussion about this at Akademy one evening, and the general conclusion is that it seems to work quite well for the Qt Project. It is important, though, that the message we send with auto-closing a bug is nice and tells the user to just reopen the report to keep it alive. Then I think this would be a good solution. Of course, some wishes and valid bugs would be automatically closed then, too. But this is probably not a big issue, since a wish that will never get implemented is useful neither for us as developers nor for the users at all. And if there are bug reports that from a developer's perspective should not be auto-closed, then we could attach a custom tag 'no-auto-close' or so to the bug. Then this script could ignore the tagged ones. Comments? Strong objections? ;) Greetings Dominik
