Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()

[Thorsten Leemhuis <regressions@leemhuis.info>]

On 20.04.23 16:50, Jakub Kicinski wrote:
> On Thu, 20 Apr 2023 16:24:53 +0200 Toke Høiland-Jørgensen wrote:
>>>> But it is always a question of time :) To save
>>>> time I usually try to send two wireless tree pull requests per cycle,
>>>> one early in the cycle and the second around the middle.  
>>>
>>> Why not ask Linus to pull this directly from the list then?

BTW (to reply to two mails with one): Toke, thx for giving it a shot!

> Out of curiosity, Thorsten, do you have stats on "how long does it take
> fixes to reach Linus" per tree? Stats get people to act much quicker
> than pleas, just sayin' ;)

I know, I know... :-( Nevertheless thx for the reminder. :-D

I really wish that I had some, but right now the data I have in regzbot
is too messy and not a good base to generate such stats, as they would
likely be misleading (that's the long story short).

I once had the rough plan to approach this differently by looking at all
commits that ended up in the first big batches of stable updates (e.g.
releases like 6.0.3 with many hundreds of changes). I wanted to filter
out the regression fixes and then (1)look how long it took from posting
the fix till it was mainlined and (2)backported to stable. But there
afaics is no good way to automate the first part of the job: filtering
out fixes for regressions that actually bothered someone and might or
might not have been tracked by regzbot (the "might not" share might be
the bigger one, which is part of the valid stats problem indicated above).

>>> He doesn't
>>> mind doing that for an occasional regression fix. And then he can decide
>>> himself if the change is worth the risk -- and obviously can take into
>>> account if he'll release and rc8 or not.  
>>
>> I'm OK with doing it that way; I'll do so later tonight unless Kalle or
>> Jakub complains before then...
> 
> Ah, just after our last(?) 6.3 PR was submitted :(
> No objections to you posting this directly to Linus...
> 
> That said it is a 6.2 regression AFAICT so it's not exactly in the
> "must be fixed in 6.3" category.

Out of curiosity (really, it's not meant as a rhetorical device, I'm
trying to understand this point of view):

Why do you think that? And should it really be like that?

Sure, if it was an old problem (say from 5.18) that was only recently
found I'd agree, especially if the fix might have a more than average
risk of causing other trouble. But shouldn't we care about regressions
that were found shortly after a release (e.g. 6.2 in this case) at least
as much (or maybe even more?) as we care about those found during the
weeks preceding it?

FWIW, it's not the first time I hear a statement like that and every
time I wonder how Linus thinks about this. But whatever, not going to CC
him for that.

Ciao, Thorsten