13:03:31 <jki> #startmeeting CIP IRC weekly meeting
13:03:31 <collab-meetbot`> Meeting started Thu Dec 14 13:03:31 2023 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:31 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:31 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
13:03:37 <arisut> Waiting for you h
13:03:42 <jki> #topic AI review
13:03:53 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:03:59 <jki> still need to do that...
13:04:02 <arisut> Just fixing the meeting date on the bot topic
13:04:09 <jki> ah, ok
13:04:29 <jki> any other to-dos from last time?
13:04:42 <jki> 5
13:04:43 <jki> 4
13:04:45 <jki> 3
13:04:46 <jki> 2
13:04:48 <jki> 1
13:04:49 <jki> #topic Kernel maintenance updates
13:05:12 <pave1> I was doing reviews, 6.1.66.
13:05:32 <uli> i'm reviewing 6.1.68
13:06:39 <iwamatsu> I reviewd 6.1.65 and 66.
13:07:45 <jki> anything else?
13:08:02 <jki> any further fallouts from recent backports? ;)
13:08:23 <pave1> Well, we have both .67 and .67-rt, but they only fix single wifi issue and I don't believe it applies to us.
13:09:16 <jki> because we don't have the feature enabled in our configs, or why?
13:09:46 <pave1> Because wifi is usually not used heavilly in industrial configs.
13:10:11 <jki> but do we have this config enabled or not for 6.1?
13:10:26 <pave1> I'll take a look.
13:10:56 <jki> and was that issue a fatal failure for all wifi scenarios or just for some=
13:10:58 <jki> ?
13:11:56 <pave1> I believe it is something like "blocks reboot". I'll take another look.
13:12:07 <pave1> It is not "eats filesystem" or "provides remote root".
13:12:48 <jki> yeah, that is definitely more critical
13:12:50 <jki> ok
13:13:00 <jki> anything else on maintenance?
13:13:20 <jki> 5
13:13:21 <jki> 4
13:13:23 <jki> 3
13:13:24 <jki> 2
13:13:25 <jki> 1
13:13:28 <jki> #topic Kernel release status
13:13:42 <jki> 4.4
13:13:44 <iwamatsu> https://lore.kernel.org/cip-dev/TYVPR01MB11245314D12E5E87434FA82C0928CA@TYVPR01MB11245.jpnprd01.prod.outlook.com/
13:14:03 <iwamatsu> Date the data is created: Thu Dec 14 12:57:00 PM UTC 2023
13:14:05 <iwamatsu> linux-4.4.y-cip: interval 30 day
13:14:07 <iwamatsu> latest version release date: Mon Dec 11 02:40:37 AM UTC 2023
13:14:09 <iwamatsu> limit date: Wed Jan 10 02:40:37 AM UTC 2024
13:14:10 <jki> oh, didn't reach my inbox
13:14:11 <iwamatsu> Status: On track
13:14:13 <iwamatsu> linux-4.4.y-cip-rt: interval 60 day
13:14:15 <iwamatsu> latest version release date: Thu Oct 19 03:30:18 PM UTC 2023
13:14:17 <iwamatsu> limit date: Mon Dec 18 03:30:18 PM UTC 2023
13:14:19 <iwamatsu> Status: On track
13:14:21 <iwamatsu> linux-4.19.y-cip: interval 30 day
13:14:23 <iwamatsu> latest version release date: Thu Dec  7 05:37:21 PM UTC 2023
13:14:25 <iwamatsu> limit date: Sat Jan  6 05:37:21 PM UTC 2024
13:14:27 <iwamatsu> Status: On track
13:14:29 <iwamatsu> linux-4.19.y-cip-rt: interval 60 day
13:14:31 <iwamatsu> latest version release date: Wed Oct 18 10:02:27 AM UTC 2023
13:14:33 <iwamatsu> limit date: Sun Dec 17 10:02:27 AM UTC 2023
13:14:35 <iwamatsu> Status: On track
13:14:37 <iwamatsu> linux-5.10.y-cip: interval 30 day
13:14:39 <iwamatsu> latest version release date: Thu Nov 23 11:51:14 AM UTC 2023
13:14:41 <iwamatsu> limit date: Sat Dec 23 11:51:14 AM UTC 2023
13:14:43 <iwamatsu> Status: On track
13:14:45 <iwamatsu> linux-5.10.y-cip-rt: interval 60 day
13:14:47 <iwamatsu> latest version release date: Thu Nov 23 06:12:31 PM UTC 2023
13:14:49 <iwamatsu> limit date: Mon Jan 22 06:12:31 PM UTC 2024
13:14:51 <iwamatsu> Status: On track
13:14:53 <iwamatsu> linux-6.1.y-cip: interval 15 day
13:14:55 <iwamatsu> latest version release date: Mon Dec 11 11:00:07 AM UTC 2023
13:14:57 <iwamatsu> limit date: Tue Dec 26 11:00:07 AM UTC 2023
13:14:59 <iwamatsu> Status: On track
13:15:01 <iwamatsu> linux-6.1.y-cip-rt: interval 30 day
13:15:03 <iwamatsu> latest version release date: Mon Dec 11 07:08:30 PM UTC 2023
13:15:05 <iwamatsu> limit date: Wed Jan 10 07:08:30 PM UTC 2024
13:15:07 <iwamatsu> Status: On track
13:15:19 <jki> nice
13:15:22 <iwamatsu> I put a script to https://gitlab.com/cip-project/cip-kernel/lts-commit-list/-/blob/master/bin/cip-release-term.sh
13:15:36 <pave1> 4.19-cip-rt is next; I seen -rt-rc, so hopefully coordination will be easy.
13:15:50 <jki> we do not need to go through the kernels individually anymore then
13:16:12 <jki> we could only focus on issues
13:16:15 <jki> if any
13:16:48 <jki> maybe I can try to run that script upfront next time
13:17:01 <jki> include the output into the reminder
13:17:05 <jki> good
13:17:35 <jki> anything further to discuss in this context?
13:17:47 <jki> 5
13:17:48 <jki> 4
13:17:49 <jki> 3
13:17:50 <jki> 2
13:17:52 <jki> 1
13:17:53 <jki> #topic Kernel testing
13:18:48 <arisut> Nothing new for me
13:19:14 <arisut> Trying to test the new kernelci api
13:19:38 <arisut> And checking what we can do with it
13:20:00 <pave1> Aha, thanks for remainder. I seen announcement twice, but I should take a look, too.
13:21:44 <jki> any news from SQUAD?
13:21:50 <sietze> Yes!
13:21:52 <sietze> SQUAD Reporting has now gone live: https://squad.ciplatform.org/
13:22:08 <sietze> Everybody is invited to have a look and see how it fits their needs
13:22:34 <jki> linux-cip vs cip-kernel - hmm....
13:22:50 <sietze> Well, the latter was for testing purposes
13:22:55 <sietze> I shall remove that in due time
13:23:11 <jki> ok, thought you wanted to use it for testing also in the future
13:23:15 <jki> then it's fine
13:23:27 <sietze> I think I can hide it and avoid such questions in the future ;-)
13:23:54 <sietze> Anyway, we would like to have feedback
13:24:01 <jki> now, how to make use of this - some simple example?
13:26:48 <jki> is something like this usefull (compare builds)? https://squad.ciplatform.org/_/comparebuilds/?&baseline=5.10.191-cip38_a10a81410&target=5.10.194-cip39_83aa48649&comparison_type=test&project=cip-kernel%2Flinux-5.10.y-cip
13:26:53 <sietze> One can show the overall results of test suites vs environments (defconfig + device)
13:26:56 <sietze> Eg https://squad.ciplatform.org/linux-cip/linux-5.10.y-cip/build/5.10.204-cip41_c43d7b7bb/?failures_only=false&results_layout=table#!#test-results
13:27:58 <sietze> One can see the history of a given test case vs builds and devices/defonfigs
13:28:00 <sietze> Eg https://squad.ciplatform.org/_/comparetest/?project=18&suite=spectre-meltdown-checker-test&test=CVE-2018-12126
13:28:21 <sietze> And there's a lot of more data hidden in there
13:29:07 <sietze> The questions is, if the overviews that SQUAD now presents are useful for the kernel developers
13:29:10 <pave1> Okay. Can someone go through data, and select "this went wrong, this is bad, we need to fix this" example?
13:29:21 <pave1> Then we fix the example and go through next example?
13:30:40 <jki> will hunter work on this?
13:30:56 <sietze> Yes, he already started
13:31:08 <jki> great!
13:31:26 <sietze> But we also need to know what exactly developers would like to see reported
13:31:55 <sietze> Of course Chris, Hunter and I have our ideas, but it would be great to hear what the others would expect of the reporting
13:32:51 <pave1> Developers don't know :-). Issues that could hit our users. But we don't have much feedback what cip users are doing with the kernel.
13:34:07 <sietze> But what do you expect when looking at the test results?
13:35:40 <pave1> Well, green tick for working kernels and red cross for broken kernels would be nice :-).
13:35:51 <sietze> :-D
13:36:26 <sietze> Well squad will give you a lot of green ticks and red crosses
13:36:32 <sietze> I can give you that ;-)
13:37:28 <pave1> Well.
13:37:38 <sietze> Using Hunter's work, we have the possibility to add custom reports on top of what SQUAD already does
13:37:52 <pave1> I don't have example nearby, but IMO good example is how stable kernel works.
13:38:06 <pave1> Greg acts as a developer, various labs act as testers.
13:38:49 <pave1> When they hit a bug, they report what config broke, and then work together to locate the failure.
13:39:44 <pave1> I can dig up mail threads from the area.
13:40:08 <sietze> That could be helpful, but maybe a dedicated meeting would be more efficient here
13:40:28 <pave1> But I believe best start would be Q&A team watching the results, and telling us "everything ok" or "we see this, you broke it, you fix it".
13:41:08 <sietze> Ok
13:41:43 <sietze> Does it make sense to have dedicated meeting on this, with the QA Team and other involved parties?
13:42:21 <sietze> With the current information I have now, I am unsure where to improve our reports to fit CIP needs
13:42:40 <pave1> I'd preffer to get single good bug report on cip-dev, first.
13:42:49 <pave1> But of course, we can do the meeting.
13:43:08 <sietze> Whom should we invite?
13:43:48 <sietze> pavel, patersonc, hunter, ...?
13:44:07 <pave1> jki, uli, iwamatsu.
13:44:23 <jki> yep
13:44:31 <sietze> Ok, I'll talk to patersonc and we'll setup the meeting
13:44:57 <jki> but keep in mind that vacations are coming...
13:45:38 <sietze> Sure, probably will take place in January
13:46:25 <jki> meanwhile, if anyone wants to use the tool to extract and analyse some newly failing tests for a newer kernel...
13:46:38 <jki> ...just report that to the list
13:46:57 <sietze> Yes
13:47:15 <sietze> We already have POC on how to fetch custom results from SQUAD
13:47:15 <sietze> https://gitlab.com/cip-playground/squad-hacking/cip-test-reports
13:48:11 <pave1> You can use -stable kernels as a test data.
13:48:59 <pave1> Maybe 20% of -stable-rc kerenls are bad, so you'll get both successes and failures.
13:49:37 <pave1> Take a look how other test labs report the results to the lkml.
13:49:54 <pave1> ...and best do the same. Currently I'm doing that with test results from a gitlab.
13:50:25 <pave1> That's what should be done, best if QA team could do that, not me.
13:52:29 <jki> sietze: did this help you more?
13:52:58 <sietze> Yes, a bit, but I still would like to have the meeting, to get a better picture
13:53:17 <pave1> Example how this works in "bug found" case is e: Thu, 30 Nov 2023 11:21:34 -0600, From: Daniel Díaz <daniel.diaz@linaro.org>, Subject: Re: [PATCH 5.15 00/69] 5.15.141-rc1 review and following thread on the lkml.
13:53:20 <jki> sure
13:55:02 <jki> anything else on testing today?
13:55:25 <jki> 5
13:55:26 <jki> 4
13:55:28 <jki> 3
13:55:29 <jki> 2
13:55:31 <jki> 1
13:55:33 <jki> #topic AOB
13:55:46 <jki> vacations...
13:56:02 <jki> I'll be off next Thursday and the week after as well
13:56:26 <pave1> :-). We went from "30 cm of snow" to "ton of mud".
13:56:47 <jki> just in time for xmas :)
13:56:57 <hunter> it's like a blizzard in here sorry for being late!
13:57:01 <pave1> I should be available on Dec 21, unsure (probably not) about Dec 28
13:57:24 <pave1> Well, but at least we did have snow this winter! :-)
13:57:44 <jki> who can take over next week then?
13:57:47 <hunter> I agree, not looking forward to the slush afterwards.
13:58:10 <jki> and should we keep the 28th?
13:58:33 <hunter> I can join for that date no problem.
13:58:41 <uli> i won't be here on the 28, though
13:59:04 <pave1> I can control the bot on Dec 21 .
13:59:13 <jki> great, thanks
13:59:23 <arisut> thanks
13:59:33 <iwamatsu> I will not be able to participate on the 28th.
13:59:34 <jki> maybe you want to decide next week then what to do with the 28th
14:00:20 <pave1> -pavel, -iwamatsu, -uli, -jki. It is quite close to Year end so I'd assume we'd cancel it.
14:00:36 <jki> ok
14:00:44 <arisut> ok
14:00:56 <iwamatsu> +1
14:00:57 <jki> any other things for today?
14:01:16 <jki> 5
14:01:17 <jki> 4
14:01:18 <jki> 3
14:01:20 <jki> 2
14:01:21 <jki> 1
14:01:24 <jki> #endmeeting