lkml.org 
[lkml]   [2001]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Linux Bug Tracking & Feature Tracking DB
On Sun, 30 Dec 2001, Stewart Smith wrote:

> What about instead of tracking bugs and if they've been squashed. Why
> don't we build a database of known bugs with different kernel versions.
> i.e. You can go to the site and get a complete list of every single bug
> that people have entered about 2.0.36 you're still running on that box
> under the stairs.
> People could then 'vote' on the bug, so we could keep track of what's a
> big problem for a lot of people, and what's something that just one
> person found not to work.

Congratulations, you just invented bugzilla 8)
The only thing I dislike about bugzilla (and lookalikes) is that
someone has to go through them pruning them, updating them etc
and this is a lot of work.
Look at $vendor_of_choice's bugzilla entry for the kernel.
You'll see hundreds, nay, thousands of reports filed.

It's an immense amount of data to track.
Some people have no problem with this, others loath it.

The advantage email has over this are too numerous to list,
but they start with the fact that lots of kernel developers are
lazy[*]. 2-3 keypresses to archive a patch for looking at later/merging
are about the level of involvement thats aimed for.
Having to start a browser, go to the bugzilla site, log in, search/browse
for bugs etc.. way too involved.

Dave.

[*] In the sense that if life can be made easier, it should be.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

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

\
 
 \ /
  Last update: 2005-03-22 13:14    [W:0.172 / U:1.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site