linux-kernel - Re: [RFC PATCH v1 2/2] docs: reporting-issues: make everyone CC the regressions list

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: <YG2CztxS4jTia8wM@kroah.com>
Date:   Wed, 7 Apr 2021 12:00:46 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 2/2] docs: reporting-issues: make everyone CC the
 regressions list

On Wed, Apr 07, 2021 at 11:21:56AM +0200, Thorsten Leemhuis wrote:
> Make people CC the recently created mailing list dedicated to Linux
> kernel regressions when reporting one. Some paragraphs had to be
> reshuffled and slightly rewritten during the process, as the text
> otherwise would have gotten unnecessarily hard to follow.
> 
> The new text also makes reporters include a line useful for automatic
> regression tracking solution which does not exist yet, but is planned.
> The term "#regzb" (short for regression bot) is inspired by the "#syz"
> which can be used to communicate with syszbot (see
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md).

While I understand the wish to automate things like this, the #syz
marking will actually cause something to go off and do some work, and is
only relevant for a very small number of developers, all of whom know to
look up the instructions before doing so.  But the #regzb marking will
be requested to be added by random users who never have submitted a
problem report before, OR from long-time kernel developers who are lucky
to ever remember to read the documentation as they "know" how to do
this.

So this increased workload by people on the two ends of experience is
going to be rough, I predict a very low rate of adoption :(

What is the tag going to be good for?  The reports will need to be
handled by a person anyway and classified and tracked out-of-band from
the list somehow.  Will a tag do all that much here?

thanks,

greg k-h