| tkajinam | for your awareness... it seems unit tests in zaqar has been broken since 2023.2 release because it still relies on the oslo.db test base classes which were removed during the previous cycle. | 14:17 |
|---|---|---|
| tkajinam | I've raised this in the zaqar chennel but I don't see anyone working in the project there. I'm a kind of skeptical about its status tbvh | 14:17 |
| tkajinam | reference: https://review.opendev.org/c/openstack/zaqar/+/895349 | 14:17 |
| tkajinam | in addition to zaqar, sahara looks quite unhealthy, seeing tons of the automated patches still open in https://review.opendev.org/q/topic:create-2023.2 | 14:19 |
| tkajinam | there is a patch which fixed master gate but in fact they just made all broken functional jobs non-voting https://review.opendev.org/c/openstack/sahara/+/900128 :-( | 14:19 |
| tosky | can we just archive sahara? I should just drop my (leftover) +2 power on there | 14:21 |
| tosky | whoever took it didn't really move it forwared - but I raised this two PTGs ago | 14:22 |
| tkajinam | tosky, yeah I agree with you. I'm posting it here to ask some thoughts from TC because to move the discussion again. I know the person stepped up to keep the project but for me it does not look like it's properly kept or maintained. | 14:24 |
| tkajinam | * I know that the person stepped up | 14:24 |
| fungi | this is definitely the time in the development cycle to identify inactive projects, we basically have until the first week of january to let the release team know what projects will be included in the 2024.1 coordinated release | 14:34 |
| fungi | for any project whose usability is in question, unless its maintainers can get it into shape in the next two months, it really should be dropped from release plans (doesn't mean it has to be retired immediately, but we want to avoid making promises we can't keep about what will be in the next release) | 14:36 |
| fungi | we're already at the first cycle milestone this week | 14:38 |
| *** dtantsur_ is now known as dtantsur | 14:51 | |
| tkajinam | fungi, ok. then these two are very likely to be candidate for removal from the release... | 15:16 |
| tkajinam | we may have to check status of all projects at that point, but I'm wondering if TC can start early discussion about these two projects, because these two are apparently in bad shape now. earlier discussion may help people who is willing to maintain the project in a right way because of some effort needed to fix CIs | 15:17 |
| JayF | Those are both projects that are leaderless: http://etherpad.opendev.org/p/2024.1-leaderless | 15:17 |
| JayF | Sahara has a proposal up to mark it inactive: https://review.opendev.org/c/openstack/governance/+/899986 -- this means if the issues identified aren't resolved by milestone 2 (about two months), they'll be excluded from the next release. | 15:18 |
| fungi | tkajinam: so sounds like a similar change should be proposed for zaqar? | 15:18 |
| JayF | Zaqar has a leader; and is not on our radar for activity at the moment. | 15:19 |
| JayF | I would strongly suggest taking these observations to the mailing list. | 15:19 |
| fungi | ah, i must have misunderstood what you meant by "both" (zaqar and sahara where the two mentioned in this conversation) | 15:20 |
| tkajinam | ok so sahara is already under the way for removal... then I'll send an email to share the current observation about zaqar | 15:20 |
| JayF | tkajinam: To be clear; inactive is not removal; but it's sorta like a "yellow light" for people interested in that project to step up | 15:21 |
| JayF | tkajinam: because if not it will be | 15:21 |
| tkajinam | JayF, you mean the inactive project is still "kept" but no release will be made for it, is that right ? | 15:22 |
| JayF | That is the default state, yes. Then, as a separate action, we can retire the project if we think that's the right action. I can't speak for the whole TC but generally I think we'd look for fixed CI and a committment to keep it working over more than a few-week period. | 15:23 |
| tkajinam | OK. I understood | 15:24 |
| jamespage | JayF: hey - I find myself yet again in a position of having to send my apologies for the TC meeting - I've had a somewhat disrupted month due to accidents/work travel | 15:27 |
| jamespage | hopefully back to someone normal from next week | 15:28 |
| jamespage | wiki updated | 15:28 |
| JayF | Hey, take care of yourself and make your way home safely | 15:28 |
| jamespage | ta | 15:29 |
| frickler | we should also look at masakari, maybe they just need help, but the reqs cross job is failing since the release | 15:48 |
| tkajinam | I'd not strongly insist on this as long as people are around helping the project but I feel like the project is inactive seeing no meaningful update for some time. https://review.opendev.org/q/project:openstack%252Fmasakari | 15:57 |
| tkajinam | I saw they earlier requested help about sqla-2, and it seems Stephen is working on it, though. | 15:57 |
| JayF | tkajinam: that's basically the weird spot we find ourselves in for many of these projects | 15:57 |
| JayF | there are clearly people interested, when we engage about specific issues they often react | 15:58 |
| JayF | but there are 9 TC members, and dozens of projects | 15:58 |
| JayF | It's not sustainable for us to go check on everyone to ensure their CI is working and the like | 15:58 |
| JayF | I'm not sure how to get projects like that to ... healthcheck and do needed fixes independently, but that's a real concern | 15:58 |
| tkajinam | yeah I understand it. that's why I report my observations and concerns here. | 15:59 |
| tkajinam | I agree it's not feasible to monitor and ensure all projects are in good shape but we can start discussions about projects with suspects if we find any... | 16:00 |
| slaweq | JayF hi, just a heads up that I will not be able to attend today's TC meeting - I added my name in the absence section in the wiki page already | 16:01 |
| JayF | thanks for the heads up o/ | 16:02 |
| dansmith | JayF: I was going to wait for the open discussion to mention this, but since slaweq opened the door: | 16:57 |
| dansmith | I'm going to be out for at least all of december, as well as next week. I should be here for the meeting the week after thanksgiving, but just FYI | 16:57 |
| JayF | I'll be out next week as well, but historically we cancelled the meeting for next week -- I was going to propose that. | 16:58 |
| dansmith | yup | 16:58 |
| JayF | I should be here most of December; maybe out around new years (my travel home to visit family is next week; but I have a friend coming into town around New Years' for the Winter Classic here in Seattle) | 16:58 |
| dansmith | well, I have use-or-lose PTO and I haven't used hardly any of it, so... | 16:59 |
| JayF | Go volunteer some time in a well-deserving open source project for a month! I hear eventlet is very welcoming to volunteers /s :D | 17:01 |
| gmann | tkajinam: thanks for brining it. taking it on ML and see if changes are not reviewed will show the actual state of projects. Even someone volunteer for PTL, we can still mark project Inactive based on how projects activities are. | 17:06 |
| tkajinam | gmann, that makes sense | 17:10 |
| tkajinam | gmann, I personally think sqlalchemy 2.x would be killing multiple projects and we may see how many projects are really maintained at that time. We probably have to check CI status of all projects after bump is made in requirements | 17:11 |
| tkajinam | (which I think we discussed quickly at Vancouver | 17:11 |
| JayF | tc-members meeting in 8 minutes; sorry I missed the 1 hour warning I usually try to give | 17:53 |
| gmann | tkajinam: ++ | 18:00 |
| JayF | #startmeeting tc | 18:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
| opendevmeet | The meeting name has been set to 'tc' | 18:00 |
| JayF | #topic Roll Call | 18:00 |
| 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 |
| gmann | o/ | 18:00 |
| dansmith | o/ | 18:00 |
| JayF | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. | 18:00 |
| frickler | \o | 18:01 |
| rosmaita | o/ | 18:01 |
| JayF | #info Three noted absenses in the agenda: slaweq, jamespage, spotz | 18:01 |
| JayF | Going to give until 5 after the hour for remaining TC members to arrive. | 18:02 |
| * rosmaita sneaks upstairs to refresh my coffee | 18:02 | |
| knikolla | o/ | 18:04 |
| JayF | Thanks, that's everyone accounted for | 18:04 |
| JayF | #topic Follow up on tracked action items | 18:04 |
| JayF | we had one; it was mine | 18:04 |
| JayF | #info JayF has signed up to represent the TC at the OpenInfra Live PTG recap show | 18:04 |
| JayF | Moving on. | 18:04 |
| JayF | #topic Gate Health Check | 18:05 |
| JayF | how's the gate? | 18:05 |
| gmann | have not checked much this week. but did not hear about any frequent failure. | 18:05 |
| dansmith | kinda medium I think.. not too bad | 18:06 |
| dansmith | nothing specific from me this week | 18:06 |
| fungi | keep in mind there's an upcoming gerrit outage on friday | 18:06 |
| 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 |
| fungi | gerrit 3.8 upgrade starting at 15:30 utc friday | 18:06 |
| JayF | #info fungi notes there is a upcoming Gerrit outage on Friday, upgrade to 3.8 starting 1530 UTC Friday | 18:07 |
| gmann | JayF: yeah | 18:07 |
| 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 |
| dansmith | indeed | 18:07 |
| JayF | Thanks for linking the full details into the minutes fungi. | 18:07 |
| fungi | yw | 18:07 |
| JayF | Is there anything else on gate health before moving on? | 18:08 |
| dansmith | (not from me) | 18:09 |
| JayF | #topic Leaderless Projects | 18:09 |
| JayF | #link https://etherpad.opendev.org/p/2024.1-leaderless | 18:09 |
| JayF | I strongly encourage all tc-members, please go vote on these PTL appointments, one way or another | 18:09 |
| gmann | not much update other than ask for review on open reviews. links are there in etherpad. | 18:09 |
| gmann | yeah | 18:09 |
| JayF | #link https://review.opendev.org/q/status:open+repo:openstack/governance | 18:09 |
| gmann | I am going to send email to remaining projects who have not proposed PTL appointment yet but volunteer to be | 18:10 |
| 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 |
| frickler | what about openstack-chef? did we agree to just retire it? | 18:10 |
| JayF | No proposal has been made to governance to retire it | 18:11 |
| 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 |
| JayF | It looks like that is the consensus in the etherpad | 18:11 |
| gmann | I will check that too | 18:11 |
| JayF | gmann: lance has a +1 to retirement in the etherpad | 18:11 |
| frickler | you can also contact him as Ramereth in #opendev | 18:12 |
| 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 |
| 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 |
| gmann | frickler: thanks | 18:12 |
| JayF | ack; his comment specifically says "I am okay with retirement" so I took it at face value | 18:12 |
| 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 |
| gmann | how about rally? how we want to proceed? | 18:13 |
| gmann | discussion going on in gerrit but we should conclude that too | 18:13 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/898228 | 18:13 |
| 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 |
| JayF | Having these six month check ins with us is doing them more harm than good in many cases, I suspect. | 18:14 |
| 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 |
| 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 |
| JayF | s/can/cannot/ | 18:15 |
| JayF | Anything else before moving on? | 18:16 |
| 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:16 |
| gmann | nothing else from me, I will do remaining work we discussed today. | 18:17 |
| 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 |
| JayF | and there's no concrete proposal to how to fix it | 18:17 |
| gmann | yeah, we have many such projects | 18:17 |
| JayF | Something to think about :) | 18:17 |
| JayF | going to move on | 18:18 |
| JayF | #topic Implementation of Unmaintained branch statuses | 18:18 |
| JayF | rosmaita: you so kindly have been leading this up, how are things? | 18:18 |
| JayF | #link https://etherpad.opendev.org/p/early-caracal-unmaintained-transition | 18:18 |
| rosmaita | i think all the info is on the etherpad | 18:18 |
| rosmaita | i reached out to the release team, and they left comments | 18:18 |
| JayF | #info tc-members should read etherpad, comment asyncronously on how to adjudicate unmaintained branch transition | 18: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 |
| gmann | thanks rosmaita , did not read etherpad yet but will do today or tomorrow | 18:19 |
| rosmaita | well, we should probably make the decision soon, though | 18:19 |
| rosmaita | knikolla: there's an impact on the patch you have up | 18:19 |
| fungi | also we're probably overdue for an update/summary to openstack-discuss | 18:20 |
| rosmaita | i think we should probably discuss item #3, numbers 1 and 2 are pretty self-explanatory | 18:20 |
| 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 |
| rosmaita | fungi: ++ | 18:20 |
| 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 |
| rosmaita | so the thing with item #3 is we need to determine both what and how | 18:21 |
| 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 |
| 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:21 |
| JayF | Although I concur with dansmith I'd rather not have +2 on such branches personally. | 18:22 |
| gmann | is there way to only give member managing power and no +2/A ? | 18:22 |
| rosmaita | fungi: ^^ | 18:22 |
| dansmith | I thought it was asserted so | 18:22 |
| frickler | yes, but then the groups are not self-managed | 18:22 |
| fungi | we could probably do a trick with an extra group that is the owner of the unmaintained-core groups | 18:22 |
| fungi | put the unmaintained-core groups and the tc in the owner group. sort of circular but i think it could work | 18:23 |
| gmann | but owner still can +2 right? | 18:23 |
| frickler | that extra group could be tc-members, which already exists, just under a different name | 18:23 |
| fungi | group owner does not get the permissions conveyed by group membership, only the ability to manage the group | 18:23 |
| gmann | fungi: great. | 18:23 |
| 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:23 |
| fungi | frickler: well, then the unmaintained-core group members would be unable to also manage the unmaintained-core groups | 18:24 |
| 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 |
| gmann | yeah we need them also continue managing member and TC in the saituation where there is no one to add new member | 18:24 |
| gmann | ++ | 18:25 |
| frickler | ah, double indirection, o.k. | 18:25 |
| fungi | sort of messy but i think it would do what folks want, more or less | 18:25 |
| rosmaita | i think so ... we just need to be able to add people to the groups who can actually approve stuff | 18:25 |
| JayF | Do we have any people who have volunteered to be in that group as of now? | 18:25 |
| dansmith | it's per-project and branch right/ | 18:26 |
| gmann | I think yes per project per branch | 18:26 |
| frickler | only per-project I'd say | 18:26 |
| JayF | per project+per branch is a huge matrix and a lot of work when branches cycle around | 18:26 |
| rosmaita | well, it has to be restricted to unmaintained/* | 18:26 |
| 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 |
| knikolla | yes, only per project restricted to unmaintained/* | 18:27 |
| JayF | ++ | 18:27 |
| frickler | else you'd need to update ACLs every cycle and get a huge set of old groups | 18:27 |
| frickler | iiuc elodilles has implicitly volunteered | 18:27 |
| gmann | ok per project should be enough then, people can choose not to review any specific branch they do not volutneer for | 18:28 |
| 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 |
| rosmaita | at one point there was discussion about an openstack-wide group, or are we still agreed on per-project groups? | 18:28 |
| rosmaita | (same question as fungi) | 18:28 |
| JayF | Why do we need a universal answer, and why do we need it now? | 18:29 |
| JayF | Having a single openstack wide group to start -> easy, simple, gets it going. | 18:29 |
| fungi | it's not like they can break much, these branches are already unmaintained ;) | 18:29 |
| rosmaita | because we need to patch all the gerrit acl files | 18:29 |
| gmann | per project is needed as having +2 power on cross project is something we discussed not to give. | 18:29 |
| JayF | If we get a single large project with a lot of unmaintained, maybe they split off into their own | 18:29 |
| frickler | we need to set up the ACLs before we create the unmaintained branches | 18:29 |
| JayF | we can start simple and add complexity as the need for it reveals itself, yeah? | 18:29 |
| 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 |
| 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 |
| rosmaita | well, the "simple" move is per-project, which means creating a shit-ton of groups | 18:30 |
| JayF | knikolla++ good callback reading what we actually merged | 18:30 |
| gmann | yeah, I remember we discussed both option and agreed to go for per project in resolution | 18:30 |
| dansmith | rosmaita: or just create them as needed? | 18:30 |
| rosmaita | i think they are all needed? | 18:30 |
| dansmith | a bunch of projects will likely not opt (or not even answer) to keeping some in unmaintained | 18:30 |
| 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 |
| knikolla | all will be needed considering the default opt-in no? | 18:31 |
| knikolla | of 1 cycle | 18:31 |
| rosmaita | fungi: ++ | 18:31 |
| rosmaita | that's what i'm getting at | 18:31 |
| dansmith | knikolla: but if nothing ever gets proposed there, then there's no need for a group | 18:31 |
| gmann | as that group is not per branch so that group will be one time thing per project | 18:31 |
| knikolla | JIT groups | 18:31 |
| gmann | dansmith: but there is default opt-in for one SLURP right? | 18:31 |
| gmann | and for that we need group? | 18:32 |
| dansmith | gmann: only if there are patches to review | 18:32 |
| knikolla | I think the safer way is to pre-create the groups, otherwise we have to keep monitoring patches | 18:32 |
| rosmaita | exactly | 18:32 |
| dansmith | just saying, we shouldn't make work for ourselves. if pre-creating the groups is easy, then fine | 18:32 |
| rosmaita | but i like fungi's idea even better | 18:32 |
| gmann | yeah, pre-creation is easy than having request and checks reviews | 18:32 |
| rosmaita | because we won't have to individually patch each project's acl files | 18:32 |
| JayF | We have to amend the resolution if we implement fungi's idea. | 18:33 |
| rosmaita | i don't see a problem with that | 18:33 |
| 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 |
| rosmaita | i mean, we haven't actually done any work yet | 18:33 |
| JayF | We have changes in governance that don't have a majority of TC votes on them after multiple weeks :) | 18:33 |
| gmann | issue with that is nova unmaitained maintainers should not merge ironic/neutron changes which are maintained by some other memebres | 18:34 |
| fungi | why exactly? | 18:34 |
| rosmaita | gmann: i used to think so too, but i think we are going to have to trust the unmaintained-maintainers | 18:34 |
| fungi | i mean, first, would they want to? | 18:34 |
| rosmaita | there just aren't enough people around | 18:34 |
| 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 |
| rosmaita | plus, they can always ask for reviews from the project team for a really complicated backport or something | 18:35 |
| 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 |
| rosmaita | ok, well we can have it both ways | 18:35 |
| rosmaita | 1 - openstack-wide groupt | 18:35 |
| 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 |
| rosmaita | 2 - projects that want to restrict can merge their own change to their gerrit acl files | 18:35 |
| 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:35 |
| gmann | I know implementation is little exra work per project group but that is one time things and provide good valye | 18:36 |
| 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 |
| JayF | Does someone want to take the action to propose the amended resolution? | 18:36 |
| rosmaita | dansmith: ++ | 18:36 |
| rosmaita | i can do it | 18:37 |
| 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 |
| rosmaita | it needs to sit a week, right? | 18:37 |
| JayF | #action rosmaita to propose amendment to unmaintained branch resolution allowing a global openstack unmaintained-core group | 18:37 |
| JayF | rosmaita: yes, at least. | 18:37 |
| 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 |
| knikolla | wide* | 18:37 |
| rosmaita | fungi: am i correct that a change to cinder.config acl file will override the meta group change? | 18:37 |
| gmann | week after the last change not proposed one | 18:37 |
| rosmaita | JayF: also give me the action item to send the summary email | 18:38 |
| rosmaita | i will mention the resolution change so we can get more comments | 18:39 |
| JayF | #action rosmaita to send email to list summarizing status of implementation of unmaintained branch | 18:39 |
| JayF | alright; going to move on | 18:39 |
| knikolla | awesome | 18:39 |
| JayF | #topic 2024.1 TC Tracker | 18:39 |
| JayF | #link https://etherpad.opendev.org/p/tc-2024.1-tracker | 18:39 |
| 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 |
| rosmaita | fungi: thanks | 18:39 |
| 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 |
| JayF | If anyone wants to tackle one of those; awesome. | 18:40 |
| 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 |
| JayF | If anything, bring it up now, otherwise going to move on. | 18:41 |
| JayF | #topic Open Discussion and Reviews | 18:42 |
| 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 |
| JayF | I'm going to take a pass before my EOD today to merge anything else that is mergable. | 18:42 |
| JayF | Also, relating to holidays: I will be out of town, unavailable next week. | 18:43 |
| JayF | Traditionally TC cancels the American Thanksgiving week meeting; I'd like to do that again barring objection. | 18:43 |
| 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 |
| dansmith | JayF: ++ to cancel | 18:44 |
| gmann | next week meeting right ? | 18:44 |
| JayF | aye | 18:44 |
| knikolla | ++ on canceling next weeks meeting | 18:44 |
| gmann | k | 18:44 |
| JayF | I'll email about it after the meeting. | 18:44 |
| rosmaita | i am available, but am happy for you to cancel the meeting | 18:44 |
| JayF | does anyone know the answer for rosmaita's question? | 18:44 |
| JayF | I assumed a patch; but it's a worthy question | 18:45 |
| knikolla | Rosmaita: i think it would be a new resolution | 18:45 |
| gmann | yeah, we add new one to update any policy already appoved | 18:45 |
| rosmaita | knikolla: i'm thinking that's right | 18:45 |
| rosmaita | ok, great | 18:45 |
| rosmaita | thanks! | 18:45 |
| JayF | #info TC Meeting next week to be cancelled for American Thanksgiving week | 18:46 |
| JayF | Is there anything else for open discussion? | 18:46 |
| JayF | #endmeeting | 18:48 |
| opendevmeet | Meeting ended Tue Nov 14 18:48:26 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:48 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-14-18.00.html | 18:48 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-14-18.00.txt | 18:48 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-14-18.00.log.html | 18:48 |
| JayF | Thanks all o/ | 18:48 |
| frickler | o/ | 18:49 |
| opendevreview | Brian Rosmaita proposed openstack/governance master: Resolution to create openstack-unmaintained core https://review.opendev.org/c/openstack/governance/+/900940 | 20:32 |
| opendevreview | Brian Rosmaita proposed openstack/governance master: Resolution to create openstack-unmaintained core https://review.opendev.org/c/openstack/governance/+/900940 | 21:00 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!