00:24 zmike: DavidHeidelberg[m]: I think today might be the last day that zink dominates the ci fail charts
00:26 DavidHeidelberg[m]: zmike: 🎊
00:36 HdkR: zmike: Zink is finally going to lose at something?
00:36 HdkR: What is this reality?
00:48 daniels: zmike: don't talk yourself down like that, you can get right back to the top of the charts in no time
00:52 zmike: daniels: thanks, that's the kind of pep talk I needed to motivate myself into adding even more subtle flakes to fail merge jobs
08:35 danvet: mlankhorst, should we do backmerge dance after -rc4 because -misc-next is still on -rc1?
08:35 danvet: that's always a bit a wobbly one :-)
08:37 danvet: rodrigovivi, ^^ maybe intel-next needs that too?
10:12 danvet: tzimmermann, mlankhorst, mripard: what's your thoughts on expanding the drm-misc MAINTAINER entry to essentially match drm?
10:12 danvet: would essentially officiate drm-misc's role as the fallback place
10:13 danvet: currently lost patches are stuck for a long time until it bubbles all the way to airlied&me
10:13 danvet: (for drivers at least)
10:13 danvet: but also doing that means you get a ton more mails
10:13 danvet: or well, cc'ed on a ton more mails
10:15 danvet: currently the file match tries to limit to just shared code
10:20 danvet: I think ideal would be if we auto-label lost patches after a month or so, but that's a level of semantics that a mailing list doesn't support
10:31 danvet: I think ideal would be if somehow drm-misc maintainers would get auto-added for every path that's listing drm-misc.git as the repo
10:31 danvet: and not for all of drm
10:31 danvet: so that the big driver trees like amd/intel/msm... aren't included
10:31 danvet: but I have no idea how that could work (except manually, which is just ... ugh)
10:35 mripard: danvet: on principle, I'm fine with it
10:35 mripard: I wonder if it's not going to have the opposite outcome if amd, intel and so on are added
10:36 danvet: mripard, yeah if the result is that you just get flooded like airlied&me and only look when the shouting is too loud, it's probably not useful
10:36 mripard: like I'm pretty sure I'll just archive most of those patches without even fully reading them because there's too many mails, and it doesn't look like something for drm-misc
10:36 danvet: yeah
10:37 danvet: limiting to only what's explicitly in drm-misc would cut down
10:37 danvet: but not in a really substantial amount
10:37 mripard: but there will probably be a lot of false negatives
10:37 danvet: in the end mailing lists for tracking submissions are just not great
10:37 mripard: does get_maintainer support blocklist?
10:37 danvet: like some bot that pings you when a timer runs out might work
10:37 danvet: blocklist?
10:38 danvet: oh negative entries you mean
10:38 javierm: danvet: there's a X: field in the MAINTAINERS file to exclude some paths
10:38 mripard: if so, we could just say for drm-misc we maintain everything but amd, intel and msm
10:38 danvet: mripard, yeah it has exclude patterns
10:38 javierm: so you could for example add a 'X: drivers/gpu/drm/amd/'
10:38 mripard: and whatever else we want to exclude
10:38 mripard: let's do this then
10:38 danvet: mripard, yeah that sounds good
10:39 danvet: that way even the trees which are nominally maintained, but not at the same level as these tree would be included
10:39 danvet: it's still a shit ton of mails though :-(
10:39 danvet: mripard, I guess up to you three whether you want to try or not
10:40 danvet: try as in sign up for this flood :-)
10:40 danvet: but with the X: patterns for the big driver subtrees it should be workable I guess
10:40 mripard: yeah well
10:40 mripard: we could also start to use patchwork
10:41 mripard: but I have the feeling it's just a different can of worms
10:41 danvet: yeah it is
10:41 danvet: the trouble is that you still have no one marking old stuff as deprecated
10:41 danvet: and it's out-of-line metadata too
10:41 javierm: danvet: I do for my patches btw :) we could enforce that
10:42 javierm: got used to that when contributed to media/v4l2 because they make proper use of patchwork
10:42 danvet: and there's not even basic stuff like tagging so could do some meaningful-ish searches
10:42 danvet: javierm, yeah I guess if people only pick up patches from pw it might work
10:42 danvet: but we have a ton of committers
10:43 javierm: danvet: yes, but we could integrate with dim
10:43 javierm: and mark as merged patches that matches the subject line for example
10:43 danvet: javierm, oh that happens already
10:43 danvet: server-side even
10:44 danvet: the trouble is when you revise patches and patchwork doesn't realize that it's superseeded on its own
10:44 javierm: oh, I didn't know that
10:44 danvet: or when you drop a patch set
10:44 javierm: danvet: yeah, there's some work that submitters would need to do to make sure that their own patch series are up-to-date
10:44 javierm: or delegate to someone to do the cleanup. I belive the latter is what v4l2 folks do
10:45 danvet: javierm, that tends to run into the "m-l is awesome because you don't need an account" argument
10:45 javierm: danvet: hmm...
10:45 javierm: any sentence that starts with "m-l is awesome..." probably isn't true anyways :)
10:45 danvet: and at that point we might as well just do gitforge mr :-)
10:45 danvet: but yeah, dunno
10:47 danvet: tbh I'm also ok with the continuing fine tradition of just dropping stuff on the floor
10:47 danvet: it's kinda what you get
10:50 javierm: yeah, specially since probably quite old patches won't apply cleanly anymore so at the very least needs a rebase and re-test
10:50 mripard: danvet: iirc, b4 can tag the patches it applies as such on pw
10:50 danvet: oh I'd say after a full release/quarter you just auto-close and wait for the rebase
10:50 mripard: we could just use b4 in dim, and every committer would use it.
10:51 danvet: mripard, it's not the patches that you apply, but the ones that are outdated/superseeded/invalid that clog the gears
10:51 mripard: ok
10:51 danvet: atm we just age them out after 2 weeks in reality
10:51 danvet: which is the same crack all the lost stuff disappears in
10:52 javierm: I think 2 weeks is too soon btw, I always have to search on patchwork with archive=both
10:52 tagr: danvet: regarding that host1x fix, looks like Linus picked that up already a few days ago
10:52 danvet: oh
10:52 danvet: oh well it's in both trees now
10:53 tagr: sorry about that, I've had it in the for-next branch for Tegra for a while but forgot to send a PR
10:54 tagr: timing was a bit weird because I left during the merge window for a couple of weeks and then got back after -rc3
10:54 tagr: I should've just sent during the merge window
10:55 tagr: danvet: but like I said in the mail, it's probably best at this point to move Tegra to drm-misc fully, the overhead of the separate tree is no longer justifiable I think
10:57 danvet: tagr, yeah don't worry about this patch, we loose things through cracks fairly regularly
10:57 danvet: just good to ponder whether there's anything obvious we can do to do better
10:58 danvet: I think at least fixes in drm-misc is probably the obvious one to avoid patches lost in branches without a pr
10:59 tagr: yeah
11:00 tagr: to be honest, I'm a bit surprised how the original patch made it through in the first place because I do run build tests and this should've shown up
11:00 tagr: unless perhaps it's hidden behind some flag that I don't happen to enable
11:00 tagr: uninitialized variables really should be flagged by default, though
11:01 danvet: tagr, apparently it's clang that noticed it
11:01 danvet: and somehow gcc didn't
11:07 tagr: danvet: ugh...
11:07 tagr: guess I'm going to have to start doing builds with both then
16:58 dcbaker: doras: that commit is specifically tagged as a fixing a commit in the 23.0 branch, but the other two commits are not.
16:59 dcbaker: I'd guess that this is a case where the previous commit always provoked an existing bug, but it was possible to hit regardless
17:00 MrCooper: doras: you're not authenticated with NickServ, so your messages aren't coming through to IRC
17:05 dcbaker: Also, PSA: I'm still very behind on releases, whatever I can get pulled into the staging/23.0 branch today (and green in CI) will be released tonight (PDT). There will likely be stuff tagged that will not be in this release, I apologize for how long it's taking
17:31 doras: Thanks MrCooper. I guess lack of SASL authentication in OFTC is making this harder than it needs to be.
17:33 doras: dcbaker: I mostly meant that "nir: use xyzw order for precise fdot" is marked with resolution "1" by the commit that I linked, but the relevant commit wasn't actually cherry-picked to `staging/23.0`.
17:33 dcbaker: doras: ah, I'll have to look to be sure, but I think it's causing regressions in the radv traces
17:35 dcbaker: hmm, yeah, that did get marked as commited even though it wasn't...
17:35 dcbaker: odd
17:37 dcbaker: fixed now locally, thanks
17:37 doras: Great :)
23:45 mareko: passion, persistence, play... does it sound familiar, intel guys? :)