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

Artem S. Tashkinov
2022-10-02T09:07:07Z

On 10/2/22 09:03, Geert Uytterhoeven wrote:
> Hi Artem,
>
> On Sat, Oct 1, 2022 at 1:21 PM Artem S. Tashkinov <aros@gmx.com> 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