Re: slowly decommission bugzilla?

[Richard Weinberger <richard@nod.at>]

----- Ursprüngliche Mail -----
> Von: "richard" <richard@nod.at>
>> This, on the other hand, would help quite a few people.
>> 
>> Also, broad categories with optional, more fine-graded subcategories
>> would be nice for some areas. Like mm, which has 18 entries in
>> MAINTAINERS that start with "MEMORY MANAGEMENT - ", which confuses
>> people that do not know "if in doubt, just use the entry for MEMORY
>> MANAGEMENT"
>> 
>>> heck even a stack trace or a BUG/WARN_ON/Oops
>> 
>> This even more (but of course this is harder)

While traveling, I found some spare time to prototype my idea:

https://git.infradead.org/~rw/kcontact/

The basic idea is that users (not kernel developers) can paste their
kernel logs (warning, oops, panic, ...) into the site, and the site
gives them guidance on where to report the issue.
If you like the idea, I'll happily extend it with further instructions
on how to report and improve stack traces, etc.

The website (JavaScript-based and static) analyzes kernel logs and
looks for stack traces. For each found kernel symbol, it consults a pre-computed
lookup table to find the matching subsystem contact.
So far, it only uses the "L:" entries.

To avoid churn, it ignores the first 3 entries of each stack trace because
these are usually just entry code.

Currently, the lookup table is constructed from an x86_64 allmodconfig build.
Having a combined table with other architectures is possible too.

Thanks,
//richard