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]
Date:   Sun, 22 Nov 2020 06:33:34 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Jonathan Corbet <corbet@....net>
Cc:     Randy Dunlap <rdunlap@...radead.org>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 00/26] Make reporting-bugs easier to grasp and yet
 more detailed & helpful

Am 20.11.20 um 22:58 schrieb Jonathan Corbet:
> On Fri, 20 Nov 2020 11:46:07 +0100
> Thorsten Leemhuis <linux@...mhuis.info> wrote:
>> Am 19.11.20 um 01:29 schrieb Jonathan Corbet:
>>> On Sun, 15 Nov 2020 11:13:52 +0100
>>> Thorsten Leemhuis <linux@...mhuis.info> wrote:
>>
>>>    - Collapse the whole thing down to a patch adding reporting-bugs-v2.rst
>>>      (or some suitable name).  I do wonder if it should also move to the
>>>      process manual as part of this; not only admins will report bugs.
>> After a night's sleep and Randy's comment I for now settled on
>> Documentation/admin-guide/reporting-issues.rst
> Keeping it in the admin guide is OK.  Not sure about the name, though; if
> you're really dead set against bugs, maybe reporting-problems.rst?

Well, I'm not dead set against bugs, but it somehow seems wrong to me: 
people have problems/issues they deal with, which in the end might turn 
out to not be a bug/error in the code at all. That afaics why tracker 
software for such reports is often called "issue tracker" instead of 
"bug tracker" (and nearly nobody calls them problem trackers afaics).. 
That's why I went with "issues" in the name and the text.

But in the end I'm not a native English speaker, so I guess it's better 
if I follow advice from those. Randy, what would you choose?

> I'd be a bit more straightforward:
> 
> 	This document is obsolete, and will be replaced by
> 	Documentation/admin-guide/$NAME in the near future.
> 
> Not sure that more is really needed?

Totally fine for me (I guess I tried to be less bold and was overly 
careful).

@Jonathan, one more question: when I submit this again, should I CC more 
people (Linus, Greg, ?) to give them a chance to speak up before this 
lands in your tree?

Ciao, Thorsten

Powered by blists - more mailing lists