18:00:37 #startmeeting tc 18:00:37 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:37 The meeting name has been set to 'tc' 18:00:45 #topic Roll Call 18:00:57 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 o/ 18:00:57 o/ 18:00:59 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. 18:01:02 \o 18:01:06 o/ 18:01:18 #info Three noted absenses in the agenda: slaweq, jamespage, spotz 18:02:07 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 o/ 18:04:25 Thanks, that's everyone accounted for 18:04:29 #topic Follow up on tracked action items 18:04:32 we had one; it was mine 18:04:48 #info JayF has signed up to represent the TC at the OpenInfra Live PTG recap show 18:04:57 Moving on. 18:05:06 #topic Gate Health Check 18:05:10 how's the gate? 18:05:59 have not checked much this week. but did not hear about any frequent failure. 18:06:04 kinda medium I think.. not too bad 18:06:31 nothing specific from me this week 18:06:34 keep in mind there's an upcoming gerrit outage on friday 18:06:36 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 gerrit 3.8 upgrade starting at 15:30 utc friday 18:07:03 #info fungi notes there is a upcoming Gerrit outage on Friday, upgrade to 3.8 starting 1530 UTC Friday 18:07:21 JayF: yeah 18:07:35 #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 indeed 18:07:46 Thanks for linking the full details into the minutes fungi. 18:07:51 yw 18:08:05 Is there anything else on gate health before moving on? 18:09:04 (not from me) 18:09:05 #topic Leaderless Projects 18:09:08 #link https://etherpad.opendev.org/p/2024.1-leaderless 18:09:34 I strongly encourage all tc-members, please go vote on these PTL appointments, one way or another 18:09:39 not much update other than ask for review on open reviews. links are there in etherpad. 18:09:41 yeah 18:09:50 #link https://review.opendev.org/q/status:open+repo:openstack/governance 18:10:01 I am going to send email to remaining projects who have not proposed PTL appointment yet but volunteer to be 18:10:39 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 what about openstack-chef? did we agree to just retire it? 18:11:14 No proposal has been made to governance to retire it 18:11:23 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 It looks like that is the consensus in the etherpad 18:11:32 I will check that too 18:11:37 gmann: lance has a +1 to retirement in the etherpad 18:12:05 you can also contact him as Ramereth in #opendev 18:12:06 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 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 frickler: thanks 18:12:44 ack; his comment specifically says "I am okay with retirement" so I took it at face value 18:13:03 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 how about rally? how we want to proceed? 18:13:28 discussion going on in gerrit but we should conclude that too 18:13:48 #link https://review.opendev.org/c/openstack/governance/+/898228 18:14:16 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 Having these six month check ins with us is doing them more harm than good in many cases, I suspect. 18:15:18 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 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 s/can/cannot/ 18:16:47 Anything else before moving on? 18:16:48 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 nothing else from me, I will do remaining work we discussed today. 18:17:28 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 and there's no concrete proposal to how to fix it 18:17:48 yeah, we have many such projects 18:17:56 Something to think about :) 18:18:03 going to move on 18:18:08 #topic Implementation of Unmaintained branch statuses 18:18:15 rosmaita: you so kindly have been leading this up, how are things? 18:18:23 #link https://etherpad.opendev.org/p/early-caracal-unmaintained-transition 18:18:35 i think all the info is on the etherpad 18:18:58 i reached out to the release team, and they left comments 18:19:00 #info tc-members should read etherpad, comment asyncronously on how to adjudicate unmaintained branch transition 18:19:19 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 thanks rosmaita , did not read etherpad yet but will do today or tomorrow 18:19:26 well, we should probably make the decision soon, though 18:19:46 knikolla: there's an impact on the patch you have up 18:20:12 also we're probably overdue for an update/summary to openstack-discuss 18:20:15 i think we should probably discuss item #3, numbers 1 and 2 are pretty self-explanatory 18:20:45 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 fungi: ++ 18:21:16 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 so the thing with item #3 is we need to determine both what and how 18:21:25 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 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 Although I concur with dansmith I'd rather not have +2 on such branches personally. 18:22:19 is there way to only give member managing power and no +2/A ? 18:22:36 fungi: ^^ 18:22:46 I thought it was asserted so 18:22:48 yes, but then the groups are not self-managed 18:22:48 we could probably do a trick with an extra group that is the owner of the unmaintained-core groups 18:23:15 put the unmaintained-core groups and the tc in the owner group. sort of circular but i think it could work 18:23:19 but owner still can +2 right? 18:23:27 that extra group could be tc-members, which already exists, just under a different name 18:23:37 group owner does not get the permissions conveyed by group membership, only the ability to manage the group 18:23:53 fungi: great. 18:23:57 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 frickler: well, then the unmaintained-core group members would be unable to also manage the unmaintained-core groups 18:24:33 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 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 ++ 18:25:04 ah, double indirection, o.k. 18:25:19 sort of messy but i think it would do what folks want, more or less 18:25:40 i think so ... we just need to be able to add people to the groups who can actually approve stuff 18:25:58 Do we have any people who have volunteered to be in that group as of now? 18:26:10 it's per-project and branch right/ 18:26:30 I think yes per project per branch 18:26:32 only per-project I'd say 18:26:49 per project+per branch is a huge matrix and a lot of work when branches cycle around 18:26:59 well, it has to be restricted to unmaintained/* 18:27:09 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 yes, only per project restricted to unmaintained/* 18:27:13 ++ 18:27:14 else you'd need to update ACLs every cycle and get a huge set of old groups 18:27:58 iiuc elodilles has implicitly volunteered 18:28:00 ok per project should be enough then, people can choose not to review any specific branch they do not volutneer for 18:28:33 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 at one point there was discussion about an openstack-wide group, or are we still agreed on per-project groups? 18:28:51 (same question as fungi) 18:29:08 Why do we need a universal answer, and why do we need it now? 18:29:20 Having a single openstack wide group to start -> easy, simple, gets it going. 18:29:21 it's not like they can break much, these branches are already unmaintained ;) 18:29:21 because we need to patch all the gerrit acl files 18:29:21 per project is needed as having +2 power on cross project is something we discussed not to give. 18:29:30 If we get a single large project with a lot of unmaintained, maybe they split off into their own 18:29:35 we need to set up the ACLs before we create the unmaintained branches 18:29:45 we can start simple and add complexity as the need for it reveals itself, yeah? 18:30:09 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 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 well, the "simple" move is per-project, which means creating a shit-ton of groups 18:30:27 knikolla++ good callback reading what we actually merged 18:30:31 yeah, I remember we discussed both option and agreed to go for per project in resolution 18:30:41 rosmaita: or just create them as needed? 18:30:57 i think they are all needed? 18:30:59 a bunch of projects will likely not opt (or not even answer) to keeping some in unmaintained 18:31:00 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 all will be needed considering the default opt-in no? 18:31:12 of 1 cycle 18:31:12 fungi: ++ 18:31:32 that's what i'm getting at 18:31:33 knikolla: but if nothing ever gets proposed there, then there's no need for a group 18:31:35 as that group is not per branch so that group will be one time thing per project 18:31:52 JIT groups 18:31:53 dansmith: but there is default opt-in for one SLURP right? 18:32:03 and for that we need group? 18:32:13 gmann: only if there are patches to review 18:32:25 I think the safer way is to pre-create the groups, otherwise we have to keep monitoring patches 18:32:32 exactly 18:32:37 just saying, we shouldn't make work for ourselves. if pre-creating the groups is easy, then fine 18:32:40 but i like fungi's idea even better 18:32:49 yeah, pre-creation is easy than having request and checks reviews 18:32:59 because we won't have to individually patch each project's acl files 18:33:00 We have to amend the resolution if we implement fungi's idea. 18:33:12 i don't see a problem with that 18:33:17 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 i mean, we haven't actually done any work yet 18:33:29 We have changes in governance that don't have a majority of TC votes on them after multiple weeks :) 18:34:02 issue with that is nova unmaitained maintainers should not merge ironic/neutron changes which are maintained by some other memebres 18:34:26 why exactly? 18:34:27 gmann: i used to think so too, but i think we are going to have to trust the unmaintained-maintainers 18:34:33 i mean, first, would they want to? 18:34:37 there just aren't enough people around 18:35:06 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 plus, they can always ask for reviews from the project team for a really complicated backport or something 18:35:22 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 ok, well we can have it both ways 18:35:31 1 - openstack-wide groupt 18:35:34 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 2 - projects that want to restrict can merge their own change to their gerrit acl files 18:35:54 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 I know implementation is little exra work per project group but that is one time things and provide good valye 18:36:31 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 Does someone want to take the action to propose the amended resolution? 18:36:56 dansmith: ++ 18:37:00 i can do it 18:37:07 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 it needs to sit a week, right? 18:37:28 #action rosmaita to propose amendment to unmaintained branch resolution allowing a global openstack unmaintained-core group 18:37:34 rosmaita: yes, at least. 18:37:41 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 wide* 18:37:48 fungi: am i correct that a change to cinder.config acl file will override the meta group change? 18:37:51 week after the last change not proposed one 18:38:45 JayF: also give me the action item to send the summary email 18:39:01 i will mention the resolution change so we can get more comments 18:39:23 #action rosmaita to send email to list summarizing status of implementation of unmaintained branch 18:39:25 alright; going to move on 18:39:25 awesome 18:39:37 #topic 2024.1 TC Tracker 18:39:40 #link https://etherpad.opendev.org/p/tc-2024.1-tracker 18:39:41 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 fungi: thanks 18:40:03 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 If anyone wants to tackle one of those; awesome. 18:41:07 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 If anything, bring it up now, otherwise going to move on. 18:42:13 #topic Open Discussion and Reviews 18:42:37 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 I'm going to take a pass before my EOD today to merge anything else that is mergable. 18:43:32 Also, relating to holidays: I will be out of town, unavailable next week. 18:43:51 Traditionally TC cancels the American Thanksgiving week meeting; I'd like to do that again barring objection. 18:44:03 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 JayF: ++ to cancel 18:44:29 next week meeting right ? 18:44:32 aye 18:44:36 ++ on canceling  next weeks meeting 18:44:37 k 18:44:43 I'll email about it after the meeting. 18:44:52 i am available, but am happy for you to cancel the meeting 18:44:55 does anyone know the answer for rosmaita's question? 18:45:04 I assumed a patch; but it's a worthy question 18:45:05 Rosmaita: i think it would be a new resolution 18:45:34 yeah, we add new one to update any policy already appoved 18:45:34 knikolla: i'm thinking that's right 18:45:43 ok, great 18:45:48 thanks! 18:46:02 #info TC Meeting next week to be cancelled for American Thanksgiving week 18:46:20 Is there anything else for open discussion? 18:48:26 #endmeeting