>Well, I myself have been wondering how long the badsect(8) stuff
>is going to sit in the PR list. (PRs misc/897, bin/994 and bin/2719).
>These include fixes which, while admittedly not absolutely perfect
>in every respect, at least get the thing running again. And they've
>been there for a long time. (I have no idea if this is an isolated
>example or if this is a common thing; I don't find the PR search
>page off the NetBSD web page very conducive to browsing.)

>Now, perhaps there are other reasons for those not going in yet.
>I didn't notice that any of these mentioned much about testing.

	I wrote one of these; it was only about three lines long, and
I can't imagine that my patch would introduce any new bugs.

	All my patch does is insert the letter "r" in front of the device
name (or something to that effect, I wrote this patch a LONG time ago) to
use the raw device instead of the block device.

	All that is needed to either accept or reject this patch is for
someone with more know-about than I do say "does this break naming
conventions of other ports?" I know that, at least on the i386, the
convention in /dev is to name character devices rXXX and block devices
XXX.  It would only take but a second for someone who knows more about
/dev across more ports to decide if this would work.

	And if not, at least those making the fixes now know that the
problem exists and can find another, better solution for it.

>BTW, I have a marginally cleaner fix for badsect(8) that has been
>tested that I will be happy to send-pr if that's going to help get
>the badsect(8) fix into 1.2.

	On the one hand, if its cleaner, I'd say "go for it." A cleaner
patch can only ease the work of the maintainers and the integrators. I
can see where mine might _possibly_ be seen as less-than-optimal,
although I'm pretty sure the rXXX naming convention is consistent
across the board.

	On the other hand, tho, it seems that a lot of PRs in netbsd go
this way: someone finds it, submits a fix, and the PR sits there for months.
Then, someone else finds it, submits another fix, and it sits there. Soon
you have several fixes for the same problem, which only contributes to the
problem of backlogged pr-fixing.

	Dunno.

Cheers,
Phil
--
Phillip F Knaack
Database Programmer, Information Development for Extension Audiences (IDEA)
Iowa State University Extension