Slashdot Mirror
Linux Kernel Bugzilla Launched
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."
It should be noted that Bugzilla 'bugs' are used for everything from bug reports to feature enhancement requests.. so only a certain percentage of those 'bugs' are really bugs at all.
slashdot!=valid HTML
I think they were referring to discussions regarding the bugs. Not the list itself.
This post was generated by a Cadre of Uber Monkeys for Monkey-Man2000 (603495).
Absolute nonsense! Making bugs public is a virtue of Open Source and Free Software, not a reason to worry. MS, on the other hand, would never go about making all of its warts public.
The "owner" listed above is the person the bug is assigned to. Please don't blame him for this garbage. The "submitter" is the person who entered the bug:
p-m@yahoo.com (Wolverine)
Using your sig line to advertise for friends is lame.
The site www.osdl.org is running Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_perl/1.24_01 mod_ssl/2.8.5 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.6 on Linux.
It's not bugzilla, but it's here. Requires at least a free ADC membership.
Karma: Incomprehensible (Mostly affected by posting at +5, reading at -1, and metamoderating everything unfair.)
Don't read into it too much :) This is just a couple of engineers trying to make their lives easier.
Or maybe try OpenDarwin's bugzilla installation.
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 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.
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:
-
Why We Should All Test the New Linux Kernel
(
Japanese translation)
- Using Test Suites to Validate the Linux Kernel
(
Japanese translation)
I should point out that I asked a couple of the larger commercial Linux vendors to contribute to the Linux Quality Database, which would have enabled me to feed myself while developing it, but I got turned down. I find that hard to understand, as it would have benefited them tremendously. I don't want to say who it was that turned me down, as I don't think negative publicity would be productive.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.
Request your free CD of my piano music.
> and people that write buggy browsers will somehow write a non-buggy
> 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.
Cut that out, or I will ship you to Norilsk in a box.
Most of them are duplicates, but the nice thing is, Bugzilla makes
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.
Cut that out, or I will ship you to Norilsk in a box.
> Bugzilla _was_ really buggy
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.)
Cut that out, or I will ship you to Norilsk in a box.
- Charsets. We can't specify one, because people enter data into Bugzilla in a variety of charsets, and rely on browser auto-detection to Do The Right Thing. The validator doesn't accept this.
- Backwards compatibility. We have to work on version 4 browsers
- Lack of support in standards. For example, we use <textarea wrap=hard> because there's no way to do that in CSS, and it's what is needed.
GervBugzilla is not maintained by "Netscape guys". Well, they just hired the lead developer, but the rest of the developers work for mozilla.org or other companies.
Gerv
nor have I been able to get it to yield a list of all open bugs against a specific component.
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
Well, like the other guy said, we should at least try to be as compatible as possible.
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.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin