12:01:14 <jki> #startmeeting CIP IRC weekly meeting
12:01:14 <collab-meetbot> Meeting started Thu Sep 22 12:01:14 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:14 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:14 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:23 <jki> #topic AI review
12:01:33 <jki> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:02:17 <alicef> hello
12:02:24 <alicef> no updates here
12:02:44 <jki> 2. Check cip devices on kernelci old pull request - patersonc
12:03:09 <patersonc[m]> No updates alas
12:03:34 <jki> anything else?
12:03:46 <jki> 3
12:03:48 <jki> 2
12:03:50 <jki> 1
12:03:53 <jki> #topic Kernel maintenance updates
12:03:54 <alicef> I updated the pr for r8a7743-iwg20d-q7
12:04:16 <alicef> and waiting for denys to reviewing it
12:04:29 <pave1> I have done reviews on 5.10.144/145. Preparing to move 4.4.X forward.
12:04:38 <uli> done with 5.10.142
12:04:38 <masami> This week reported 5 new CVEs and 4 updated CVEs.
12:04:56 <patersonc[m]> alicef: thanks, I forgot about that...
12:05:15 <alicef> my talk was about the cip devices kernelci old pr as I was still writing it
12:05:37 <alicef> patersonc[m]: np
12:05:50 <iwamatsu> I do not work for kernel work in this week yet, sorry.
12:09:06 <jki> anything else to exchange?
12:09:34 <jki> 3
12:09:36 <jki> 2
12:09:38 <jki> 1
12:09:41 <jki> #topic Kernel testing
12:11:01 <patersonc[m]> As alicef said, work has been continuing on the older devices to get them running in KernelCI properly
12:11:10 <patersonc[m]> I finally did some documentation updates
12:11:29 <patersonc[m]> Not much else from me. Anything from you Alice?
12:11:47 <alicef> I reviewed and merged the documentation
12:13:05 <alicef> ps cip instance documentation can be seen here  https://static.staging.kernelci.org/docs/instances/cip/
12:14:19 <patersonc[m]> I guess that's about it
12:14:53 <jki> ok, then move on in...
12:14:55 <jki> 3
12:14:57 <jki> 2
12:15:00 <jki> 1
12:15:02 <jki> #topic AOB
12:15:21 <jki> I had two topics
12:15:30 <jki> 1. task distribution around 4.4 maintenance
12:15:47 <jki> pavel: are you around?
12:15:54 <pave1> Yes, I am.
12:16:19 <jki> we do not track the review tasks for 4.4 like for the other kernels, do we?
12:16:39 <pave1> I kind of assume that if it is in 4.9, it must be okay.
12:17:18 <jki> I mean we do not split the work and record who will do what
12:17:25 <pave1> Then I append list of changes to v4.4.org in lts-commit-list repository.
12:17:48 <pave1> Review whatever did not apply, and when I'm reasonably satisfied I move 4.4 forward.
12:18:17 <jki> means at all goes over your desk only
12:18:36 <pave1> Well, I do publish the changes in v4.4.org :-).
12:19:26 <jki> as we had some delays with 4.4 in past and more work is coming with some 6.1-cip, we should apply work-split wherever reasonable
12:19:50 <jki> also because of reduced risk when someone may not be available for some weeks
12:20:38 <pave1> We were doing coarse grained splits over email ("please look at /dev/random changes in X.Y.Z")
12:21:13 <pave1> If someone wants to play with the scripts and does next release, that's okay with me, too.
12:21:53 <pave1> But two people "cooperating" on one release.. I believe it would be easier for single person to do the work.
12:22:14 <jki> this has pros and cons
12:22:25 <jki> the pro is clearly that this is more efficient
12:22:40 <jki> the con is that it will mean larger latency if that person is not available
12:22:58 <jki> and a hard transfer if that lasts longer
12:23:42 <pave1> I believe splitting work at "few releases" level makes sense.
12:24:18 <jki> that sounds like a good idea to me
12:24:22 <pave1> Basically around 6.1-rc5, it will make sense to push 4.4.X forward.
12:24:40 <pave1> It should be small enough task for single person
12:25:11 <pave1> I wrote the scripts so I know how to operate them, but it is not rocket science and there are notes in v4.4.org.
12:25:42 <pave1> If someone wants to take the task, I can answer questions / help / etc.
12:25:59 <pave1> [I guess i would make sense for that person to create proper docs at that point.]
12:26:48 <uli> i think rather than reverse-engineering your process, it'd be better if you wrote it down
12:27:59 <pave1> I guess we should cooperate to create something.
12:28:53 <jki> uli: so you would feel like picking up 4.4 eventually?
12:29:24 <uli> if i get the time to do it, i'd be okay with that
12:30:02 <iwamatsu> o/ me too
12:31:35 <jki> well, if we are heading for one maintainer per kernel model, we will still have less maintainers than kernels ;)
12:32:14 <jki> and we will need again someone to look after 6.1-cip-rt :(
12:32:49 <pave1> So.. I'd say that maintaining 4.4.X has become quite different from the other branches.
12:33:32 <pave1> For example, I believe it would make sense for iwamatsu to release 6.1-cipX and for me to release 6.1-cipX-rtX.
12:35:39 <jki> however we split, I would welcome a lot if that split could increase the number of active maintainers for CIP
12:36:22 <pave1> I'd consider less frequent releases for the older kernels, but agreed, more maintainers is nice, too :-).
12:37:05 <iwamatsu> I think so :-)
12:38:10 <jki> good :)
12:38:32 <jki> that already covered by second AOB item
12:39:23 <jki> what would be next steps now?
12:40:40 <pave1> Next steps for 6.1-ci?
12:40:50 <pave1> 6.1-cip?
12:41:55 <jki> next steps for ramping up uli, making 4.4 workflow transferable
12:42:18 <jki> maybe also preparing for the next cip kernel, but more regarding estimating additional efforts
12:43:01 <pave1> I believe nothing for now. I finish the release.
12:43:20 <jki> let's assume uli would take over 4.4: would that give you two enough time to handle all other kernels?
12:43:55 <pave1> Then when uli wants to do the next one, I give him instructions. In a week or so, he'll have next 4.4.X release :-).
12:44:12 <jki> or would you need a similar level of review contributions by him like now?
12:44:41 <iwamatsu> nice > next 4.4.y release
12:45:02 <pave1> Reviews are majority of work. I'd say we should keep that split.
12:45:25 <pave1> Handling 4.4.X is not that much work.
12:45:51 <jki> then uli needs an impression about what additional work is needed for 4.4
12:46:23 <jki> and we were not yet in real backport needs there, right?
12:47:01 <pave1> We don't do much backporting, no. Plus we don't really have renesas submitting backports for inclusion.
12:48:17 <jki> na, 4.4 is no longer enabling backport target
12:48:27 <jki> just like 4.19 stopped that
12:48:40 <pave1> I think we can start with some small 4.4.X releases "soon" so that Uli learns the scripts.
12:48:59 <jki> cool
12:50:33 <jki> anything else? about this or beyond?
12:52:12 <jki> 3
12:52:14 <jki> 2
12:52:16 <jki> 1
12:52:19 <jki> #endmeeting