Make PIM bug trackers maintainable again

[Denis Kurz]

Hi all,

I've been looking for a way to get all the KDE PIM bug trackers back to some 
maintainable state. In my opinion, the great amount of bugs somewhat defeats 
the purpose of a tracker. With a few thousand open bugs, many of them 
outdated, these trackers are no longer useful for
 * bug reporters who want to find duplicates
 * users who are looking for workarounds for bugs they encounter
 * developers looking for bugs to fix
 * anyone who tries to get an idea of the state of the software
 * bug triagers
...

I don't think that textbook bug triaging is still feasible. I assembled a list 
of kmail2 bugs that have never been confirmed for 4.14 or later, and that 
alone took hours. Therefore, I'd like to set all these bugs (not confirmed for 
>=4.14) to NEEDSINFO. I chose 4.14 because I think that any major, recent 
distribution should be at least on 4.14, but I might be wrong. The list 
contains any kmail2 bug whose bug ID is at most 350000 that did not receive 
comments after the 4.14 release, or none of the comments after the 4.14 
release confirm the bug for >=4.14. For any bug reported after 2015-01-01 with 
unspecified version, I assumed >=4.14. By only looking at bug IDs < 350000, I 
implicitly assumed that bugs reported after 2015-07-06 were filed against 
>=4.14. Altogether, I think that my approach was reasonably conservative.

I know that closing bugs does not fix them. That's why I propose to set them 
to NEEDSINFO, and why I'd like to add a comment like this:

"This bug has only been confirmed for versions of kmail2 that are at least two 
years old. Can someone confirm if this is still an issue?

If this bug is still not confirmed for a Frameworks-based version of kmail2 
(version 5.0 or later, as part of KDE Applications 15.08 or later) in three 
months, this bug will be closed."

As stated in the comment, someone could than close those bugs three months 
later. They should be easily identifiable by their Status and Modification 
Date.

In case you wonder: I didn't want to change 868 kmail2 bugs without consent of 
its developers. So, what do you think? If you think this is a sensible step 
for kmail2, should I repeat it for other PIM trackers?

Regards, Denis