Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

[Artem S. Tashkinov]

On 10/2/22 09:03, Geert Uytterhoeven wrote:
> Hi Artem,
>
> On Sat, Oct 1, 2022 at 1:21 PM Artem S. Tashkinov <aros@xxxxxxx> wrote:
> > On 10/1/22 10:57, Thorsten Leemhuis wrote:
> > > On 01.10.22 12:47, Artem S. Tashkinov wrote:
> > > > On 10/1/22 10:39, Greg KH wrote:
> > > > > On Sat, Oct 01, 2022 at 10:30:22AM +0000, Artem S. Tashkinov wrote:
> > >
> > > > > > I have a 20+ years experience in IT and some kernel issues are just
> > > > > > baffling in terms of trying to understand what to do about them.
> > > > > >
> > > > > > Here's an example: https://bugzilla.kernel.org/show_bug.cgi?id=216274
> > > > > >
> > > > > > What should I do about that? Who's responsible for this? Who should I
> > > > > > CC?
> > > > >
> > > > > Input subsystem.
> > > >
> > > > It's great you've replied immediately, what about hundreds or even
> > > > thousands of other bug reports where people have no clue who has to be
> > > > CC'ed?
> > >
> > > Quoting from https://docs.kernel.org/admin-guide/reporting-issues.html:
> > >
> > > "[...] try your best guess which kernel part might be causing the issue.
> > > Check the MAINTAINERS file [...] In case tricks like these don’t bring
> > > you any further, try to search the internet on how to narrow down the
> > > driver or subsystem in question. And if you are unsure which it is: just
> > > try your best guess, somebody will help you if you guessed poorly. [...]"
> > >
> > > HTH, Ciao, Thorsten
> >
> > Absolute most people:
> >
> > * Will never read this document
> > * Will not be able to "search the internet on how to narrow down the
> > driver or subsystem in question"
>
> So how did these people arrive at "bugzilla" in the first place? ;-)

Google kernel bug -> bugzilla.kernel.org

> Or is this a case of "if all you have is a hammer...", so you
> actively start looking for a bugzilla?
> I.e. people who are used to bugzilla/discourse/slack/irc/trac/... will
> look for how to use bugzilla/discourse/slack/irc/trac/... to interact
> with the developer and/or maintainer.
>
> The definitive guide is the MAINTAINERS file.  If there is a (rare)
> corresponding "B" entry, you can use that.  Else fall back to the
> "M" and "L" entries.  "C" might be good for an initial query, but not
> for the actual reporting, as there's even less traceability than with
> mailing lists (the latter are archived by lore).

Just like I said before email sucks terribly for bug reporting except
for rare cases when the developer notices your email right away and
promptly submits a patch. This happens once in a blue moon unfortunately.

Best regards,
Artem