[regression] ath11k broken in v6.7

[Kalle Valo]

Thorsten Leemhuis <regressions at leemhuis.info> writes:

> On 22.01.24 09:24, Kalle Valo wrote:
>> "Linux regression tracking (Thorsten Leemhuis)"
>> <regressions at leemhuis.info> writes:
>>
>>> FWIW, that usage was slightly off and not how it's supposed to be done.
>>> But whatever, let's ignore that. I'm reworking things currently
>>> slightly, as you are not the first one that slightly got mislead -- and
>>> the newer commands will hopefully be mire intuitive.
>> 
>> Just to educate myself, how should I have done it? (But feel free to
>> skip the question if you are busy)
>
> I think that's not worth it, as I hope to introduce the new commands in
> the near future (but you know how it is with the last 5 to 10
> percent...).

I sure do know :) I assume you will announce in the regressions list
once the new interface is available, I'll then take a look at it in
detail and update my notes.

> But let me show you how it's then supposed to be done in this
> situation, that way you can give early feedback:
>
>   #regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218364
>   #regzbot introduced: 0a3d898ee9a8
>
> That "#regzbot report" will be new and make it more obvious to users
> what regzbot should consider to be the report (e.g. what Link:/Closes:
> tags later in commits fixing the issue will link to).

Thanks, this looks very intuitive to me.

> You used "#regzbot introduced: 0a3d898ee9a8 ^" and due to the "^" it
> assumed the start of this thread would be the report

Actually I did that on purpose as I wanted to test how including a mail
to a regression report works :)

> (side note: mixing that aspect into the "introduced" command was a
> stupid idea anyway.).
>
> That "#regzbot link:" will vanish as well (at least from the docs, it
> will remain to be supported), as people use it wrong in various
> different ways: for duplicates, reports (like your did), patch
> submissions fixing the issue (then 'regzbot monitor' should have been
> used) among others. Which is totally understandable now that I look at
> it. That's why it will be replaced by "#regzbot related: <url>" to avoid
> any connection with the Link: tag used in commits; for duplicates
> "#regzbot dup:" will stay around.

So, in the new interface, how should I handle a situation that a
regression is first reported on the mailing list, added to regzbot and
later there's also a bug report opened for the issue?

>> I wish there would be a person who could follow stable
>> releases from wireless perspective and make sure everything is ok there.
>
> Maybe at some point regression tracking can help somewhat with that. But
> I still have to fix a few things to make people use it and scale it up.

I just feel it should be more than that, I'm worried that randomly
taking wireless commits to stable releases is risky. There really should
be someone looking after wireless (read: reviewing patches) in stable
releases. This would be a good role for someone who is interested to
learn how kernel.org development works and helping the community. Do we
have a way to announce these kind volunteer vacancies somewhere? :)

> Side note: some people seem to have gotten the impression that I care a
> lot about *all* stable/longterm kernels. Let me use this opportunity to
> say that it's not really the case. I fully understand and respect that
> those series are a somewhat separate thing some developers don't want to
> be involved in (especially the older trees). But the thing is: the
> latest stable tree is what we tell users to use -- and something quite a
> few important distros ship as their regular kernel these days. That's
> why I take special care of regression that found there.

Yeah, I understand that a lot of users use stable kernel releases. But
the reality is that we in wireless really don't have the bandwidth to
manage stable kernels, it is enough of a challenge to manage Linus'
releases. So help here is very much needed.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches