18:00:37 <JayF> #startmeeting tc
18:00:37 <opendevmeet> Meeting started Tue Nov 14 18:00:37 2023 UTC and is due to finish in 60 minutes.  The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:37 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:37 <opendevmeet> The meeting name has been set to 'tc'
18:00:45 <JayF> #topic Roll Call
18:00:57 <JayF> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct.
18:00:57 <gmann> o/
18:00:57 <dansmith> o/
18:00:59 <JayF> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee.
18:01:02 <frickler> \o
18:01:06 <rosmaita> o/
18:01:18 <JayF> #info Three noted absenses in the agenda: slaweq, jamespage, spotz
18:02:07 <JayF> Going to give until 5 after the hour for remaining TC members to arrive.
18:02:47 * rosmaita sneaks upstairs to refresh my coffee
18:04:14 <knikolla> o/
18:04:25 <JayF> Thanks, that's everyone accounted for
18:04:29 <JayF> #topic Follow up on tracked action items
18:04:32 <JayF> we had one; it was mine
18:04:48 <JayF> #info JayF has signed up to represent the TC at the OpenInfra Live PTG recap show
18:04:57 <JayF> Moving on.
18:05:06 <JayF> #topic Gate Health Check
18:05:10 <JayF> how's the gate?
18:05:59 <gmann> have not checked much this week. but did not hear about any frequent failure.
18:06:04 <dansmith> kinda medium I think.. not too bad
18:06:31 <dansmith> nothing specific from me this week
18:06:34 <fungi> keep in mind there's an upcoming gerrit outage on friday
18:06:36 <JayF> I'll note we had some comments in here earlier about some requirements cross jobs causing some pain for that team; but I think that is not the gate being tempermental, but a project being straight-broken.
18:06:52 <fungi> gerrit 3.8 upgrade starting at 15:30 utc friday
18:07:03 <JayF> #info fungi notes there is a upcoming Gerrit outage on Friday, upgrade to 3.8 starting 1530 UTC Friday
18:07:21 <gmann> JayF: yeah
18:07:35 <fungi> #link https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/thread/XT26HFG2FOZL3UHZVLXCCANDZ3TJZM7Q/ Upgrading review.opendev.org to Gerrit 3.8 on November 17, 2023
18:07:46 <dansmith> indeed
18:07:46 <JayF> Thanks for linking the full details into the minutes fungi.
18:07:51 <fungi> yw
18:08:05 <JayF> Is there anything else on gate health before moving on?
18:09:04 <dansmith> (not from me)
18:09:05 <JayF> #topic Leaderless Projects
18:09:08 <JayF> #link https://etherpad.opendev.org/p/2024.1-leaderless
18:09:34 <JayF> I strongly encourage all tc-members, please go vote on these PTL appointments, one way or another
18:09:39 <gmann> not much update other than ask for review on open reviews. links are there in etherpad.
18:09:41 <gmann> yeah
18:09:50 <JayF> #link https://review.opendev.org/q/status:open+repo:openstack/governance
18:10:01 <gmann> I am going to send email to remaining projects who have not proposed PTL appointment yet but volunteer to be
18:10:39 <JayF> Sounds good. We should probably be prepared to mark most of these inactive and have them miss the release, given we're already past milestone-1
18:10:48 <frickler> what about openstack-chef? did we agree to just retire it?
18:11:14 <JayF> No proposal has been made to governance to retire it
18:11:23 <gmann> frickler: not yet. I will check with Lance if they are ok with retirement or Inactive (if want to give some time if anyone shows up)
18:11:31 <JayF> It looks like that is the consensus in the etherpad
18:11:32 <gmann> I will check that too
18:11:37 <JayF> gmann: lance has a +1 to retirement in the etherpad
18:12:05 <frickler> you can also contact him as Ramereth in #opendev
18:12:06 <fungi> yes, lance spoke up in the discussion and said to retire it if there's nobody else interested in taking it on
18:12:11 <gmann> JayF: but we did not discuss about Inactive state for that. lance comment was before PTG where we discussed about Inactive state path
18:12:37 <gmann> frickler: thanks
18:12:44 <JayF> ack; his comment specifically says "I am okay with retirement" so I took it at face value
18:13:03 <JayF> In any event, sounds like it's close enough that a governance change might be the better place to get definitive feedback, but I'll leave that in your capable hands :)
18:13:12 <gmann> how about rally? how we want to proceed?
18:13:28 <gmann> discussion going on in gerrit but we should conclude that too
18:13:48 <gmann> #link https://review.opendev.org/c/openstack/governance/+/898228
18:14:16 <JayF> Yeah, I think gerrit is a good place to have that discussion. For some of these projects I do think we should have real converstations with interested parties about offboarding them from openstack governance.
18:14:28 <JayF> Having these six month check ins with us is doing them more harm than good in many cases, I suspect.
18:15:18 <gmann> k, moving rally will have more work as we need to update many jobs too but I am ok to continue discuss in gerrit
18:15:49 <JayF> Yeah, if we need it for other jobs we need to help them keep it running :) We can depend on it and have it held up by one very brave tired human :D
18:15:57 <JayF> s/can/cannot/
18:16:47 <JayF> Anything else before moving on?
18:16:48 <gmann> if they want to do I am ok but if we are just moving because of election thing it is not required I feel
18:17:03 <gmann> nothing else from me, I will do remaining work we discussed today.
18:17:28 <JayF> Yeah; there is just a clear "miss" here in OpenStack governance where like, one-person and/or feature-complete projects don't have a great place in our model
18:17:36 <JayF> and there's no concrete proposal to how to fix it
18:17:48 <gmann> yeah, we have many such projects
18:17:56 <JayF> Something to think about :)
18:18:03 <JayF> going to move on
18:18:08 <JayF> #topic  Implementation of Unmaintained branch statuses
18:18:15 <JayF> rosmaita: you so kindly have been leading this up, how are things?
18:18:23 <JayF> #link https://etherpad.opendev.org/p/early-caracal-unmaintained-transition
18:18:35 <rosmaita> i think all the info is on the etherpad
18:18:58 <rosmaita> i reached out to the release team, and they left comments
18:19:00 <JayF> #info tc-members should read etherpad, comment asyncronously on how to adjudicate unmaintained branch transition
18:19:19 <JayF> I'm all for an async, etherpad-first process, that sounds great to me. Anything we wanna discuss sync in the meeting before we skip ahead to the next topic?
18:19:25 <gmann> thanks rosmaita , did not read etherpad yet but will do today or tomorrow
18:19:26 <rosmaita> well, we should probably make the decision soon, though
18:19:46 <rosmaita> knikolla: there's an impact on the patch you have up
18:20:12 <fungi> also we're probably overdue for an update/summary to openstack-discuss
18:20:15 <rosmaita> i think we should probably discuss item #3, numbers 1 and 2 are pretty self-explanatory
18:20:45 <fungi> it's been a while since the resolution about this passed, and we ought to keep it fresh in people's minds that these branches will be going away sooner than they're used to
18:20:54 <rosmaita> fungi: ++
18:21:16 <JayF> Maybe send the email drafted in there, but be clear about the places there are still open questions we're figuring out?
18:21:19 <rosmaita> so the thing with item #3 is we need to determine both what and how
18:21:25 <dansmith> I'm pretty unconcerned with the details of the communication, as well as the details of the groups.. I'd prefer TC for managing membership in a vacuum, but no +2 rights just to make the expectation clear
18:21:58 <JayF> That sounds OK to me; but I do think given we're setting up a system for 'the community' to use; asking them how they wanna interact with it is a reasonable middle step.
18:22:12 <JayF> Although I concur with dansmith I'd rather not have +2 on such branches personally.
18:22:19 <gmann> is there way to only give member managing power and no +2/A ?
18:22:36 <rosmaita> fungi: ^^
18:22:46 <dansmith> I thought it was asserted so
18:22:48 <frickler> yes, but then the groups are not self-managed
18:22:48 <fungi> we could probably do a trick with an extra group that is the owner of the unmaintained-core groups
18:23:15 <fungi> put the unmaintained-core groups and the tc in the owner group. sort of circular but i think it could work
18:23:19 <gmann> but owner still can +2 right?
18:23:27 <frickler> that extra group could be tc-members, which already exists, just under a different name
18:23:37 <fungi> group owner does not get the permissions conveyed by group membership, only the ability to manage the group
18:23:53 <gmann> fungi: great.
18:23:57 <dansmith> it's not critical that we be barred from +2 I just think it'd be the tidy-est way to communicate we can't be pinged for reviews :)
18:24:05 <fungi> frickler: well, then the unmaintained-core group members would be unable to also manage the unmaintained-core groups
18:24:33 <fungi> the idea is for yet another group that is the owner, and then put the group itself and also the tc-members group in the owner group
18:24:37 <gmann> yeah we need them also continue managing member and TC in the saituation where there is no one to add new member
18:25:02 <gmann> ++
18:25:04 <frickler> ah, double indirection, o.k.
18:25:19 <fungi> sort of messy but i think it would do what folks want, more or less
18:25:40 <rosmaita> i think so ... we just need to be able to add people to the groups who can actually approve stuff
18:25:58 <JayF> Do we have any people who have volunteered to be in that group as of now?
18:26:10 <dansmith> it's per-project and branch right/
18:26:30 <gmann> I think yes per project per branch
18:26:32 <frickler> only per-project I'd say
18:26:49 <JayF> per project+per branch is a huge matrix and a lot of work when branches cycle around
18:26:59 <rosmaita> well, it has to be restricted to unmaintained/*
18:27:09 <dansmith> I though it was per project and branch because some people care about a given release, but whatever, doesn't matter that much to me
18:27:10 <knikolla> yes, only per project restricted to unmaintained/*
18:27:13 <JayF> ++
18:27:14 <frickler> else you'd need to update ACLs every cycle and get a huge set of old groups
18:27:58 <frickler> iiuc elodilles has implicitly volunteered
18:28:00 <gmann> ok per project should be enough then, people can choose not to review any specific branch they do not volutneer for
18:28:33 <fungi> does it absolutely need to be per-project even? i wonder if just one unmaintained-core group would work out, with sufficient trust in people
18:28:39 <rosmaita> at one point there was discussion about an openstack-wide group, or are we still agreed on per-project groups?
18:28:51 <rosmaita> (same question as fungi)
18:29:08 <JayF> Why do we need a universal answer, and why do we need it now?
18:29:20 <JayF> Having a single openstack wide group to start -> easy, simple, gets it going.
18:29:21 <fungi> it's not like they can break much, these branches are already unmaintained ;)
18:29:21 <rosmaita> because we need to patch all the gerrit acl files
18:29:21 <gmann> per project is needed as having +2 power on cross project is something we discussed not to give.
18:29:30 <JayF> If we get a single large project with a lot of unmaintained, maybe they split off into their own
18:29:35 <frickler> we need to set up the ACLs before we create the unmaintained branches
18:29:45 <JayF> we can start simple and add complexity as the need for it reveals itself, yeah?
18:30:09 <knikolla> the resolution as written specifies per project groups, but if we see value in openstack-wide groups we can make a new resolution to create those
18:30:15 <fungi> technically we could set up the acls after creating the branches, but nobody from the volunteer pool will be able to approve anything until acls are updated
18:30:17 <rosmaita> well, the "simple" move is per-project, which means creating a shit-ton of groups
18:30:27 <JayF> knikolla++ good callback reading what we actually merged
18:30:31 <gmann> yeah, I remember we discussed both option and agreed to go for per project in resolution
18:30:41 <dansmith> rosmaita: or just create them as needed?
18:30:57 <rosmaita> i think they are all needed?
18:30:59 <dansmith> a bunch of projects will likely not opt (or not even answer) to keeping some in unmaintained
18:31:00 <fungi> note that if the idea of project-specific unmaintained-core groups is tossed out, a single openstack-unmaintained-core group could just be added to the openstack meta acl inherited by all openstack projects
18:31:08 <knikolla> all will be needed considering the default opt-in no?
18:31:12 <knikolla> of 1 cycle
18:31:12 <rosmaita> fungi: ++
18:31:32 <rosmaita> that's what i'm getting at
18:31:33 <dansmith> knikolla: but if nothing ever gets proposed there, then there's no need for a group
18:31:35 <gmann> as that group is not per branch so that group will be one time thing per project
18:31:52 <knikolla> JIT groups
18:31:53 <gmann> dansmith: but there is default opt-in for one SLURP right?
18:32:03 <gmann> and for that we need group?
18:32:13 <dansmith> gmann: only if there are patches to review
18:32:25 <knikolla> I think the safer way is to pre-create the groups, otherwise we have to keep monitoring patches
18:32:32 <rosmaita> exactly
18:32:37 <dansmith> just saying, we shouldn't make work for ourselves. if pre-creating the groups is easy, then fine
18:32:40 <rosmaita> but i like fungi's idea even better
18:32:49 <gmann> yeah, pre-creation is easy than having request and checks reviews
18:32:59 <rosmaita> because we won't have to individually patch each project's acl files
18:33:00 <JayF> We have to amend the resolution if we implement fungi's idea.
18:33:12 <rosmaita> i don't see a problem with that
18:33:17 <JayF> Which is a heck of a lot easier than patching the acl files, but it means we'll have to ensure we vote on that so it can land.
18:33:24 <rosmaita> i mean, we haven't actually done any work yet
18:33:29 <JayF> We have changes in governance that don't have a majority of TC votes on them after multiple weeks :)
18:34:02 <gmann> issue with that is nova unmaitained maintainers should not merge ironic/neutron changes which are maintained by some other memebres
18:34:26 <fungi> why exactly?
18:34:27 <rosmaita> gmann: i used to think so too, but i think we are going to have to trust the unmaintained-maintainers
18:34:33 <fungi> i mean, first, would they want to?
18:34:37 <rosmaita> there just aren't enough people around
18:35:06 <gmann> not for all projects, a few of them might want to maintain some projects and also want some way that other members cannot merge things in their maintained projects
18:35:07 <rosmaita> plus, they can always ask for reviews from the project team for a really complicated backport or something
18:35:22 <fungi> also, what exactly is it protecting against? if someone with insufficient understanding of neutron approves a change for its unmaintained/yoga branch and it causes a problem, someone else can propose and approve a revert of that too
18:35:24 <rosmaita> ok, well we can have it both ways
18:35:31 <rosmaita> 1 - openstack-wide groupt
18:35:34 <gmann> in single group members can be added say I want to maintain project x but get power to merge things in ohter projects maintained by someone else
18:35:50 <rosmaita> 2 - projects that want to restrict can merge their own change to their gerrit acl files
18:35:54 <JayF> fungi++ that mostly reflects my thoughts. The risk, with no releases, is minimal if someone is trusted to merge code in any openstack project (trust against non-maliciousness)
18:36:01 <gmann> I know implementation is little exra work per project group but that is one time things and provide good valye
18:36:31 <dansmith> I definitely lean towards "this is all low-confidence stuff so do whatever is easiest for us" .. if a single group that can do whatever they want to break unmaintained stuff is easiest, then let's do that until we have evidence that it's a problem
18:36:49 <JayF> Does someone want to take the action to propose the amended resolution?
18:36:56 <rosmaita> dansmith: ++
18:37:00 <rosmaita> i can do it
18:37:07 <fungi> well, it's not a little extra work, it's patching every single gerrit acl for openstack projects. but it's hopefully only done once (and copied to any new acls that get added in the future)
18:37:11 <rosmaita> it needs to sit a week, right?
18:37:28 <JayF> #action rosmaita to propose amendment to unmaintained branch resolution allowing a global openstack unmaintained-core group
18:37:34 <JayF> rosmaita: yes, at least.
18:37:41 <knikolla> i think i like the openstack-side solution as it creation an additional layer of separation between project teams and unmaintained branches
18:37:48 <knikolla> wide*
18:37:48 <rosmaita> fungi: am i correct that a change to cinder.config acl file will override the meta group change?
18:37:51 <gmann> week after the last change not proposed one
18:38:45 <rosmaita> JayF: also give me the action item to send the summary email
18:39:01 <rosmaita> i will mention the resolution change so we can get more comments
18:39:23 <JayF> #action rosmaita to send email to list summarizing status of implementation of unmaintained branch
18:39:25 <JayF> alright; going to move on
18:39:25 <knikolla> awesome
18:39:37 <JayF> #topic 2024.1 TC Tracker
18:39:40 <JayF> #link https://etherpad.opendev.org/p/tc-2024.1-tracker
18:39:41 <fungi> rosmaita: yes, it can (you have to set an extra option in that section in the cinder acl but it's doable)
18:39:50 <rosmaita> fungi: thanks
18:40:03 <JayF> TC tracker items are setup now, there are some items at the top I pulled as potential action items from the vPTG
18:40:35 <JayF> If anyone wants to tackle one of those; awesome.
18:41:07 <JayF> And in the future, if there are updates to any of your tracked TC tracker tasks, we'd talk about them here
18:41:17 <JayF> If anything, bring it up now, otherwise going to move on.
18:42:13 <JayF> #topic Open Discussion and Reviews
18:42:37 <JayF> Please take a look at governance reviews. There's a lot of stuff that is technically mergable but only has votes from 3-4 TC members. I'd prefer a majority of us look at things.
18:42:50 <JayF> I'm going to take a pass before my EOD today to merge anything else that is mergable.
18:43:32 <JayF> Also, relating to holidays: I will be out of town, unavailable next week.
18:43:51 <JayF> Traditionally TC cancels the American Thanksgiving week meeting; I'd like to do that again barring objection.
18:44:03 <rosmaita> i have a dumb question ... to amend a resolution, do I patch the  resolution, or propose a new resolution that supersedes the original resolution?
18:44:19 <dansmith> JayF: ++ to cancel
18:44:29 <gmann> next week meeting right ?
18:44:32 <JayF> aye
18:44:36 <knikolla> ++ on canceling  next weeks meeting
18:44:37 <gmann> k
18:44:43 <JayF> I'll email about it after the meeting.
18:44:52 <rosmaita> i am available, but am happy for you to cancel the meeting
18:44:55 <JayF> does anyone know the answer for rosmaita's question?
18:45:04 <JayF> I assumed a patch; but it's a worthy question
18:45:05 <knikolla> Rosmaita: i think it would be a new resolution
18:45:34 <gmann> yeah, we add new one to update any policy already appoved
18:45:34 <rosmaita> knikolla: i'm thinking that's right
18:45:43 <rosmaita> ok, great
18:45:48 <rosmaita> thanks!
18:46:02 <JayF> #info TC Meeting next week to be cancelled for American Thanksgiving week
18:46:20 <JayF> Is there anything else for open discussion?
18:48:26 <JayF> #endmeeting