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

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 20 Apr 2023 17:59:49 +0200 Thorsten Leemhuis wrote:
> > 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).

I wouldn't bother with the patches you didn't track in regzbot.
This probably depends on how various people apply / maintain their
patches (sigh) but for networking (and anything else that's pretty 
pure git management) author date of the commit should give you the
time when patch was posted.

So we could go regzbot report date -> author date in upstream -> commit
date in stable potentially without much coding.

Going to Linus's tree vs stable should also be possible. Chris Mason
has showed me once a git incantation which finds the merge commit in
Linus's tree at which a given patch has arrived.. but I lost it.

> >> 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.

I'm a but curious what Linus would think, too.

Just to be clear the assumption I operate on is that all regressions
are important to fix within reasonable time frame. The question is
whether it matters for this regression that we're close to final.
Whether we should engage extraordinary means to get the fix in before
final is cut.

If it was a 6.3 regression we should try as hard as we can to fix it
in final (e.g. the mlx5 regression), if it's in 6.2 already - the extra
week of waiting may not be worth skipping trees and bothering Linus.

IOW for older regressions there's only the question of whether the fix
is in upstream in a reasonable time. It doesn't matter as much which
particular tag it hits.