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.
Greetings,
Dominik
More information about the kde-core-devel
mailing list