PRs in the bin/ category
A significant number of old PRs are in the "bin/" category. Even though some of these PRs go back 10 years, a lot of them are still valid bugs or requests for enhancement. It would be good if we could hit the "bin" category hard and try to reduce the number of PRs there.
Why are there so many?
A lot of this may well be because it's not seen as being "cool" to work on the userland. There is a certain amount of kudos associated with kernel hackers, whereas working on the userland may well be percieved as being less cool. Maybe a real co-ordinated push on the bin/ PRs might be enough to get a bit of momentum going... Getting people involved in the first place is often the hardest part of the challenge.
Also, because userland PRs don't usually require specific hardware to demonstrate the bug, these PRs can stay open long after the original submitter's email address starts bouncing - which contrasts with kernel PRs which are often harder to resolve once the submitter disappears or no longer has the particular hardware to test with.
Lastly, some parts of the userland have been barely touched in the 30 years since it was written. Sometimes old coding styles are enough to make it hard to work on the code in question, which is why nobody does. Occasionally, the best solution to a problem may be to rewrite the tool from scratch.
What can we do with them?
The advantage of working with the userland PRs is that usually anybody will be able to recreate the problem without needing specific hardware, and anyone with programming knowledge should be able to solve it. So, what we can do:
- Verify that the problem can be recreated, and that it is indeed a bug.
- Stick a test case into the PR audit trail, if there isn't one there already.
- Try to figure out where the bug lies. Is it easily fixable?
For PRs with patches, does the patch apply? Does it work? See also Bugathons/PRsWithPatches
- For PRs without patches, try to code one up. If the original submitter is no longer able to test it, make sure at least the test case now gives the expected behaviour, and that nothing else seems to be broken.
Then, we need to try to get the patch pushed into the tree. Tag it with [patch] and add it to MarkLinimon's recommended PR list (~linimon/public_html/recommended.prs) so that it is included in the weekly reports that get mailed out if it doesn't get committed first.