<sima>
tzimmermann, airlied my stuff got stolen over lunch at the river board yesterday, was busy running around sorting that out
<sima>
will do the pr now
Guest17624 has quit [Ping timeout: 480 seconds]
<tzimmermann>
oh, that sucks
<tzimmermann>
sima, thanks a lot
simon-perretta-img has joined #dri-devel
<sima>
hm airlied already sent the pr, I guess I'll do another on in drm-fixes
<tzimmermann>
sima, i still see 11 unmerged patches in drm-misc-fixes. some of those are from last week
hikiko has joined #dri-devel
<sima>
tzimmermann, yeah applying it to drm-fixes now, it's compiling
<sima>
if you can do another pr today once it's out so I can forward it all to linus would be great
Nasina has joined #dri-devel
hikiko_ has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
cascardo_ has quit []
cascardo has joined #dri-devel
<sima>
tzimmermann, pushed
<tzimmermann>
sima, great thanks
<tzimmermann>
sima, dumb question, do you handle drm-misc-fixes during merge windows? i've looked at airlied's PR and i'm confused. it contains drm-misc-next-fixes but not drm-misc-fixes
<sima>
tzimmermann, he might have not included it because it requires a backmerge and then forgot about it
<tzimmermann>
i see.
<sima>
I'm wondering whether we should just do parallel pr from both drm-next and drm-fixes
<sima>
since otherwise we'd need to recreate linus' main drm-next pr merge, which isn't great
<sima>
I've done that, but it's a bit a mess
<sima>
I think trying to teach committers to not push to the wrong -fixes is not ever going to work out
<sima>
and blocking the branches in gitlab probably only results in bugfixes getting lost
<sima>
tzimmermann, anyway I'll do them all through drm-fixes now, pls bring it on
<tzimmermann>
shouldn't -next-fixes only be open between -rc6 and the kernel release?
<sima>
airlied, ^^ dunno what else beyond "embrace the committer chaos" we have for options
<tzimmermann>
:D
<sima>
tzimmermann, yeah, but drm-misc-fixes during the merge window is usually the wrong baseline
<sima>
tzimmermann, also thanks for the ping to make sure those patches aren't left behind
<tzimmermann>
that's confusing
<tzimmermann>
when the merge window is open, drm-fixes goes into linus' master, which will become -rc1. right?
<sima>
yeah it was, not entirely awake yet here
<sima>
I meant that drm-misc-fixes is often the right baseline (since it's a fresher -rc) for -fixes, but at least my idea was to not use it during -rc since that means we have the backmerge chaos
<sima>
so there's tensions between committers just wanting to drop their bugfixes into the most convenient tree and what linus wants in terms of history
<ukleinek>
..ooOO(And what gregkh wants for stable)
<sima>
so drm-misc-fixes is often the right baseline for committers but the wrong from maintainer pov
<sima>
ukleinek, we mostly managed to explain to gregkh what he needs to do, and he updated his scripts
<sima>
so that's sorted
<tzimmermann>
urgh
<sima>
only took 8 years of screaming on dri-devel though
<sima>
tzimmermann, committers are great for scaling, but also bring some unique problems, it's just part of the deal
<tzimmermann>
to help committers and backporters, maybe we could instrument dim to warn if patches with Fixes tag goe into non-fixes branches. and it could warn about patches without Fixes tag that go into -fixes branches
<sima>
tzimmermann, might have a Fixes: for a patch in -next
<sima>
and we still want those Fixes: tags, in case someone cherry-picks the original -next patch to a stable tree later on
<tzimmermann>
it's ok to do this intentionally, but often commiters simply don't know better
<sima>
this check would discourage people from adding these tags to -next bugfixes, so might be net loss
jsa1 has joined #dri-devel
<sima>
yeah I'm not sure committers would know when it's ok to do this intentionally, they'd just delete the tags
<sima>
imo current state is best, bit of fun around the merge window, but probably least amount of lost patches overall
<tzimmermann>
sima, if it's just a single patch that goes to stable, it shouldn't go into -next. dim could detect this
<sima>
since the merge window fun only occasionally means they are delayed in the pr train, not lost
<tzimmermann>
well, ok
<sima>
tzimmermann, the case of bugfix later on cherry-picked is sometimes "didn't realize", sometimes intentional additional testing, sometimes (like for intel/amd) intentional process
kts has joined #dri-devel
<sima>
and if we'd do at the sha1 in Fixes: it would probably mean even more patches in drm-misc-fixes during the merge window than now
<sima>
since that'd be the default recommendation
<tzimmermann>
good point
<sima>
and we still haven't figured out how to script "are we in the merge window" after almost a decade
<sima>
hence my conclusion to just embrace the occasional chaos as the price for patches at least landing somewhere
<tzimmermann>
sima, something else: i'd like to finally get some of https://patchwork.freedesktop.org/series/141168/ merged. you already looked through it. could you please review the first two patches. once they are in, the driver updates can follow one by one
<sima>
tzimmermann, will do this afternoon, need to run some errands now
<tzimmermann>
ukleinek, is net a large tree? i have a feeling that we cannot close drm-next for two weeks
<tzimmermann>
sima, thanks
<sima>
tzimmermann, only one that's bigger than drm
<tzimmermann>
haha :D
<sima>
on how big net is
<sima>
otoh never looked at committers, might be that drm has more people committing to trees than everyone else
<ukleinek>
tzimmermann: I didn't intend to suggest closing drm-next, just use the link as indication for "Are we in the merge window"?
<sima>
ukleinek, the problem is that indication isn't good enough, would need to be precise or patches get lost
<ukleinek>
yes, I think net has only a handful of committers but more patches. (Didn't recheck though)
<sima>
ukleinek, we also have the additional fun that our drm-misc-next is always open (so that committers can always push)
JRepin has quit []
JRepin has joined #dri-devel
<sima>
which means before the merge window until -rc1 we have 3 trees: -rc bugfixes, merge window bugfixes, -next for the subsequent merge window
<sima>
ukleinek, closing -next for a month with committers just means they forget to push all that stuff and it'd be pure chaos after -rc1
<ukleinek>
sima: "I didn't intend to suggest closing drm-next"
<sima>
and it's that "3 branches actually for one month before -rc1" which is confusing committers
<sima>
ukleinek, yeah, just explaining why "are we in the merge window" is more messy for us since you need to pick the right branch among 3 trees
<sima>
tzimmermann, airlied I think the only really clean approach is what amd/intel do, committers push to -next only, maintainers cherry-pick correctly, gregkh's scrip supports that now
<sima>
but it's real work for drm-misc, I think more than the usual merge window confusion
<sima>
*drm-misc maintainers
sghuge has quit [Remote host closed the connection]
Mangix has quit [Remote host closed the connection]
<ukleinek>
getting rid of the duplicates in -next when a patch is commited to a fixes branch would be nice from the POV of an drm-outsider, but I see the complications that this would result in.
sghuge has joined #dri-devel
Mangix has joined #dri-devel
<tzimmermann>
sima, i don't like this. for maintaining suse kernels, i end up with lots of bug fixes that don't have Fixes tags. figuring out the broken commit complicates backporting. amd is notorious for that.
<sima>
tzimmermann, did you look at the cherry-pick sha1 resolver gregkh built?
<sima>
that should help
JRepin has quit [Remote host closed the connection]
<sima>
and I've asked agd5f to included the necessary cherry-picked from lines for amd trees now too to help with that
JRepin has joined #dri-devel
<tzimmermann>
sima, we have our own tooling. it uses what upstream already provides. yet there are cases remaining
The_Company has quit [Read error: Connection reset by peer]
vliaskov__ has joined #dri-devel
<sima>
tzimmermann, in the past agd5f deleted the cherry-pick annotations because gregkh complained about them
<sima>
if we still have this with recent stuff (meaning landed this year in -next) we need to look into it and add what's missing
epoch101 has joined #dri-devel
rasterman has joined #dri-devel
warpme has joined #dri-devel
simon-perretta-img has quit []
anholt has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
dolphin has quit [Quit: Leaving]
simon-perretta-img has joined #dri-devel
lynxeye has joined #dri-devel
LeviYun has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
rjodin has joined #dri-devel
epoch101 has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
psykose has joined #dri-devel
rjodin has quit []
phasta has joined #dri-devel
hikiko_ has joined #dri-devel
fab has joined #dri-devel
fab has quit []
hikiko has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
<mripard>
sima: it also doesn't help that committers don't always get the same answer to the question "which tree should I commit this" depending on who you ask :)
<mripard>
the policy of what is indeed a fix isn't defined anywhere afaik
haaninjo has joined #dri-devel
<airlied>
my usual policy unless something is super urgent I often leave drm-misc-fixes until rc1 is out
<airlied>
because I don't want to be constantly explaining to Linus why these things have different bases and might conflict
<airlied>
I suppose I should just suck it up and continue fixes in the merge window
simon-perretta-img_ has quit []
simon-perretta-img has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
<sima>
airlied, yeah that's what I'm leaning towards too
<sima>
we've sorted out the "but alll thheeeesee cherry-picks" lament from gregkh, need a new one
<sima>
mripard, hm I thought we're defacto going with "like stable"
<sima>
and I thought that was documented somewhere
<sima>
but yeah in reality it's not the same, because linus is more lenient than gregkh with "what is a bugfix" at least sometimes
<sima>
and so people see a difference
jsa1 has quit [Ping timeout: 480 seconds]
<kode54>
dammit, I have the sad confused brains
<kode54>
every time I see gregkh's name I think of Zoah from Chrono Cross
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
nashpa has quit []
dliviu has joined #dri-devel
guludo has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
jsa1 has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
fab has joined #dri-devel
alarumbe has quit []
hansg has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
fab has quit []
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
egbert has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
fab has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
<mripard>
sima: "like stable" isn't really clear cut either right now
<mripard>
it's "what people think are fixes" + "what the AUTOSEL bot thinks is a good fix, even it's not"
warpme has quit []
fab has quit [Quit: fab]
fab has joined #dri-devel
apinheiro has quit [Quit: Leaving]
fab has quit []
fab has joined #dri-devel
fab has quit []
<sima>
mripard, yeah, it's complicated
warpme has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
<phasta>
I've also wondered more than once already why AUTOSEL picks some of my patches, which clearly are not bugs, but just mere improvements, and where stable was not on CC