13:08:08 <jki> #startmeeting CIP IRC weekly meeting
13:08:08 <brlogger> Meeting started Thu Feb  3 13:08:08 2022 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:08:08 <brlogger> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:08:08 <brlogger> The meeting name has been set to 'cip_irc_weekly_meeting'
13:08:15 <jki> here we go
13:08:23 <jki> found the magic spell
13:08:43 <jki> who is around?
13:09:08 <uli> o/
13:09:11 <iwamatsu> hi
13:09:14 <masami> hi
13:09:15 <josiah> Hi
13:09:18 <alicef> jki: https://gist.github.com/aliceinwire/2e6320fe4cd12a128102ce6ee3d3724d
13:09:23 <alicef> Hi
13:10:05 <jki> alicef: I have this as well, but when you are in hectic... ;)
13:10:05 <alicef> there is also patersonc but looks he have problems with matrix/element
13:10:10 <patersonc> hi
13:10:15 <patersonc> Joining from another client now
13:10:39 <jki> missing pavel
13:10:46 <jki> but given that we are late already...
13:10:57 <jki> #topic AI review
13:11:15 <jki> 1. Request private KernelCI branches for CIP maintainers - patersonc
13:11:22 <jki> any news on this PR?
13:11:28 <patersonc> Finally made the initial PR
13:11:29 <patersonc> https://github.com/kernelci/kernelci-core/pull/1022
13:11:34 <patersonc> Sorry for the delay
13:12:28 <jki> alicef: you will review this?
13:12:41 <alicef> yes
13:13:02 <jki> anything else missing for a merge?
13:13:06 <alicef> I have already reviewed with patersonc in private
13:14:33 <alicef> the discussion was about enabling rc to be tested for each commit and not only tags
13:15:07 <alicef> I don't think the PR is completely satisfy the issue request but is a good starting point
13:15:49 <patersonc> Any push to the *-rc branches will be run in KernelCI
13:16:14 <patersonc> Just maybe not instantly
13:16:45 <alicef> oh nice you could confirm that?
13:17:40 <patersonc> not until it's merged, or manually triggered in staging
13:18:25 <alicef> ok thanks
13:19:03 <alicef> I have no other objections
13:19:08 <alicef> as now
13:20:19 <jki> ok - so alicef will ack, and then someone else still needs to merge it, right?
13:20:28 <alicef> using cip_variants as I said looks good for me
13:21:02 <alicef> ack, staging test and merge
13:21:19 <jki> great
13:21:30 <jki> next topic?
13:21:38 <alicef> we need also gtucker ack
13:21:51 <alicef> yes next topic
13:22:02 <jki> 2. Make TSC motion regarding linux-4.4.y branch by CIP - jan
13:22:09 <jki> this has been sent
13:22:40 <jki> was the wording ok for all?
13:23:11 <patersonc> I think for the v4.4.y branch (non-cip) we should say we'll follow the current stable rules, not CIP's rules
13:24:36 <iwamatsu> That mean that we do not accept backports about features?
13:24:45 <jki> yes, regarding what CIP would additionally accept
13:24:51 <jki> that goes into cip only
13:25:24 <jki> but what we do not accept - because of out of scope - will also not go into 4.4.y
13:25:38 <jki> that was my idea behind referring to CIP rules
13:25:39 <patersonc> v4.4.y = bug/security fixes (like current LTS). v4.4.y-cip = v4.4.y + feature backports (current SLTS rules)
13:25:50 <patersonc> Gotcha
13:26:04 <iwamatsu> I understood.
13:26:13 <patersonc> Agree that v4.4.y should be CIP scope only, just follow LTS rules
13:26:39 <jki> we likely need to craft the announcement email carefully in this regard
13:26:49 <alicefm> if someone send a pull request for out the cip scope will not be accepted?
13:27:02 <alicefm> I'm understanding correctly?
13:27:45 <jki> at least we do not commit on accepting that - I would leave us the freedom to do so if there is value for us
13:28:03 <alicefm> ok
13:28:06 <jki> it's that thin line we were discussion last week and also in the TSC call
13:28:42 <jki> meanwhile, my motion still needs a second in order to start the actual voting
13:28:58 <jki> or suggestions to sharping the wording
13:30:35 <jki> anything else on this topic?
13:30:46 <alicefm> wording looks ok from what i remember
13:31:39 <jki> 3. Draft press announcement about 5.10 release and 4.4 self-maintenance - jan
13:31:55 <jki> i won this task during the TSC call
13:32:18 <jki> didn't have time to look into it yet, though
13:32:53 <jki> anything else for AIs?
13:33:10 <jki> 3
13:33:12 <jki> 2
13:33:14 <jki> 1
13:33:17 <jki> #topic Kernel maintenance updates
13:33:38 <uli> reviewed more 5.10.94 patches
13:34:03 <iwamatsu> I reivewed 5.10.96.
13:34:04 <masami> There was 8 new CVEs this week. also, there were tons of security fix for 4.X series.
13:37:47 <masami> I'll more look into security fix for 4.4.y from next week.
13:37:52 <masami> maybe, I'll send a patch to cip-dev mailing list if I can backport it.
13:38:25 <jki> what will be our criteria to look at backport candidates?
13:38:34 <jki> CVE attached? Or more?
13:38:54 <iwamatsu> I also take a look.
13:39:59 <iwamatsu> For CVE, if it is  related to our reference board, try backport.
13:41:22 <jki> and how will we track that? our wiki is not tracking 4.9 and 4.14, only 4.19 regarding commits, thus backport candidates
13:41:47 <jki> btw, https://www.kernel.org/category/releases.html no longer lists 4.4 - was something sent already?
13:42:37 <iwamatsu> I think other backports will be the same.
13:42:54 <iwamatsu> Certainly we need a mechanism to manage patches  for 4.4.y.
13:43:05 <iwamatsu> 4.4.302 has been released.
13:43:19 <jki> ah, ok
13:43:38 <iwamatsu> it has EOL mark.
13:43:46 <jki> just today
13:43:50 <iwamatsu> yes
13:44:10 <jki> oh, Greg mentioned us
13:44:17 <jki> we have the ball in our field
13:44:46 <jki> because of "is considering" - we are decided to
13:46:06 <jki> I think we should probably move forward with Pavel's proposal soon then, not yet referring to the ongoing 4.4.y continuation thing
13:46:24 <jki> that could still be announced later on top, once we have the ok
13:47:31 <jki> I can follow up on Pavel's post to cip-dev, suggesting that
13:48:01 <patersonc> How often will CIP add to their own version of 4.4.y?
13:48:14 <patersonc> And will there be "releases"?
13:48:23 <patersonc> 4.4.303 etc.?
13:51:34 <jki> good questions
13:52:08 <jki> it would probably make sense and should be easy to implement tagging releases along the CIP ones
13:52:55 <iwamatsu> I do not know the release of releases now. if the patch is accumulated, it will be release...
13:56:55 <jki> I think this would be about tagging the baseline of 4.4.30X-cip with 4.4.30X, like before
13:57:12 <jki> but only in our continuation branch
13:57:37 <jki> anyway, we need the general OK to publish and annouce the branch at all first
13:57:49 <jki> other topic here?
13:57:53 <jki> topics
13:59:17 <jki> 3
13:59:18 <jki> 2
13:59:21 <jki> 1
13:59:26 <jki> #topic Kernel testing
14:00:06 <patersonc> Not much news from me
14:01:42 <jki> everything's running smoothly then :)
14:01:45 <iwamatsu> We can not build 5.10.y/-cip tree yet.
14:01:55 <jki> ...except for...
14:02:15 <jki> what blocks it?
14:02:36 <alicefm> Not much news from me either
14:02:42 <iwamatsu> gcc
14:03:03 <patersonc> Oh yes, I did an MR, we just need to update cip-pipeilnes to use it
14:03:04 <patersonc> Sorry
14:03:53 <iwamatsu> gcc of gitlab's kernel build container is not fit 5.10.y.
14:04:06 <iwamatsu> NOP
14:06:25 <jki> anything else here?
14:07:36 <jki> 3
14:07:37 <jki> 2
14:07:40 <jki> 1
14:07:43 <jki> #topic AOB
14:07:56 <jki> irc bot: we'll get a new one!
14:08:19 <alicefm> ok nice
14:08:20 <jki> likely. Neal dug out a hosting at LF, details to be clarified
14:08:25 <masami> great!
14:08:25 <iwamatsu> nice
14:08:35 <jki> also if/how to get the archive migrated
14:09:33 <jki> any other business?
14:10:23 <jki> 3
14:10:26 <jki> 2
14:10:28 <jki> 1
14:10:31 <jki> #endmeeting