Tuesday, 2024-05-14

gmanntc-members: need reviews on these project retirement repo content removal (note: these can be merged with 2nd reviewers +2) https://review.opendev.org/q/remove+repo+content+owner:self+status:open04:01
gmannACL for all these repo have been changed to retired.config which means tc-members can merge them04:01
gmannafter these, we will be able to merge the governance change and rest of the cleanup04:02
gmannthis is correct link, please use this one https://review.opendev.org/q/remove+repo+content+owner:gmann@ghanshyammann.com+status:open04:03
fricklergmann: did you see my comment on https://review.opendev.org/c/openstack/releases/+/919402 ? although we don't seem to have done this before, maybe actually EOLing stable branches before/while retiring a project might be a good idea06:12
fricklergmann: the solum content removal changes depend on the governance change, comparing to the other removals this seems to be an error?07:18
opendevreviewBrian Haley proposed openstack/project-team-guide master: Improve terminology in project-team-guide tree  https://review.opendev.org/c/openstack/project-team-guide/+/91786408:12
opendevreviewMerged openstack/project-team-guide master: Improve terminology in project-team-guide tree  https://review.opendev.org/c/openstack/project-team-guide/+/91786408:26
slaweqgouthamr hi, just FYI, I will not be available on today's meeting because I'm in Berlin for the OpenInfra Day09:51
slaweqI added my name in the https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Absence but telling it also here just in case :)09:51
opendevreviewSlawek Kaplonski proposed openstack/project-team-guide master: Add info about recheck comments with "unrelated failure" info  https://review.opendev.org/c/openstack/project-team-guide/+/91406511:12
opendevreviewSlawek Kaplonski proposed openstack/project-team-guide master: Remove obsolete sections from the testing doc  https://review.opendev.org/c/openstack/project-team-guide/+/91955911:12
opendevreviewFrancesco Di Nucci proposed openstack/openstack-manuals master: Full review of obtain-images  https://review.opendev.org/c/openstack/openstack-manuals/+/91863315:05
gouthamrslaweq: ack! enjoy openinfra day!15:41
JayFI may be unavailable/distracted during the TC meeting today as well. Don't wait on me even if I'm lurking.15:45
gouthamrJayF: ack16:52
gouthamrtc-members: a reminder that we'll have the weekly TC meeting in this room in ~1 hour17:01
gtemagouthamr: I am on event and not going to participate today 17:06
gouthamrgtema: ack; ty for letting me know17:06
fungioid germany may contribute to an inquorate tc meeting17:07
gmannfrickler: yeah, repo content removal should not depends on governance change, let me fix it17:08
gmannfrickler: done, please check17:10
gmannfrickler: on release/EOL stable for retired project, I like the idea and it make sense to EOL all stable branches which are retired in this process. let me propose it to p-t-g guide and accordingly will update the changes in release repo17:14
gmannfrickler: one question on this though, EOLing in release does not delete the file from release repo as it has already released version data. I think we can just EOL those by using the latest released hash of that branch. what you think?17:37
gmannfrickler: ohk, i think you mean to delete the stable branches not release file. 17:41
fricklergmann: sorry for not being explicit there, actually what needs to happen is to add -eol tags as release in the deliverables files, matching that latest hash on the respective branches. after that the branch cleanup script can delete the matching branches17:43
gmannfrickler: yeah, I got it after seeing some example for EOL. 17:44
gmann'latest hash on the respective branches'  or 'latest *released* version hash' ? in former we might face challenge to release it because it means we are doing a last release for it even project is inactive ?17:48
gmann'latest *released* version hash' can be safe bet where we know that version is the last worked fine before project went inactive17:48
spotz[m]I’m here!17:59
fricklerwe'll need the latest hash on the branch else the deletion script will complain. or maybe discuss with release team to amend the script17:59
gouthamr#startmeeting tc18:00
opendevmeetMeeting started Tue May 14 18:00:09 2024 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.18:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:00
opendevmeetThe meeting name has been set to 'tc'18:00
noonedeadpunko/18:00
gouthamrWelcome 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
gouthamrToday's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee.18:00
gouthamr#topic Roll Call18:00
gmanno/18:00
dansmitho/18:00
spotz[m]o/18:00
frickler\o18:00
JayFo/18:00
gouthamrabsent today: slaweq gtema 18:01
gouthamr#chair frickler 18:01
opendevmeetCurrent chairs: frickler gouthamr18:01
opendevreviewGhanshyam proposed openstack/project-team-guide master: Update retired project stable branch handling  https://review.opendev.org/c/openstack/project-team-guide/+/91960818:02
gouthamrwe have quorum; so lets begin 18:02
gouthamr#link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee (Agenda) 18:02
gouthamr^ light agenda today, so lets use the meeting to discuss ongoing items; but please hold for "Open Discussion"18:03
gouthamr#topic AIs from previous week18:03
gouthamrPyPi maintainers cleanup lists (gouthamr)18:03
gouthamrProgress on eventlet removal (JayF)18:03
gouthamrOSCaaS/speeding up DevStack (dansmith)18:03
gouthamrMarking inactive projects prominently (gtema)18:03
gouthamri think there's been some updates regarding these.. 18:03
JayFI put a comment on the change, chatted with hberaud about the status of things, and emailed the list this morning with a call to action for projects to start eventlet removal work18:04
gouthamrty JayF 18:04
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/4KOGIDNM2SWJDBBFCTCJC3ZSITLMVMDL/ ([all][tc] Eventlet migration: Call to action)18:04
gouthamr#link https://review.opendev.org/c/openstack/governance/+/902585 (Migrate eventlet usages to asyncio)18:04
gouthamrlets see that discussion evolve on the ML.. 18:06
gouthamron point (2): "We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model."18:06
gouthamrdo you mean to pursue https://review.opendev.org/c/openstack/governance/+/916546 as a resolution? 18:06
JayFIt's my understanding that nobody, at this point, has expressed any desire to make oslo libraries dependant on a single threading model, and there are very few examples of cases that may need update. That means, to me, no action is the correct action.18:07
noonedeadpunkfrankly speaking, for me personally it would be /o\ to try to assess all possible frameworks that will come to the picture with threading18:07
noonedeadpunkand if I'd be trying to start contributing - I would just give up instantly18:08
dansmithnoonedeadpunk: I'm not sure I understand what you're saying18:08
dansmithI think the ask is that they *not* depend on any specific framework or strategy,18:08
dansmithand AFAIK, that's mostly a no-op from where they are today18:09
spotz[m]So seems do nothing right now makes sense18:09
noonedeadpunkdansmith: yeah, and then from someone from outside of the project it may make unbearable to do anything in this project18:09
dansmithnoonedeadpunk: in what way?18:10
dansmithI mean, given they're already there by all reports, that would imply the last 12+ years has been unbearable?18:10
JayFToday, it's safe to assume on any OpenStack project it's using eventlet as the primary concurrency/event model. If we end up having multiple projects choose different models -- or even as some suggest, using different models in different parts of a single project, it'll be more complexity for contributors to interact with.18:11
noonedeadpunkprobably I'm thinking about smth different18:11
JayFI'm not looking forward to that complexity at all, and it's a primary reason I'm disappointed we were unable to find a path everyone was happy with.18:11
noonedeadpunkbut I was more about with what to replace eventlet18:12
dansmithwe're talking about libraries here, not the service projects right?18:12
dansmith"shared tooling such as oslo libraries" is what gouthamr was asking for confirmation on right?18:12
noonedeadpunkas doing asyncio vs fastapi vs gevent - are all quite different18:12
noonedeadpunkah, ok18:13
noonedeadpunkyeah, then different things, sorry18:13
gouthamryes; specifically wrt shared libraries :) 18:13
dansmithwe already have service projects using things other than eventlet, and even multiples within the same project, FWIW18:13
noonedeadpunk(and that is not good idea imo)18:13
spotz[m]Are any a good replacement to champions?18:14
noonedeadpunk(probably nobody in power in dictate, but I'd love tc to come with "recommendation" at very least)18:14
dansmithnoonedeadpunk: it's just not that simple18:14
JayFspotz[m]: hberaud and I both attempted to champion asyncio; we got minimal support from other TC members on the proposed spec.18:14
dansmiththe needs of nova-compute are quite different from nova-api, and very different from glance18:14
dansmithJayF: and from other community members, IMHO18:15
dansmithnot just TC18:15
JayFdansmith: strangely enough, I consider your comments a form of support: you gave feedback on why you thought it was a bad idea18:16
JayFdansmith: the silence/lack of participation in some cases is more difficult to deal with; you can't argue with or understand something from a ghost18:16
fungiit's a common misconception that projects solved their problems in different ways because of a lack of cohesive leadership18:17
fungisometimes different problems are better solved in different ways18:17
dansmithum, not sure what we're talking about here.. my point was that there were lots of non-TC voices on that review expressing lots of different opinions than just "replace eventlet with X"18:17
dansmithJayF: ^18:17
JayFdansmith: I'm trying to say, s/support/engagement/ might have been the better way to word my statement at 11:1418:17
dansmithJayF: ah, then in that case I agree, since most of the voices weren't from the TC18:18
gouthamrwe're re-iterating stuff here, which is good, but, lets do it on the ML if this sentiment is shared by the wider community.. 18:18
dansmiththat said, I think the projects are really the important voices and not necessarily TC people because they're in the position to make a decree18:18
spotz[m]There may not be one good solution any more but maybe the TC can come up with a list of recommendations18:19
gouthamr++ 18:19
TheJuliaspotz[m]: ++18:19
noonedeadpunkyes, exactly. list of recommendations is I believe what might be expected18:21
TheJuliaAn ideal warning at the bottom: you get to maintain eventlet if you don't choose one of the ones above.18:22
dansmithI really don't even want us making a list of allowed ones, personally18:23
dansmithuntil and unless someone appears to choose something completely off the wall, which feels unlikely18:23
JayFI think such a list would be useful, whether in governance, docs, or non-openstack context. I'd be happy to review such a change wherever it was placed; but I'm putting future eventlet migration efforts towards coding -- first up is IPA eventlet removal.18:24
dansmithso if you change that to s/ones above/something else/ then I'm in :)18:24
dansmithsuggestions are certainly a good idea18:24
dansmithgouthamr: did you want to discuss other AIs?18:25
gouthamryes18:26
dansmithI cleaned up OCaaS and it should be mergeable now18:26
gouthamrideally this list will get built over time18:26
dansmithhad to fix a couple devstack, ironic, and nova things18:26
gouthamr#link https://review.opendev.org/c/openstack/devstack/+/676016 (Use OSCaaS to speed up devstack runs)18:26
gouthamrin https://review.opendev.org/c/openstack/devstack/+/918681/6/.zuul.yaml you're enabling this on a "base" job; so we'd not merge this, correct? 18:27
dansmithyep, hence the DNM :)18:28
dansmithjust to show that it's working18:28
dansmithI honestly think turning this on for more people is a good idea, bt I18:28
dansmithbut I'd at least like to be *able* to turn it on in some nova jobs :)18:28
gouthamrack; looks good to me, thank you for pursuing this.. we might find stray issues and have to fix them when doing this with other jobs18:28
dansmithit's possible but in my few years of using it I've never found such a scenario :)18:29
dansmithwon't know unless we try though18:29
gouthamrhaha @ few years18:30
fungiit's been suggested many times over the years, and in the past the main pushback from reviewers was "this doesn't reflect how people interact with devstack clouds in the real world" (which frankly could be true of a lot of other pragmatic choices devstack already makes)18:30
fungis/devstack clouds/openstack clouds/ i mean18:30
dansmithI don't think that argument applies as much to the OCaaS one18:30
dansmithit does to clarkb's approach I think18:30
dansmiththis is literally running osc in shell mode, which is fully supported in the regular usage of it and is really the only way an admin can do stuff quicker than one operation per 5s18:31
fungiah, yes there is a bit of a difference in approach18:31
fungiand still has the desired effect of not incurring startup overhead over and over18:32
dansmithyup18:32
dansmithgouthamr: we're 30m into the call and feels like we're still stuck on the first agenda item, no? :)18:32
gouthamrlets get this reviewed, and i'll call it out in our weekly summary so others can try adding jobs with this; there'll be good coverage with and without anyway.. but, it might save a few jobs hitting timeouts, and satisfy local devstack users that can't wait 40 mins18:32
noonedeadpunkI kinda wonder, if it won't be easier to handle osc overhead jsut by enabling caching to memcached?18:32
dansmithnoonedeadpunk: it's not just the caching18:33
gouthamrdansmith: there aren't many items today, so speak away :)18:33
fungientrypoint discovery is painful18:33
dansmithit's the masssssive startup cost of importing all the python18:33
* noonedeadpunk haven't read patch fully18:33
noonedeadpunkah18:33
fungiand i/o-bound18:33
dansmithnoonedeadpunk: run "openstack shell" and see how long it takes to just get to a shell prompt.. it's *that* which we save over a thousand such invocations :)18:33
* noonedeadpunk have to live with ansible, where nobody counts startup costs it seems...18:34
dansmithgouthamr: okay, well, then maybe I'll duck out.. today is nova spec review day and I'm woefully behind18:34
gouthamron the PyPi maintainers cleanup - like clarkb mentioned, there doesn't seem to be a way to distinguish Owners vs Maintainers from the warehouse API that's publicly available. which is a PITA... I was going to poke clarkb/fungi for some help and post an update to openstack-discuss18:34
fungiyeah, i'm back from vacation if you know what you need18:35
gouthamrfungi++ ty18:35
gmanntry login with openstackci and see if it give the list of packages it own 18:35
gouthamr^ that 18:35
gouthamris what i needed help with18:35
gouthamrlets chat about this off-meeting though18:36
fungiyep18:37
gouthamrwe'll skip the 2024.2 TC Tracker this week because we're doing quite well on the items; thank you all for participating in the reviews and keeping your patches updated. It'll be back next week.. 18:37
gouthamr#topic Open Discussion18:37
spotz[m]I'd still like to see the AC charter change go through but it seems stalled18:38
gouthamra reminder to folks that you can edit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee and propose topics, and state your absence anytime before the meeting starts :) 18:38
gouthamr(sees JayF's update; hope you have a good time off) 18:38
noonedeadpunkfwiw, opening openstack shell takes 0.3s for me...18:38
JayFI'll be not off, but in Europe -- including presenting at the OIF Days + BM SIG at CERN :D 18:39
gmannone thing for inactive projects, I have started the retirement for 5 inactive/leaderless projects. To move next on retirement process, I need two TC members review/merge these repo content https://review.opendev.org/q/remove+repo+content+owner:gmann@ghanshyammann.com+status:open18:39
gmannand the governance changes to retire those projects are also up for review18:39
spotz[m]Oh I'll be off and traveling too OI Day at CERN too:)18:39
noonedeadpunkJayF: oh, where you'll be on OIF Days?18:39
JayFnoonedeadpunk: OIF Days CERN in early June. I'll be UK the week before, Paris Mon/Tues, then on to Geneva for the events. There is a BM SIG the day before as well, I think we have slots left if you wanna join there too.18:40
gouthamrspotz[m]: on the AC change; i'm trying to make the TC and SIG repos visible directly on our docs: https://review.opendev.org/c/openstack/governance/+/918488 - this would vastly signify your proposal because you can just link to it18:41
spotz[m]join us noonedeadpunk !18:41
noonedeadpunkI'm going to Paris and was in Sweden... And I have /o\ of internal stuff in early June18:41
gouthamrfrickler suggested that I move it to a different place than the "OpenStack Project Teams" page that i've currently hijacked. I can do this :) 18:41
spotz[m]Thanks gouthamr 18:41
JayFnoonedeadpunk: if you wanna sync up that Mon/Tues while I'm in paris, let me know -- I've got zero plans for those days as of now.18:42
noonedeadpunkgmann: Im looking at patches for retireement, and I don't see a README left?18:42
gouthamrspotz[m] frickler: ty i'll update 18:42
JayFnoonedeadpunk: gmann: https://review.opendev.org/c/openstack/ec2api-tempest-plugin/+/919399/1/README.rst lgtm?18:42
fungikeep in mind that retired repositories/projects where contributions landed before they ceased to be official are also treated as qualifying for ac status18:42
gmannnoonedeadpunk: it should be there in every repo, please comment if i missed any18:42
fungiso just looking at "current" published official repositories isn't the whole picture, necessarily18:42
fungithis is why we move them from the projects.yaml file to legacy.yaml18:43
fungiso that the election tooling can continue to find them18:43
noonedeadpunkok, I see why - project never had one18:44
gouthamrfungi: thanks; important call out.. this point's there in our retirement guide 18:44
gmannk, I added in those cases also18:44
gouthamr#link https://docs.openstack.org/project-team-guide/repository.html#step-3-retire-repository-from-the-governance-repository ^18:44
gouthamrdo we have any advice to share on a non-Openstack project's retirement/removal? 18:45
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/R42DO7M4BECGRLBTBXYRNRSF7JQGK5GB/ ([neutron][releases][tc] Retiring tap-as-a-service-tempest-plugin and old stable branches of tap-as-a-service)18:45
gmannif anyone contributed in the new retired project during election electorate timeframe then yes they are considered as AC18:45
fricklergouthamr: so you'll want to add a 4th table to your page with legacy repos I guess18:45
gmanngouthamr: I do not think TC need to recommend on non openstack one, maybe opedev process can be followed directly 18:46
gouthamrfrickler: true; and i can parse the retirement date18:46
fungian up side to this approach is that you'll finally have validation of the formatting of those files, and avoid last minute scrambles we've had in the past with people making untested edits to them which later break the election tools18:46
gmannfrickler: gouthamr:  humm, maybe but we do not need to publish retired project, having those data in repo is enough it hink18:47
gouthamrgmann: or probably show only those currently eligible for AC18:47
gouthamrit'd be easy to do automatically; as long as the documentation stays updated :D 18:48
gmanngouthamr: eligibility for AC can be determined by scripts we have not via what we published right. i mean for retiring project, we used to have those project in project data before they went to retirement and any contribution to that will be counted by the script18:48
gouthamrgmann: ack; but what the script does isn't shared publicly, no? 18:49
gmannI am not strongly against of publish all retired project but that is not exactly what AC means will be, it will be calculated by the timeframe also18:49
fricklerimo this is not about election tooling, but about documentation18:49
gmanngouthamr: it is shared via the charter or at least with modification spotz[m] is doing18:49
gmannour charter should cover that what all we consider in AC irrespective of our doc structure 18:50
JayFgmann: ++18:51
gouthamrfor sure - agree as far as framing the charter goes; but, having things visible will make things easier to grok for the reader.. 18:51
fungiif "eligibility for AC can be determined by scripts we have" is a reference to https://opendev.org/openstack/election then that is published yes18:52
gmannsure, you can publish retired proejct data but it will be lot extra work to shape it in same way as projects data are18:52
spotz[m]After the charter change we still need to update the scriipts18:53
gmannyes18:53
fungialso if you change the schema/data model within any of those yaml files, the election tools will need updating because they parse them18:53
gmanncharter change is imp here and we should make that depends on our doc structure or script change etc. let's do charter change first and then implemention 18:54
gmannfrickler: yeah, good point. and not just election but release tooling also18:54
gmannrelease tools also fetch data as per schema 18:54
gmannfungi: ^^ i mean. wrongly tagged frickler 18:55
frickleranother short notice before we finish: sqla2.0 is now in u-c, big thanks to stephenfin for having made this possible with years of work18:55
gouthamr++18:55
fungiat one time we talked about adding a python-based parser in openstack/governance which election and release tools could use to avoid code duplication, but i don't think that every came to pass (dhellmann started writing one at one point)18:55
spotz[m]++18:56
gouthamr#link https://wiki.openstack.org/wiki/Successes 18:56
gouthamr#link https://review.opendev.org/c/openstack/requirements/+/879743 (Update SQLAlchemy and alembic, drop sqlalchemy-migrate) 18:56
* fungi is thrilled to see that folks are still using the success and thanks features18:56
* gouthamr loves it too18:57
gouthamralright; our time's up.. thank you all for attending and for the discussion.. see you at this meeting next week18:59
gouthamr#endmeeting 19:00
opendevmeetMeeting ended Tue May 14 19:00:05 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-14-18.00.html19:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-14-18.00.txt19:00
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-14-18.00.log.html19:00
spotz[m]Thanks gouthamr and everyone19:00
JayFgmann: +2 on all those retirement changes; just noting I didn't review for *missing* patches (e.g. I didn't check to ensure no repos were missed). Thanks for pushing those 20:18
gmannJayF: thanks21:06
gouthamrgmann: can i update the topic for these changes? these are "project-update" afaict; but, if you prefer to use "retire-x" to track everything, i can leave these alone21:47
gouthamrgmann: an alternative is to use a hashtag i think.. but i can't seem to set them on this repo21:48
clarkbwe haev an open todo to allow hashtags by registered users on all changes. Currently the acls are a bit project by project but there isn't any reason for that other than we haven't sorted out what the change to the central ACLs needs to look like and then making that by hand21:49
gouthamrah ack clarkb; i can request editHashtags for this repo in the meanwhile, but likely these retirement changes will go into a bunch of repositories21:50
JayFgouthamr: traditionally we only use those topics in governance repo; I'm not sure they provide value outside, but I personally have no strong preference21:51
gouthamrJayF: yes; since there's a nice house-rules doc, i want to stick to it/continue using these tags appropriately21:53
JayFyeah I'm saying, those only apply to governance repo, the big set of changes that g mann linked up are not in governance repo21:53
JayFunless I lost a lot of context somewhere21:53
gouthamrnope; you're on point :) 21:54
gouthamri was seeking permission before pressing buttons and workflowing the governance changes that need to precede the other retirement changes22:04
clarkbI'm working on retiring devstack-gate. In the governance repo it is part of the tact sig. Looking in legacy.yaml there are no preexisting tact sig repo retirements. What is the correct way to do this for a sig repo? seems like the implicit expectation is that you retire an entire sig rather than a single repo?22:06
clarkboh maybe you use the partial flag then only set a retirement date for the repo and not the sig. I'll do that and people can -1 if it is wrong22:07
gouthamrclarkb: i saw some "partial" retirments22:07
gouthamryes22:07
opendevreviewClark Boylan proposed openstack/governance master: Retire devstack-gate  https://review.opendev.org/c/openstack/governance/+/91962922:09
clarkbside note: the openstack retirement process seems to be overly verbose. Like why do we need to mark deliverables as retired in step 9 when that is already done in step 322:11
clarkbsorry step 8 not step 922:11
clarkboh thats in the openstack releases repo22:11
clarkbstill feels verbose but at least there are different functions here22:11
spotz[m]clarkb: we like words?:)22:12
JayFlet me find my three-part thesis on verbosity in openstack /s 22:13
gouthamr:D22:13
clarkbits just glaringly obvious when you compare the process to the minimal for retirement of something in opendev22:16
clarkbyou basically set repo state to the "empty" "deleted" state and then remove the project from the CI system22:16
clarkbbut with openstack there are like 8 other steps to make22:16
clarkbgmann: shoudl we send email about devstack-gate's retirement? It was never really end user/operator facing and instead was a CI system driver. I can't imagine anyone is using it today, but maybe they are?22:18
spotz[m]A lot of it is historical governance. And after trying to get the charter updated for AC status I can see why no one wants to try and streamline it22:18
clarkbya but that info is also inherently part of the metadata of https://review.opendev.org/c/openstack/devstack-gate/+/919626 and it is fully reversible22:20
clarkbwe don't need to triple account it if we're willing to look it up at the source22:20
clarkband if anyone objects 5 yaers from now they can use `git revert` and get on their way22:20
clarkbalso I suppose there is a slight accounting difference in project / sig team member saying we're retiring this now because it isn't needed anymore and TC doing top down retirements because project teams have disappeared22:22
clarkbmore important to do things with lots of documentation trail when making the top down decision22:22
opendevreviewMerged openstack/governance master: Retire Solum project  https://review.opendev.org/c/openstack/governance/+/91921122:27
opendevreviewMerged openstack/governance master: Retire Senlin project  https://review.opendev.org/c/openstack/governance/+/91934722:39
opendevreviewMerged openstack/governance master: Retire Murano project  https://review.opendev.org/c/openstack/governance/+/91935822:39
opendevreviewMerged openstack/governance master: Retire Sahara project  https://review.opendev.org/c/openstack/governance/+/91937422:39
opendevreviewMerged openstack/governance master: Retire ec2-api project  https://review.opendev.org/c/openstack/governance/+/91939422:39

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!