Kernel Bug Database V1.10 on-line

Version 1.10 of my kernel bug database is now on-line at:

http://grabjohn.com/kernelbugdatabase/

Main updates:

* Automatic account creation

No need to E-Mail a request for an account to me - there is a link to create one if you don't have one already.

* Generate a config file with the same options as the one that was uploaded with the bug report.

If the original submitter of a bug uploaded their config file, you can download a config file with the same options set.

* Patch database

Patches can be submitted against a bug report, along with comments, and the facility is in place to automatically test the patch to see if it applies against any number of kernel trees. This will probably not be enabled until the bug database is moved on to another machine which has more disk space for the uncompressed kernel trees.

It's also possible to browse the available patches, search for strings in patches, and download the patches, (obviously).

* Command line interface improvements

Eventually intended to be accessible via E-Mail, you can currently test the command line interface via the web. I've added commands related to patch handling.

* Minor enhancements

Various enhancements, including categorising of drop down lists of kernel versions and config options.

* Various bugfixes

Various bugfixes and minor enhancaments to improve the bug database overall.

Important note
========= ====

Bugs in the database are not assigned any kind of status, nor are they assigned to one or more people, for them to work on.

This is intentional - eventually, the best way to use this database will be like this:

* A user uploads their config file, (or an oops, or searches using keywords).

* No bugs are found, or only ones that are nothing to do with the bug the user is experiencing.

* The user submits a bug report

* That bug report is re-named, re-numbered, commented on, or even deleted if it is a duplicate, by developers, until eventually a patch is posted that fixes it.

* The original user uploads their config file, again a week later and gets a list of bug reports back which match certain options in it, which the developers have identified as causing the bugs.

* That list now includes the bug that the user is experiencing, and hopefully also includes a patch to fix it.

* The user downloads the patch, and can also get information about which new kernel versions it can be applied to, and by going back to the bug list, can also find out which new kernel versions the bug is actually fixed in.

Note that if a user's original bug report is actually a duplicate of an existing bug in the database, the bug report can simply be deleted, (possibly after moving comments, patches, etc, from it to the original bug).

As long as the original user does not rely on tracking the bug report by number, and instead searches via config options, (which can be as easy as uploading the relevant .config file), they should still find any applicable comments and patches that the developers have submitted. A list of kernels that any available patches successfully apply to can easily be downloaded, saving even more time in cases where a patch is made against one tree, and the user wants to apply it to another tree, (for example, because of other bugs preventing the latest kernel version from being usable on their machine).

Comments, flames, etc, welcome.

John.

any reason why it has forced registration with a forced email address? Makes it hard to just browse the bugs.

Ingo

Well, it was to discourage people posting stupid and/or rude comments on it.

Username: guest
Password: guest

if you really don't want to register with it.

John.

John Bradford, Thu, Jan 09, 2003 14:30:52 +0100:

why login at all if one really just want to browse the bugs?

You're right - I'll fix it in the next version, (try again in a couple of hours :-) ).

John.

On Thu, 2003-01-09 13:11:04 +0000, John Bradford <[email protected]> wrote in message <[email protected]>:

What do I get? His/her config file, or some other?

One can watch certain subsystems/drivers. That's a _really_ nice feature, and I'd even like to be notified if a file belonging to one of "my" choosen subsystems is to be changed on mainstream. However, choosing subsystems of interest isn't quite fun because of the entrie's order.

I'd do this with three parts (within one list):

ARCH - ALPHA
ARCH - SPARC
ARCH - ...

Then important subsystems:
FS-Core
INIT
NET
NET-IPv4
NET-IPv6
NET-xxx
PCI
SCSI
IDE
...

...and at last, I'd list all chooseable drivers:
3c509
cpuid
ACPI
APM
FS - AFS
FS - EXT2
FS - EXT3
FS - codepages
...

That would really ease finding the interesting parts. Where, for example, can I go for sparc?

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/

No, you don't just get a copy of the original config file:

When a config file is uploaded to the system, it's parsed and the actual config options are stored in a database. If comments are present in a form that resembles what the existing kernel configurators use to indicate different sections, then those comments are used to categorise the config options in the database.

The main reason for this is so that if somebody reports a bug, and includes their config information, a developer can select one of their config options from a list, and indicate that the bug is triggered by it.

Re-generating the config file from that database, so that somebody else can download it was added as an afterthought :-). Comments are re-inserted, as well as an additional comment showing which kernel version the config was originally intended for.

Well, at the moment, the list is just generated from the MAINTAINERS file, I didn't want to introduce my own grouping of things, but it really depends on what people want.

I could add the ability to watch via config options as well as the list of maintainers, would that be helpful?

Hmm, good point, there is only an UltraSPARC maintainer listed. The problem is, this is a problem with the MAINTAINERS file that my database has inherited - do we fix the MAINTAINERS file or my db?

John.