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
> any reason why it has forced registration with a forced email address?
Well, it was to discourage people posting stupid and/or rude comments
on it.
> Makes it hard to just browse the bugs.
Username: guest
Password: guest
if you really don't want to register with it.
John.
On Thu, 2003-01-09 13:11:04 +0000, John Bradford <[email protected]>
wrote in message <[email protected]>:
> Version 1.10 of my kernel bug database is now on-line at:
>
> http://grabjohn.com/kernelbugdatabase/
> If the original submitter of a bug uploaded their config file, you can
> download a config file with the same options set.
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/
John Bradford, Thu, Jan 09, 2003 14:30:52 +0100:
> > any reason why it has forced registration with a forced email address?
>
> Well, it was to discourage people posting stupid and/or rude comments
> on it.
>
> > Makes it hard to just browse the bugs.
>
> Username: guest
> Password: guest
>
> if you really don't want to register with it.
>
why login at all if one really just want to browse the bugs?
> > Version 1.10 of my kernel bug database is now on-line at:
> > http://grabjohn.com/kernelbugdatabase/
>
> > If the original submitter of a bug uploaded their config file, you can
> > download a config file with the same options set.
>
> What do I get? His/her config file, or some other?
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.
> 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
> =2E..
>
> =2E..and at last, I'd list all chooseable drivers:
> 3c509
> cpuid
> ACPI
> APM
> FS - AFS
> FS - EXT2
> FS - EXT3
> FS - codepages
> =2E..
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?
> That would really ease finding the interesting parts. Where, for
> example, can I go for sparc?
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.
> > > any reason why it has forced registration with a forced email address?
> >
> > Well, it was to discourage people posting stupid and/or rude comments
> > on it.
> >
> > > Makes it hard to just browse the bugs.
> >
> > Username: guest
> > Password: guest
> >
> > if you really don't want to register with it.
> >
>
> 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.