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
