Re: How to improve the quality of the kernel?

[Martin Bligh]

Natalie Protasevich wrote:
> On 6/18/07, Martin Bligh <mbligh@xxxxxxxxxx> wrote:
> > >> > So if you make changes to random-driver.c you can do `git-log
> > >> > random-driver.c|grep Tested-by" to find people who can test
> > >> > your changes for you.
> > >>
> > >> You would'nt even need to search in GIT.  Maybie even when ever a
> > >> patchset is being proposed a mail could be sent to appropriate
> > >> hardware/or feature pseudo-auto-generated mailing-list?
> > >>
> > >> On lkml I mostly try to follow patches/bugs associated with hardware I
> > >> use.  Why not try to automate the process and get more testers in?
> > >>
> > >
> > > I think this is an excellent point. One data point could be a field in
> > > bugzilla to input the hardware information. Simple query can select
> > > common hardware and platform. So far it's not working when hardware is
> > > just mentioned in the text part.
> >
> > if it's free text it'll be useless for search ... I suppose we could
> > do drop-downs for architecture at least? Not sure much beyond that
> > would work ... *possibly* the common drivers, but I don't think
> > we'd get enough coverage for it to be of use.
>
> How about several buckets for model/BIOS version/chipset etc., at
> least optional, and some will be relevant some not for particular
> cases. But at least people will make an attempt to collect such data
> from their system, boards, etc.

Mmm. the problem is that either they're:

1. free text, in which case they're useless, as everyone types
mis-spelled random crud into them. However, free-text search
through the comment fields might work out.

2. Drop downs, in which case someone has to manage the lists
etc, they're horribly crowded with lots of options. trying to
do that for model/BIOS version/chipset would be a nightmare.

If they're mandatory, they're a pain in the butt, and often
irrelevant ... if they're optional, nobody will fill them in.
Either way, they clutter the interface ;-(

Sorry to be a wet blanket, but I've seen those sort of things
before, and they just don't seem to work, especially in the
environment we're in with such a massive diversity of hardware.

If we can come up with some very clear, tightly constrained
choices, that's a decent possibility. Nothing other than
kernel architecture (i386 / x86_64 / ia64) or whatever springs
to mind, but perhaps I'm being unimaginative.

Nothing complicated ever seems to work ... even the simple
stuff is difficult ;-(

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/