Re: "Reporting issues" document feedback

Re: "Reporting issues" document feedback

[Thorsten Leemhuis]

[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

Re: "Reporting issues" document feedback

[w4v3]

Hi Thorsten,

Thanks for the quick and illuminating response :)

> 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.

Here you go: https://bugzilla.kernel.org/show_bug.cgi?id=212643
https://marc.info/?l=linux-acpi&m=161824910030600&w=2

> 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.

Good to know. It does seem like many recent ACPI bug reports on bugzilla
have been processed by maintainers. Maybe it is the ACPI-subcomponent I
chose for the bug: in Config-Tables, only two other bugs were submitted
and they did not attract comments. Anyways, I understand now that it's
not an issue with the document so thanks for forwarding it to Rafael.

> 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.

Certainly: currently, it says
    Search the archives of the bug tracker or mailing list in question ...
but it is probably a good idea to suggest always searching both.

Have a nice day too
Patrick

Re: "Reporting issues" document feedback

[Rafael J. Wysocki]

On Wed, Apr 14, 2021 at 3:22 PM w4v3 <vv4v3@protonmail.com> wrote:
>
> Hi Thorsten,
>
> Thanks for the quick and illuminating response :)
>
> > 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.
>
> Here you go: https://bugzilla.kernel.org/show_bug.cgi?id=212643
> https://marc.info/?l=linux-acpi&m=161824910030600&w=2
>
> > 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.
>
> Good to know. It does seem like many recent ACPI bug reports on bugzilla
> have been processed by maintainers. Maybe it is the ACPI-subcomponent I
> chose for the bug: in Config-Tables, only two other bugs were submitted
> and they did not attract comments. Anyways, I understand now that it's
> not an issue with the document so thanks for forwarding it to Rafael.

As a rule, ACPI bugs submitted through the BZ are processed by the
ACPI team (not necessarily by me in person, though), but the response
time may vary, so it's better to report urgent issues by sending
e-mail to linux-acpi@vger.kernel.org.

Definitely issues where table dumps or similar are requested are best
handled in the BZ, so reporters can be asked to create a BZ entry for
a bug reported by e-mail anyway.

If you are interested in the history (ie. what issues were reported in
the past), you need to look at both the BZ and the ml record.

HTH

Re: "Reporting issues" document feedback

[w4v3]

Alright, thanks for clarifying!


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, April 14, 2021 3:42 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:

> On Wed, Apr 14, 2021 at 3:22 PM w4v3 vv4v3@protonmail.com wrote:
>
> > Hi Thorsten,
> > Thanks for the quick and illuminating response :)
> >
> > > 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.
> >
> > Here you go: https://bugzilla.kernel.org/show_bug.cgi?id=212643
> > https://marc.info/?l=linux-acpi&m=161824910030600&w=2
> >
> > > 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.
> >
> > Good to know. It does seem like many recent ACPI bug reports on bugzilla
> > have been processed by maintainers. Maybe it is the ACPI-subcomponent I
> > chose for the bug: in Config-Tables, only two other bugs were submitted
> > and they did not attract comments. Anyways, I understand now that it's
> > not an issue with the document so thanks for forwarding it to Rafael.
>
> As a rule, ACPI bugs submitted through the BZ are processed by the
> ACPI team (not necessarily by me in person, though), but the response
> time may vary, so it's better to report urgent issues by sending
> e-mail to linux-acpi@vger.kernel.org.
>
> Definitely issues where table dumps or similar are requested are best
> handled in the BZ, so reporters can be asked to create a BZ entry for
> a bug reported by e-mail anyway.
>
> If you are interested in the history (ie. what issues were reported in
> the past), you need to look at both the BZ and the ml record.
>
> HTH

Re: "Reporting issues" document feedback

[Thorsten Leemhuis]

On 14.04.21 15:42, Rafael J. Wysocki wrote:
> On Wed, Apr 14, 2021 at 3:22 PM w4v3 <vv4v3@protonmail.com> wrote:
>>> 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.
>> Here you go: https://bugzilla.kernel.org/show_bug.cgi?id=212643
>> https://marc.info/?l=linux-acpi&m=161824910030600&w=2

BTW: thx!

>>> 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.
>>
>> Good to know. It does seem like many recent ACPI bug reports on bugzilla
>> have been processed by maintainers. Maybe it is the ACPI-subcomponent I
>> chose for the bug: in Config-Tables, only two other bugs were submitted
>> and they did not attract comments. Anyways, I understand now that it's
>> not an issue with the document so thanks for forwarding it to Rafael.
> 
> As a rule, ACPI bugs submitted through the BZ are processed by the
> ACPI team (not necessarily by me in person, though), but the response
> time may vary, so it's better to report urgent issues by sending
> e-mail to linux-acpi@vger.kernel.org.

Rafael, thx for clarifying. And what you wrote is likely the case for
subsystems as well, so I submitted a patch to mentioned that in
reporting-issues.rst:

https://lore.kernel.org/linux-doc/dd13f10c30e79e550215e53a8103406daec4e593.1618482489.git.linux@leemhuis.info/

Thx everyone! Ciao, Thorsten