| JayF | rosmaita: There are significant windstorms in my area today, and power outages. Please be on standby to run the meeting in case my internet/power goes kaput. | 16:11 |
|---|---|---|
| rosmaita | JayF: ack | 16:12 |
| JayF | tc-members: meeting in ~17 minutes | 17:43 |
| JayF | #startmeeting tc | 18:00 |
| 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 |
| 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 | 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 |
| JayF | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. | 18:00 |
| JayF | #topic Roll Call | 18:00 |
| gmann | o/ | 18:00 |
| JayF | o/ | 18:00 |
| slaweq | o/ | 18:00 |
| dansmith | o/ | 18:01 |
| rosmaita | o/ | 18:01 |
| JayF | #info One absence indicated in the agenda: jamespage. | 18:01 |
| frickler | \o | 18:02 |
| JayF | Going to give folks until 5 minutes past the hour to arrive before moving on to the agenda. | 18:02 |
| rosmaita | i over-dressed for work today, i thought we were having a video meeting | 18:03 |
| JayF | Nope, the video meeting -- first one of January -- was cancelled :) | 18:04 |
| slaweq | haha :) | 18:04 |
| knikolla | o/ | 18:04 |
| spotz[m] | O/ | 18:04 |
| JayF | #topic Follow up on tracked action items | 18:04 |
| JayF | We had one item from over the holidays | 18:04 |
| JayF | #info spotz[m] to Look into updating https://docs.openstack.org/install-guide/openstack-services.html and report back to TC | 18:05 |
| spotz[m] | Patch is up not sure if it's merged yet as there were some changes requested | 18:05 |
| gmann | it is merged | 18:06 |
| gmann | #link https://review.opendev.org/c/openstack/openstack-manuals/+/904293 | 18:06 |
| spotz[m] | Sweet | 18:06 |
| JayF | Awesome! Thanks for that! | 18:06 |
| JayF | Moving on, then. | 18:06 |
| JayF | #topic Gate health check | 18:06 |
| JayF | Has there been any gate issues to speak of since we last met? | 18:07 |
| 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 |
| frickler | I saw some issues in cinder | 18:07 |
| 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 |
| slaweq | from what I can say, gates are running pretty fine recently | 18:07 |
| rosmaita | frickler: thanks for fixing the s3 job for cinder | 18:07 |
| gmann | fix is merged i think | 18:08 |
| 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 |
| dansmith | however, we'll see how it goes and it'll tell us something one way or the other I guess | 18:08 |
| frickler | that s3 issue is fixed, but some other fixes of mine still needed multiple recheck | 18:08 |
| gmann | yeah, we can do those in tempest jobs if that goes well | 18:08 |
| 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:08 |
| frickler | also lots of 3rd party CI for cinder produce just rubbish, but that's just a side note I think | 18:09 |
| knikolla | (sorry, got caught up in a meeting that is running over) | 18:10 |
| JayF | So that sounds like mostly a positive gate report. | 18:11 |
| JayF | Going to move on if there are no other comments? | 18:11 |
| JayF | #topic Leaderless Projects | 18:12 |
| JayF | #link https://etherpad.opendev.org/p/2024.1-leaderless | 18:12 |
| JayF | This has to be coming to a close as C-2 is coming up soon, yes? | 18:12 |
| 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 |
| JayF | Yeah, I see no further open PTL appointments. | 18:13 |
| gmann | rest all other 11 projects are handled either with PTL appointment or marking them Inactive | 18:13 |
| gmann | no open PTL appointment | 18:13 |
| slaweq | speaking about inactive projects | 18:14 |
| gmann | Monasca and senlin are PTL-less and inactive so they can go to next step as per inactive process | 18:14 |
| slaweq | can I ask question about Monasca now or better at the end of the meeting? | 18:14 |
| 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 |
| JayF | slaweq: go for it | 18:14 |
| slaweq | thx | 18:14 |
| gmann | yeah it is related, I saw ML discusison over that | 18:14 |
| slaweq | as You maybe noticed, on the ML there is new volunteer who wants to help with Monasca potentially | 18:15 |
| slaweq | but IIUC he is willing to do it in free time only | 18:15 |
| slaweq | and isn't really active contributor yet | 18:15 |
| slaweq | Monasca is already marked as inactive project this cycle | 18:15 |
| 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 |
| 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 |
| slaweq | or should we help to move it to x/ namespace and let it be unofficial project? | 18:16 |
| gmann | after fujistu change their directioh, Monasca is very less active since than | 18:16 |
| JayF | and that such a decision would likely end up with us revisiting this topic in months | 18:16 |
| JayF | slaweq: I think for move to unofficial we don't even change the namespace anymore, but IMBW | 18:17 |
| gmann | JayF: I do not think single controbutor base but how active project is and can be | 18:17 |
| gmann | yeah, I think slaweq proposal to them to continue development in X/ namespace make sense to me too | 18:17 |
| 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 |
| fungi | for unofficial, the repo in the openstack/ namespace is retired and interested parties create a new fork in a different namespace | 18:17 |
| JayF | and it's hard for a single person to make that kinda promise in any context | 18:17 |
| gmann | JayF: we need to change namespace. we had resolution in past saying only official projects stay in openstack/ name space | 18:17 |
| JayF | ack | 18:17 |
| 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 |
| fungi | (ideally not x/ since that was the dumping ground for evicted projects whose maintainers didn't respond during the namespace migration) | 18:18 |
| gmann | and if not then take decision to move to x/ or retire completly in next cycle | 18:19 |
| 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 |
| 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 |
| JayF | I am +1 to slaweq's plan; but it is mutually exclusive with Monasca being in the release. | 18:19 |
| frickler | well IIUC moving would mean retiring and creating a fork, like fungi said | 18:19 |
| slaweq | gmann I didn't hear from them neighter | 18:19 |
| 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:19 |
| gmann | yeah, let's check with them first as moving to x/namespace and retirement is too separate thing | 18:20 |
| fungi | or could be on gitlab.com or sourcehut or wherever | 18:20 |
| 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 |
| 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:20 |
| slaweq | ok, so I will try to reach out to them to discuss that | 18:21 |
| 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 |
| JayF | The worst thing we can do is no-action which leaves that person in limbo. | 18:21 |
| slaweq | hopefully I will have some info before our next meeting | 18:21 |
| frickler | for senlin there has also been someone ( eandersson ) interested in keeping it alive, but not enough to go for PTL | 18:21 |
| 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:21 |
| 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 |
| 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 |
| JayF | Even if I am extremely appreciative of their willingness to. | 18:22 |
| 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 |
| 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:23 |
| gmann | slaweq: we have done that in past for mistral or other project based on their volunteer in ML | 18:24 |
| 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 |
| fungi | on the other hand, how much harm can they do given monasca's current state> | 18:24 |
| 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:24 |
| gmann | fungi: yeah | 18:25 |
| JayF | fungi: a lot, really. They'd have a keystone token to the rest of the cloud. | 18:25 |
| slaweq | gmann as I said, I will try to reach out to them this week | 18:25 |
| gmann | slaweq: ++ thanks | 18:25 |
| 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:25 |
| gmann | slaweq: if they are ok with unofficial, i am all ok with that. | 18:26 |
| JayF | and that includes not "flapping" projects between active/inactive | 18:26 |
| fungi | yes, i do think that project removal from openstack should come without any significant hope that the project can re-enter | 18:26 |
| 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 |
| JayF | frickler: part of the problem is inactivity is a sort of limbo | 18:27 |
| gmann | frickler: retirement is requirement in next cycle of project went into inactive state | 18:27 |
| 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 |
| gmann | so we have this cycle to keep project inactive and ask new volunteer to make it active | 18:27 |
| JayF | it's an interesting downside to "inactivity" status I'm not sure we've encountered until now | 18:28 |
| frickler | well we could make the volunteer core without them being PTL | 18:28 |
| 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 |
| gmann | yes, that is possible | 18:28 |
| 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:28 |
| 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 |
| 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 |
| slaweq | yeap | 18:29 |
| gmann | I am confused on that trust thing :) | 18:29 |
| gmann | concern on new contributors or they had some bad history? | 18:30 |
| 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 |
| slaweq | gmann new contributors which are not known at all in community | 18:30 |
| JayF | Most projects with >1 contributor have a built-in auditing process; additional contributors who are watching reviews, contributions coming in, etc | 18:30 |
| gmann | but there are always new contributors in project right | 18:30 |
| 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 |
| gmann | mistral was one good example in same situation | 18:31 |
| 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 |
| slaweq | gmann yes, but usually such new contributor is not the only contributor | 18:31 |
| fungi | seems to me the concern in this case is that the volunteer has nobody to shepherd them | 18:31 |
| JayF | knikolla++ you said that much more eloquently than I did | 18:31 |
| 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 |
| 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 |
| 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:32 |
| gmann | my suggestion is to give them a chance for this cycle and see how it goes | 18: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 |
| gmann | we can always retire it anytime if we see any dubious activties or no activity at all | 18:33 |
| 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:33 |
| gmann | yeah, that is going to be the msg | 18:34 |
| 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 |
| slaweq | OpenStack community still | 18:34 |
| JayF | slaweq++ | 18:34 |
| spotz[m] | Can we move in and out of the x namespace? | 18:34 |
| 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 |
| 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 |
| JayF | spotz[m]: it's extremely labor-intensive for the infra team, that is not a good situation | 18:35 |
| 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:35 |
| frickler | moving to x|other is much effort, in addition monasca contains quite a number of repos | 18:36 |
| fungi | spotz[m]: also not really, because there will still be a retired copy in the openstack/ namespace too | 18:36 |
| spotz[m] | Ok just a thought | 18:36 |
| 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 |
| 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 |
| 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 |
| 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:36 |
| slaweq | knikolla++ | 18:37 |
| dansmith | ...which is also "much work" | 18:37 |
| JayF | ++ | 18:37 |
| dansmith | I think moving to X sounds like it's the best option here, | 18:38 |
| knikolla | It's work that aims to break down the barriers between project teams, but yes, it's a lot of work. | 18:38 |
| JayF | Is there value in taking a quick straw pole with the vote feature? See how close we are to consensus? | 18:38 |
| JayF | *poll | 18:39 |
| 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 |
| 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 |
| dansmith | I just picked "two years" as a random "somewhere way down the line" point, fwiw | 18:39 |
| 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 |
| 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 |
| 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:40 |
| 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 |
| gmann | *volunteer | 18:41 |
| 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:41 |
| 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 |
| fungi | rosmaita: yes, instead of retiring it in openstack and automatically creating new repositories that they may simply let sit and rot | 18:42 |
| rosmaita | fungi: that sounds good to me | 18:42 |
| JayF | So with slaweq's permission I suggest we have two specific actions: | 18:42 |
| fungi | also, just to repeat again, please not the x/ namespace, encourage them to pick a new namespace for their repos | 18:42 |
| frickler | if we retire it now, we make the learning curve needed by a new contributor even steeper | 18:42 |
| JayF | 1 - slaweq takes an action to reach out privately to the contributor and ask about official openstack vs "fork" | 18:43 |
| slaweq | yes | 18:43 |
| 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 |
| 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 |
| 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:43 |
| fungi | otherwise we're just wasting more resources in our infrastructure | 18:44 |
| gmann | fungi: ++ | 18:44 |
| frickler | fungi: ok, I agree to that | 18:44 |
| 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:44 |
| 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 |
| 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 |
| 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 |
| frickler | knikolla: well being inactive, we will not release monasca this cycle anyhow | 18:45 |
| 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 |
| 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 |
| 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 |
| JayF | We have other agenda items, I'm going to timebox any remaining in this discussion to :50 | 18:46 |
| 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 |
| frickler | I'm fine with the two proposed ais | 18:47 |
| knikolla | spotz: i would love to hear your thoughts with regards to how this might impact perception towards new contributors. | 18:48 |
| 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 |
| gmann | that is why my suggestion is to give them chance, monitor and then take action | 18:48 |
| JayF | #action slaweq to contact interested Monasca contributor privately to discuss options of OpenStack official vs unofficial governance | 18:48 |
| 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 |
| 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 |
| JayF | #action JayF to ensure Monasca has a dedicated agenda item for Jan 16 2024 meeting | 18:49 |
| gmann | for senlin, I will take action to contact eandersson on moving to next step | 18:50 |
| JayF | We have reached the timebox for this topic, and have several additional topics we need to plow through. | 18:50 |
| JayF | #action gmann will contact eandersson privately on next steps for Senlin | 18:50 |
| JayF | #topic Implementation of Unmaintained Branch Statuses | 18:50 |
| JayF | I believe patches are up, and we are in the waiting period now. | 18:50 |
| JayF | Is there any action to take now? | 18:50 |
| rosmaita | nothing at the moment | 18:51 |
| JayF | #topic TC Charter Updates & OIF Bylaw Changes | 18:51 |
| JayF | These were merged, thank you all for getting your votes placed in a timely fashion. | 18:51 |
| JayF | and thanks to gmann for whipping votes while I was on vacation :) | 18:51 |
| JayF | I don't think there's anything further to discuss here? | 18:52 |
| 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 |
| JayF | #topic 2024.1 TC Tracker | 18:52 |
| gmann | thanks everyone on voting/feedback on those and finishing on time | 18:52 |
| JayF | #link https://etherpad.opendev.org/p/tc-2024.1-tracker | 18:52 |
| spotz[m] | Wqqit should be announced as official on Friday | 18:52 |
| gmann | yeah | 18:52 |
| JayF | That's aweomse, thanks :) Sorry for chopping your topic off, trying to get like 5 topics in 10 remaining minutes :D | 18:53 |
| JayF | If there's any update for TC Tracker items, please note them in the etherpad. | 18:53 |
| JayF | #topic TripleO next steps | 18:53 |
| JayF | fungi added this topic | 18:53 |
| fungi | real quick, the release team needs to know how to handle tripleo deliverables for 2024.1 | 18:53 |
| JayF | it seems like there are still some repos here in limbo | 18:53 |
| fungi | the tripleo release liaisons aren't responding | 18:54 |
| fungi | and tripleo still has release managed deliverables | 18:54 |
| 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 |
| gmann | oh, i thought only stable/wallaby they want to keep and rest all derpecated means no release needed | 18:55 |
| knikolla | is nuking them off the face of the earth an option? | 18:55 |
| JayF | https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2784 | 18:55 |
| fungi | not all of tripleo's deliverables are stable branch repos | 18:55 |
| fungi | some are master branch only | 18:55 |
| JayF | I see one here with release-management as something other than deprecated | 18:55 |
| JayF | er, a couple, with none | 18:55 |
| gmann | ohk so master repo are needed for stable/wallaby right? | 18:55 |
| 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 |
| JayF | Even stable/wallaby is retired by that team now | 18:56 |
| gmann | I think their test repo tempest test skip repo or so | 18:56 |
| JayF | per their reply when I asked about unmaintained branch changes | 18:56 |
| JayF | So I think anything remaining is likely retirable, but I'm nervous saying that without seeing a full list. | 18:56 |
| 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:56 |
| gmann | ++, if stable/wallaby going then we can just have no release for master repo and start retirement soon | 18:57 |
| 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 |
| 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 |
| gmann | maybe we can move stable/wallaby status first | 18:57 |
| gmann | so that is will be clear direction on tripleO as complete project | 18:58 |
| 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 |
| 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 |
| 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 |
| JayF | ++ | 18:58 |
| 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 |
| gmann | I can do governance change for release-management for those | 18:59 |
| fungi | so there are people out there who aren't aware that tripleo is dead | 18:59 |
| fungi | gmann: yes, that's what i mean by dropping release management for those | 18:59 |
| fungi | thanks! | 19:00 |
| gmann | cool, I will propose those today and we can reivew | 19:00 |
| JayF | I'm sorry, we've reached time. | 19:00 |
| JayF | Open Discussion will not be happening today. | 19:00 |
| JayF | #endmeeting | 19:00 |
| opendevmeet | Meeting ended Tue Jan 9 19:00:17 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2024/tc.2024-01-09-18.00.html | 19:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-01-09-18.00.txt | 19:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2024/tc.2024-01-09-18.00.log.html | 19:00 |
| slaweq | o/ | 19:00 |
| spotz[m] | Thanks all | 19:00 |
| gmann | JayF: you mentioned tripleO stable/wallaby is retired. is that in ML or they initiated the changes? that will help be to update the remaining tripleO repo release management | 19:37 |
| JayF | It's a private email. I'm going to send it out to TC members + fungi so context is shared. | 19:38 |
| gmann | as all are marked deprecated in governance so I can remove master-only repo file from release repo but found tripleo-upgrade which stable/wallaby exist so not sure I should keep it or remove | 19:38 |
| gmann | JayF: cool, so let's make it official by proposing trieplO completely retired in governance and if you can ask tripleo members who confirmed in private email to vote as +1 | 19:39 |
| gmann | I can propose change of retirement of complete tripleO if that is ok? | 19:40 |
| gmann | that way will be easy to cleanup the things instead of cleaning master-only repo now and stable/wallaby one later | 19:40 |
| JayF | Yeah, if you submit such a PR I'd be happy to send that email | 19:41 |
| fungi | full retirement would be the clearest possible outcome | 19:41 |
| gmann | yeah, doing that | 19:41 |
| fungi | and last call for projects adopting tripleo deliverables they're relying on (though i think most of those have already been claimed?) | 19:41 |
| gmann | yeah | 19:42 |
| opendevreview | Ghanshyam proposed openstack/governance master: Retire TripleO project https://review.opendev.org/c/openstack/governance/+/905145 | 20:02 |
| gmann | JayF: fungi ^^ | 20:05 |
| gmann | I will send it on ML also as last call | 20:05 |
| fungi | thanks! | 20:06 |
| gmann | this is release data update change https://review.opendev.org/c/openstack/releases/+/905147 | 20:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!