From: Eli Carter <eli.carter@inet.com>
To: John Bradford <john@grabjohn.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Dedicated kernel bug database
Date: Thu, 19 Dec 2002 14:24:33 -0600 [thread overview]
Message-ID: <3E022B01.2030205@inet.com> (raw)
In-Reply-To: 200212192012.gBJKCGsV002580@darkstar.example.net
John Bradford wrote:
> [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?
No, no, you mis-understand. A bug report going through some sort of
validation filter is applicable to any project. A validation script
that checks for a very close match to existing bugs for instance, and
asks the submitter about it, would be widely applicable.
Parsing an oops would be a kernel-specific validation filter.
> Version tracking over
> multiple separate trees as diverse as 2.4 and 2.5 isn't pretty kernel
> specific?
No, it isn't. There are a lot of projects out there that use a
'development' and 'stable' tree, and some that use more. bugzilla
itself does this. Trolltech's Qt has several version branches.
We do have more development branches than most, but we are not unique.
My point is that this is functionality that makes sense for the base
version of the bug tracking software, not just for the kernel version.
> 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).
Perhaps, but I'm not convinced that it would be easier to write a kernel
bug database from scratch than it would be to improve an existing
project to address the kernel's needs. And _that_ is what we were
discussing.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
next prev parent reply other threads:[~2002-12-19 20:16 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 [this message]
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
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=3E022B01.2030205@inet.com \
--to=eli.carter@inet.com \
--cc=john@grabjohn.com \
--cc=linux-kernel@vger.kernel.org \
/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.