RFC: KDE Bugzilla Bugs Expiration

Daniel Vrátil dvratil at kde.org
Fri Jul 31 10:07:54 BST 2015


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: dvratil at kde.org
Jabber: dan.vratil at kdetalk.net
IRC: dvratil on Freenode (#kde, #kontact, #akonadi)




More information about the kde-core-devel mailing list