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