09:00:02 <szlin> #startmeeting CIP IRC weekly meeting
09:00:02 <brlogger> Meeting started Thu May 23 09:00:02 2019 UTC and is due to finish in 60 minutes.  The chair is szlin. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:02 <brlogger> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:02 <brlogger> The meeting name has been set to 'cip_irc_weekly_meeting'
09:00:08 <szlin> #topic rollcall
09:00:13 <szlin> please say hi if you're here
09:00:22 <pave1> hi
09:00:27 <vidda> hi
09:00:29 <iwamatsu> hi
09:00:31 <patersonc> hi
09:00:53 <szlin> #topic AI review
09:00:59 <szlin> 1. Upload check script to lts-commit-list repository - Pavel
09:01:12 <pave1> I've just issued the command to do the upload :-).
09:01:24 <szlin> #info https://gitlab.com/cip-project/cip-kernel/lts-commit-list/commit/820135ffab6611345d2fcc828959b657fcdc049d
09:01:31 <szlin> pave1: thank you
09:01:42 <pave1> It is there now, but it will need more work. So far it is more of a python library that needs to be called from python.
09:01:43 <bwh> hi
09:02:32 <szlin> 2. Release 4.4 and 4.19 kernel - Iwamatsu
09:02:41 <szlin> #info https://lists.cip-project.org/pipermail/cip-dev/2019-May/002369.html
09:02:48 <szlin> 3. Prepare the CIP kernel release document - Iwamatsu
09:03:39 <szlin> iwamatsu: would you like to update this AI?
09:04:18 <iwamatsu> We released 4.19.13-cip2 and 4.4.176-cip32.
09:05:13 <szlin> iwamatsu: thanks, but this topic related to the release document of CIP kernel
09:05:41 <iwamatsu> I wrote a brief explanation in the email. Do we need more explanation?
09:06:58 <szlin> IIRC, pavel requested to have release procedure for CIP kernel
09:07:07 <szlin> pave1: please correct me if I'm wrong
09:07:49 <pave1> Correct. If you point me what email it is, I guess I can take a look and transform it into README somewhere.
09:09:22 <iwamatsu> I see.
09:09:23 <iwamatsu> Please give me some time.
09:09:32 <szlin> iwamatsu: thanks, I will keep this AI
09:09:37 <szlin> 4. Arrange a meeting between CIP core and CIP security WG - szlin
09:09:40 <szlin> -> Done
09:09:43 <szlin> #topic Kernel maintenance updates
09:09:48 <szlin> Iwamatsu-san released kernel 4.19.13-cip2 and 4.4.176-cip32
09:09:49 <szlin> #info https://lists.cip-project.org/pipermail/cip-dev/2019-May/002369.html
09:10:22 <szlin> iwamatsu: pave1 would you like to update the status of kernel maintenance?
09:10:49 <pave1> szlin: I did review 4.19.38 and 4.19.45. Nothing much else to report.
09:11:09 <szlin> pave1: thank you for your update
09:12:02 <szlin> any other topics?
09:12:21 <iwamatsu> szlin: I reviewed the released kernel patch (4.4.157).
09:12:53 <szlin> iwamatsu: thank you.
09:13:01 <iwamatsu> And I restart failed-patches tracking.
09:13:31 <iwamatsu> I create new repository for this, and pushed. https://gitlab.com/cip-project/cip-kernel/classify-failed-patches
09:13:48 <szlin> #info https://gitlab.com/cip-project/cip-kernel/classify-failed-patches
09:14:15 <iwamatsu> This is based on a script created by Daniel. There are still many problems.
09:15:06 <szlin> iwamatsu: I suggest it would be better to have license declaration
09:15:40 <iwamatsu> szlin: OK, I will add license file
09:15:53 <szlin> iwamatsu: thanks
09:16:00 <pave1> iwamatsu: Let me take a look. I wonder if it would make sense to have single repository for lts commit lists etc...
09:16:10 <szlin> #action Add license file in classify-failed-patches
09:16:18 <szlin> pave1: fair enough
09:16:33 <szlin> any other topics?
09:16:46 <pave1> iwamatsu: And I guess we should find better way to reference patches than their sumary line.
09:17:12 <pave1> iwamatsu: But we'll probably not solve that now over irc.
09:17:25 <bwh> You should usse the first 12 digits of the commit hash too
09:18:01 <iwamatsu> pave1: Indeed.
09:18:12 <pave1> bwh: Commit hash of the upstream commit, agreed.
09:19:13 <szlin> #agreed Use commit hash instead of summary line in "failed patches"
09:19:16 <szlin> 3
09:19:17 <szlin> 2
09:19:19 <szlin> 1
09:19:40 <szlin> #topic Kernel testing
09:19:51 <patersonc> Three topics from me today.
09:20:02 <patersonc> 1)
09:20:07 <patersonc> The stability of lab-cip-renesas has improved since we switched out a dodgy remote power switch.
09:20:10 <patersonc> 2)
09:20:15 <patersonc> #info: Michael (Siemens) has released gitlab-cloud-ci. A tool which makes it possible to setup a Kubernetes cluster in an AWS instance, driven by GitLabCI.
09:20:19 <patersonc> #info https://gitlab.com/cip-playground/gitlab-cloud-ci
09:20:22 <patersonc> Looks like a good tool for us, however I wonder how much AWS would end up costing.
09:20:27 <patersonc> I don't know how good GitLab's shared (free) runners are, so have started looking into GitLab CI in more detail to test.
09:20:33 <patersonc> Let me know if anyone has any experience/thoughts.
09:21:20 <patersonc> It looks like Daniel has taken a quick look.
09:21:34 <szlin> patersonc: are you using gitlab ce or gitlab ee?
09:22:01 <patersonc> szlin: Whatever CIP's LAVA account is
09:22:14 <szlin> patersonc: got it, thanks.
09:22:17 <bwh> pave1: I understand that running CI "in the cloud" is usually rather expensive
09:22:17 <szlin> any other topics?
09:22:26 <bwh> I mean patersonc ^
09:22:26 <patersonc> s/LAVA/GitLab
09:22:53 <patersonc> bwh: That's my worry. As Daniel suggested we could trial it. There is probably a tool in AWS to estimate though.
09:23:25 <patersonc> For things that aren't updated much, perhaps the free runners would be good enough.
09:23:26 <pave1> patersonc: Or maybe try gitlab's shared runners, first, and see how it works?
09:23:39 <patersonc> pave1: That's what I started looking into last night
09:24:28 <patersonc> The alternative is a member company shares a server for the GitLab runner
09:25:15 <patersonc> Any more comments? Or should I move on? (1 more topic)
09:25:43 <szlin> let's move on
09:25:50 <patersonc> 3)
09:25:52 <patersonc> It looks like it is going to be hard for all member companies to set up their own LAVA worker for their reference platforms,
09:26:03 <patersonc> so I am investigating setting up/getting some quotes for a new external LAVA worker to host all CIP reference platforms.
09:26:04 <patersonc> This means that members can just send boards to a central place to be added to a lab.
09:26:09 <patersonc> Does anyone have any specific requirements for this new lab?
09:26:10 <patersonc> One thing I'm not sure on is what kind of uptime guarantees we need. For example, are we happy for a lab to be down for a few hours? A day? ...
09:26:39 <patersonc> The other is bandwidth requirements
09:27:02 <patersonc> Any thoughts?
09:27:46 <szlin> patersonc: I suggest you can send the investigating email to cip-dev
09:27:57 <patersonc> szlin: Sure
09:28:10 <pave1> We are releasing kernels two times a month. So I guess downtime of few hours should not be huge problem for us.
09:28:51 <pave1> Bandwidth: It seems that LAVA does a lot of "lets grab this filesystem image from this url and apply it".
09:29:18 <patersonc> Thanks pave1 . Let's continue this discussion after the meeting.
09:29:18 <pave1> that is going to eat some bandwidth, and maybe we should have images close to the lab..
09:29:27 <pave1> patersonc: ack.
09:29:30 <szlin> #action send investigating email for kernel-testing lab to cip-dev - patersonc
09:29:35 <szlin> any other topics?
09:29:40 <patersonc> Not from me
09:29:43 <szlin> 3
09:29:44 <szlin> 2
09:29:44 <szlin> 1
09:29:51 <szlin> #topic CIP Core
09:30:44 <szlin> any topics?
09:30:51 <szlin> 3
09:30:52 <szlin> 2
09:30:53 <szlin> 1
09:30:58 <szlin> #topic Software update
09:31:43 <szlin> iwamatsu: I saw you sent the ITP email with libuboot*
09:32:17 <szlin> iwamatsu: and "libubootenv" was uploaded a week ago
09:32:29 <szlin> any other topics?
09:32:30 <szlin> 3
09:32:31 <szlin> 2
09:32:32 <szlin> 1
09:32:41 <iwamatsu> szlin: Yes, I did.
09:32:47 <szlin> iwamatsu: thanks
09:32:54 <szlin> #topic AOB
09:33:00 <szlin> any other business?
09:33:05 <szlin> 3
09:33:08 <szlin> 2
09:33:08 <szlin> 1
09:33:14 <szlin> #endmeeting