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

[Linus Torvalds]

Ok, nice to see the new regression tracking bot start to show life.

Greg had one suggestion, 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:

On Wed, Nov 24, 2021 at 1:25 AM Regzbot (on behalf of Thorsten
Leemhuis) <regressions@xxxxxxxxxxxxx> wrote:
>
> ========================================================
> current cycle (v5.15.. aka v5.16-rc), culprit identified
> ========================================================
...
> =========================================================================================
> previous cycle (v5.14..v5.15), culprit identified, with activity in the past three months
> =========================================================================================
...
> ==================================================================================
> older cycles (..v5.14), culprit identified, with activity in the past three months
> ==================================================================================
...
> ====================================================
> current cycle (v5.15.. aka v5.16-rc), unkown culprit
> ====================================================
...

note how there was a lot of other stuff in between those "culprit
idenfified" and "unknown culprit" for the current kernel.

One of the things I really liked about the regression tracking you did
before was that it helped me get a sense for the state of the release,
and so I'd like to see that "current cycle" in one go.

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, but that was my initial reaction to this first report.

               Linus