PR and issue list purging? #751

notro · 2014-12-29T18:16:48Z

In my experience most people opening issues, don't close them when they are resolved.
This leaves a long issue list with irrelevant information, and quite impossible to see the outstanding issues with the current/next kernels.

In my own projects I regularly close issues older than 2 months, unless I know they are still valid.
I use this message:

Closing issue since there has been no activity for more than 2 months. Reopen if needed.

This keeps the list short which makes it easy to get a view of outstanding issues.

Could we do something like that for this repo as well?

I think maybe PR's can be treated much the same. If there's silence for 2 months, it won't be pulled, will it?

I know there are different views on who 'owns' the issue, and some might feel personally offended if the PR/issue is closed on them.
If we can come up with a happy standard closing phrase, I think this should be less of a problem.
Let the phrase include that it's possible to reopen, and I presume we won't get many hard feelings.

Stats

List of issues/PR's which have it's last update in the specified period:

There are currently 139 open issues.

2012: 2 issues
2013: 38 issues
first half of 2014: 36 issues
july-october: 44 issues

There are currently 19 open Pull Requests.

first half of 2014: 5 PR's
july-october: 7 PR's

What do you think?

popcornmix · 2014-12-29T18:45:38Z

You are right. Periodically I go through the open issues and ping people. I normally hope the original reporter will close them when happy, but many reporters don't comment again once their issue is resolved.
I do close issues on occasion with a "Closing due to lack of response. Please reopen if this is still an issue" (and they are rarely reopened). This should probably be done more often.

The other problem is many github issues are reported in the wrong places.
General "how do I..." issues should be closed and redirected to forums.
A lot of issues are really distribution (raspbian) or firmware.
Upstream kernel bugs and issues from community contributed PRs (e.g. 1wire/I2S/I2C/SPI) tend to hang around as I often can't help, but the hope is someone from community can help.

Feel free to comment on issues you feel should be purged and I'll close them if I agree (which I imagine I will).

I'll endeavour to purge more often (it usually happens when I've got a slow background task to work on, like git bisecting to find a regression).