[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17971.50834.907414.761549@notabene.brown>
Date: Sun, 29 Apr 2007 08:11:30 +1000
From: Neil Brown <neilb@...e.de>
To: "Martin J. Bligh" <mbligh@...igh.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Diego Calleja <diegocg@...il.com>,
Chuck Ebbert <cebbert@...hat.com>,
Adrian Bunk <bunk@...sta.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>
Subject: Re: Linux 2.6.21
On Saturday April 28, mbligh@...igh.org wrote:
>
> Yes, human involvement from someone with half a brain would be better.
> Andrew does a lot of that. Not a particularly good use of talent really.
> but still.
I think more than half a brain is needed to do this well. You need a
reasonable understanding of how all the bits of the kernel work
together so that you have a good chance of sending the bug in the right
direction. You need a good understanding of the kernel community and
various sub communities so that you know who might be both able and
willing to deal with the bug. And it wouldn't hurt to have a good
over-view of the current 'hot' areas of the kernel so you know if it
is really worth suggesting "try with the latest -mm" or not.
And you need good people skills.
So I think you really need a lot of up-to-date knowledge to do this
well. Because of Andrew's position as a funnel, he has a lot of that
knowledge. It would be really nice if he had some help though. And I
really think that would mean finding someone in the community who
would rather be coding (and currently are) and convincing them that
there is a higher calling for them. Finding someone out side or on
the edge of the community is less likely to be effective.
>
> As Andrew has pointed out before though - even though he forwards
> the bugs, nobody does anything with it. The sad truth seems to be
> that people have very little interest in fixing bugs when they are
> reported - it's not sexy, I guess.
Not sexy, and also not at all easy. A lot of the interesting bugs
seem to be subtle interactions between separate parts of the kernel -
one part making an assumption or exhibiting a behaviour that the other
part didn't expect. And we all know that writing bug^Wcode is easier
than removing bugs. I can spend hour and hours reading through code
trying to get the big picture, and end up finding a one-line change
that then needs documenting, testing and external review. It's not
easy.
> I'm still unconvinced the users or the tool are the problem, but if it
> makes you happier, we can do that.
No, they aren't the problem. Bugs are the problem. But they might be
a more effective part of the solution.
My perception of the kernel bugzilla is that visibility is very low.
I think there is value in weekly reminders, and I wouldn't mind seeing
a weekly Email on linux-kernel with something like a list of open bugs
that have not seen any activity in between 1 and 2 weeks. It might
get someone out-of-area interested, and might be noticed by someone
who thinks they are in-area and get them wondering why they didn't
find out when the bug was first reported.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists