linux-kernel - Re: Linux regressions report for mainline [2021-11-24]

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] [day] [month] [year] [list]

Message-ID: <b9fc1beb-0495-b6b7-b352-d2505e709af2@leemhuis.info>
Date:   Thu, 25 Nov 2021 12:52:06 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2021-11-24]

On 24.11.21 19:13, Linus Torvalds wrote:
> Ok, nice to see the new regression tracking bot start to show life.

Yeah. :-D

Sadly one of my biggest problems with regression tracking remains:
getting aware of regression reports. I can fully understand that most
people don't care about regzbot for now, but it would really help if
everyone would CC regressions@...ts.linux.dev on mails regarding
regressions (e.g. reports or any replies to them).

> Greg had one suggestion,

Still not sure how to approach his use case, but for now I started
adding the usual subsystem commit summary prefixes (e.g. "net:", "usb:",
"drm/amd") to the title of newly added regression, which might help
somewhat and won't hurt.

> I have another - namely about grouping of these things.
>
> I like how you group them by "identified" and "unknown", because
> that's certainly very meaningful.
> 
> But at the same time it does mean that if I look for "what are current
> issues with the development kernel", it ends up being very spread out:

Hah, fun fact: the order you purposed was the one I initially had in
mind. But I later changed my mind, as I thought 'hey, if the culprit of
the regression is known, it should be able to fix this quickly (e.g. by
a revert, if there are no conflicts) even for regressions that made it
into proper releases".

But whatever: I'm totally fine with this and already changed the web
interface yesterday after your mail arrived, only took a minute:

https://linux-regtracking.leemhuis.info/regzbot/mainline/

Next report will use this order as well.

> I suspect that Greg may have a slightly similar issue - as a driver
> maintainer, he cares about current cycle things (but mainly only when
> they affect his subsystems), but with his stable maintainer hat on he
> then cares more about the older cycles.
> 
> Greg suggested splitting out the issues one by one - to try to have
> the right people on the Cc for any _particular_ issue, and while I
> think that's not the solution in this case (I very much want to see
> the "summary" email), it would be good to perhaps at least organize
> that summary email slightly differently.
> 
> I suspect this is something we'd need to iterate on as we use this in
> our workflow

Definitely. If there is something else you want to see changed or think
is odd wrt to regzbot or my work as regression tracker, just let me know.

> but that was my initial reaction to this first report.

Thx for the feedback, much appreciated.

Ciao, Thorsten