<linimon> the important thing to realize is that there is no “magic bullet” that will get the # of PRs to zero. If you try to attack it like that you will quickly burn out.

<rwatson> 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.

What to do with PRs possibly needing MFCs after a certain amount of time? How about if the original committer is no longer engaged?

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.

<rwatson> linimon: I'd love to lose the architecture ones and break out kern into “driver”, “net”, “fs”, etc.

<bsdimp> Well, “this describes the bug well” is one level of quality and “This fix is wrong” is another orthogonal measure.

<linimon> another attribute is “this is a regression” vs. “this is a first time”.

<linimon> another attribute is “this is repeatable” plus “here is a test case”.

<linimon> I haven't decided yet what to do about “performance”.

Refactor 'analyzed' into 'yes, it's a real problem'; 'yes, there might be a solution'; 'yes, this is the right solution and it's ready for a committer to test and commit'.

<rwatson> right now we sort them by criticality, which is dumb. We should sort by state, or possibly last modified date or such.

<rwatson> Enhance the triaging guide as a way to do technology transfer. In particular, distinguishing documentation for people who do kernel debugging from documentation for people on the wrong end of the whole situation (I have a bug and I don't care how to fix it, just fix it).

<rwatson> In 8.x, there's a whole man page for textdumps, but it looks like there's no man page on regular kernel dumps.

<njl> There are tools to help with MFC, see src/tools/tools dir. I like the awk script: basically just prints the appropriate cvs commands based on a commit msg, so you can do eval mfc.awk and paste an email. That is, if you're brave.

<bsdimp> The number one thing that would make my life easier would be a shell script that says 'trust any (or the last) patch you find in pr #1234 , apply it, if it succeeds 100% compile. If that succeeds commit it with data mined from the PR as the default commit message…

<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).

<astrodog> consider a yearly timer, that asks people if the problem is still occuring, if there is no discussion. (Mark's note: I think Bugzilla can do this.)

<rwatson> I've started running a cron'd nightly perl script to gather some basic stats on gnats on freefall over time. This is the most basic perl script that can be done, I'm sure it's been done many times. You can look in ~rwatson/gnats/gnats.log to see the data so far (today).

<rwatson> a few years ago Mike Smith was interested in doing a “FreeBSD Labs” test environment, but I think the idea never went anywhere.

<rwatson> what would be nice is a livecd that you could stick in to test your hardware; it would exercise your hardware, then register with a web page automatically.