gmann | tc-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:open | 04:01 |
---|---|---|
gmann | ACL for all these repo have been changed to retired.config which means tc-members can merge them | 04:01 |
gmann | after these, we will be able to merge the governance change and rest of the cleanup | 04:02 |
gmann | this is correct link, please use this one https://review.opendev.org/q/remove+repo+content+owner:gmann@ghanshyammann.com+status:open | 04:03 |
frickler | gmann: 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 idea | 06:12 |
frickler | gmann: the solum content removal changes depend on the governance change, comparing to the other removals this seems to be an error? | 07:18 |
opendevreview | Brian Haley proposed openstack/project-team-guide master: Improve terminology in project-team-guide tree https://review.opendev.org/c/openstack/project-team-guide/+/917864 | 08:12 |
opendevreview | Merged openstack/project-team-guide master: Improve terminology in project-team-guide tree https://review.opendev.org/c/openstack/project-team-guide/+/917864 | 08:26 |
slaweq | gouthamr hi, just FYI, I will not be available on today's meeting because I'm in Berlin for the OpenInfra Day | 09:51 |
slaweq | I added my name in the https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Absence but telling it also here just in case :) | 09:51 |
opendevreview | Slawek 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/+/914065 | 11:12 |
opendevreview | Slawek Kaplonski proposed openstack/project-team-guide master: Remove obsolete sections from the testing doc https://review.opendev.org/c/openstack/project-team-guide/+/919559 | 11:12 |
opendevreview | Francesco Di Nucci proposed openstack/openstack-manuals master: Full review of obtain-images https://review.opendev.org/c/openstack/openstack-manuals/+/918633 | 15:05 |
gouthamr | slaweq: ack! enjoy openinfra day! | 15:41 |
JayF | I may be unavailable/distracted during the TC meeting today as well. Don't wait on me even if I'm lurking. | 15:45 |
gouthamr | JayF: ack | 16:52 |
gouthamr | tc-members: a reminder that we'll have the weekly TC meeting in this room in ~1 hour | 17:01 |
gtema | gouthamr: I am on event and not going to participate today | 17:06 |
gouthamr | gtema: ack; ty for letting me know | 17:06 |
fungi | oid germany may contribute to an inquorate tc meeting | 17:07 |
gmann | frickler: yeah, repo content removal should not depends on governance change, let me fix it | 17:08 |
gmann | frickler: done, please check | 17:10 |
gmann | frickler: 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 repo | 17:14 |
gmann | frickler: 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 |
gmann | frickler: ohk, i think you mean to delete the stable branches not release file. | 17:41 |
frickler | gmann: 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 branches | 17:43 |
gmann | frickler: 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 inactive | 17:48 |
spotz[m] | I’m here! | 17:59 |
frickler | we'll need the latest hash on the branch else the deletion script will complain. or maybe discuss with release team to amend the script | 17:59 |
gouthamr | #startmeeting tc | 18:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
opendevmeet | The meeting name has been set to 'tc' | 18:00 |
noonedeadpunk | o/ | 18:00 |
gouthamr | 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 |
gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. | 18:00 |
gouthamr | #topic Roll Call | 18:00 |
gmann | o/ | 18:00 |
dansmith | o/ | 18:00 |
spotz[m] | o/ | 18:00 |
frickler | \o | 18:00 |
JayF | o/ | 18:00 |
gouthamr | absent today: slaweq gtema | 18:01 |
gouthamr | #chair frickler | 18:01 |
opendevmeet | Current chairs: frickler gouthamr | 18:01 |
opendevreview | Ghanshyam proposed openstack/project-team-guide master: Update retired project stable branch handling https://review.opendev.org/c/openstack/project-team-guide/+/919608 | 18:02 |
gouthamr | we 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 week | 18:03 |
gouthamr | PyPi maintainers cleanup lists (gouthamr) | 18:03 |
gouthamr | Progress on eventlet removal (JayF) | 18:03 |
gouthamr | OSCaaS/speeding up DevStack (dansmith) | 18:03 |
gouthamr | Marking inactive projects prominently (gtema) | 18:03 |
gouthamr | i think there's been some updates regarding these.. | 18:03 |
JayF | I 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 work | 18:04 |
gouthamr | ty 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 |
gouthamr | lets see that discussion evolve on the ML.. | 18:06 |
gouthamr | on point (2): "We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model." | 18:06 |
gouthamr | do you mean to pursue https://review.opendev.org/c/openstack/governance/+/916546 as a resolution? | 18:06 |
JayF | It'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 |
noonedeadpunk | frankly speaking, for me personally it would be /o\ to try to assess all possible frameworks that will come to the picture with threading | 18:07 |
noonedeadpunk | and if I'd be trying to start contributing - I would just give up instantly | 18:08 |
dansmith | noonedeadpunk: I'm not sure I understand what you're saying | 18:08 |
dansmith | I think the ask is that they *not* depend on any specific framework or strategy, | 18:08 |
dansmith | and AFAIK, that's mostly a no-op from where they are today | 18:09 |
spotz[m] | So seems do nothing right now makes sense | 18:09 |
noonedeadpunk | dansmith: yeah, and then from someone from outside of the project it may make unbearable to do anything in this project | 18:09 |
dansmith | noonedeadpunk: in what way? | 18:10 |
dansmith | I mean, given they're already there by all reports, that would imply the last 12+ years has been unbearable? | 18:10 |
JayF | Today, 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 |
noonedeadpunk | probably I'm thinking about smth different | 18:11 |
JayF | I'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 |
noonedeadpunk | but I was more about with what to replace eventlet | 18:12 |
dansmith | we'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 |
noonedeadpunk | as doing asyncio vs fastapi vs gevent - are all quite different | 18:12 |
noonedeadpunk | ah, ok | 18:13 |
noonedeadpunk | yeah, then different things, sorry | 18:13 |
gouthamr | yes; specifically wrt shared libraries :) | 18:13 |
dansmith | we already have service projects using things other than eventlet, and even multiples within the same project, FWIW | 18: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 |
dansmith | noonedeadpunk: it's just not that simple | 18:14 |
JayF | spotz[m]: hberaud and I both attempted to champion asyncio; we got minimal support from other TC members on the proposed spec. | 18:14 |
dansmith | the needs of nova-compute are quite different from nova-api, and very different from glance | 18:14 |
dansmith | JayF: and from other community members, IMHO | 18:15 |
dansmith | not just TC | 18:15 |
JayF | dansmith: strangely enough, I consider your comments a form of support: you gave feedback on why you thought it was a bad idea | 18:16 |
JayF | dansmith: the silence/lack of participation in some cases is more difficult to deal with; you can't argue with or understand something from a ghost | 18:16 |
fungi | it's a common misconception that projects solved their problems in different ways because of a lack of cohesive leadership | 18:17 |
fungi | sometimes different problems are better solved in different ways | 18:17 |
dansmith | um, 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 |
dansmith | JayF: ^ | 18:17 |
JayF | dansmith: I'm trying to say, s/support/engagement/ might have been the better way to word my statement at 11:14 | 18:17 |
dansmith | JayF: ah, then in that case I agree, since most of the voices weren't from the TC | 18:18 |
gouthamr | we'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 |
dansmith | that said, I think the projects are really the important voices and not necessarily TC people because they're in the position to make a decree | 18:18 |
spotz[m] | There may not be one good solution any more but maybe the TC can come up with a list of recommendations | 18:19 |
gouthamr | ++ | 18:19 |
TheJulia | spotz[m]: ++ | 18:19 |
noonedeadpunk | yes, exactly. list of recommendations is I believe what might be expected | 18:21 |
TheJulia | An ideal warning at the bottom: you get to maintain eventlet if you don't choose one of the ones above. | 18:22 |
dansmith | I really don't even want us making a list of allowed ones, personally | 18:23 |
dansmith | until and unless someone appears to choose something completely off the wall, which feels unlikely | 18:23 |
JayF | I 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 |
dansmith | so if you change that to s/ones above/something else/ then I'm in :) | 18:24 |
dansmith | suggestions are certainly a good idea | 18:24 |
dansmith | gouthamr: did you want to discuss other AIs? | 18:25 |
gouthamr | yes | 18:26 |
dansmith | I cleaned up OCaaS and it should be mergeable now | 18:26 |
gouthamr | ideally this list will get built over time | 18:26 |
dansmith | had to fix a couple devstack, ironic, and nova things | 18:26 |
gouthamr | #link https://review.opendev.org/c/openstack/devstack/+/676016 (Use OSCaaS to speed up devstack runs) | 18:26 |
gouthamr | in 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 |
dansmith | yep, hence the DNM :) | 18:28 |
dansmith | just to show that it's working | 18:28 |
dansmith | I honestly think turning this on for more people is a good idea, bt I | 18:28 |
dansmith | but I'd at least like to be *able* to turn it on in some nova jobs :) | 18:28 |
gouthamr | ack; looks good to me, thank you for pursuing this.. we might find stray issues and have to fix them when doing this with other jobs | 18:28 |
dansmith | it's possible but in my few years of using it I've never found such a scenario :) | 18:29 |
dansmith | won't know unless we try though | 18:29 |
gouthamr | haha @ few years | 18:30 |
fungi | it'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 |
fungi | s/devstack clouds/openstack clouds/ i mean | 18:30 |
dansmith | I don't think that argument applies as much to the OCaaS one | 18:30 |
dansmith | it does to clarkb's approach I think | 18:30 |
dansmith | this 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 5s | 18:31 |
fungi | ah, yes there is a bit of a difference in approach | 18:31 |
fungi | and still has the desired effect of not incurring startup overhead over and over | 18:32 |
dansmith | yup | 18:32 |
dansmith | gouthamr: we're 30m into the call and feels like we're still stuck on the first agenda item, no? :) | 18:32 |
gouthamr | lets 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 mins | 18:32 |
noonedeadpunk | I kinda wonder, if it won't be easier to handle osc overhead jsut by enabling caching to memcached? | 18:32 |
dansmith | noonedeadpunk: it's not just the caching | 18:33 |
gouthamr | dansmith: there aren't many items today, so speak away :) | 18:33 |
fungi | entrypoint discovery is painful | 18:33 |
dansmith | it's the masssssive startup cost of importing all the python | 18:33 |
* noonedeadpunk haven't read patch fully | 18:33 | |
noonedeadpunk | ah | 18:33 |
fungi | and i/o-bound | 18:33 |
dansmith | noonedeadpunk: 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 | |
dansmith | gouthamr: okay, well, then maybe I'll duck out.. today is nova spec review day and I'm woefully behind | 18:34 |
gouthamr | on 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-discuss | 18:34 |
fungi | yeah, i'm back from vacation if you know what you need | 18:35 |
gouthamr | fungi++ ty | 18:35 |
gmann | try login with openstackci and see if it give the list of packages it own | 18:35 |
gouthamr | ^ that | 18:35 |
gouthamr | is what i needed help with | 18:35 |
gouthamr | lets chat about this off-meeting though | 18:36 |
fungi | yep | 18:37 |
gouthamr | we'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 Discussion | 18:37 |
spotz[m] | I'd still like to see the AC charter change go through but it seems stalled | 18:38 |
gouthamr | a 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 |
noonedeadpunk | fwiw, opening openstack shell takes 0.3s for me... | 18:38 |
JayF | I'll be not off, but in Europe -- including presenting at the OIF Days + BM SIG at CERN :D | 18:39 |
gmann | one 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:open | 18:39 |
gmann | and the governance changes to retire those projects are also up for review | 18:39 |
spotz[m] | Oh I'll be off and traveling too OI Day at CERN too:) | 18:39 |
noonedeadpunk | JayF: oh, where you'll be on OIF Days? | 18:39 |
JayF | noonedeadpunk: 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 |
gouthamr | spotz[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 it | 18:41 |
spotz[m] | join us noonedeadpunk ! | 18:41 |
noonedeadpunk | I'm going to Paris and was in Sweden... And I have /o\ of internal stuff in early June | 18:41 |
gouthamr | frickler 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 |
JayF | noonedeadpunk: 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 |
noonedeadpunk | gmann: Im looking at patches for retireement, and I don't see a README left? | 18:42 |
gouthamr | spotz[m] frickler: ty i'll update | 18:42 |
JayF | noonedeadpunk: gmann: https://review.opendev.org/c/openstack/ec2api-tempest-plugin/+/919399/1/README.rst lgtm? | 18:42 |
fungi | keep in mind that retired repositories/projects where contributions landed before they ceased to be official are also treated as qualifying for ac status | 18:42 |
gmann | noonedeadpunk: it should be there in every repo, please comment if i missed any | 18:42 |
fungi | so just looking at "current" published official repositories isn't the whole picture, necessarily | 18:42 |
fungi | this is why we move them from the projects.yaml file to legacy.yaml | 18:43 |
fungi | so that the election tooling can continue to find them | 18:43 |
noonedeadpunk | ok, I see why - project never had one | 18:44 |
gouthamr | fungi: thanks; important call out.. this point's there in our retirement guide | 18:44 |
gmann | k, I added in those cases also | 18:44 |
gouthamr | #link https://docs.openstack.org/project-team-guide/repository.html#step-3-retire-repository-from-the-governance-repository ^ | 18:44 |
gouthamr | do 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 |
gmann | if anyone contributed in the new retired project during election electorate timeframe then yes they are considered as AC | 18:45 |
frickler | gouthamr: so you'll want to add a 4th table to your page with legacy repos I guess | 18:45 |
gmann | gouthamr: I do not think TC need to recommend on non openstack one, maybe opedev process can be followed directly | 18:46 |
gouthamr | frickler: true; and i can parse the retirement date | 18:46 |
fungi | an 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 tools | 18:46 |
gmann | frickler: gouthamr: humm, maybe but we do not need to publish retired project, having those data in repo is enough it hink | 18:47 |
gouthamr | gmann: or probably show only those currently eligible for AC | 18:47 |
gouthamr | it'd be easy to do automatically; as long as the documentation stays updated :D | 18:48 |
gmann | gouthamr: 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 script | 18:48 |
gouthamr | gmann: ack; but what the script does isn't shared publicly, no? | 18:49 |
gmann | I 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 also | 18:49 |
frickler | imo this is not about election tooling, but about documentation | 18:49 |
gmann | gouthamr: it is shared via the charter or at least with modification spotz[m] is doing | 18:49 |
gmann | our charter should cover that what all we consider in AC irrespective of our doc structure | 18:50 |
JayF | gmann: ++ | 18:51 |
gouthamr | for sure - agree as far as framing the charter goes; but, having things visible will make things easier to grok for the reader.. | 18:51 |
fungi | if "eligibility for AC can be determined by scripts we have" is a reference to https://opendev.org/openstack/election then that is published yes | 18:52 |
gmann | sure, you can publish retired proejct data but it will be lot extra work to shape it in same way as projects data are | 18:52 |
spotz[m] | After the charter change we still need to update the scriipts | 18:53 |
gmann | yes | 18:53 |
fungi | also if you change the schema/data model within any of those yaml files, the election tools will need updating because they parse them | 18:53 |
gmann | charter 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 |
gmann | frickler: yeah, good point. and not just election but release tooling also | 18:54 |
gmann | release tools also fetch data as per schema | 18:54 |
gmann | fungi: ^^ i mean. wrongly tagged frickler | 18:55 |
frickler | another short notice before we finish: sqla2.0 is now in u-c, big thanks to stephenfin for having made this possible with years of work | 18:55 |
gouthamr | ++ | 18:55 |
fungi | at 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 features | 18:56 | |
* gouthamr loves it too | 18:57 | |
gouthamr | alright; our time's up.. thank you all for attending and for the discussion.. see you at this meeting next week | 18:59 |
gouthamr | #endmeeting | 19:00 |
opendevmeet | Meeting ended Tue May 14 19:00:05 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-05-14-18.00.html | 19:00 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-14-18.00.txt | 19:00 |
opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-14-18.00.log.html | 19:00 |
spotz[m] | Thanks gouthamr and everyone | 19:00 |
JayF | gmann: +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 |
gmann | JayF: thanks | 21:06 |
gouthamr | gmann: 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 alone | 21:47 |
gouthamr | gmann: an alternative is to use a hashtag i think.. but i can't seem to set them on this repo | 21:48 |
clarkb | we 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 hand | 21:49 |
gouthamr | ah ack clarkb; i can request editHashtags for this repo in the meanwhile, but likely these retirement changes will go into a bunch of repositories | 21:50 |
JayF | gouthamr: traditionally we only use those topics in governance repo; I'm not sure they provide value outside, but I personally have no strong preference | 21:51 |
gouthamr | JayF: yes; since there's a nice house-rules doc, i want to stick to it/continue using these tags appropriately | 21:53 |
JayF | yeah I'm saying, those only apply to governance repo, the big set of changes that g mann linked up are not in governance repo | 21:53 |
JayF | unless I lost a lot of context somewhere | 21:53 |
gouthamr | nope; you're on point :) | 21:54 |
gouthamr | i was seeking permission before pressing buttons and workflowing the governance changes that need to precede the other retirement changes | 22:04 |
clarkb | I'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 |
clarkb | oh 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 wrong | 22:07 |
gouthamr | clarkb: i saw some "partial" retirments | 22:07 |
gouthamr | yes | 22:07 |
opendevreview | Clark Boylan proposed openstack/governance master: Retire devstack-gate https://review.opendev.org/c/openstack/governance/+/919629 | 22:09 |
clarkb | side 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 3 | 22:11 |
clarkb | sorry step 8 not step 9 | 22:11 |
clarkb | oh thats in the openstack releases repo | 22:11 |
clarkb | still feels verbose but at least there are different functions here | 22:11 |
spotz[m] | clarkb: we like words?:) | 22:12 |
JayF | let me find my three-part thesis on verbosity in openstack /s | 22:13 |
gouthamr | :D | 22:13 |
clarkb | its just glaringly obvious when you compare the process to the minimal for retirement of something in opendev | 22:16 |
clarkb | you basically set repo state to the "empty" "deleted" state and then remove the project from the CI system | 22:16 |
clarkb | but with openstack there are like 8 other steps to make | 22:16 |
clarkb | gmann: 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 it | 22:18 |
clarkb | ya but that info is also inherently part of the metadata of https://review.opendev.org/c/openstack/devstack-gate/+/919626 and it is fully reversible | 22:20 |
clarkb | we don't need to triple account it if we're willing to look it up at the source | 22:20 |
clarkb | and if anyone objects 5 yaers from now they can use `git revert` and get on their way | 22:20 |
clarkb | also 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 disappeared | 22:22 |
clarkb | more important to do things with lots of documentation trail when making the top down decision | 22:22 |
opendevreview | Merged openstack/governance master: Retire Solum project https://review.opendev.org/c/openstack/governance/+/919211 | 22:27 |
opendevreview | Merged openstack/governance master: Retire Senlin project https://review.opendev.org/c/openstack/governance/+/919347 | 22:39 |
opendevreview | Merged openstack/governance master: Retire Murano project https://review.opendev.org/c/openstack/governance/+/919358 | 22:39 |
opendevreview | Merged openstack/governance master: Retire Sahara project https://review.opendev.org/c/openstack/governance/+/919374 | 22:39 |
opendevreview | Merged openstack/governance master: Retire ec2-api project https://review.opendev.org/c/openstack/governance/+/919394 | 22:39 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!