* What is our short term path? I think your short term path is to support and keep eventlet healthy in the short term. From there we have at least 4 options (ordered by order of preference that I think would benefit more to us): 1) getting involved in the current eventlet code base and trying fixing our py3.12 issues. That would be an occasion for some of us to gain the core maintainer rights. AFAIK some people have already proposed patches to solve our issues. The main problem with this option is the lack of active maintenance in the home repository of eventlet. This repository rests almost on the shoulder of one active maintainer and we should notice that nobody reviewed patches during almost 9 months. So IMO that option looks a bit hypothetical as it would also require current core maintainers contributions. The snake bites its tail. 2) We could engage in discussion with the current core maintainers to propose them to migrate eventlet into the openstack organization (maybe hosted into the oslo world), and then gain member rights to start making eventlet healthy again in the short term. If we decide to follow this path, I'd also suggest giving the maintainers rights to the current core members even if we move this project into our umbrella. This option would give us more flexibility to add new core members to this lib. The main issue with that option is that all the current PRs proposed to the current home repo would be lost if their authors do not volunteer to migrate their patches too... Tons of work would be lost and we would have to really well socialize the fact that the lib has been migrated to continue to benefit from the python community contributions and expertise. 3) if 1) 2) do not succeed, then we could decide to fork the eventlet lib into our organization (maybe hosted into the oslo world). I think that forking is the less desirable option as it would split the works and contributions between the eventlet existing repos. However, that won't be the first time that a project is forked and this option could lead us to keep eventlet healthy in the short term without too much effort either. We should also notice that all the contributions made to the original repos could be lost for us by forking this project. 4) Finally our last option is to see downstream distros maintainers fixing eventlet by patching it manually as already made in fedora ( https://src.fedoraproject.org/rpms/python-eventlet/blob/rawhide/f/python3.12...), however, we should notice that this option won't solve our upstream issue, as AFAIK, our requirements are pulled directly from pypi in the requested version. So that won't solve the issue in our gates, CI etc... Even if it is not really a solution I preferred to also refer to this option to list all our main paths. As Julia previously noticed we are now close to the end of the year, so our activity will decrease during the next few weeks. That could be an opportunity to let time to see what's happening in the eventlet original repo and then decide early in 2024 between the previous options as well as the intent to investigate and put in place a better longer term solution. * What are the steps we can execute upon quickly without too much interruption to projects? I think the first step is to officialize and formalize this topic. We could start designing and propose a community goal to define short term and long term actions. We could design a decision tree with defined milestones to put in place our short term and long term solution and then prioritize things and get the big picture of the things to do move forward. This community goal can host the next discussions related to this topic as already made by example with the secure RBAC topic ( https://review.opendev.org/c/openstack/governance/+/799705). I can initiate and manage this proposal and I volunteer to champion the process and to try to get us to a plan. Also, depending on the outcome of the previous options, we could decide to delay the adoption of the python 3.12 runtimes. In other words, we could decide to ignore Python 3.12 during our next series (D). That will enlarge our maintenance windows and leave us more rooms to reach an appropriate solution. * Is a fork to live for a few cycles acceptable to us, or not? That would be one option but not the preferable one. IMO It would be preferable to either gain maintainers in the original repos, or migrate the official repos into the openstack org, but that decision mostly depends on the future activities and feedback of the current core maintainers of eventlet. * Are there intermediate steps we can take as we plan and begin executing on a long term plan? IMO, considering the gevent maintenance activity, the gevent solution could lead us in a near future to a similar situation that the current one faced with eventlet. I think we need to prioritize a more perennial solution and the stdlib asyncio one is a solution with battery included and more close to the python mantras and philosophy. One first step could be to start forking oslo.service to migrate it to asyncio as a first step toward a long term plan. However, we should notice that forking this kind of deliverables would increase the technical debt of the oslo world during a while, and likely it would necessitate patching both instances of the oslo deliverables if a bug or an issue is detected. AFAIK the activity on oslo.service has been a bit quiet since a while so I won't expect tons of issues suddenly, for this reason, I think this lib is a good starting point to reach an intermediate step. Another point would be to define a standardized guide line to indicate to the community how to migrate their services. The Oslo migration could be a good opportunity for us to collect good practices and design the migration guide. * Are there "smaller", more isolated, places we can start and move forward to a desired end state faster than others? At first glance, I'd argue that the Oslo world could move faster than other places. Once the move on oslo would be done then, we could start migrating small services that are not relying too much to eventlet. Those services are not yet identified. I think we need the eyes of service experts, case by case, to identify who are the low hanging fruits first on the service side. * Are we okay with an intermediate end state? What is "good enough" in this case. An intermediate state could be: - the eventlet part is under control - oslo world is forked and migrated - a migration guide have been created based on our oslo observations - some services (easily migrated) have been fully transitioned to asyncio - at this point only the major services still relies on eventlet As our main issue lives in mixing eventlet and asyncio, if a couple of services are fully migrated then we could start speaking of an accomplished intermediate state where the migration is well isolated and under control. The remaining services could then rely on our previous experiences and maybe their migration could be faster than initially expected. To finish, as this topic seems to be sized to be delivered over multiple upstream releases, I'd imagine that py3.12 would be at some point supported by the coming versions of the downstream distros, so maybe we will be in sync with our intermediate state of migration that would make our PMs justifications easiers. Thoughts? As I wrote previously I'm volunteering to champion this topic and now I'm gonna start to initiate a (WIP) goal proposal. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/