RFC: KDE Bugzilla Bugs Expiration

Dominik Haumann dhaumann at kde.org
Sun Aug 2 14:03:55 BST 2015

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.


More information about the kde-core-devel mailing list