This is an old revision of the document!
These are various ideas gleaned from IRC and email. For now, they are in no particular order.
"What To Do About ..."
- <rwatson> linimon: the hard patches are generally patches of somewhat dubious quality against a subsystem without an active maintainer. For example, a patch to fix ncpfs use of IPX or the like. There's no obvious way for the committer to validate that the patch fixes the problem or doesn't introduce others, and the level of effort to get up to speed on the subsystem is extremely non-trivial.
Categorization Ideas
- <rwatson_> I tend to deal with four kinds of kernel bug reports, I think:
- The kernel panicked, help!
- The kernel hung, help!
- The kernel didn't do what I wanted, help!
- The kernel generated what appeared to be debugging output, but didn't reflect an actual bug.
Ideas About State Transition Table
unsorted
- Updates for Categories and Class.
- What to do about “we don't support this hardware” PRs?
- How to flag “you need hardware xyz to confirm this”? Perhaps a field “Hardware-Specific” and restrict it to Yes and No? If it's free-form, users are going to fill it up with all kinds of stuff. OTOH maybe we can subsume some of the chaos in amd64/i386.
- Figure out what to do with [http://people.freebsd.org/~linimon/studies/prs/prs_possibly_committed.html PRs possibly needing MFCs] after a certain amount of time? How about if the original committer is no longer engaged?
- Possibly <vwe> an idea would be to add anybody to X-GNATS-Notify who ever responded to a PR (assuming anybody filed a follow up has an interest in that particular PR)