18:00:24 <dcavalca> #startmeeting Hyperscale SIG
18:00:24 <centbot> Meeting started Wed Mar 17 18:00:24 2021 UTC.  The chair is dcavalca. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:24 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:31 <dcavalca> morning everybody
18:00:32 <jvreeland> hello
18:00:39 <dcavalca> #chair dcavalca jvreeland
18:00:39 <centbot> Current chairs: dcavalca jvreeland
18:00:48 <dcavalca> hopefully DST didn't mess up the schedule too badly
18:03:05 <dcavalca> alright, let's get started
18:03:08 <dcavalca> #topic Followups
18:03:21 <dcavalca> let's see what we had from the last meeting
18:04:05 <dcavalca> I sent a talk to CentOS Dojo in May to do a SIG update
18:04:25 <dcavalca> I looked into toddlers for the systemd repo, but I couldn't figure out how to make it work for this usecase
18:04:30 <dcavalca> details in the ticket if anybody's interested
18:04:56 <dcavalca> didn't have time to work on the selinux thing
18:05:11 <dcavalca> jvreeland: I saw you make the ticket for pbisaacs request
18:05:24 <dcavalca> in general, that looks reasonable to me
18:05:30 <dcavalca> can you invite him to these meetings as well?
18:06:03 <jvreeland> I've invited them to both meetings, though a bit last min this time. Not sure on their timezone.
18:06:35 <dcavalca> yeah, I also need to reschedule this one as it conflicts with Fedora Server
18:06:48 <dcavalca> I was going to do it but then realized it was best to wait for DST to go through
18:07:27 <jvreeland> makes sense. Adding aarch64 seems reasonable to me, i'd be happy to help onboard them regardless. But not sure of the consequences if we enable aarch64 and then abandon it later
18:07:45 <dcavalca> I might push this back to 16 UTC, which would make it 9am PDT
18:08:01 <dcavalca> but I haven't checked for conflicts yet
18:08:18 <dcavalca> yeah, my main concern with aarch64 (and ppc64le) was that we need to have someone committed to making them work
18:08:40 <dcavalca> that's why when we originally made the koji tags I only asked for x86_64
18:09:08 <dcavalca> the way koji works, once an arch is enabled builds have to succeed for it
18:09:14 <dcavalca> otherwise it'll block the package for all arches
18:09:25 <jvreeland> If they make an account on pagure do they need to be a member to comment on that ticket?
18:09:36 <jvreeland> *member of the sig
18:09:52 <dcavalca> I don't think so? that's a good question though
18:10:09 <dcavalca> I can also just add them to the pagure group if that's an issue
18:10:52 <dcavalca> yeah I think everybody can create issues and comment
18:10:57 <jvreeland> Ok, i'll send a follow up email asking them to sign up and comment on that ticket.
18:11:05 <dcavalca> but only SIG members can edit metadata on issues and stuff like that
18:11:10 <dcavalca> thanks jvreeland
18:11:31 <dcavalca> alright, did we have anything else for followups?
18:12:05 <dcavalca> let's move on
18:12:07 <jvreeland> i didn't have time to do further work on the kernel for the sig
18:12:34 <dcavalca> jvreeland: yeah, I still need to come up with a story for the secure boot thing as well
18:12:51 <dcavalca> #topic Announcements
18:13:07 <dcavalca> on my end, I shipped an updated mtr package yesterday
18:13:30 <dcavalca> according to our networking folks the one in CentOS was missing some major features around TCP debugging they needed
18:14:02 <dcavalca> malmond has also started packaging our rpm rebuild with CoW support within the SIG
18:14:11 <dcavalca> but there's still a bunch of work to do there before it's usable
18:14:44 <dcavalca> anything else?
18:15:00 <dcavalca> oh I should tag these for the minutes
18:15:21 <dcavalca> #info pushed updated mtr package to the SIG
18:15:42 <dcavalca> #info malmond started working on rpm CoW packaging
18:15:47 <anitazha> derp i made it. cant believe i was in the wrong channel twice
18:16:05 <dcavalca> lol no worries anitazha
18:16:16 <dcavalca> we were doing announcements
18:16:36 <dcavalca> do we have anything else here?
18:17:15 <dcavalca> alright, let's do
18:17:20 <dcavalca> #topic Tickets
18:17:36 <dcavalca> so, we already talked about #31
18:17:53 <dcavalca> for #27, as I mentioned before, I haven't made much progress with toddlers
18:18:08 <dcavalca> so I might end up setting up a sync task from my end to unblock things for now
18:18:18 <dcavalca> this was the systemd staging git repo for context
18:19:52 <dcavalca> for #23 Neal had offered to help make a selinux module, I'll follow up with him
18:20:18 <dcavalca> jvreeland mentioned before there's no update on the kernel work in #7
18:20:25 <dcavalca> I don't have any update on that on my end either
18:20:46 <dcavalca> for #13, filbranden was going to followup with Cloud SIG, but he just had a kid, so someone else should probably take this up :)
18:22:35 <dcavalca> did I miss anything?
18:22:47 <jvreeland> Doesn't look like it
18:23:09 <dcavalca> alright
18:23:13 <dcavalca> #topic Membership
18:23:36 <dcavalca> do we have anything to discuss for membership?
18:24:35 <dcavalca> looks like a no
18:24:38 <dcavalca> #topic Misc
18:24:52 <dcavalca> so, I have two things I wanted to bring up here
18:25:00 <dcavalca> first is that we need to reschedule this meeting
18:25:15 <dcavalca> would 16 UTC on the same days work for folks?
18:25:30 <dcavalca> (that's 9am PDT)
18:25:32 <jvreeland> works for me
18:26:05 <dcavalca> I would do 17, but that conflicts with the centos office hours once a month, so that doesn't work
18:26:52 <dcavalca> alright, we can always change it later if it turns out to be a problem
18:26:56 <dcavalca> I'll make the PR and post to the list
18:27:01 <dcavalca> #action dcavalca reschedule meeting to 16 UTC
18:27:26 <dcavalca> the other thing I wanted to talk about is release versioning
18:27:35 <dcavalca> this came up while working with malmond on rpm
18:27:53 <dcavalca> for stuff that's a straight import from Fedora, I don't think we need to do anything
18:28:10 <dcavalca> as foo-123-1 will end up as foo-123-1.hs in the SIG, so there's no confusion
18:28:19 <dcavalca> where it gets tricky is if we do make changes
18:28:38 <dcavalca> in that case we can bump release, but that'll get confusing when upstream also bumps release for something unrelated
18:28:50 <dcavalca> so, my suggestion was to append a .N to the release
18:29:14 <dcavalca> so if we take foo-123-1 and make changes to it, in the SIG it goes as foo-123-1.1.hs
18:29:29 <dcavalca> and if we make more changes foo-123-1.2.hs and so on
18:29:36 <dcavalca> does this make sense?
18:30:27 <jvreeland> I think this looks a lot like the minorbump in the version guidlines for fedora, should we use that Release: <pkgrel>%{?dist}[.<minorbump>]
18:30:34 <jvreeland> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_release_and_post_release_versions
18:31:01 <dcavalca> ah, yeah that does look similar
18:31:38 <dcavalca> I think it's probably fine, and if end up doing this for a package that already has a minorbump we can just add an extra .N
18:31:47 <dcavalca> it'll look ugly but I doubt it'd be much of an issue in practice
18:31:54 <jvreeland> sounds good
18:32:08 <dcavalca> alright, I'll try and get this written up then
18:32:27 <dcavalca> #action dcavalca write up release versioning policy as discussed
18:32:32 <dcavalca> that's all I had
18:32:58 <dcavalca> anything else?
18:34:38 <dcavalca> alright, I think this is it
18:34:41 <dcavalca> thanks everyone
18:34:49 <dcavalca> #endmeeting