18:00:38 <JayF> #startmeeting tc
18:00:38 <opendevmeet> Meeting started Tue Jan  9 18:00:38 2024 UTC and is due to finish in 60 minutes.  The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:38 <opendevmeet> The meeting name has been set to 'tc'
18:00:45 <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:48 <JayF> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee.
18:00:50 <JayF> #topic Roll Call
18:00:52 <gmann> o/
18:00:52 <JayF> o/
18:00:57 <slaweq> o/
18:01:04 <dansmith> o/
18:01:20 <rosmaita> o/
18:01:40 <JayF> #info One absence indicated in the agenda: jamespage.
18:02:03 <frickler> \o
18:02:25 <JayF> Going to give folks until 5 minutes past the hour to arrive before moving on to the agenda.
18:03:30 <rosmaita> i over-dressed for work today, i thought we were having a video meeting
18:04:06 <JayF> Nope, the video meeting -- first one of January -- was cancelled :)
18:04:15 <slaweq> haha :)
18:04:25 <knikolla> o/
18:04:38 <spotz[m]> O/
18:04:48 <JayF> #topic Follow up on tracked action items
18:04:56 <JayF> We had one item from over the holidays
18:05:07 <JayF> #info spotz[m] to Look into updating https://docs.openstack.org/install-guide/openstack-services.html and report back to TC
18:05:51 <spotz[m]> Patch is up not sure if it's merged yet as there were some changes requested
18:06:00 <gmann> it is merged
18:06:01 <gmann> #link https://review.opendev.org/c/openstack/openstack-manuals/+/904293
18:06:19 <spotz[m]> Sweet
18:06:35 <JayF> Awesome! Thanks for that!
18:06:43 <JayF> Moving on, then.
18:06:47 <JayF> #topic Gate health check
18:07:06 <JayF> Has there been any gate issues to speak of since we last met?
18:07:09 <dansmith> I haven't really done much yet this year that interacts with the gate, so I don't have much to add
18:07:23 <frickler> I saw some issues in cinder
18:07:32 <dansmith> I know that nova has changed their boot mode to use the split kernel (AWS style) because they think it will help with panics, but I'm skeptical
18:07:35 <slaweq> from what I can say, gates are running pretty fine recently
18:07:46 <rosmaita> frickler: thanks for fixing the s3 job for cinder
18:08:00 <gmann> fix is merged i think
18:08:01 <dansmith> skeptical that it should matter, and also concerned that it moves us further away from testing what people actually use for booting in the real world
18:08:12 <dansmith> however, we'll see how it goes and it'll tell us something one way or the other I guess
18:08:28 <frickler> that s3 issue is fixed, but some other fixes of mine still needed multiple recheck
18:08:29 <gmann> yeah, we can do those in tempest jobs if that goes well
18:08:45 <rosmaita> cinder has a change in the gate right now that should help with the OOM issues we see a lot: https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/901672
18:09:53 <frickler> also lots of 3rd party CI for cinder produce just rubbish, but that's just a side note I think
18:10:48 <knikolla> (sorry, got caught up in a meeting that is running over)
18:11:31 <JayF> So that sounds like mostly a positive gate report.
18:11:36 <JayF> Going to move on if there are no other comments?
18:12:41 <JayF> #topic Leaderless Projects
18:12:50 <JayF> #link https://etherpad.opendev.org/p/2024.1-leaderless
18:12:59 <JayF> This has to be coming to a close as C-2 is coming up soon, yes?
18:13:17 <gmann> one project left to handle, openstack-chef which I am going to start the retirement which is what agreed in discussion/eterpad
18:13:31 <JayF> Yeah, I see no further open PTL appointments.
18:13:38 <gmann> rest all other 11 projects are handled either with PTL appointment or marking them Inactive
18:13:48 <gmann> no open PTL appointment
18:14:04 <slaweq> speaking about inactive projects
18:14:08 <gmann> Monasca and senlin are PTL-less and inactive so they can go to next step as per inactive process
18:14:22 <slaweq> can I ask question about Monasca now or better at the end of the meeting?
18:14:29 <JayF> I appreciate that we've taken more time this cycle to evaluate activity and make noise about how some of these projects are inactive; it seems like we've dredged up some users who might be interested on the mailing list (even if in some cases it may not be in OpenStack governance)
18:14:43 <JayF> slaweq: go for it
18:14:49 <slaweq> thx
18:14:50 <gmann> yeah it is related, I saw ML discusison over that
18:15:11 <slaweq> as You maybe noticed, on the ML there is new volunteer who wants to help with Monasca potentially
18:15:27 <slaweq> but IIUC he is willing to do it in free time only
18:15:34 <slaweq> and isn't really active contributor yet
18:15:49 <slaweq> Monasca is already marked as inactive project this cycle
18:16:16 <slaweq> so my question is: should we help ramp up this guy quickly and make Monasca part of the release in this cycle
18:16:26 <JayF> I am of the opinion it would be a mistake for the TC to vote to consider a project "active" based on a single contributor's commitment.
18:16:33 <slaweq> or should we help to move it to x/ namespace and let it be unofficial project?
18:16:35 <gmann> after fujistu change their directioh, Monasca is very less active since than
18:16:45 <JayF> and that such a decision would likely end up with us revisiting this topic in months
18:17:00 <JayF> slaweq: I think for move to unofficial we don't even change the namespace anymore, but IMBW
18:17:07 <gmann> JayF: I do not think single controbutor base but how active project is and can be
18:17:24 <gmann> yeah, I think slaweq proposal to them to continue development in X/ namespace make sense to me too
18:17:40 <JayF> I think of it not in terms of "how active" but in terms of "how likely are we to keep a 18 month maintenance promise"
18:17:48 <fungi> for unofficial, the repo in the openstack/ namespace is retired and interested parties create a new fork in a different namespace
18:17:48 <JayF> and it's hard for a single person to make that kinda promise in any context
18:17:54 <gmann> JayF: we need to change namespace. we had resolution in past saying only official projects stay in openstack/ name space
18:17:58 <JayF> ack
18:18:42 <gmann> other way is we can try for one more cycle if that contributor is able to keep up project as per openstack requirement
18:18:45 <fungi> (ideally not x/ since that was the dumping ground for evicted projects whose maintainers didn't respond during the namespace migration)
18:19:01 <gmann> and if not then take decision to move to x/ or retire completly in next cycle
18:19:04 <slaweq> ok, so I can continue work with this volunteer to move project to x/ namespace and retire it in openstack/ name space
18:19:34 <gmann> slaweq: i did not hear from them  in email but do you know they agree with x/ namespace proposal or they only wanted to maintain it in openstack/
18:19:41 <JayF> I am +1 to slaweq's plan; but it is mutually exclusive with Monasca being in the release.
18:19:43 <frickler> well IIUC moving would mean retiring and creating a fork, like fungi said
18:19:52 <slaweq> gmann I didn't hear from them neighter
18:19:58 <fungi> well, start a fork of it elsewhere, which could be another (new) namespace in opendev if that's where the new maintainers want
18:20:13 <gmann> yeah, let's check with them first as moving to x/namespace and retirement is too separate thing
18:20:21 <fungi> or could be on gitlab.com or sourcehut or wherever
18:20:29 <gmann> and if they say they only wanted to maintain in openstack then we can give them a cycle to se ehow it goes
18:20:37 <slaweq> JayF yes, it would mean that it will not be part of OpenStack official release, but new team/volunteer can make release when they want to
18:21:01 <slaweq> ok, so I will try to reach out to them to discuss that
18:21:09 <JayF> Yeah, I'm just making the point that there is a decision point for TC: retire monasca to enable it to exist outside, or re-active it so this contributor is freed up to put it in the next release.
18:21:17 <JayF> The worst thing we can do is no-action which leaves that person in limbo.
18:21:19 <slaweq> hopefully I will have some info before our next meeting
18:21:25 <frickler> for senlin there has also been someone ( eandersson ) interested in keeping it alive, but not enough to go for PTL
18:21:47 <gmann> JayF: slaweq and give them a chance means they have to make projct active and change status to active otherwise it can be retired in next cycle
18:22:20 <JayF> I do not trust a new, not-yet-active contributor to a project to be able to commit to support a release of Monasca for 18 months.
18:22:26 <gmann> so we can appoint them PTL or give core power to merge thing and make it active and see how they progress but do not change inactive status just because there is volunteer instead based on porject activites
18:22:30 <JayF> Even if I am extremely appreciative of their willingness to.
18:23:47 <gmann> frickler: re senlin: yeah i had discussion with him and if DPL model make sense and he agree on that. but did not see any proposal from him. maybe they can get prevous PTL helping something there in future
18:23:50 <slaweq> gmann yes, we can but the thing is that this seems a bit scary for me to give someone totally new +2 power in official repo just like that. Maybe I'm wrong but doing that in unofficial project seems better for me :)
18:24:30 <gmann> slaweq: we have done that in past for mistral or other project based on their volunteer in ML
18:24:31 <slaweq> from the other hand, I totally understand that moving it back and forth between namespaces isn't good solution at all so we may want to try for one more cycle if needed to see how it will go
18:24:45 <fungi> on the other hand, how much harm can they do given monasca's current state>
18:24:59 <gmann> slaweq: for unofficial, we have to retire monasca which I am totally ok but I would like to know if new volunteer is ok for that or not
18:25:08 <gmann> fungi: yeah
18:25:13 <JayF> fungi: a lot, really. They'd have a keystone token to the rest of the cloud.
18:25:25 <slaweq> gmann as I said, I will try to reach out to them this week
18:25:32 <gmann> slaweq: ++ thanks
18:25:51 <JayF> fungi: If we put "OpenStack" on something; I want it to mean more than just "someone showed up and we gave them the keys with minimal oversight"
18:26:03 <gmann> slaweq: if they are ok with unofficial, i am all ok with that.
18:26:12 <JayF> and that includes not "flapping" projects between active/inactive
18:26:47 <fungi> yes, i do think that project removal from openstack should come without any significant hope that the project can re-enter
18:27:11 <frickler> well we can keep the project just inactive for a cycle or more, can we? or is retirement mandatory for inactive projects?
18:27:21 <JayF> frickler: part of the problem is inactivity is a sort of limbo
18:27:39 <gmann> frickler: retirement is requirement in next cycle of project went into inactive state
18:27:44 <JayF> frickler: this interested party can't really contribute without a PTL or active core team; we can't release an inactive project, but without retiring it it can't be created outside of openstack
18:27:58 <gmann> so we have this cycle to keep project inactive and ask new volunteer to make it active
18:28:00 <JayF> it's an interesting downside to "inactivity" status I'm not sure we've encountered until now
18:28:13 <frickler> well we could make the volunteer core without them being PTL
18:28:25 <gmann> and if they are not able to make active then we retire in next cycle and they can fork it outside openstack
18:28:38 <gmann> yes, that is possible
18:28:49 <JayF> Is someone on the TC, or in the community, going to volunteer to monitor submissions and act as an ... auditor (for lack of a better word)?
18:29:22 <gmann> we have done this in past for a few projects where project has zero active maintainers and new maintainers got core power as fresh and maintained project
18:29:23 <JayF> There are two prongs to concern here: technical, which is minimal (CI will validate this), and trust -- which is only built through time/reputation. I think slaweq and I are both expressing concern about the trust side
18:29:45 <slaweq> yeap
18:29:54 <gmann> I am confused on that trust thing :)
18:30:10 <gmann> concern on new contributors or they had some bad history?
18:30:23 <fungi> we've had a lot of lengthy debates in the past that our community is unwilling to extend trust to newcomers, and that has been blamed (rightfully or no) for some of the decline in renewal of our contributor base
18:30:36 <slaweq> gmann new contributors which are not known at all in community
18:30:42 <JayF> Most projects with >1 contributor have a built-in auditing process; additional contributors who are watching reviews, contributions coming in, etc
18:30:54 <gmann> but there are always new contributors in project right
18:31:03 <JayF> In the case of a project with no activity and a single contributor, it does put us at risk for an "inside attack" style security risk, that's all I'm concerned about.
18:31:12 <gmann> mistral was one good example in same situation
18:31:14 <knikolla> I also share the concern with regards to trust. In active projects, contributors aren't +2 until the current cohort of cores trusts their knowledge and contributions. In an inactive project there is no such continuity of trust and we as the TC don't have enough information on an individual to vet them.
18:31:20 <slaweq> gmann yes, but usually such new contributor is not the only contributor
18:31:25 <fungi> seems to me the concern in this case is that the volunteer has nobody to shepherd them
18:31:28 <JayF> knikolla++ you said that much more eloquently than I did
18:32:05 <gmann> this seems not good if we do not want to trust new contributors instead we can mentor them if we are in doubt on their policy follow or so
18:32:10 <JayF> fungi: ++ yes, combined with the concern that a single contributor may not represent any real continuity of maintenance for monasca (e.g. we'll have a version of this conversation again when this person moves on)
18:32:52 <gmann> I am ok to retire monsaca based on project activities but not based on because volunteer is new and we do not trust them
18:33:13 <gmann> my suggestion is to give them a chance for this cycle and see how it goes
18:33:33 <JayF> gmann: If this contributor was interested in a repository I had knowledge and ability to mentor in, I'd be taking that route/stance instead. I don't have that knowledge for the monasca case so I don't know what other options there are. I cannot volunteer another person (does someone with this knowledge even exist in the community still?) to do this work.
18:33:42 <gmann> we can always retire it anytime if we see any dubious activties or no activity at all
18:33:54 <frickler> so if essentially we're saying new contributors aren't given a chance to make a project active again, we can stop looking for them
18:34:10 <gmann> yeah, that is going to be the msg
18:34:38 <slaweq> In know it is rather extremal example but it happened already in the past for other opensource project that someone put there some malicious code even if there were existing reviewers who approved it. In this case, we are givin completly unknown person possibility to merge things without any control. And if this would be still official project, some existing user may simply upgrade Monasca and expect it is fine as it's "signed" by the
18:34:38 <slaweq> OpenStack community still
18:34:52 <JayF> slaweq++
18:34:53 <spotz[m]> Can we move in and out of the x namespace?
18:35:13 <JayF> that concern would be mitigated by a trusted openstack community member volunteering to mentor or take a monitoring role on Monasca while trust is being built
18:35:24 <knikolla> If we see dubious activity implies the TC will be monitoring every patch to that repo. If one of the TC members is willing to mentor this individual than sure, we can take the proposed path.
18:35:37 <JayF> spotz[m]: it's extremely labor-intensive for the infra team, that is not a good situation
18:35:55 <gmann> I will say if we are moving it out of openstack based on situation 'new contributors and only one to maintain so we cannot trust them' then we should make a policy about it first and consistent
18:36:04 <frickler> moving to x|other is much effort, in addition monasca contains quite a number of repos
18:36:07 <fungi> spotz[m]: also not really, because there will still be a retired copy in the openstack/ namespace too
18:36:09 <spotz[m]> Ok just a thought
18:36:25 <clarkb> the problems with moving things back and forth are that you either need to rename projects (something that gerrit doesn't actually support that we hack around) or you need to force push contents between two different locations to catch one side or the other up again
18:36:49 <JayF> So to be clear; I personally have two concerns: 1) Trust building. As discussed this can be worked around by having a trusted community member in a monitoring/mentoring role. 2) Long term support -- is it wise for us, in general, to reactivate a project based on a committment from a single person.
18:36:50 <gmann> yeah, it is lot of work to just move x/ namespace. that is why I am saying let's try them in openstack/ only
18:36:55 <knikolla> The ideal solution here would be the creation of a set of individuals (whether from the TC or vetted from the TC) that can take on situations like this one and bootstrap and mentor the new contributor.
18:37:15 <slaweq> knikolla++
18:37:36 <dansmith> ...which is also "much work"
18:37:40 <JayF> ++
18:38:35 <dansmith> I think moving to X sounds like it's the best option here,
18:38:42 <knikolla> It's work that aims to break down the barriers between project teams, but yes, it's a lot of work.
18:38:58 <JayF> Is there value in taking a quick straw pole with the vote feature? See how close we are to consensus?
18:39:02 <JayF> *poll
18:39:02 <dansmith> and if in two years these projects have resurrected themselves significantly, then we could consider a change, but 99% chance that will not happen, so moving is probably a safe bet
18:39:07 <gmann> I think simple is 1. keep it inactive 2. give volunteer +2 (not PTL) power to maintain it in openstack/ 3. in next cycle we monitor the activies and move to next step either retire or make it active
18:39:52 <dansmith> I just picked "two years" as a random "somewhere way down the line" point, fwiw
18:40:11 <JayF> dansmith: yeah, similarly why I've been using the "18 months" support window in my comments; it's just a nice point in the future to think about
18:40:32 <fungi> consider it as two actions: 1. retire the existing openstack/ namespace repos. 2. *if* (and only if) the volunteer is really interested, then create new repositories with copies of the original pre-retirement code in a new namespace in opendev (if that's where they want to work on it)
18:40:39 <knikolla> gmann: if we go with 3, monitoring implies a level of work that would be better invested while mentoring in real time rather than retroactively.
18:41:19 <gmann> knikolla: monitor the activities is less work as we are doing here and ofcourse anyone can colunteer to mentor there is not restriction in that anytime
18:41:32 <gmann> *volunteer
18:41:55 <rosmaita> fungi: to summarize, your idea is we retire the project from openstack, and the interested contributor can ask to have it re-created elsewhere if they are really interested in maintaining it
18:42:22 <gmann> let's do that as slaweq going to confirm with volunteer if they are ok with x/ namespace , if yes then it is easy for us otherwise we can see how we can move on this
18:42:26 <fungi> rosmaita: yes, instead of retiring it in openstack and automatically creating new repositories that they may simply let sit and rot
18:42:38 <rosmaita> fungi: that sounds good to me
18:42:44 <JayF> So with slaweq's permission I suggest we have two specific actions:
18:42:52 <fungi> also, just to repeat again, please not the x/ namespace, encourage them to pick a new namespace for their repos
18:42:56 <frickler> if we retire it now, we make the learning curve needed by a new contributor even steeper
18:43:01 <JayF> 1 - slaweq takes an action to reach out privately to the contributor and ask about official openstack vs "fork"
18:43:21 <slaweq> yes
18:43:23 <JayF> 2 - I take an action to summarize this discussion to the mailing list, with a link to this chat log, and see if there's a larger community consensus around the trust/activity issues.
18:43:43 <JayF> And that'll give us a week to think about it, digest that feedback, and take this up as a dedicated agenda item with more context in a week.
18:43:54 <fungi> frickler: i wasn't suggesting necessarily retiring now, just saying don't think of it as "moving" to a new namespace, think of it as retiring if that's what's going to happen, don't automatically create more repos on the assumption they'll actually get used
18:44:06 <fungi> otherwise we're just wasting more resources in our infrastructure
18:44:11 <gmann> fungi: ++
18:44:17 <frickler> fungi: ok, I agree to that
18:44:49 <knikolla> frickler: I agree, and I think it unfortunately is unavoidable for it to be steep. Managing an open source project requires work. We've lowered the bar so much that I don't think it can go any further while we still provide 'official' releases that have any meaning in their officiality.
18:45:12 <fungi> the natural follow-on to retiring is that interested parties *can* fork the code (in opendev or somewhere else), just don't assume that will happen and prematurely do it for them
18:45:28 <gmann> fungi: and ask them to do new namespace or so just to make sure they are serious on that instead of setting up for them and then wait if they show up
18:45:35 <JayF> frickler: I'd also say the 'learning curve' for an abandoned OpenStack project is not comparable to the learning curve for an active one. I hope people are able to see that, as well.
18:45:49 <frickler> knikolla: well being inactive, we will not release monasca this cycle anyhow
18:46:24 <rosmaita> since JayF will be linking to this conversation, i want to go on record as opposing giving a completely new contributor +2 on an openstack code repository
18:46:26 <JayF> Monasca only gets a release this cycle if we make it active in the next 2 days, which I think is not possible based on our bylaws and how long resolutions have to hold over.
18:46:43 <gmann> IMO, it is little dangerous to community 'welcome new contributors' effort and may need wider discussion/policy chnages if we want to do that
18:46:44 <JayF> We have other agenda items, I'm going to timebox any remaining in this discussion to :50
18:47:30 <gmann> rosmaita: but we did that in past and many time. gave +2 power to new contributors and they successfully maitained the projects/repo
18:47:42 <frickler> I'm fine with the two proposed ais
18:48:30 <knikolla> spotz: i would love to hear your thoughts with regards to how this might impact perception towards new contributors.
18:48:35 <gmann> so we have to be careful on both side 1. trust new contributors blindly  or 2. do not trust them at all
18:48:47 <gmann> that is why my suggestion is to give them chance, monitor and then take action
18:48:54 <JayF> #action slaweq to contact interested Monasca contributor privately to discuss options of OpenStack official vs unofficial governance
18:49:21 <JayF> #action JayF to raise the larger issues of new contributor trust and project activity, along with this debate chat log, to the mailing list and larger community.
18:49:26 <rosmaita> i think the best way to monitor is to let them continue development in the 'x' namespace and show that they have things under control
18:49:36 <JayF> #action JayF to ensure Monasca has a dedicated agenda item for Jan 16 2024 meeting
18:50:12 <gmann> for senlin, I will take action to contact eandersson on moving to next step
18:50:13 <JayF> We have reached the timebox for this topic, and have several additional topics we need to plow through.
18:50:26 <JayF> #action gmann will contact eandersson privately on next steps for Senlin
18:50:36 <JayF> #topic Implementation of Unmaintained Branch Statuses
18:50:48 <JayF> I believe patches are up, and we are in the waiting period now.
18:50:52 <JayF> Is there any action to take now?
18:51:16 <rosmaita> nothing at the moment
18:51:29 <JayF> #topic TC Charter Updates & OIF Bylaw Changes
18:51:44 <JayF> These were merged, thank you all for getting your votes placed in a timely fashion.
18:51:57 <JayF> and thanks to gmann for whipping votes while I was on vacation :)
18:52:09 <JayF> I don't think there's anything further to discuss here?
18:52:24 <gmann> yeal, all done from TC side on this. once individual members vote on bylaw changes (during ongoing election) then foundation staff will take next step accordingly.
18:52:37 <JayF> #topic 2024.1 TC Tracker
18:52:42 <gmann> thanks everyone on voting/feedback on those and finishing on time
18:52:43 <JayF> #link https://etherpad.opendev.org/p/tc-2024.1-tracker
18:52:45 <spotz[m]> Wqqit should be announced as official on Friday
18:52:57 <gmann> yeah
18:53:14 <JayF> That's aweomse, thanks :) Sorry for chopping your topic off, trying to get like 5 topics in 10 remaining minutes :D
18:53:31 <JayF> If there's any update for TC Tracker items, please note them in the etherpad.
18:53:43 <JayF> #topic TripleO next steps
18:53:50 <JayF> fungi added this topic
18:53:54 <fungi> real quick, the release team needs to know how to handle tripleo deliverables for 2024.1
18:53:57 <JayF> it seems like there are still some repos here in limbo
18:54:03 <fungi> the tripleo release liaisons aren't responding
18:54:13 <fungi> and tripleo still has release managed deliverables
18:55:05 <fungi> if tripleo deliverables won't participate in the 2024.1 release, then the release team needs to know that for sure since we're coming up on the "membership deadline" where they determine which deliverables will be included in the coordinated release
18:55:05 <gmann> oh, i thought only stable/wallaby they want to keep and rest all derpecated means no release needed
18:55:18 <knikolla> is nuking them off the face of the earth an option?
18:55:21 <JayF> https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2784
18:55:21 <fungi> not all of tripleo's deliverables are stable branch repos
18:55:26 <fungi> some are master branch only
18:55:32 <JayF> I see one here with release-management as something other than deprecated
18:55:41 <JayF> er, a couple, with none
18:55:56 <gmann> ohk so master repo are needed for stable/wallaby right?
18:56:08 <fungi> and the tripleo maintainers asked to keep master-branch-only deliverables unretired while they continued relying on them for stable/wallaby support upstream
18:56:19 <JayF> Even stable/wallaby is retired by that team now
18:56:22 <gmann> I think their test repo tempest test skip repo or so
18:56:29 <JayF> per their reply when I asked about unmaintained branch changes
18:56:46 <JayF> So I think anything remaining is likely retirable, but I'm nervous saying that without seeing a full list.
18:56:49 <fungi> the consensus from the tc late last year was that with stable/wallaby reaching unmaintained/eol state, the master branch repos could in theory also be retired, yes?
18:57:23 <gmann> ++, if stable/wallaby going then we can just have no release for master repo and start retirement soon
18:57:25 <JayF> That's my belief; can we get the full repo list into a change or to a mailing list post just so we can make sure we're approving a specific thing and not just everyone nodding and then someone's CI blows up because we got rid of something we were unaware of?
18:57:32 <fungi> anyway, the lowest-effort solution for now would be to tell the release managers that they can drop release management of any remaining tripleo deliverables
18:57:48 <gmann> maybe we can move stable/wallaby status first
18:58:06 <gmann> so that is will be clear direction on tripleO as complete project
18:58:11 <fungi> rather than continuing to try to get a response from the tripleo release liaisons who are presumably no longer around or paying attention
18:58:45 <JayF> fungi: I am +1 to dropping release management from those deliverables, and likely +1 to retiring them as well, but without seeing the specific list it's hard to be 100% certain :D
18:58:49 <gmann> fungi: is it ok for them to add release-management: None in governance and TC can do retirement or so in own pace
18:58:57 <JayF> ++
18:59:13 <fungi> related, the vmt still sees private reports of suspected security vulnerabilities come in for those tripleo repos (though it's less of a concern since we expressly don't coordinate reports for tripleo and never have)
18:59:22 <gmann> I can do governance change for release-management for those
18:59:26 <fungi> so there are people out there who aren't aware that tripleo is dead
18:59:43 <fungi> gmann: yes, that's what i mean by dropping release management for those
19:00:06 <fungi> thanks!
19:00:07 <gmann> cool, I will propose those today and we can reivew
19:00:09 <JayF> I'm sorry, we've reached time.
19:00:15 <JayF> Open Discussion will not be happening today.
19:00:17 <JayF> #endmeeting