| *** monstr <monstr!~monstr@nat-108f.starnet.cz> has joined #cip | 04:52 | |
| *** monstr <monstr!~monstr@nat-108f.starnet.cz> has quit IRC (Ping timeout: 248 seconds) | 04:57 | |
| *** sskartheekadivi <sskartheekadivi!~sskarthee@user/sskartheekadivi> has quit IRC (Read error: Connection reset by peer) | 05:53 | |
| *** sskartheekadivi <sskartheekadivi!~sskarthee@user/sskartheekadivi> has joined #cip | 05:53 | |
| *** frieder <frieder!~frieder@89.244.121.37> has joined #cip | 07:22 | |
| *** masami <masami!~masami@FL1-111-168-44-134.tky.mesh.ad.jp> has joined #cip | 11:59 | |
| *** jki <jki!~jki@62.156.206.40> has joined #cip | 12:00 | |
| jki | hi all | 12:00 |
|---|---|---|
| iwamatsu | hello | 12:00 |
| masami | hello | 12:00 |
| uli | hello | 12:00 |
| patersonc | hi | 12:01 |
| jki | #startmeeting CIP IRC weekly meeting | 12:01 |
| 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 |
| collab-meetbot` | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 12:01 |
| collab-meetbot` | The meeting name has been set to 'cip_irc_weekly_meeting' | 12:01 |
| *** collab-meetbot` changes topic to " (Meeting topic: CIP IRC weekly meeting)" | 12:01 | |
| jki | #topic AI review | 12:01 |
| *** collab-meetbot` changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)" | 12:01 | |
| jki | - blogpost draft [iwamatsu-san, all] | 12:02 |
| iwamatsu | I updated draft | 12:02 |
| uli | i have requested access, but nothing happened | 12:02 |
| jki | we need to finalize it soon, so everyone should quickly have a look | 12:02 |
| jki | one moment... | 12:02 |
| jki | done | 12:03 |
| uli | thanks, i'll have a look later | 12:03 |
| iwamatsu | uli: thanks! | 12:03 |
| jki | iwamatsu: do you have more editing planned, or is the draft done from your perspective? | 12:04 |
| jki | at least conclusion is "tbd" ;) | 12:05 |
| iwamatsu | No, not yet. I haven't written the conclusion yet. I plan to write it tomorrow. | 12:05 |
| jki | what was agreed regarding hand-over to LF for formatting and publishing? | 12:06 |
| jki | "asap", or a concrete date? | 12:06 |
| iwamatsu | I haven't decided on that yet either. | 12:07 |
| 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 |
| iwamatsu | I will check it. | 12:08 |
| jki | thanks! | 12:08 |
| jki | no further AIs on my list | 12:09 |
| jki | 5 | 12:09 |
| jki | 4 | 12:09 |
| jki | 3 | 12:09 |
| jki | 2 | 12:09 |
| jki | 1 | 12:09 |
| jki | #topic Kernel maintenance updates | 12:09 |
| *** collab-meetbot` changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)" | 12:09 | |
| uli | i'm working on 4.19 | 12:09 |
| masami | This week reported 355 new CVEs and 65 updated CVEs. | 12:09 |
| pave1 | I am reviewing 6.12.97 | 12:09 |
| iwamatsu | I reviewed 6.12.95 and 4.19.y-st-rc | 12:09 |
| iwamatsu | 4.19.y-st > I am reviewing now. | 12:10 |
| uli | thank you | 12:10 |
| jki | anything to add? | 12:11 |
| jki | 5 | 12:11 |
| jki | 4 | 12:11 |
| jki | 3 | 12:11 |
| jki | 2 | 12:11 |
| jki | 1 | 12:11 |
| jki | #topic Kernel release status | 12:12 |
| *** collab-meetbot` changes topic to "Kernel release status (Meeting topic: CIP IRC weekly meeting)" | 12:12 | |
| jki | two were late this morning, one was release later on | 12:12 |
| jki | 4.19 is still due, but I guess under review right now, right? | 12:12 |
| uli | correct | 12:12 |
| jki | ok - any issues ahead? | 12:13 |
| uli | not from my point of view | 12:13 |
| jki | given that we are already in holiday season: any shortages due to that? | 12:14 |
| jki | please have a look at upcoming release dates | 12:14 |
| jki | 6.12 and 5.10 would be next then | 12:14 |
| jki | if there are no issues, then move on | 12:15 |
| jki | 5 | 12:15 |
| jki | 4 | 12:15 |
| jki | 3 | 12:15 |
| jki | 2 | 12:15 |
| jki | 1 | 12:15 |
| jki | #topic Kernel testing | 12:15 |
| *** collab-meetbot` changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)" | 12:15 | |
| patersonc | No news from me | 12:16 |
| jki | if there are also no issues... | 12:16 |
| jki | 5 | 12:17 |
| jki | 4 | 12:17 |
| jki | 3 | 12:17 |
| jki | 2 | 12:17 |
| jki | 1 | 12:17 |
| jki | #topic AOB | 12:17 |
| *** collab-meetbot` changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)" | 12:17 | |
| jki | any news from trying out our llm setup? | 12:17 |
| pave1 | no time :-( | 12:17 |
| jki | please use the next chance when you have reviews, at least for a few patches first | 12:18 |
| jki | or we will end up with "no time to look into saving time" ;) | 12:19 |
| jki | patersonc: you had some topic during ETSC that we should discuss, just forgot what | 12:20 |
| patersonc | Did you guys want to discuss having RC branches for CI to run on? | 12:20 |
| jki | right | 12:20 |
| jki | maintainers: what are your thoughts? | 12:21 |
| pave1 | Well, usual setup is | 12:22 |
| pave1 | qa does the releases, but I dont believe we have manpower | 12:22 |
| pave1 | for that. | 12:22 |
| iwamatsu | I'm sorry. I don't understand the details of this. | 12:22 |
| jki | patersonc: can you describe a potential workflow? | 12:23 |
| 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:24 |
| pave1 | We are doing that. | 12:25 |
| jki | would flagging out an rc be useful for 3rd parties? downstream users and testers? | 12:25 |
| iwamatsu | Thanks for the explanation. I am running a similar process in my -rc branch. | 12:26 |
| pave1 | jki: I dont believe we have 3rd parties interested in that. | 12:27 |
| 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:27 |
| uli | i prefer starting stuff manually to minimize latency | 12:28 |
| iwamatsu | I think it would be best to create an "-rc" branch that allows force commits and target that branch. | 12:29 |
| jki | and we should present a consistent pattern to the outside for all streams, if that isn't the case yet | 12:30 |
| pave1 | p | 12:30 |
| 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:31 |
| pave1 | I'd stay with it. | 12:32 |
| patersonc | Note that any regression tracking would be broken if the exact same branch is used for completely different kernel versions | 12:32 |
| patersonc | Ideally we'd have an -rc branch per SLTS version | 12:32 |
| pave1 | You basically dont release if things are not green. | 12:33 |
| jki | on first glance, I find several, distinct -rc branches here: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/branches/active | 12:35 |
| jki | but not for all versions/variants | 12:35 |
| jki | and not really following the same schema | 12:36 |
| jki | that can possibly be improved, no? | 12:36 |
| patersonc | So should we standardise that? Have some central "linux-6.1.y-cip-rc" branches? | 12:36 |
| patersonc | (or ci/linux-6.1.y-cip-rc) | 12:36 |
| pave1 | You can have responsibility for release, | 12:36 |
| pave1 | then testing will be up to you. | 12:37 |
| pave1 | That would be good, because | 12:37 |
| jki | pavel: who is "you" here? | 12:37 |
| pave1 | currently it is I create branch, I tag it, I test, I push. | 12:37 |
| pave1 | ...with no oversight. | 12:38 |
| pave1 | You would be qa team. | 12:38 |
| jki | we have no saparate QA team right now | 12:38 |
| jki | and tagging is done by the maintainers anyway | 12:39 |
| pave1 | Well, its called testing team currently. | 12:39 |
| jki | and publishing | 12:39 |
| jki | our test team is (also) a support team for other WGs / maintainers | 12:39 |
| pave1 | Exactly, having second person look at code before release would be good. | 12:39 |
| 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:40 |
| jki | we can build that up, provided we can either find volunteers to do that regularly or request funding for contracts | 12:41 |
| pave1 | Yeah I dont like the wait part. | 12:41 |
| jki | I don't disagree that more could be done here! | 12:41 |
| jki | but that wait part will remain | 12:41 |
| jki | naturally: you are signing, not a test reviewer | 12:41 |
| jki | and you have the upload rights so far | 12:42 |
| 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 |
| 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 |
| jki | anyway for scaling out, involving more people into QA, unifiying the workflows and branches is step #1 in any case | 12:43 |
| 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 |
| pave1 | Yep. Quick and simple and has worked well so far. | 12:43 |
| patersonc | The difference will be using standardised rc branches for this, and using KernelCI to run the testing | 12:44 |
| jki | changing branch names and possibly also mirroring them to kernel.org would be simple and would not change the workflow | 12:45 |
| jki | but it would allow us to do so in the future when needed (or when more people support testing) | 12:45 |
| jki | so I would recommend such unifications as well | 12:45 |
| pave1 | I can take a look at kci again, but last time it was not all green. | 12:45 |
| patersonc | That's the other decision - where will the -rc branches primarily live? kernel.org or gitlab? | 12:46 |
| uli | 4.4-st-rc and 4.19-st-rc are on kernel.org | 12:47 |
| jki | can be both, to keep both pipelines | 12:47 |
| patersonc | jki: Sure. But one has to be pushed to first | 12:47 |
| 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:47 |
| jki | perfect, then only push to kernel.org, and gitlab is covered | 12:48 |
| 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:49 |
| pave1 | patersonc: ok, there was 4.4-rt release today, could you describe steps to get test result for that? | 12:50 |
| jki | iwamatsu: likely your take for 6.12 | 12:50 |
| 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 |
| pave1 | ...but it would be really good to be able to do equivalent testing | 12:53 |
| jki | so, you would get the test results you have to today + the chance to look at kci results | 12:54 |
| jki | right? | 12:54 |
| pave1 | without creating the rc. For example after patch series is applied. | 12:54 |
| pave1 | Well... today I dont get test result. | 12:54 |
| patersonc | We can get results here: https://kernelci.ciplatform.org/ | 12:54 |
| pave1 | I get test result_s_ I have to interpret | 12:55 |
| 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 |
| jki | there is no rt testing in our pipeline? then this is another reason for using kci consistently | 12:55 |
| pave1 | and often retry the tests. | 12:56 |
| 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:56 |
| pave1 | I'll take a look after the meeting. | 12:58 |
| jki | as we are close to the full hour: please have a look at that again for next week | 12:58 |
| jki | next week, someone would have to run this call, I'm off | 12:58 |
| jki | any volunteers? | 12:59 |
| patersonc | I'm also away next week | 12:59 |
| iwamatsu | I can takeover. | 12:59 |
| jki | thanks! | 12:59 |
| pave1 | Thank you! | 12:59 |
| jki | good - anything else for today? | 12:59 |
| iwamatsu | :-) | 12:59 |
| jki | 5 | 12:59 |
| jki | 4 | 12:59 |
| jki | 3 | 12:59 |
| jki | 2 | 12:59 |
| jki | 1 | 12:59 |
| jki | #endmeeting | 12:59 |
| collab-meetbot` | Meeting ended Thu Jul 30 12:59:59 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 12:59 |
| collab-meetbot` | Minutes: http://ircbot.wl.linuxfoundation.org/meetings/cip/2026/07/cip.2026-07-30-12.01.html | 12:59 |
| collab-meetbot` | Minutes (text): http://ircbot.wl.linuxfoundation.org/meetings/cip/2026/07/cip.2026-07-30-12.01.txt | 12:59 |
| collab-meetbot` | Log: http://ircbot.wl.linuxfoundation.org/meetings/cip/2026/07/cip.2026-07-30-12.01.log.html | 12:59 |
| *** collab-meetbot` changes topic to "Civil Infrastructure Platform Project. CIP mailing list at https://lists.cip-project.org/g/cip-dev | CIP kernel meeting every Thursday at 13:00 UTC | Find the meeting logs at https://ircbot.wl.linuxfoundation.org/meetings/cip/ and chat logs at https://ircbot.wl.linuxfoundation.org/logs/%23cip/" | 12:59 | |
| jki | thanks all! | 13:00 |
| uli | thanks | 13:00 |
| masami | thank you | 13:00 |
| pave1 | Thank you! | 13:00 |
| *** masami <masami!~masami@FL1-111-168-44-134.tky.mesh.ad.jp> has quit IRC (Quit: Leaving) | 13:00 | |
| iwamatsu | thank you | 13:00 |
| *** jki <jki!~jki@62.156.206.40> has quit IRC (Quit: Leaving) | 13:00 | |
| *** frieder <frieder!~frieder@89.244.121.37> has quit IRC (Remote host closed the connection) | 18:02 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!