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