Make PIM bug trackers maintainable again

[ianseeks]

On Sunday, 18 September 2016 12:17:42 BST Denis Kurz wrote:
> 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
As a user who does log bugs now and again, i think this is a good idea but i'd 
drop the time limit to 1 month to get people to engage urgently.
One thing i find discouraging is that a bug can sit there for months/years and 
you have no clue as to whether any of the assignees have even looked at it let 
alone confirm/duplicate/close it. It would be a nice touch to have a count of 
the number of times the assignees have opened it to look at it even if they do 
nothing about for a while otherwise you think "whats the point?". 

-- 
opensuse:tumbleweed:20160916
Qt: 5.6.1
KDE Frameworks: 5.26.0
KDE Plasma: 5.7.95
kwin5-5.7.95-154.1.x86_64
kmail5-16.08.1-82.2.x86_64
Kernel:  4.7.3-1-default
Nouveau:  1.0.12_1.4