Thus spake Nate Lawson <[EMAIL PROTECTED]>: > The best way is to send a pr and then followup on mailing lists as > appropriate or perhaps by contacting the maintainer. The PR provides > history for a given problem and patch and the followup initiates action on > behalf of the committers. It's important to get someone to take up the > "responsible" field before any action can happen.
This idea works if the components in question have maintainers. The bits that are in most need of patching do not, so obvious one-line patches go un-committed because nobody thinks themselves to be familiar enough with the code. > BTW, the number of PRs is not totally the fault of committers. I've been > scanning through the DB with about 50% of my FreeBSD-time and fixing > things that I find there. However, it has taken about 3x as long as I > expected to commit a patch because almost all of them are very incomplete > and actually are more a suggestion on an area that needs improvement, not > a fix. I applaud you, but the PR problem won't be solved until the other 90% of the committer base chips in as well. It is *not* always the case that closing PRs requires extra work. On several occasions, people have reinvented the wheel and committed patches identical (or nearly so) to ones I submitted six months earlier. I'm sure others have noticed the same thing. It's even worse when the patch that's actually applied is bogus, as in the case of some changes to renice(1). I don't have a whole lot of free time, but when I spend some of it getting something right, I don't care to wait for months and then have to explain to someone else why they got it wrong. Admittedly the majority of PRs, even some of the ones with patches, are nontrivial to address. But so little attention is given to the PR database that even the straightforward PRs get overlooked. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message