Linux Kernel Bugzilla Launched 187
paskie writes "Martin J. Bligh of IBM announced
launch of a Bugzilla bug tracking
database for 2.5 linux kernel series - it's at bugme.osdl.org. Finally there will be
some possibility to easily keep track of known bugs without being subscribed to
thousand of mailing lists or googling to death. According to the relevant lkml
thread, kernel developers will still prefer discussions to happen on the
mailing lists, though. The Bugzilla server
and connection is donated by OSDL and IBM
folks administer the database."
Re:Bugzilla is good because Mozilla is buggy (Score:2, Informative)
Re:Why? (Score:2, Informative)
Re:A public database of errors? (Score:2, Informative)
Re:Already with the funny? (Score:5, Informative)
p-m@yahoo.com (Wolverine)
Re:Still responsive? (Score:1, Informative)
Re:Bug tracking for OSX? (Score:3, Informative)
Re:IBM's Linux Strategy? (Score:4, Informative)
Re:Bug tracking for OSX? (Score:2, Informative)
What I hoped to do with the Linux Quality Database (Score:5, Informative)
Unfortunately, the dot-com crash ensued just as I was getting started, and things have been a little too hectic since then for me to do much about it.
A number of people suggested I use bugzilla, and I thought a lot about it, but didn't want to use it, at least not in its current form, because it lacks a feature that I feel is critical for a bug database that is to be used to track operating system development: storage of preset machine configurations.
Perhaps the people with the new kernel bugzilla can put this in.
What I envisisioned was a way for the user to specify the hardware configuration of their machines by drawing on a database of all known hardware. (Just making that database would be a big job in itself). The user could give a name to each configuration.
Then when reporting a bug, the user would be presented with a popup menu or scrolling list of their configuration presets. There would be a way to make variations for a particular bug report, to indicate that a board had been added or removed from the stored preset.
Then the user would upload their kernel .config file.
This would allow the kernel developers to search for combinations of hardware that is or isn't installed along with kernel config options that are selected or not set.
This would help a lot to identify situations where FooBar Corp's ethernet board doesn't work when you've got a WhizzyVideo card installed.
I would also encourage people to report the configurations for successful kernel tests. That would help to build confidence as well as to identify untested areas so more attention could be paid to them.
Unfortunately, I'm just a guy working alone and although some have offerred to help, I have been working too hard just to survive to even coordinate the development of such a database.
However, I have found some time to write some articles on various aspects of Linux and web software quality [sunsite.dk] and post them at the site. Writing is what I like to do to relax when I'm not programming - I write articles like these whenever I can, despite despite what the anklebiters have to say about them [slashdot.org].
The OSDL was kind enough to mirror my two kernel testing articles and even translate them into Japanese. You can mirror or translate them if you like, as they are under the GNU Free Documentation License. I would be particularly pleased if any of my articles were translated into more languages.
The two kernel testing articles are:
But I found the OSDL's interest in my articles quite encouraging.
A lot of people are griping about not being able to file bugs anonymously with bugzilla. I had always intended to allow anonymous bug reports, although I would encourage users to log in so we could follow up with them.
Also some people are saying in other comments that bug reports that aren't emailed to the linux-kernel mailing lists won't be as good as the traditional ones. But I'd like to point out that linux-kernel is one of the highest traffic mailing lists around, and the discussions are extremely technical and often heated. Patches also fall on the floor all the time, as I found when someone posted a patch that fixed the problem I reported when I first subscribed.
I felt then and still feel that linux-kernel is too intimidating for the average linux user, so most will choose not to partipate in kernel QA. A bug database with a nice web interface where the reporter doesn't have to participate in the mailing list traffic can only encourage more people to post bugs. And a bug database would make it possible to log successes without overwhelming the list.
It would also be possible to publish an XML interface to the database, so people could log reports programmatically. That would help for identifying configuration information, for example you could run a program that would do what lspci does and upload it to your account at the bugbase.
Re:Bugzilla is good because Mozilla is buggy (Score:5, Informative)
> bug tracking system?
Mozilla is written in C, C++, XUL, and JavaScript, and has to run
on innumerable platforms and display under innumerable GUIs.
Bugzilla is written in Perl and HTML and has to run under Linux
and display on the web. It's an easier thing.
That said, Bugzilla is extremely useful and convenient, _much_ more
functional than other competing issue-tracking systems. There's a
reason other large projects (OpenOffice, Gnome, and now maybe the
Linux kernel) are adopting it: it's best-of-breed issue-tracking
software.
Did anyone else notice that the version over at ODSL (for the Linux
kernel) has an added feature that b.m.o. doesn't have, where you
can set a pref so that after changing a bug you view that bug again
instead of going on to the next bug that matches your most recent
search criteria? That's quite cool; I hope b.m.o. gets that too.
Re:Bugzilla is good because Mozilla is buggy (Score:2, Informative)
it easy to track such things. Bugzilla _was_ really buggy. The
speed with which it shaped up during the second half of 2001 is
at least partly due to Bugzilla; once a critical mass of serious
testers get involved with using Bugzilla for its intended purpose,
the developers don't have to waste extra time tracking bugs down.
If a bug report doesn't have enough details, they just mark it
qawanted, comment about what information is needed, and future it
until one of the testers coughs up some details -- and someone will,
if the bug is at all critical.
Re:Bugzilla is good because Mozilla is buggy (Score:2, Informative)
Err, that should read, "Mozilla _was_ really buggy". It crashed
all the time, until circa 0.9.5 or so, then got progressively more
stable until 1.0.1. (1.1 and 1.2 have slipped a bit in terms of
stability, but that was expected, as they're for feature work.)
Re:What about bugzilla for bugzilla? (Score:5, Informative)
Re:What about bugzilla for bugzilla? (Score:3, Informative)
Gerv
Re:GCC Bugzilla? (Score:3, Informative)
Did you try selecting the name of the component, and pressing "Search"? Works for me...
If bugzilla is ever to become a realistic issue tracking system, it needs to have most of the features taken out and replaced with simple, generic systems.
Believe me, we'd take out features if we could be sure people wouldn't complain that they actually used them. Bugzilla has the number of features it has because people find them useful. It evolves under user pressure.
Gerv
Still missing some stuff... (Score:4, Informative)
w3c doesn't absolutely require a charset to be specified.
The errors that link came up with didn't deal with any of the items you listed, they're just plain improper html.
Fixing those problems wouldn't hurt anything. Probably wouldn't help either, but like I said in my original post, we should be setting an example and following the standards as much as possible.