12:01:01 <jki> #startmeeting CIP IRC weekly meeting
12:01:01 <collab-meetbot> Meeting started Thu Sep  3 12:01:01 2026 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:01 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:01 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:01 <masami> hi
12:01:06 <jki> #topic AI review
12:01:12 <jki> <void>
12:01:21 <jki> 5
12:01:23 <jki> 4
12:01:24 <jki> 3
12:01:26 <jki> 2
12:01:27 <jki> 1
12:01:30 <jki> #topic Kernel maintenance updates
12:01:35 <uli_> i've been working on 4.19
12:01:39 <masami> This week reported 136 new CVEs and 69 updated CVEs.
12:01:57 <pave1> I was reviewing 6.12.106 and .108.
12:01:59 <jki> "I reviewed v6.12.97." (iwamatsu-san)
12:02:52 <jki> there were some single-fix stable release(s?) again - anything we need to worry about?
12:03:05 <pave1> .107. I took a look, nothing for us.
12:03:12 <uli_> in 5.10 one, then one that reverts the one, and then another one :)
12:03:50 <jki> release oscillations
12:04:07 <jki> so, no special actions needed, I hear
12:04:55 <pave1> virtio_net_hdr. I actually may take another look, as I initially parsed as virtualization
12:05:02 <pave1> only, and it may be broader.
12:05:24 <jki> remote?
12:05:38 <pave1> But we probably do not use related functionality... so should be ok.
12:05:41 <jki> and virt is in scope for us
12:05:55 <jki> we surely use virtio-net e.g.
12:05:55 <pave1> Not remote, afaict. Someone having access to tun/tap.
12:06:02 <jki> ok
12:06:19 <pave1> Yeah, you probably should not allow KGB agents to use virtio-net :-).
12:06:31 <pave1> So in scope, but I would not panic for this one.
12:07:17 <jki> anything else?
12:07:42 <jki> 5
12:07:44 <jki> 4
12:07:45 <jki> 3
12:07:47 <jki> 2
12:07:49 <jki> 1
12:07:52 <jki> #topic Kernel release status
12:08:00 <jki> all on track
12:08:07 <pave1> My notes say do 4.19-rt as soon as 4.19 is released.
12:08:12 <jki> but a few are upcoming
12:08:38 <jki> yeah, maybe you noticed that I added the version tag to the status report
12:09:12 <jki> can help identifying when rt and vanilla got out of sync due to delayed rt release
12:09:28 <jki> and that is I think what happened with last 4.19-rt
12:10:37 <pave1> Basically we'll want to change 4.4 and 4.19 from "every two months" to "every other -cip release".
12:10:48 <pave1> ...which should be same in ideal world, but...
12:11:17 <jki> there can always be special situation, we should just make sure to realign then
12:11:38 <pave1> (y)
12:12:42 <jki> anything to add?
12:12:55 <jki> 5
12:12:57 <jki> 4
12:12:59 <jki> 3
12:13:01 <jki> 2
12:13:02 <jki> 1
12:13:05 <jki> #topic Kernel testing
12:13:29 <patersonc> Thanks for the QEMU lava-docker MR jki
12:13:40 <patersonc> I assume this installs the version you need now?
12:14:02 <arisut> kci-dev is improving the mcp extension and we are currently writing a document about this
12:14:03 <jki> it installs it, yes - but that is still as much as I checked
12:14:11 <patersonc> Okay
12:14:12 <arisut> we are improving reports
12:14:20 <patersonc> Thanks arisut
12:14:41 <pave1> We should probably start testing 7.2-stable
12:14:42 <arisut> I also just got aware of patersonc PR on pipeline, will review it
12:14:51 <patersonc> In the LAVA world - the TI lab is still offline, sorry. Affected by holidays I believe
12:15:26 <jki> arisut: are there pipelines / workflows for the MCP already?
12:15:56 <arisut> yes, but we have an unofficial mcp server that will be make public next week
12:16:16 <pave1> ok.
12:16:17 <arisut> also the documentation on pipelines/workflows
12:16:28 <arisut> will be released next week
12:17:25 <jki> will be interesting to watch in use (or try out ourselves...?)
12:18:05 <arisut> yes, would be interesting to have cip using it
12:18:23 <jki> I guess there is quite some potential for LLM-based triaging of LAVA results
12:18:45 <arisut> yes
12:18:53 <jki> filtering out patterns, generating context-specific statistic etc
12:19:06 <jki> cool!
12:19:22 <arisut> yes, that would be cool
12:20:19 <jki> more on testing?
12:20:25 <arisut> I will ping you when is ready
12:20:31 <jki> TIA!
12:20:46 <patersonc> I think LAVA is also working on an MCP as well
12:22:21 <jki> 5
12:22:23 <jki> 3
12:22:25 <jki> 4
12:22:27 <jki> 2
12:22:29 <jki> 1
12:22:31 <jki> #topic AOB
12:23:03 <jki> iwamatsu not here, he wanted to have a look at the review tooling
12:23:03 <pave1> I got question about next -cip kernel.
12:23:16 <jki> yes...
12:23:22 <pave1> Slowly we should put 7.4-cip on our radar.
12:24:04 <pave1> And we should probably talk about -rc branches.
12:24:04 <jki> what would be concrete steps?
12:24:50 <pave1> jki: Dunno. I guess "we are selecting next -cip" on TSC meeting.
12:25:11 <pave1> And really start looking for what would be suitable longterm stable in a month or so?
12:25:30 <jki> that discussion will surely start, but we do not know the next version yet, formally
12:26:00 <pave1> No, we don't. It is time for discussion, not for the results :-)
12:26:15 <jki> 7.4 is not unlikely, but there is only a 7.3-rc1 now
12:26:39 <pave1> Yep, simple maths also points to 7.4.
12:26:50 <pave1> I believe we are sure we will not do 6.18-cip at this moment?
12:26:58 <jki> that is clear
12:27:03 <pave1> Ok.
12:27:19 <pave1> So likely "whatever next kernel is marked as longterm stable by Greg".
12:27:36 <jki> same procedure as every two years, yes
12:27:43 <pave1> (y)
12:27:53 <jki> TSC will ask us what it will mean effort-wise
12:28:19 <jki> are we expecting changes, because of the new kernel or anything else?
12:28:27 <jki> that will likely be a topic in Prague
12:28:59 <pave1> LLMs are causing problems. Flood of patches from unusual contributors.
12:29:13 <jki> the CIP project may grow next year, and that can be a chance to address topics that need more attention
12:29:21 <pave1> Of course, it is not LLMs mistake, but..
12:29:21 <jki> or scale up existing work
12:29:27 <patersonc> pave1: Upstream? Or on cip-dev?
12:29:39 <uli_> upstream
12:29:49 <pave1> Upstream. Likely uli has better numbers than me.
12:30:00 <uli_> 1300+ in the last month in 5.10, i didn't check how many are ai
12:30:30 <uli_> that's 5x or so compared to last month
12:30:36 <uli_> *previous month
12:30:38 <patersonc> Sure - mainline/stable is a bit nuts with LLM atm. I was just wondering if CIP had seen any direct patches
12:30:39 <jki> the risk of fragile "fixes" hitting stable is surely rising
12:31:08 <pave1> ...so -- that. I see it in 6.12/6.1 reviews, too.
12:31:28 <jki> that's why we need to think about measures that may help CIP to stand this
12:31:56 <jki> "though AI at it" is not the only answer, but we will likely not be able to ignore that as well
12:32:15 <jki> that's why we are looking into this already
12:32:42 <pave1> So stable maintainers are misusing LLms already, not sure "more LLMs" is the answer.
12:33:05 <pave1> Other side effect is that fixes now hit 6.12 first, and 6.1/5.10 with some delay, causing duplicate reviews.
12:33:06 <jki> did anyone study already what RH is doing in https://hummingbird-project.io/? not kernel, but...
12:34:02 <jki> as I wrote, LLM will not be the only answer
12:34:18 <jki> I do expect more effort on the reviewing side, even with LLM support
12:34:41 <jki> so, if we think we need more hands on deck for that, I would request support
12:34:47 <jki> people or budget
12:35:19 <pave1> I guess question is "is this new normal" or "is this temporary spike"?
12:35:52 <uli_> my observation is that the number of patches has been rising the whole year. the current number is an extreme, but no idea how it will continue...
12:36:10 <pave1> But I'd say more support may well be needed.
12:36:19 <uli_> +1
12:36:26 <jki> given that there are more new - apparently AI-backed - first-time contributors, I expect not only a spike
12:36:54 <jki> than this is already a topic of us for the ETSC in Prague
12:37:17 <jki> it's likely resonating because there is such a strong interest in CIP because of the kernel
12:37:25 <pave1> jki: one could hope that they run out of simple things to fix eventually, but it is hard to predict when that happens.
12:37:54 <jki> I don't think (or read?) that we are only talking about first-time fix contributors
12:38:48 <pave1> jki: no, problem is total ammount of patches going in
12:39:01 <jki> besides more hands on the review and potentially backporting front, I would also stress again that we need eyes and hands on testing
12:39:40 <pave1> yes. And I'd like to see work on reducing configurations, so we concentrate effort on stuff people actually use.
12:40:17 <jki> pavel: that will be tough, but please propose concrete areas
12:40:29 <jki> I rather expect the configs to grow further
12:40:57 <jki> with every new cip kernel and more advanced use cases on top
12:41:16 <jki> that said, there are surely still unneeded switches in our configs
12:41:25 <jki> but how to identify them?
12:42:27 <pave1> jki: we could require each company to write explanation for each switch.
12:42:44 <pave1> jki: they would likely make them realize they don't need the switch after all :-)
12:43:28 <jki> pavel: key problem is that each company is already complex in the chain where the configs come from
12:43:36 <pave1> jki: we could start with switches that look suspicious.
12:43:43 <jki> and then there end-customer scenarios as well
12:44:21 <jki> yes, if someone like you could question concrete switches with significant impact, that is a starting point
12:44:24 <pave1> jki: yeah, eventually it will lead to efforts on companies as well (and maybe even end users).
12:45:12 <pave1> jki: I can try starting with something (when things got a bit quieter).
12:45:30 <pave1> jki: Eventually someone "owning" the configs and having power to ask questions etc could be good.
12:46:11 <jki> we can try, but the easiest way of getting rid of things is when no one forward-ports a config to a newer kernel
12:47:01 <jki> while, at the same time, we also lose bits that are valid because users believe this forward porting is automatic...
12:47:13 <pave1> jki: we may consider starting with minimal kernel for 7.4-cip, so people will need to explicitely ask for config additions.
12:47:31 <jki> that is too late
12:47:52 <jki> we then already started to ignore bits that are actually relevant
12:48:48 <jki> well, too late is relative, but we can't wait for a year or so, like it happened with some 6.12 bits
12:49:26 <jki> key is to get users more actively involve on configs, just not yet clear how to achieve that better
12:50:47 <jki> okay... more topics?
12:50:52 <pave1> jki: Question is how to achieve that without major disruption.
12:51:44 <jki> pavel: continuously talking about it in public :)
12:52:01 <jki> no better idea right now...
12:52:30 <jki> maybe we could live-visualize the subsystems in scope?
12:53:01 <jki> better than only waiting for users to come back with "why did you ignore this CVE?"
12:53:59 <pave1> Publicity is good.
12:55:17 <pave1> We could do some kind of stunt like "one CONFIG option a week", speak up if you need that option.
12:55:35 <jki> no one is folling CIP at such a pace
12:55:51 <jki> they are all busy updating their products :D
12:56:53 <jki> so, any other topcis for today?
12:57:28 <jki> 5
12:57:31 <jki> 4
12:57:32 <jki> 3
12:57:34 <jki> 2
12:57:36 <jki> 1
12:57:37 <jki> #endmeeting