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:

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.

Bugathons/bin (last edited 2010-08-04 13:36:18 by GavinAtkinson)