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: <CAKXUXMw7kHBPov23kF1HUBrW9DL+huqAG8ZRLJwGgU67nCOPeg@mail.gmail.com>
Date:   Mon, 22 Mar 2021 17:55:05 +0100
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ksummit-discuss@...ts.linuxfoundation.org,
        workflows@...r.kernel.org,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: [Ksummit-discuss] RFC: create mailing list "linux-issues"
 focussed on issues/bugs and regressions

On Mon, Mar 22, 2021 at 4:38 PM Thorsten Leemhuis <linux@...mhuis.info> wrote:
>
>
> Lo! I want to provide users with an easier way to search our multitude
> of mailing lists for reports about issues (aka bugs), as reporting the
> same kernel problem multiple times has known downsides for everyone
> involved. That's why I propose to create this new mailing list:
>
> linux-issues@...ts.linux.dev
>
> Developers and users reporting or handling issues then can CC it or
> search it via lore. But this will only fly if the idea has buy-in from
> at least the core kernel maintainers, to make sure they and the
> developers actually use it. That's why I'm looking for feedback with
> this mail and also CCed ksummit-discuss, as that's the easiest way to
> make sure maintainers get aware of this idea and can raise their voice.
>
>
> Note, there is a second reason why ksummit-discuss is CCed: another
> reason why I want to create this new list is making it easier to find
> and track regressions reported to our various mailing lists (often
> without LKML in CC, as for some subsystems it's seems to be custom to
> not CC it). Back on the maintainers summit in 2017 it was agreed to
> create a dedicated list for this purpose
> (https://lwn.net/Articles/738216/). I even requested a
> "linux-regressions@...r.kernel.org" a while later, but didn't hear
> anything back; and, sadly, about the same time I started having trouble
> finding spare time for working on regression tracking. :-/
>
> But I soon will get back into that area:
> https://linux-regtracking.leemhuis.info/post/hello-world/ Hence it's a
> good time to prepare some groundwork for that. But these days I think
> having something like linux-regressions@...ts.linux.dev might be over
> engineered, at least for now: a linux-issues@...ts.linux.dev with a
> simple "[regressions]" in the subject will suffice, as that tag is
> something a lot of people are used to already. And if we think we need
> that list we can still create it in the future. Or what do you folks
> think about it?
>

Thorsten, I generally support this initiative. I am just wondering:

What is the definition of an issue for you?

Just four examples that come to my mind:

- all the warnings that Stephen Rothwell reports on linux-next, such
as https://lore.kernel.org/linux-next/20210322170452.726525e8@canb.auug.org.au/
or https://lore.kernel.org/linux-next/20210322075108.3967d5d1@canb.auug.org.au/?
- all the issues that the kernel test robot reports?
- all the errors and warnings that kernel ci reports? Basically, each
"issue" that is already aggregated in this email,
https://lore.kernel.org/linux-next/6058787c.1c69fb81.d3f10.8c6d@mx.google.com/?
- all the syzbot reports?

Are you including all those automatic testing and checking efforts as
reporting valid "issues"? Or would you like to keep this list only for
reports from single individual human users that need to detect the
"issue" without using one of the tools above?

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ