All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eli Carter <eli.carter@inet.com>
To: John Bradford <john@grabjohn.com>
Cc: linux-kernel@vger.kernel.org, davej@codemonkey.org.uk,
	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 11:48:16 -0600	[thread overview]
Message-ID: <3E020660.9020507@inet.com> (raw)
In-Reply-To: 200212191335.gBJDZRDL000704@darkstar.example.net

John Bradford wrote:
> Following on from yesterday's discussion about there not being much
> interaction between the kernel Bugzilla and the developers, I began
> wondering whether Bugzilla might be a bit too generic to be suited to
> kernel development, and that maybe a system written from the ground up
> for reporting kernel bugs would be better?

Can you perhaps improve bugzilla instead of starting over?  (I have not 
looked at bugzilla code... I'm just hoping we can build from where we 
are instead of starting over.)

> I.E. I am prepared to write it myself, if people think it's
> worthwhile.
> 
> For example, we get a lot of posts on LKML like this:
> 
> "Hi, foobar doesn't work in 2.4.19"
> 
> Now, does that mean:
> 
> * The bug first appeared in 2.4.19, and is still in 2.4.20
> * The bug reporter hasn't tested 2.4.20
> * The bug reporter can't test 2.4.20 because something else is broken
> * The bug actually first appeared in 2.4.10, but it didn't irritate
>   them enough to complain until now.

This case is not specific to the kernel:
"feature X doesn't work in program Y version Z"
it may appear in Z-3 through Z+1, but fixed in Z+2, etc.
So I hope it is something that could be done in/added to bugzilla.

> A bug database designed from scratch could allow such information to
> be indexed in a way that could be processed and searched usefully.  A
> list of tick-boxes for worked/didn't work/didn't test/couldn't test
> for several kernel versions could be presented.
> 
> Also, we could have a non-web interface, (telnet or gopher to the bug
> DB, or control it by E-Mail).

Can you interface with bugzilla's database backend maybe?  It seems like 
refactoring bugzilla might be better?

> 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?

> I'm not criticising the fact that we've got Bugzilla up and running,
> but just pointing out that we could do better, (and I'm prepared to
> put in the time and effort).  I just need ideas, really.

I certainly do not want to stand in your way!  I just hope you can stand 
on the shoulders of giants.

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------


  parent reply	other threads:[~2002-12-19 17:40 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 [this message]
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
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=3E020660.9020507@inet.com \
    --to=eli.carter@inet.com \
    --cc=akpm@digeo.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davej@codemonkey.org.uk \
    --cc=john@grabjohn.com \
    --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.