12:01:33 <jki> #startmeeting CIP IRC weekly meeting
12:01:33 <collab-meetbot`> Meeting started Thu Jul  7 12:01:33 2022 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:33 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:33 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:59 <jki> looks like we can start already
12:02:05 <jki> #topic AI review
12:02:23 <jki> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:03:52 <alicef> I think this AI is not directly mine. we was talking about reading the email, that I have not replayed yet. patersonc[m] do you have any comment on this?
12:04:34 <alicef> I think the problems need to be sent to kernelCI not me.
12:04:36 <jki> sorry if I misinterpreted that - but who can/will do the next step?
12:05:13 <patersonc[m]> Agreed that a lot of the points in Pavel's email are more for KernelCI
12:05:15 <alicef> So opening issues directly to KernelCI about any CIP results issues is the best way
12:05:22 <alicef> to have it solved
12:05:41 <patersonc[m]> I was going to add them on CC by our work mail client corrupts all the links making it impossible for others to use...
12:05:52 <alicef> pave1: should not send the email directly to me. each problem he found need to be sended to kernelCI
12:06:09 <alicef> and I will help solve such problems from kernelci
12:06:13 <pave1> I don't think I know enough about kernelci to do submissions myself.
12:06:27 <alicef> pave1: just open issues on github
12:06:30 <pave1> I just need something to test the kernels.
12:07:01 <patersonc[m]> If we truly don't want to get results from configs/arches we don't "care" about, we should reduce the test coverage. But that would have the impact of reducing the test coverage ;)
12:07:21 <alicef> pave1: not sure what you mean by that. are you implaying that KernelCI is not testing ?
12:07:39 <alicef> sorry but the best way of getting your kernel testing is using KernelCI effort
12:07:51 <jki> I suppose kernelci wants one issue per failing build/test, right?
12:08:02 <alicef> just opening the issues to cip is not making KernelCI aware of such problems
12:08:11 <alicef> yes
12:08:25 <alicef> KernelCI is already doing it for the stable kernels
12:08:26 <pave1> I'm impliying that kernelci is currently useless for CIP kernel work.
12:08:56 <pave1> It is possible that submitting a lot of issues would improve that.
12:09:09 <alicef> how do you expect that I replay to this ?
12:09:31 <pave1> But that's significant work and I don't think I'm the best one to do that.
12:09:57 <alicef> KernelCI example on stable kernels bugs https://github.com/orgs/kernelci/projects/6
12:11:29 <alicef> jki: sorry but this is not my issue. the issue is to upstream bugs with kernelci to kernelci.
12:12:04 <jki> understood, but we need someone to carry to bugs there
12:12:14 <alicef> That is the best way for getting collaboration from kernelci
12:12:31 <jki> seems like no one is currently willing to do that
12:13:15 <jki> I can try to sit down over a few failures we've seen and start creating issues, CC'ing you, if that helps
12:13:19 <alicef> jki: we don't need someone to carry bugs there. we need that who is checking kernel results follow a upstream workflow
12:13:28 <alicef> on kernelci
12:13:48 <patersonc[m]> At the very least send Pavel's email to the kernelci mailing list
12:13:53 <alicef> just keeping bugs internal to cip is not a collaboration effort
12:14:05 <jki> alicef: if you know best what we need to do, we need your help to do the first steps
12:15:23 <jki> so, what is best now as first step? forward/resend the email or create issues?
12:15:56 <patersonc[m]> ideally both, but email as a minimum
12:16:00 <alicef> sorry, I really struggle to understand where is the problem on upstreaming issues with kernelci to kernelci.
12:16:16 <pave1> I don't thimk that email is suitable for forwarding .-)
12:16:27 <alicef> ...
12:16:50 <jki> pavel: can you write a suitable one to get started?
12:17:18 <alicef> I don't think we need someone to forward it
12:17:27 <alicef> just put kernelci in cc
12:18:44 <patersonc[m]> (kernelci@groups.io)
12:18:49 <alicef> kernelci@groups.io
12:19:34 <alicef> I'm not the one that can decide for pavel what wark and dosen't work for pave1
12:19:43 <pave1> Hmmm. I can write something but I'd preffer not to talk directly to kernelci.
12:19:54 <jki> pavel: why not?
12:20:10 <alicef> ...
12:20:36 <pave1> Not sure if I'm diplomatic enough for that... and that I know enough about kernelci/cip relationship.
12:21:37 <jki> but you know best what you consider a kernelci issue, and why
12:22:12 <patersonc[m]> KernelCI are happy to receive any feedback
12:24:46 <patersonc[m]> Let's move on
12:25:39 <jki> not sure if we have a consensus on the next steps yet
12:25:58 <patersonc[m]> The action is on Pavel to send his feedback to the KernelCI mailing list
12:26:26 <jki> pavel: ok for you?
12:26:35 <pave1> No.
12:26:48 <pave1> There's real work to be done in testing.
12:27:05 <pave1> Currently it seems noone is willing to do the work.
12:27:29 <pave1> Tesing group seems to say 'just talk to kernelci'.
12:27:55 <pave1> I could not find single suitable bugreport. I detailed that in the email.
12:29:48 <jki> ok, let's postpone the topic to a later round - will also have a look again myself
12:30:10 <jki> 2. Check cip devices on kernelci old pull request - patersonc
12:30:25 <patersonc[m]> No progress this week
12:30:38 <jki> 3. Update https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware - iwamatsu-san
12:31:33 <jki> .../wrt qemu targets
12:31:45 <iwamatsu> Chris and I support armhf and arm64 into kernel testing.
12:32:20 <iwamatsu> so we can enable / support OK to status of each QEMU.
12:32:31 <jki> great!
12:32:43 <jki> will you flip the related marks in the wiki?
12:33:17 <iwamatsu> OK, I will do it.
12:33:23 <jki> TIA
12:33:39 <jki> anything else here?
12:33:51 <jki> 3
12:33:53 <jki> 2
12:33:56 <jki> 1
12:33:58 <jki> #topic Kernel maintenance updates
12:34:32 <uli> looked into potential 4.4 backports
12:34:36 <masami> There was 8 CVEs and 2 updated CVEs this week.
12:34:47 <pave1> I believe that whoever believes kernelci is good idea should do the work.
12:35:01 <pave1> Sorry, connection problem.
12:35:15 <pave1> I did some reviews on 5.10.129.
12:35:44 <iwamatsu> I reviewed 5.10.129
12:37:18 <jki> what is the status on 4.4 side? can we push out new releases?
12:37:36 <jki> that question came up in the TSC
12:37:58 <iwamatsu> pave1: sorry, I dont know status of latest 4.4.y-st tree. If you think we can release it, I will work...
12:38:08 <pave1> I'm currently traveling. I should be able to work on it next week.
12:38:30 <pave1> We can release but we are lagging behind -- random and tcp.
12:39:02 <uli> from what i can see so far, most (if not all) random patches don't apply to the implementation in 4.4
12:40:29 <jki> do we know more about them by now, if we should fix something in 4.4 as well?
12:40:42 <jki> are they in 4.9?
12:41:25 <uli> random seems to have been rewritten between 4.4 and 4.9, and the patches in question are all fixups for the new implementation, afaict
12:41:29 <iwamatsu> dont apply > As with CVE, some patches will be difficult to apply. We will also need to make that choice.
12:41:35 <alicef> pave1: sending to kernelci is needed for getting kernelci opinion on this. is not just about doing the work.
12:42:34 <alicef> also we is useful for improving CIP connections with KernelCI
12:42:34 <pave1> I'm still not sure why random was rewritten.
12:43:04 <jki> reach out to the developer(s)?
12:43:38 <jki> maybe even in private if that topic could be sensitiv
12:43:54 <pave1> We may want to do other stuff first.
12:46:44 <patersonc[m]> Does the RT project follow any kind of release schedule?
12:46:59 <patersonc[m]> I.e. is there something we can align to?
12:47:31 <pave1> There seem to be individual maintainers doing stable-rt
12:47:48 <pave1> each with his own schedule.
12:48:08 <pave1> About 1-2 releases a week seem common.
12:49:06 <pave1> ..a month, not a week.
12:49:09 <pave1> sorry.
12:49:23 <patersonc[m]> Okay
12:49:34 <patersonc[m]> And are we maintaining the v4.4 version now?
12:49:50 <pave1> Yes, we are.
12:50:39 <patersonc[m]> Thanks
12:51:06 <jki> any other topics for this section?
12:51:36 <iwamatsu> o/
12:52:28 <iwamatsu> other information: Chris and I supported BBB and QEMU arm to 4.4.y and 4.9.y tree for CI testing.
12:52:31 <patersonc[m]> It's a shame we didn't sync our 5.10 releases with either 5.10.119 or 5.10.120 - both of them seem to have an RT release
12:53:15 <pave1> Thanks! 4.4 testing is needed.
12:53:16 <iwamatsu> Yes, it is my mistake..
12:53:40 <patersonc[m]> 4.4: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/582284563
12:54:42 <iwamatsu> but current test is boot and scm. I am working to add other test to each target.
12:54:58 <patersonc[m]> Thanks iwamatsu
12:55:27 <jki> so we are already in...
12:55:28 <pave1> Reallistically, boot is most useful test.
12:55:30 <jki> #topic Kernel testing
12:56:51 <patersonc[m]> See the latest 4 pipelines here: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines
12:57:08 <patersonc[m]> QEMU arm/arm64 and BBB all now working
12:57:23 <patersonc[m]> I've also enabled the boot testing for the RT configs for v5.10
12:59:13 <patersonc[m]> That's probably about it
12:59:19 <patersonc[m]> Thank you iwamatsu for your MRs
12:59:20 <pave1> Thank you!
12:59:46 <jki> great work!
13:00:32 <iwamatsu> you are welcome.
13:01:00 <jki> move on?
13:01:11 <jki> 3
13:01:12 <jki> 2
13:01:14 <jki> 1
13:01:16 <jki> #topic AOB
13:01:33 <jki> first, I'm not available next week
13:01:38 <jki> could someone take over?
13:01:41 <pave1> Sorry for connection problems.
13:02:12 <pave1> I'll be available next week, but not the week after that.
13:02:43 <jki> pavel: can you run the meeting next week?
13:02:58 <pave1> Yes, I can.
13:03:09 <jki> perfect, thanks!
13:03:30 <pave1> You are welcome .-).
13:03:48 <jki> then Chris brought up the valid question if we are already thinking about the next major CIP kernel
13:04:29 <pave1> When should that begin?
13:04:32 <jki> i think we are still early in the learning phase what 4.4 selfmaintenance "costs"
13:04:56 <patersonc[m]> jki: oh yea, forgot about that
13:05:36 <patersonc[m]> The obvious question will be - what will it cost to maintain a 4th kernel in parallel
13:05:43 <jki> we will eventually need to answer the question how much extra effort a 5.2x-cip would bring and how much we need to scale further, and when
13:05:50 <jki> right
13:06:21 <jki> so far, we kept the pace of having a new kernel every 2 years (more or less, just later announced for 5.10)
13:06:50 <jki> we will not have to answer that question tomorrow, but we should keep that in mind and collect data
13:07:14 <patersonc[m]> I'm guessing the team is fairly maxed out already?
13:08:41 <pave1> With the reviews, yes. We still could decide to review less.
13:09:25 <jki> how much do we find in reviews?
13:09:32 <pave1> And we also have some flexibility regarding how much we backport.
13:10:22 <pave1> jki> Well.. There's a lot of stuff that does not match published stable rules.
13:10:53 <pave1> But finding hard bugs where Greg is willing to revert is more rare, perhaps one in 50 patches.
13:11:46 <jki> well, that is still quite some value for us and our users
13:12:36 <pave1> ..and for stable community, too, I guess. It is our contribution to stable community.
13:13:15 <jki> of course!
13:14:21 <jki> ok, let's keep that question of efforts in mind
13:15:11 <jki> maybe also a topic for the next extended TSC, and then we should have some first feelings collected
13:15:44 <jki> anything else for today?
13:16:15 <jki> 3
13:16:17 <jki> 2
13:16:18 <jki> 1
13:16:20 <jki> #endmeeting