On Sun, May 02, 1999 at 03:33:23PM -0700, Jonathan Stone wrote:
> In message <19990502192634.C24722@fundy.ca>,David Maxwell writes:
> 
> >On Sun, May 02, 1999 at 06:02:03PM -0400, Curt Sampson wrote:
> >> 
> >> One of the things I've realised during the release process for 1.4
> >> is that we don't really have a way of tracking how many people are
> >> affected or likely to be affected by a particular bug. 
> >> 
> >> Unfortuantely, I don't have a solution for this at the moment. I'm
> >> just opening up this topic to see if anyone here has any thoughts
> >> on better ways to approach this problem.
> 
> This is a  sampling problem.
> 
> When you combine it with the fact that we dont have a good idea of how
> many people are acutally running NetBSD at all, let alone on a given
> hardware/firmware/BIOS/PROM level, I think it becomes intractable.

  What if we turn the problem around -- instead of finding out
who has problems, what if we found out who _didn't_ have
problems, or at least who has such hardware?  For example,
volunteers could set up their /etc/rc.local to E-mail their
dmesg or some such to a site.  That site could then munge
through these, and get a list of who has what hardware.  If
someone needed to know in a hurry "does DMA work for ATAPI CD-ROMs
on any hardware?", they could look through a database of dmesg's,
and contact those volunteers with a note like "I notice you are
running April -current, with a DMA-capable CD-ROM in your system.
Could you check if DMA actually works on your machine?  Thanks."

  Yes, it would mean a bit of work for the volunteers, and we
would want to make this a voluntary thing -- we're not
Microsoft.  But I think a lot of people would not mind shipping
their dmesg's to a place, especially if the dmesg's were kept
confidential (and encrypted while in-transit), if that's a concern.

  It would also be a way for Joe User to help contribute, even if
Joe doesn't know a compiler from a pile-driver.

  And it would also be a cool source for data -- # of
machines volunteered for each port, average uptime per port,
frequent panic messages.

  Brian