linux-kernel - Re: [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users should do once the report got out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ec324fd-e9e4-f913-1929-154035e8b3e8@infradead.org>
Date:   Sun, 11 Oct 2020 08:06:35 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>,
        Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users
 should do once the report got out

On 10/11/20 6:29 AM, Thorsten Leemhuis wrote:
> Many thx for you comments. Consider all the obvious spelling and grammatical mistakes you pointed out fixed, I won't mention all of them in this reply to keep things easier to follow.
> 
> Am 09.10.20 um 19:37 schrieb Randy Dunlap:
>> On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:
> 
>>> +wait a week at maximum (or just two days if it's something urgent) before
>>> +sending a friendly reminder. If the maintainer is not responding in a timely
>>> +manner or not handing it appropriately, mention that you are considering to
>>> +escalate the issue to a higher authority and do so if there is in the end
>>
>>                                              and do so if there seems to be
>> no way around this.
>>
>> although such a "threat" probably won't do much good.
> 
> Hmmm, yeah, I guess did not find the right tone here. But I think this situation needs to be mentioned in the text. And FWIW, something about it is even in the old text:
> 
> """
> If you suspect a maintainer is not responding to these types of bugs in a timely manner (especially during a merge window), escalate the bug to LKML and Linus Torvalds.
> """"
> 
> So how about this:
> ```
> The 'issues of high priority' (see above for an explanation) are an exception here: maintainers should address them as soon as possible; that's why you should wait a week at maximum (or just two days if it's something urgent) before sending a friendly reminder.
> 
> Sometimes the maintainer might not be responding in a timely manner; other times there might be disagreements, for example if an issue qualifies as regression or not. In such cases raise your concerns on the mailing list and ask others for public or private replies how to move on. If that fails, it might be appropriate to escalate the issue to a higher authority. In case of a WiFi driver that would be the wireless maintainers; if there are no higher level maintainers or all else fails, it might be one of those rare situations where it's okay to get Linus Torvalds involved.
> ```
> 
> 
> Still not totally happy with it, but I better at least. Or what do other think about it?

Thanks, it's better.

-- 
~Randy