13:00:52 #startmeeting CIP IRC weekly meeting 13:00:52 Meeting started Thu Jan 27 13:00:52 2022 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:52 The meeting name has been set to 'cip_irc_weekly_meeting' 13:01:00 greetings @all! 13:01:06 hello 13:01:10 hi 13:01:13 hi 13:04:52 let's wait a bit longer, the circle is still small 13:05:22 hi 13:08:34 ok, seems we don't get more today 13:08:43 #topic AI review 13:08:55 1. Merge kernelci support in isar-cip-core - jan 13:09:18 currently waiting on a question I had on patch 2 of alicef's series 13:09:34 just replayed 13:09:49 ok, great 13:10:32 then I will wait for v3, rebase my consolidation on top and post that as well 13:10:51 As the v2 rebase was greately differing from the first patch series structure the installation script got lost in translation 13:11:17 sending the v3 patch 13:11:22 I didn't find that in the history myself, but anyway 13:11:30 where is your consolidation ? 13:11:39 locally only so far 13:11:52 ok 13:11:58 will send it out once rebased 13:12:48 then next topic 13:12:51 jki: is all in the mail. just the first patch series is missing versioning 13:13:23 as there is no contribution documentation on isar-cip-core 13:13:46 and lacking which contribution version I should follow 13:13:54 right, that should be fixed 13:15:42 ok - move on? 13:15:50 3 13:15:51 2 13:15:54 1 13:15:57 2. Clarify with KernelCI whether CIP maintainers can get accounts - alicef 13:16:13 this work is done in collaboration with patersonc 13:16:39 patersonc[m] opened a issue on this https://github.com/kernelci/kernelci-core/issues/983 14days ago 13:17:06 but the issue is still in the todo list 13:17:25 how needs to do something now? 13:19:02 patersonc[m] said to write a PR but I didn't see it yet 13:19:28 s/said/proposed/ 13:19:47 then we should transfer the AI to him ;) 13:21:47 jki: actually it was already 13:22:17 ok, my bad 13:22:22 anything else on this? 13:22:31 3 13:22:34 please check last week meeting https://lists.cip-project.org/g/cip-dev/message/7470 13:22:35 2 13:23:10 ok 13:23:31 let's clarify the state with him in the next meeting 13:23:42 #topic Kernel maintenance updates 13:24:03 reviewed 5.10.94 candidate patches 13:24:10 I was reviewing 5.10.94. 13:24:18 there was 4 new CVEs in this week. 13:24:25 I also replied to https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/issues/10 13:25:32 This issue describes patch for CVE-2021-4203 needs a commit f06bc03 to avoid null pointer dereference bug if DEBUG_CREDENTIALS is enabled. 13:27:05 stable kernels and cip kernels are already applied the commit. 13:30:24 Should we discuss self-maintainance of 4.4.X? 13:32:27 what aspects would require discussion? 13:32:48 I thought that was the main discussion of this meeting 13:33:05 Well... Do we maintain everything or just the hardware CIP boards have? 13:33:32 And if everything, should we attempt to be assigned 4.4-stable tree? 13:33:39 right, that needs a decision 13:33:50 what about commons parts ? memory, filesystem 13:34:23 alicef: We need to do common parts. No discussion neccessary there. 13:34:24 so far, the story was: everything that is enabled in the superset of our configs 13:35:09 pavel: I think so 13:35:47 but "just hardware" is ambiguos. 13:36:29 jki: yes, our configs are main focus. 13:36:32 just wanted to be sure that also commons part are into "just hardware" 13:36:47 jki: But we have basically just 2 boards in our 4.4.X testing. We build for a bit more. 13:37:30 doing more is one thing, committing on doing more is another 13:37:47 my concerns are about that commitment, explicit or implicit 13:38:19 we need the manage our limited resources in the end 13:39:03 Well, we'd get implicit commitment, yes. 13:39:34 But we can still ask people to bisect when they encounter problem, that's how stable works. 13:40:06 And we'd probably get testing from the community. (And some exposure/advertising). 13:40:14 we'd PROVIDE implicit commitment by saying we host a complete 4.4.y-stable 13:40:26 but I can't assess the effort 13:40:48 Yes, agreed, we would. 13:40:51 while I would possibly have to provide answers to the members if they want to know that 13:41:14 We'd have react to emails and if someone bisects bad patch we'd have to revert it. 13:41:22 OTOH we would get community testing. 13:41:29 https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/448669210 13:41:44 I see the point 13:41:47 ...we are currently testing on single arm board and x86 qemu. 13:42:20 kernelci is also testing 4.4 cip 13:42:41 ...but people probably expect arm64 to work etc... 13:43:01 and there we already have a difference, right 13:43:08 https://linux.kernelci.org/build/cip/branch/linux-4.4.y-cip-rt/kernel/v4.4.296-cip67-rt37/ 13:43:20 187 builds 13:44:16 and testing on most of accessible kernelci boards 13:44:29 I see pros: more exposure, better testing, outside people more willing to help us. 13:44:45 And there are cons: more work. 13:44:52 before asking the Linux community to give us the 4.4-stable tree in the name if CIP, we should ask our TSC for an approval 13:45:13 and they will ask us to provide at least an estimate on that 13:45:22 that "more work" 13:45:35 or that "saved work due to contributions" 13:46:20 jki: I guess so. But we have to ask fairly quickly as taking over 4.4-stable will be hard once the tree closes. 13:46:47 why will it be hard after that? 13:47:20 this is a complex question, and I'm concern we won't get a quick answer 13:47:42 jki: I see two possibilities: a) Greg is right that noone cares about 4.4.X any more. I believe people will still test it if we provide it, but would not expect too much extra work. 13:47:49 on the other side we also have Gregkh opinion in merit 13:48:12 b) someone besides -cip still uses 4.4. We'll get bugreports but we are also likely to get external help. 13:48:44 jki: Well, once tree closes, it will be marked at closed, and people will be hard-pressed to move away from it. 13:49:04 Backlog will accumulate, so it will not be easy "pick where Greg left" any more 13:49:15 Tree will be marked as unmainained at kernel.org. 13:49:29 Agreed this is a complex question :-(. 13:49:50 Testers will move away from the tree once it is marked as closed. 13:49:51 pavel: did you already reach out to Greg and carefully ask whether he would hand over at all? 13:50:06 not saying that we decided to do that already 13:50:29 then we may gain time - or close the topic because he refuses to do that 13:50:30 (let me search that). 13:51:14 greg replay on CIP maintainance: That is up to them to do, I wish them well, I think it is a loosing game 13:51:16 and one that is going to cost more money than they realize. 13:52:11 so if I understand the first part correctly. Greg say that is up to CIP to decide. 13:52:28 alicef: do you have links handy? I tried to "carefully ask", but have too much mail and can't find the right one now. 13:52:35 was that on our CIP tree or on the official stable tree? 13:52:38 https://lore.kernel.org/lkml/YehSi9Bati3sNado@kroah.com/ 13:52:54 link of the full Gregkh replay: https://lore.kernel.org/lkml/YehSi9Bati3sNado@kroah.com/ 13:53:24 also twitter feed on the issue: https://twitter.com/gregkh/status/1484052284308865025 13:54:05 Thank you, that's the one. You can see my message in the parent. 13:54:26 reading Greg's reply, he is only referrring to our tree and to our way of maintenance (narrow) 13:54:50 so, he is actually confirming the concerns regarding to promise "we just continue" 13:54:59 which we can't 13:56:25 Well, yes, it appears so. I did not want to do more explaining/discussion without checking with you. 13:56:36 my stomach says: better direct the remaining users to our tree and make them contribute there if they see value 13:56:53 we can advertise that, but we should also explain the limited scope 13:57:11 we could even provide a "vanilla" stable tree without backports as well 13:57:26 but under a different url to clarify that it is different 13:57:43 I believe that would be good idea, yes. 13:57:45 differently maintained 13:58:16 But I don't think we'll get people testing it the way they are testing 4.4-stable. 13:59:05 is that testing coupled to the URL or the scope of (committed) maintenance? 14:00:55 Gentoo is actually removing 4.4 and also 4.9 kernel 14:00:56 Its just inertia, probably. They have always tested 4.4.x so they'll likely continue if it is on same url. 14:01:56 as they are already not enough used anymore 14:02:48 It seems ~3 projects (+ us) are testing 4.4.X-rc candidates. 14:03:35 we need active testers in the end, those who also report when the find something 14:04:02 make them aware of what we do, how we do that, and the active and interested ones should follow 14:04:32 jki: but on what boards ? cip is willing to accept bugs also amd64? 14:06:08 I agree it is not easy. I believe it will be easier to get people to cooperate if we act as stable maintainers. 14:06:16 let's say: if there are active testers on arm64 who are willing to submit reports and solutions for arm64, we take them 14:06:36 but we will not invest more than that - we don't have the mandate by CIP 14:07:10 if users want to change that: become a CIP member an vote for it! 14:08:09 I think the key is being transparent, not overpromising anything, rather accidentally over-delivering from time to time 14:08:28 Ok, so: 14:09:03 a) Have we decided at maintaining 4.4-stable and 4.4-stable-rt separately? 14:09:28 b) Will we do some kind of announcement when Greg anounnces 4.4.x closes? 14:09:37 b1) Who does the announcing? :-) 14:10:13 c) Does it make sense to ask CIP TSC if we want to become stable maintainers? 14:11:33 I think we will not be able to sell c) to the TSC 14:11:54 at least I feel like I would lack enough arguments 14:12:29 doing a) in a separate tree, explaining via b) how that works, may be worth to present to the TSC 14:12:56 Ok, that makes sense. 14:13:46 the announcement should be sent by the CIP kernel maintainer(s) 14:13:57 on the wording, we can work together 14:14:16 Ok, that works for me. 14:15:08 I will try to present that idea on next week TSC call 14:15:14 Thank you! :-) 14:16:05 ok, we are overtime :) 14:16:12 anything else here? 14:16:18 Yep, sorry about that :-) 14:16:34 np, it's an important topic 14:17:14 move on in... 14:17:17 3 14:17:20 2 14:17:23 1 14:17:26 #topic Kernel testing 14:18:00 I updated some KernelCI patches 14:18:23 one that is needed for enabling lab-cip devices not yet enabled on kernelci 14:18:40 but some of them are offline/not working 14:18:53 denx-lab? 14:19:04 so I will discuss about putting them online with patersonc[m] 14:19:17 jki: is not only one 14:19:24 ok 14:19:32 https://github.com/kernelci/kernelci-core/pulls?q=is%3Apr+is%3Aopen+label%3Acip 14:20:15 but yes also denx-lab 14:20:42 other PR refactor is about preempt_rt 14:21:03 I see in staging that we we are already getting rt test results correctly 14:21:30 so will be enabled after the next review from kernelci 14:22:48 ok, great 14:22:57 https://staging.kernelci.org/test/job/cip/branch/linux-5.10.y-cip-rt/kernel/v5.10.83-cip1-rt1/ 14:23:16 baseline-cip-nfs is the test with isar-cip-core by the way 14:24:22 that's all for me 14:24:52 thanks 14:24:55 anything else? 14:25:10 3 14:25:13 2 14:25:16 1 14:25:19 #topic AOB 14:25:46 anyone anything here? 14:26:39 3 14:26:43 2 14:26:48 1 14:26:52 #endmeeting