12:01:55 <jki> #startmeeting CIP IRC weekly meeting
12:01:55 <collab-meetbot`> Meeting started Thu Aug 31 12:01:55 2023 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:55 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:55 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:59 <jki> #topic AI review
12:02:03 <jki> 1. create kernelci pipeline for buster images (arisut)
12:02:16 <arisut> jki: still didn't get replay to my email
12:02:22 <iwamatsu> hi all,
12:02:34 <jki> I thought I replied...
12:02:41 <arisut> https://lists.cip-project.org/g/cip-dev/message/12810
12:02:53 <arisut> is the most recent one
12:03:03 <arisut> https://lists.cip-project.org/g/cip-dev/topic/100775400#12810
12:03:26 <jki> ok, possibly misremembered, will follow up
12:03:32 <arisut> thanks
12:03:38 <jki> 2. draft press release about 6.1-cip (jan)
12:03:59 <jki> sent, seems the board still needs to do some decisions
12:04:06 <jki> thanks for your feedback already
12:04:13 <jki> any other AI I missed?
12:04:28 <jki> 3
12:04:30 <jki> 2
12:04:31 <pave1> This should be everything.
12:04:31 <jki> 1
12:04:35 <jki> #topic Kernel maintenance updates
12:04:53 <masami> This week reported 4 new CVEs and 5 updated CVEs.
12:05:01 <uli> i'm preparing 4.4 for release and reviewing 6.1.46
12:05:08 <pave1> I did some reviews, 6.1.48 to 6.1.50.
12:05:41 <iwamatsu> I reviewed 6.1.46, 47, 48, 49, and I am reviewing 6.1.50.
12:07:36 <jki> some curious question on the review process: when you check patches for 6.1, do you also already check if they apply to older stable?
12:07:42 <jki> or is that done later?
12:07:51 <pave1> Well, this is getting messy.
12:08:18 <pave1> Greg used to publish his queues, so it was possibly to review patches before they were released.
12:08:22 <pave1> He no longer does that.
12:08:45 <pave1> Still, we try to group the patches by the "upstream commit" id,
12:09:02 <pave1> and then review the version targeted for the oldest release.
12:09:24 <pave1> So if the patch is queued for 4.14, 4.19, 5.10 and 6.1, we review 4.14 version.
12:10:12 <jki> did anyone talk to Greg about that?
12:10:41 <pave1> I tried.
12:11:30 <pave1> ...with not much success. He said he was not aware how those queue branches were generated.
12:11:51 <jki> ok
12:12:23 <jki> well, anything else on "maintenance"?
12:12:48 <jki> 5
12:12:50 <jki> 4
12:12:51 <jki> 3
12:12:53 <jki> 2
12:12:54 <jki> 1
12:12:56 <jki> #topic Kernel release status
12:13:00 <jki> 4.4
12:13:07 <uli> on track, will send a request for reviews in the next few days
12:13:21 <pave1> -rt should be on track.
12:13:31 <jki> 4.19
12:13:39 <iwamatsu> on track
12:13:46 <jki> 5.10
12:13:50 <iwamatsu> on track
12:14:03 <jki> sorry: RT for both as well?
12:14:07 <iwamatsu> yes
12:14:14 <jki> 6.1
12:14:15 <pave1> -rt trees should be on track, all of them.
12:14:24 <iwamatsu> on track
12:14:27 <jki> good
12:14:32 <jki> #topic Kernel testing
12:15:06 <patersonc> Hello.
12:15:11 <patersonc> The Denx LAVA lab is now back online
12:15:27 <patersonc> So we'll have more devices online again
12:16:01 <patersonc> I had a quick look at your isar linux source download issue Jan and sent a commit for adding gitlab cache support
12:16:08 <patersonc> Feel free to give it a go
12:16:32 <patersonc> I've not much else this week
12:17:44 <jki> patersonc: where did you send that commit to?
12:18:10 <patersonc> cip-dev
12:18:17 <patersonc> https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/c62fced2cd86757aa0eebc14eedf04c203f34cde
12:18:32 <patersonc> There's a completed pipeline there as well
12:19:33 <jki> didn't see it on the list yet, will check again
12:19:42 <patersonc> Okay :)
12:19:51 <jki> but caching will only help after the first re-run
12:20:09 <jki> it will cause failures after every kernel update
12:20:19 <jki> I'm not in favor of it therefore
12:20:52 <patersonc> There is that risk, yes
12:21:16 <patersonc> You could have an automated nightly build to download and save the relevant files to the cache
12:21:34 <jki> yes, and promote that pattern downstream
12:21:43 <jki> it remains a workaround IMHO
12:21:59 <patersonc> Yea, kernel.org should really be more stable :P
12:22:06 <jki> we will also check how many caches will be generated and if they will be shared
12:22:21 <patersonc> It depends on the key
12:22:29 <patersonc> If they use the same key it will be shared
12:22:47 <jki> will the caches accumulated the fetches?
12:22:56 <patersonc> Although the master branch usually has a different set - unless an option is changed
12:23:05 <jki> will they grow larger and larger therefore?
12:23:25 <jki> I'm afraid there are still many missing bits, even for this approach
12:23:53 <patersonc> Yes
12:24:22 <jki> ah, you didn't send a patch, you only provided that commit link in your reply
12:24:37 <patersonc> oh yea, sorry
12:25:10 <jki> we can start using caches, also sstate caches in fact, but that will need cache maintenance
12:25:41 <jki> given the increasing number of jobs, it may actually be benefical for our CI time
12:25:57 <jki> storage should still be much cheaper (will likely need to use S3 for that)
12:27:26 <jki> anyway - anything else on this? I'll follow up on the ML in any case
12:27:59 <patersonc> Nothing from me
12:28:06 <jki> anything else on testing in general?
12:28:51 <jki> 5
12:28:52 <jki> 4
12:28:54 <jki> 3
12:28:56 <jki> 2
12:28:57 <jki> 1
12:29:00 <jki> #topic AOB
12:30:53 <jki> anyone anything?
12:31:05 <jki> 5
12:31:07 <jki> 4
12:31:08 <jki> 3
12:31:09 <jki> 2
12:31:11 <jki> 1
12:31:12 <jki> #endmeeting