12:01:40 <jki> #startmeeting CIP IRC weekly meeting
12:01:40 <collab-meetbot`> Meeting started Thu Jul 30 12:01:40 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:40 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:40 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:45 <jki> #topic AI review
12:02:00 <jki> - blogpost draft [iwamatsu-san, all]
12:02:10 <iwamatsu> I updated draft
12:02:39 <uli> i have requested access, but nothing happened
12:02:42 <jki> we need to finalize it soon, so everyone should quickly have a look
12:02:49 <jki> one moment...
12:03:16 <jki> done
12:03:27 <uli> thanks, i'll have a look later
12:03:43 <iwamatsu> uli: thanks!
12:04:19 <jki> iwamatsu: do you have more editing planned, or is the draft done from your perspective?
12:05:02 <jki> at least conclusion is "tbd" ;)
12:05:40 <iwamatsu> No, not yet. I haven't written the conclusion yet. I plan to write it tomorrow.
12:06:08 <jki> what was agreed regarding hand-over to LF for formatting and publishing?
12:06:28 <jki> "asap", or a concrete date?
12:07:10 <iwamatsu> I haven't decided on that yet either.
12:08:16 <jki> ok, I will do a review by tomorrow latest. as I won't be available next week, I would ask you to move this forward once ready
12:08:25 <iwamatsu> I will check it.
12:08:42 <jki> thanks!
12:09:01 <jki> no further AIs on my list
12:09:06 <jki> 5
12:09:07 <jki> 4
12:09:09 <jki> 3
12:09:11 <jki> 2
12:09:12 <jki> 1
12:09:15 <jki> #topic Kernel maintenance updates
12:09:37 <uli> i'm working on 4.19
12:09:40 <masami> This week reported 355 new CVEs and 65 updated CVEs.
12:09:43 <pave1> I am reviewing 6.12.97
12:09:59 <iwamatsu> I reviewed 6.12.95 and 4.19.y-st-rc
12:10:35 <iwamatsu> 4.19.y-st > I am reviewing now.
12:10:51 <uli> thank you
12:11:29 <jki> anything to add?
12:11:49 <jki> 5
12:11:51 <jki> 4
12:11:54 <jki> 3
12:11:56 <jki> 2
12:11:58 <jki> 1
12:12:00 <jki> #topic Kernel release status
12:12:20 <jki> two were late this morning, one was release later on
12:12:47 <jki> 4.19 is still due, but I guess under review right now, right?
12:12:52 <uli> correct
12:13:11 <jki> ok - any issues ahead?
12:13:28 <uli> not from my point of view
12:14:03 <jki> given that we are already in holiday season: any shortages due to that?
12:14:12 <jki> please have a look at upcoming release dates
12:14:55 <jki> 6.12 and 5.10 would be next then
12:15:39 <jki> if there are no issues, then move on
12:15:41 <jki> 5
12:15:43 <jki> 4
12:15:44 <jki> 3
12:15:45 <jki> 2
12:15:47 <jki> 1
12:15:49 <jki> #topic Kernel testing
12:16:01 <patersonc> No news from me
12:16:57 <jki> if there are also no issues...
12:17:03 <jki> 5
12:17:05 <jki> 4
12:17:07 <jki> 3
12:17:09 <jki> 2
12:17:11 <jki> 1
12:17:13 <jki> #topic AOB
12:17:30 <jki> any news from trying out our llm setup?
12:17:54 <pave1> no time :-(
12:18:38 <jki> please use the next chance when you have reviews, at least for a few patches first
12:19:19 <jki> or we will end up with "no time to look into saving time" ;)
12:20:13 <jki> patersonc: you had some topic during ETSC that we should discuss, just forgot what
12:20:30 <patersonc> Did you guys want to discuss having RC branches for CI to run on?
12:20:39 <jki> right
12:21:05 <jki> maintainers: what are your thoughts?
12:22:04 <pave1> Well, usual setup is
12:22:38 <pave1> qa does the releases, but I dont believe we have manpower
12:22:43 <pave1> for that.
12:22:52 <iwamatsu> I'm sorry. I don't understand the details of this.
12:23:33 <jki> patersonc: can you describe a potential workflow?
12:24:42 <patersonc> At the moment CIP runs it's CI after a release/tag has been made. I'm proposing that we shift that testing left so that it's done before we make releases. Of course if the maintainers are already running pipelines their side before releaseing then there is no action
12:25:22 <pave1> We are doing that.
12:25:58 <jki> would flagging out an rc be useful for 3rd parties? downstream users and testers?
12:26:15 <iwamatsu> Thanks for the explanation. I am running a similar process in my -rc branch.
12:27:28 <pave1> jki: I dont believe we have 3rd parties interested in that.
12:27:36 <patersonc> I guess it's also partly a question of whether you'd rather KernelCI kicks off pipelines automatically (from dedicated RC branches/tags), or whether you are happy to kick off pipelines manually using kci-dev
12:28:33 <uli> i prefer starting stuff manually to minimize latency
12:29:38 <iwamatsu> I think it would be best to create an "-rc" branch that allows force commits and target that branch.
12:30:26 <jki> and we should present a consistent pattern to the outside for all streams, if that isn't the case yet
12:30:39 <pave1> p
12:31:54 <patersonc> So is the consensous to stick to the current apporach of pusing to RC/test branches in gitlab? Rather than something more formal on kernel.org?
12:32:24 <pave1> I'd stay with it.
12:32:27 <patersonc> Note that any regression tracking would be broken if the exact same branch is used for completely different kernel versions
12:32:40 <patersonc> Ideally we'd have an -rc branch per SLTS version
12:33:18 <pave1> You basically dont release if things are not green.
12:35:40 <jki> on first glance, I find several, distinct -rc branches here: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/branches/active
12:35:46 <jki> but not for all versions/variants
12:36:06 <jki> and not really following the same schema
12:36:26 <jki> that can possibly be improved, no?
12:36:27 <patersonc> So should we standardise that? Have some central "linux-6.1.y-cip-rc" branches?
12:36:42 <patersonc> (or ci/linux-6.1.y-cip-rc)
12:36:56 <pave1> You can have responsibility for release,
12:37:12 <pave1> then testing will be up to you.
12:37:27 <pave1> That would be good, because
12:37:34 <jki> pavel: who is "you" here?
12:37:59 <pave1> currently it is I create branch, I tag it, I test, I push.
12:38:09 <pave1> ...with no oversight.
12:38:21 <pave1> You would be qa team.
12:38:40 <jki> we have no saparate QA team right now
12:39:00 <jki> and tagging is done by the maintainers anyway
12:39:06 <pave1> Well, its called testing team currently.
12:39:07 <jki> and publishing
12:39:47 <jki> our test team is (also) a support team for other WGs / maintainers
12:39:48 <pave1> Exactly, having second person look at code before release would be good.
12:40:31 <jki> if we want to have dedicated persons look over test results, you as maintainer need to involve them actively, what for them, then release
12:41:12 <jki> we can build that up, provided we can either find volunteers to do that regularly or request funding for contracts
12:41:25 <pave1> Yeah I dont like the wait part.
12:41:26 <jki> I don't disagree that more could be done here!
12:41:35 <jki> but that wait part will remain
12:41:50 <jki> naturally: you are signing, not a test reviewer
12:42:18 <jki> and you have the upload rights so far
12:43:15 <iwamatsu> I agree with patersonc's proposal. We will push the next release candidate to the `linux-6.12.y-cip-rc` branch and test it. The `linux-6.12.y-cip` branch will be updated only when a release is made.
12:43:16 <iwamatsu> My understanding is that while we previously pushed to the `linux-6.12.y-cip` branch, the target has now changed to the `linux-6.12.y-cip-rc` branch.
12:43:24 <jki> anyway for scaling out, involving more people into QA, unifiying the workflows and branches is step #1 in any case
12:43:26 <patersonc> Given we have no qa team we'll have to rely on CI automation. RC release pushed to -rc branch, KCI pipeline kicked off, if no new regresions reported then push to the public release branch
12:43:52 <pave1> Yep. Quick and simple and has worked well so far.
12:44:32 <patersonc> The difference will be using standardised rc branches for this, and using KernelCI to run the testing
12:45:04 <jki> changing branch names and possibly also mirroring them to kernel.org would be simple and would not change the workflow
12:45:22 <jki> but it would allow us to do so in the future when needed (or when more people support testing)
12:45:36 <jki> so I would recommend such unifications as well
12:45:52 <pave1> I can take a look at kci again, but last time it was not all green.
12:46:44 <patersonc> That's the other decision - where will the -rc branches primarily live? kernel.org or gitlab?
12:47:00 <uli> 4.4-st-rc and 4.19-st-rc are on kernel.org
12:47:05 <jki> can be both, to keep both pipelines
12:47:23 <patersonc> jki: Sure. But one has to be pushed to first
12:47:55 <patersonc> Given that gitlab is mirroring kernel.org already maybe we do the same for the -rc branches. Then it's the same as with the -st branches as well/
12:48:20 <jki> perfect, then only push to kernel.org, and gitlab is covered
12:49:45 <patersonc> Okay. So if someone could create the linux-6.12.y-cip-rc etc. branches on kernel.org, we can update the gitlab mirroring to pull them and we can configure KernelCI to kick off pipelines for them
12:50:20 <pave1> patersonc: ok, there was 4.4-rt release today, could you describe steps to get test result for that?
12:50:35 <jki> iwamatsu: likely your take for 6.12
12:53:32 <jki> pavel: to my understanding, you push to kernel.org/4.4-rt-rc, kci gets triggered against that, and the branch also gets auto-mirrored to gitlab where our ci will be triggered
12:53:42 <pave1> ...but it would be really good to be able to do equivalent testing
12:54:12 <jki> so, you would get the test results you have to today + the chance to look at kci results
12:54:21 <jki> right?
12:54:28 <pave1> without creating the rc. For example after patch series is applied.
12:54:47 <pave1> Well... today I dont get test result.
12:54:59 <patersonc> We can get results here: https://kernelci.ciplatform.org/
12:55:13 <pave1> I get test result_s_ I have to interpret
12:55:20 <patersonc> If you want results for specific patches etc. you can kick off a pipeline using the kci-dev tool that Arisu-san has been working on
12:55:29 <jki> there is no rt testing in our pipeline? then this is another reason for using kci consistently
12:56:00 <pave1> and often retry the tests.
12:56:03 <patersonc> Example of RT tests running on 4.19-rt: https://dashboard.kernelci.org/tree/cip/linux-4.19.y-cip-rt/00f8046ad084e5fcab977142e1409b13b92bd8ce?p=t
12:58:16 <pave1> I'll take a look after the meeting.
12:58:26 <jki> as we are close to the full hour: please have a look at that again for next week
12:58:52 <jki> next week, someone would have to run this call, I'm off
12:59:05 <jki> any volunteers?
12:59:07 <patersonc> I'm also away next week
12:59:13 <iwamatsu> I can takeover.
12:59:17 <jki> thanks!
12:59:23 <pave1> Thank you!
12:59:30 <jki> good - anything else for today?
12:59:37 <iwamatsu> :-)
12:59:49 <jki> 5
12:59:51 <jki> 4
12:59:53 <jki> 3
12:59:55 <jki> 2
12:59:57 <jki> 1
12:59:59 <jki> #endmeeting