PRs containing patches
Around a third of all open PRs contain the 'patch' tag, indicating they contain a patch of some form. From an end-users point of view, these may well be the most frustrating type of ignored PR, for several reasons:
- A user has actually gone to the effort of diagnosing the problem and coding a solution or workaround, only to have it ignored.
- Users may feel frustrated as they percieve the actual process of committing the patch to be simple, compared with the effort of creating the patch.
- Patches can quickly become outdated and unapplyable in their current form, and may regularly need to be updated by the submitter and/or other people wanting the functionality.
For these reasons and more, it would be good if we could go through PRs which contain the [patch] tag and decide if they are ready to be committed as-is. If so, they could be added to the list of recommended PRs in ~linimon/public_html/recommended.prs or committed straight away, or if the patch is deemed unsuitable then feedback should be added to the PR to explain why so, to give other people a clue as to how to get the patch into a committable shape.
Possible criteria to decide if it committable include:
- Is the corrected behaviour actually a bug (or, do we want the functionality, for improvement requests)?
- Does it fix the bug in question?
- Does it apply cleanly to -HEAD?
- Does it follow style(9), or can it be made to easily?
There are a lot of patches in PRs that do fix real bugs, and do fit the above criteria for being ready to commit. Let's get some of them pushed into the tree!
For those with freefall access, a list of unallocated PRs containing patches can be generated with:
query-pr -q -x -t '\[patch\]' -r freebsd-
Similarly, to list (e.g.) non-ports PRs, use:
query-pr -q -x -t '\[patch\]' -r freebsd- | awk '$3 !~ /ports/ { print }'