lkml.org 
[lkml]   [2021]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: "Reporting issues" document feedback
Date

[CCing Rafael]

Beforehand: many thx for your feedback and for reporting the bug you
faced, much appreciated.

On 13.04.21 23:18, w4v3 wrote:

> I would like to make some suggestions regarding the "Reporting
> issues" document
> (https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
> <https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html>).
>
> I recently tried to submit a bug report, and since that was my
> first time of doing so I closely read through said document.

Glad to see it being read :-D

> Now it
> makes it very clear that one should consult the maintainers file on
> how to proceed and that in most cases, bugzilla is not the right
> place to submit a bug. It does however say that if the entry contains
> a line starting with "bugs:", then I should file my issue with the
> indicated bug tracker.
>
> My problem was ACPI-related, and the corresponding entry in the
> maintainers file does have a line with "bugs:" pointing to bugzilla.
> I concluded that it would be sufficient to file the bug there (after
> all, bugzilla asks you identify the subsystem and seemingly forwards
> the issue to the appropriate email address), but I don't think it was
> since I didn't receive any response, and after looking into the
> archive of the mailing list of the subsystem I could see that
> meanwhile,

Links to your bug report and the thread on the mailing list would have
helped here to understand better what's going on, but whatever, they are
not that important.

> the same bug had been reported (and dealt with) on that list.
> Admittedly, it does say in the document that if there is no "bugs:"
> line and "in many other cases", one should write an email to the
> maintainer and the mailing list, but I don't think it's very clear.
> To make it even more fool(like me)proof, it'd be worth pointing out
> that the existence of a "bugs:" line does not imply that simply
> submitting the bug there is enough to call attention to it.

But it should, otherwise the subsystem should remove the line starting
with B: ("bugs:" in the webview).

Rafael might be able to clarify things.

But afais it's appropriate there is a B: line: just a few weeks ago I
took a quick look at bugzilla and ACPI bugs in particular, and back then
most of the bug reports there got handled by the maintainers. That's why
I assume you were just unlucky and your report fall through the cracks
(but obviously I might be wrong here). And maybe your report even did
help: the developer that fixed the issue might have seen both the bug
entry and the mailed report, but simply forget to close the former.

Things like that can not be prevented completely, as all of us are just
humans. :-/

> Conversely, I'm surprised that despite the ACPI subsystem having
> bugzilla as designated bug tracker, the issue was only reported on
> the mailing list

If there is a B: entry in MAINTAINERS, then afaik that's the preferred
way to report bugs. But kernel development is driven by mail, hence
there will always be someone to report an issue by mail. That's not
ideal, but that's how it is. :-/ That's mainly an issue for the few
subsystems that have a B: entry, as they need to watch two areas.

> and not on bugzilla (except by me). This makes it
> seem like all the "bugs:" line indicates is that the given bug
> tracker has a section for that subsystem, which may be neither
> necessary nor sufficient for bug reporting. If this is the case then
> stating this could clarify how to understand the maintainers file.

Let's see what Rafael says.

But your mail showed me that indeed there is one aspect that
reporting-issues currently does not cover: in cases like yours reporters
are better off checking both the mailing list archives and the bug
tracker before reporting a bug.

Again, thx for your feedback! Have a nice day!

Ciao, Thorsten

\
 
 \ /
  Last update: 2021-04-14 12:45    [W:0.073 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site