Re: Dedicated kernel bug database

[John Bradford]

[CC list trimmed]

> >  > >It could warn the user if they attach an un-decoded oops that their
> >  > >bug report isn't as useful as it could be, and if they mention a
> >  > >distribution kernel version, that it's not a tree that the developers
> >  > >will necessarily be familiar with
> >  > Perhaps a more generalized hook into bugzilla for 'validating' a bug 
> >  > report, then code specific validators for kernel work?
> > 
> > Its a nice idea, but I think it's a lot of effort to get it right,
> > when a human can look at the dump, realise its not decoded, and
> > send a request back in hardly any time at all.
> > I also don't trust things like this where if something goes wrong,
> > we could lose the bug report. People are also more likely to ping-pong
> > ,argue or "how do I..." with a human than they are with an automated robot.
> 
> Either way, it isn't kernel specific.... which is what I was trying to 
> address.  If it is valuable (which as you demonstrate is debatable,) 
> then it is valuable in bugzilla baseline, not just kernel-bugzilla.

What!?  Parsing an oops isn't kernel specific?  Version tracking over
multiple separate trees as diverse as 2.4 and 2.5 isn't pretty kernel
specific?  In any case, people could take the kernel bug database, and
genericify it, much more easily than somebody could tailor an existing
bug tracking application to the needs of the kernel, (which is
demonstrated by the fact that the developers are not getting Bugzilla
reports).

John.