06:15 tzimmermann: airlied, sima, hi. please merge last week's PR of drm-misc-fixes https://lore.kernel.org/dri-devel/20250528153550.GA21050@linux.fritz.box/
06:16 sima: tzimmermann, airlied my stuff got stolen over lunch at the river board yesterday, was busy running around sorting that out
06:16 sima: will do the pr now
06:16 tzimmermann: oh, that sucks
06:17 tzimmermann: sima, thanks a lot
06:20 sima: hm airlied already sent the pr, I guess I'll do another on in drm-fixes
06:24 tzimmermann: sima, i still see 11 unmerged patches in drm-misc-fixes. some of those are from last week
06:26 sima: tzimmermann, yeah applying it to drm-fixes now, it's compiling
06:26 sima: if you can do another pr today once it's out so I can forward it all to linus would be great
06:36 sima: tzimmermann, pushed
06:36 tzimmermann: sima, great thanks
06:36 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
06:37 sima: tzimmermann, he might have not included it because it requires a backmerge and then forgot about it
06:37 tzimmermann: i see.
06:37 sima: I'm wondering whether we should just do parallel pr from both drm-next and drm-fixes
06:37 sima: since otherwise we'd need to recreate linus' main drm-next pr merge, which isn't great
06:37 sima: I've done that, but it's a bit a mess
06:38 sima: I think trying to teach committers to not push to the wrong -fixes is not ever going to work out
06:38 sima: and blocking the branches in gitlab probably only results in bugfixes getting lost
06:38 sima: tzimmermann, anyway I'll do them all through drm-fixes now, pls bring it on
06:39 tzimmermann: shouldn't -next-fixes only be open between -rc6 and the kernel release?
06:39 sima: airlied, ^^ dunno what else beyond "embrace the committer chaos" we have for options
06:39 tzimmermann: :D
06:39 sima: tzimmermann, yeah, but drm-misc-fixes during the merge window is usually the wrong baseline
06:39 sima: tzimmermann, also thanks for the ping to make sure those patches aren't left behind
06:40 tzimmermann: that's confusing
06:41 tzimmermann: when the merge window is open, drm-fixes goes into linus' master, which will become -rc1. right?
06:41 sima: yeah it was, not entirely awake yet here
06:42 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
06:42 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
06:43 ukleinek: ..ooOO(And what gregkh wants for stable)
06:43 sima: so drm-misc-fixes is often the right baseline for committers but the wrong from maintainer pov
06:43 sima: ukleinek, we mostly managed to explain to gregkh what he needs to do, and he updated his scripts
06:43 sima: so that's sorted
06:43 tzimmermann: urgh
06:43 sima: only took 8 years of screaming on dri-devel though
06:44 sima: tzimmermann, committers are great for scaling, but also bring some unique problems, it's just part of the deal
06:44 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
06:44 sima: tzimmermann, might have a Fixes: for a patch in -next
06:45 sima: and we still want those Fixes: tags, in case someone cherry-picks the original -next patch to a stable tree later on
06:45 tzimmermann: it's ok to do this intentionally, but often commiters simply don't know better
06:45 sima: this check would discourage people from adding these tags to -next bugfixes, so might be net loss
06:46 sima: yeah I'm not sure committers would know when it's ok to do this intentionally, they'd just delete the tags
06:46 sima: imo current state is best, bit of fun around the merge window, but probably least amount of lost patches overall
06:46 tzimmermann: sima, if it's just a single patch that goes to stable, it shouldn't go into -next. dim could detect this
06:46 sima: since the merge window fun only occasionally means they are delayed in the pr train, not lost
06:47 tzimmermann: well, ok
06:48 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
06:49 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
06:49 sima: since that'd be the default recommendation
06:49 tzimmermann: good point
06:50 sima: and we still haven't figured out how to script "are we in the merge window" after almost a decade
06:50 sima: hence my conclusion to just embrace the occasional chaos as the price for patches at least landing somewhere
06:51 ukleinek: look at https://patchwork.hopto.org/net-next.html :-)
06:51 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
06:52 sima: tzimmermann, will do this afternoon, need to run some errands now
06:52 tzimmermann: ukleinek, is net a large tree? i have a feeling that we cannot close drm-next for two weeks
06:52 tzimmermann: sima, thanks
06:53 sima: tzimmermann, only one that's bigger than drm
06:53 tzimmermann: haha :D
06:53 sima: on how big net is
06:54 sima: otoh never looked at committers, might be that drm has more people committing to trees than everyone else
06:54 ukleinek: tzimmermann: I didn't intend to suggest closing drm-next, just use the link as indication for "Are we in the merge window"?
06:55 sima: ukleinek, the problem is that indication isn't good enough, would need to be precise or patches get lost
06:55 ukleinek: yes, I think net has only a handful of committers but more patches. (Didn't recheck though)
06:55 sima: ukleinek, we also have the additional fun that our drm-misc-next is always open (so that committers can always push)
06:56 sima: which means before the merge window until -rc1 we have 3 trees: -rc bugfixes, merge window bugfixes, -next for the subsequent merge window
06:56 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
06:57 ukleinek: sima: "I didn't intend to suggest closing drm-next"
06:57 sima: and it's that "3 branches actually for one month before -rc1" which is confusing committers
06:57 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
06:59 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
06:59 sima: but it's real work for drm-misc, I think more than the usual merge window confusion
06:59 sima: *drm-misc maintainers
07:00 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.
07:01 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.
07:03 sima: tzimmermann, did you look at the cherry-pick sha1 resolver gregkh built?
07:03 sima: that should help
07:03 sima: and I've asked agd5f to included the necessary cherry-picked from lines for amd trees now too to help with that
07:07 tzimmermann: sima, we have our own tooling. it uses what upstream already provides. yet there are cases remaining
07:17 sima: tzimmermann, in the past agd5f deleted the cherry-pick annotations because gregkh complained about them
07:18 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
09:03 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 :)
09:03 mripard: the policy of what is indeed a fix isn't defined anywhere afaik
09:16 airlied: my usual policy unless something is super urgent I often leave drm-misc-fixes until rc1 is out
09:17 airlied: because I don't want to be constantly explaining to Linus why these things have different bases and might conflict
09:20 airlied: I suppose I should just suck it up and continue fixes in the merge window
10:11 sima: airlied, yeah that's what I'm leaning towards too
10:11 sima: we've sorted out the "but alll thheeeesee cherry-picks" lament from gregkh, need a new one
10:12 sima: mripard, hm I thought we're defacto going with "like stable"
10:12 sima: and I thought that was documented somewhere
10:12 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
10:12 sima: and so people see a difference
10:22 kode54: dammit, I have the sad confused brains
10:22 kode54: every time I see gregkh's name I think of Zoah from Chrono Cross
11:57 mripard: sima: "like stable" isn't really clear cut either right now
11:58 mripard: it's "what people think are fixes" + "what the AUTOSEL bot thinks is a good fix, even it's not"
12:08 sima: mripard, yeah, it's complicated
12:21 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
12:37 sima: phasta, it's just statistical guesses plus a heavy bias towards picking a patch in case of doubts
14:43 mareko: alyssa: any further comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35315 ?
15:37 MrCooper: sima: plus now with AI slop (which for me means I've stopped even looking at those for now)
15:43 sima: MrCooper, I thought it was just a classifier NN and not genAI slop?
15:43 sima: but yeah still unexplainable mistakes that can't be fixed
15:45 MrCooper: the last batch of autosel patches I saw had "reasoning" after the --- separator
15:46 sima: ugh
15:46 sima: yeah I missed that
15:47 sima: you'd probably need to throw that thing into another llm and ask it to condense it down to something readable :-/
15:48 MrCooper: sounds like LLMs are the new turtles
15:48 MrCooper: maybe if one stacks them high enough, magic happens
17:09 mdnavare_: Awesome thank you so much emersion
22:29 mareko: tarceri_: FYI https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35315