culling doesnt mean ignoring - it just means de-prioritizing. There's
four basic bug categories:
1- bugs where there's inactivity on the reporter side. This we should
de-prioritize - and reactivate them once their activity changes.
2- bugs where there's inactivity on the _maintainer_ side show bad bugs
in our process.
3- bugs that are old but have lots of activity are usually the most
difficult bugs where both side try their best to get it resolved.
4- bugs that are relatively new can be in any of the above 3 categories,
we dont know yet.
so i think we should list bugs in category #3 first: the hardest bugs,
which need the most eyes. Then should we list #2 - the embarrasing bugs
where our pocess failed. Then should we list #4 - new, not yet resolved
bugs which need more eyes - especially in late -rc's. Then comes #1 -
inactive bugs.
the problem for your scripting is to efficiently parse lkml activity for
these bugs: which replies are from the "maintainer", and how "active" is
a thread. So i guess a good heuristic is what you did in your latest
mail: to reverse sort by age of the bug - but i'd also suggest to list
too old entries where the bugzilla is not in NEEDINFO state - those
indicate inactive (or unaware) maintainers.
Ingo
--
