PRs and DRs containing patches
Many submissions to FreeBSD contain a patch of some form. From an end-users point of view, these may well be the most frustrating type of ignored submissions, 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 perceive the actual process of committing the patch to be simple, compared with the effort of creating the patch.
- Patches can quickly become outdated and unapplicable in their current form, and may regularly need to be updated by the submitter and/or other people wanting the functionality.
- Bugs with patches (whether originally there or added later) that don't get acted on can acquire a will-never-get-fixed smell that can discourage others coming in later with the same problem, sometimes for years.
For these reasons and more, it would be good if we could go through PRs which contain patches and decide if they are ready to be committed as-is. If not, 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 submitted patches 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!
PRs containing patches in Bugzilla
Around a third of all open PRs in FreeBSD's Bugzilla contain a patch of some form. Here are the ones for individual ports:
Similarly, for base system PRs:
And for documentation PRs:
DRs containing patches in Phabricator
In general, most DRs in Phabricator contain patches.
In MarkLinimon's experience, PRs/DRs should be worked on "newest first". While this is counter-intuitive, many of the older submissions are either controversial, are going to require some hard work, or both. These can be quite frustrating and thus the easiest ones to discourage new volunteers. So, the above links are sorted newest-first.