From: John Bradford <john@grabjohn.com>
To: davej@codemonkey.org.uk (Dave Jones)
Cc: linux-kernel@vger.kernel.org, alan@lxorguk.ukuu.org.uk,
lm@bitmover.com, lm@work.bitmover.com, torvalds@transmeta.com,
vonbrand@inf.utfsm.cl, akpm@digeo.com
Subject: Re: Dedicated kernel bug database
Date: Thu, 19 Dec 2002 20:42:54 +0000 (GMT) [thread overview]
Message-ID: <200212192042.gBJKgsTl002677@darkstar.example.net> (raw)
In-Reply-To: <20021219201811.GA7715@suse.de> from "Dave Jones" at Dec 19, 2002 08:18:11 PM
> > > I also don't trust things like this where if something goes wrong,
> > > we could lose the bug report.
> > How? I don't see as that is more likely than with Bugzilla.
>
> user submits bug report
> robot rejects it
It's not coded to reject stuff. Just parse it and point out obvious mistakes.
> user reads rejection, gets confused, gives up.
I do see what you mean, but that's not how I see it working:
user submits bug report
[it gets stored]
robot generates messages similar to compiler *warnings*.
> > Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
>
> Point to one important posting thats been ignored in recent times.
What about that data corruption bug that was pointed out around
2.4.18, and brought up again, when it was discovered that the patch
wasn't applied. That is a case of a bug report getting lost. Not
exactly what I meant, though, but it's relevant.
> More likely they weren't ignored, it was just deemed irrelevant,
> unimportant, or lacked information detailing how important the problem
> was.
Well, that's what the automated warnings would protect against - at
least the user would get a response, telling them how to submit a more
useful response.
> Besides, this is one area where bugzilla is helping.
> If I ignored/missed an agp related bug report on linux kernel,
> and the same user also filed it in bugzilla, I'll get pestered
> about it automatically later.
Agreed.
> > I don't see any way of making Bugzilla do all the things I described
> > originally, specifically the advanced tracking of versions tested.
>
> I still think you're solving a non-problem. Of the 180 or so bugs so
> far, there has been _1_ vendor kernel report. 1 2.4 report. and
> 1 (maybe 2) undecoded oopses (which were subsequently decoded less
> than 24hrs later.
Well, if we never get above that rate of bugs being entered in to the
database, then we might as well not have it, and go back to having
everything on LKML.
> > That could help to find duplicates, which is a big problem when you
> > have 1000+ bugs.
>
> In an ideal world, we'd never have that many open bugs 8-)
Good point :-)
> Realistically, I check bugzilla a few times a day, I notice
> when something new has been added. Near the end of each week
> I[*] go through every remaining open bug looking to see if there's
> something additional that can be added / pinging old reporters /
> closing dead bugs. Dupes usually stand out doing this.
> How exactly do you plan to automate dupe detection ?
> You can't even do things like comparing oops dumps, as they
> may have been triggered in different ways,.
I mean make it easier for people to identify dupes.
I've got loads of ideas about how we could build a better bug database
- for example, we have categories at the moment in Bugzilla. Why? We
already have a MAINTAINERS file, so say somebody looks up the relevant
maintainer in that list, finds them, then goes to enter a bug in
Bugzilla. Now they have to assign it to a category, and different
people may well assign the same bug to different categories -
immediately making duplicate detection more difficult.
If the number of bugs is always going to stay low, then my idea is
probably a waste of time, but I think that we are eventually going to
have loads of bug reports. We _want_ more bug reports, especially in
the development tree. Few enough people are testing it as it is!
John.
next prev parent reply other threads:[~2002-12-19 20:24 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-19 13:35 Dedicated kernel bug database John Bradford
2002-12-19 17:33 ` Brian Jackson
2002-12-20 3:26 ` Martin J. Bligh
2002-12-19 17:48 ` Eli Carter
2002-12-19 18:49 ` Dave Jones
2002-12-19 19:49 ` Eli Carter
2002-12-19 20:12 ` John Bradford
2002-12-19 20:24 ` Eli Carter
2002-12-19 20:45 ` John Bradford
2002-12-19 19:52 ` John Bradford
2002-12-19 20:18 ` Dave Jones
2002-12-19 20:32 ` Randy.Dunlap
2002-12-19 20:42 ` John Bradford [this message]
2002-12-20 3:40 ` Martin J. Bligh
2002-12-20 9:48 ` John Bradford
2002-12-20 10:40 ` Dave Jones
2002-12-20 16:08 ` Martin J. Bligh
2002-12-20 3:35 ` Martin J. Bligh
2002-12-20 17:32 ` Jon Tollefson
2002-12-19 20:09 ` Bill Davidsen
2002-12-19 20:32 ` John Bradford
2002-12-19 21:11 ` Stephen Wille Padnos
2002-12-19 21:40 ` John Bradford
2002-12-19 21:32 ` Randy.Dunlap
2002-12-19 21:55 ` John Bradford
2002-12-19 21:57 ` Eli Carter
2002-12-19 21:55 ` Randy.Dunlap
2002-12-19 22:45 ` Hanna Linder
2002-12-20 1:39 ` Martin J. Bligh
2002-12-20 2:01 ` Hanna Linder
2002-12-20 2:20 ` Martin J. Bligh
2002-12-20 15:09 ` Jon Tollefson
2002-12-20 23:52 ` Hanna Linder
2002-12-21 3:30 ` Jon Tollefson
2002-12-20 10:35 ` Dave Jones
2002-12-20 19:37 ` Hanna Linder
2002-12-20 2:10 ` Hanna Linder
2002-12-20 2:22 ` Martin J. Bligh
2002-12-20 2:58 ` Randy.Dunlap
2002-12-20 3:21 ` Martin J. Bligh
[not found] ` <31080000.1040418947@w-hlinder>
2002-12-20 21:43 ` Dedicated kernel bug database + documentaion Hanna Linder
2002-12-20 21:59 ` Randy.Dunlap
2002-12-20 22:01 ` Martin J. Bligh
2002-12-20 21:59 ` Eli Carter
2002-12-21 2:52 ` Dedicated kernel bug database Martin J. Bligh
2002-12-21 3:27 ` Jon Tollefson
2002-12-30 21:58 ` Hanna Linder
[not found] ` <mailman.1040338801.24520.linux-kernel2news@redhat.com>
2002-12-19 23:59 ` Pete Zaitcev
2002-12-20 0:19 ` Hanna Linder
2002-12-20 0:24 ` Pete Zaitcev
2002-12-20 1:01 ` Hanna Linder
2002-12-20 10:32 ` Dave Jones
2002-12-20 10:41 ` Russell King
2002-12-20 10:30 ` Dave Jones
2002-12-20 15:43 ` Eli Carter
2002-12-19 22:23 ` Stephen Wille Padnos
-- strict thread matches above, loose matches on Subject: below --
2002-12-19 17:46 Dan Kegel
2002-12-19 18:00 ` John Bradford
2002-12-19 18:08 ` Eli Carter
2002-12-19 20:08 ` John Bradford
2002-12-19 20:38 ` Eli Carter
2002-12-19 20:59 ` John Bradford
2002-12-19 21:14 ` Eli Carter
2002-12-20 14:23 ` Horst von Brand
2002-12-19 22:05 ` Dan Kegel
2002-12-19 22:26 ` Dan Kegel
2002-12-19 23:09 ` John Bradford
[not found] <2CC936747EA1284DA378A18D730697420158A50E@exchacad.ms.gettysburg.edu>
2002-12-19 20:33 ` Justin Pryzby
2002-12-19 21:04 Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-12-20 2:26 Dan Kegel
2002-12-20 11:18 Nicolas Mailhot
2002-12-22 2:50 Hell.Surfers
2002-12-22 9:16 ` John Bradford
2002-12-22 18:53 Adam J. Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212192042.gBJKgsTl002677@darkstar.example.net \
--to=john@grabjohn.com \
--cc=akpm@digeo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davej@codemonkey.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=lm@work.bitmover.com \
--cc=torvalds@transmeta.com \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.