In article <20050109235319.GA16186@miracle.mongers.org>,
	"Jesper Louis Andersen" <jlouis@mongers.org> writes:
> I wondered what the best approach would be if I am going to look through
> the PR database for bugs that could be closed. One fast look yesterday
> showed that we have a lot of bugs ''hanging'' on the following scheme:
> 
> * Someone submits bug. Responsible party is foobar-bug-people
> * Someone quickly builds a patch, patches the problem and asks for
>   feedback.
> * The bug is confirmed gone.
> * Noone closes the bug.
> 
> I plan on identifying such ones and list them for closing.

From time to time, the bug teams do sweep for, and close, bugs which
can obviously be closed, so as a non-committer, it would probably not
be productive to tangle with those.  The real problem is problem logs
that don't have enough information in them to say if they're really
fixed.  You could help with those by appending information such as,
"I could once reproduce this bug, but now it's gone."

(There are other problems, such as one-time crashes that were probably
due to hardware errors, that no one has the guts to close, but there's
not much you can do about those, either.)
 
> It could also be fun to attack some of the bugs I would think. I need
> brain teasers, hehe. So, what would be the best option once you have
> solved a bug. Submitting a patch to the PR is option one, but to where
> should I CC it? Appropriate mailing list, such that someone can review
> and patch the kernel in question? (by appropriate mailing list I mean
> tech-*). 

Great! Sometimes it's hard to get anyone interested (otherwise, it
would have been fixed already). You could look through the CVS logs
to see who's committing in that area, and pester him. Often times,
too, the bug was submitted by a developer, so you can count on that
developer being interested in the solution.
 
> Of course, I intend to ask questions when I have something I do not
> know the answer of.
>
> Please help me out here getting started. I need something more 
> productive and morale-gaining than what I am doing now ;)

NetBSD's "culture of perfection" can make it a rough place to be.
It's hard enough to deal with one perfectionist, but one hundred
plus?  First, I suggest you tackle problems that you want solved,
producing code that you can enjoy personally.  Next, start
lobbying and discussion, and be prepared to make changes depending
on the sense of the discussion.  Finally, take the long view:  if
your idea is good, it'll eventually get picked up, but if isn't so
good, you'll be glad, in the long run, to see it be culled.


Frederick