I thought about this issue some more after yesterday's TC meeting, and tried to articulate why I think keeping python 3.8 support for 2024.1 is a bad idea on the patch: https://review.opendev.org/c/openstack/governance/+/895160 I don't know if my argument there will change anyone's mind, but since a lot of people have already voted on the gerrit review, I wanted to make sure that people are at least aware of it, to wit: I just don't see that py38 support for 2024.1 makes sense. It's not a default version in Ubuntu 22.04, Debian 12, Debian 11, CentOS Stream 9, or Rocky Linux 9, which are the distros specifically called out in the current 2024.1 PTI that this proposal is patching. While we can use Ubuntu 20.04 to run unit tests, we can't run master (2024.1 development) devstack in it, so it doesn't seem to me that Ubuntu 20.04 is a distribution that we can feasibly use for meaningful 2024.1 testing. This implies, in my opinion, that there is a solid reason for dropping python 3.8 support in advance of it going EOL, as required by [0]. Looking at the Python Update Process resolution [1], python 3.8 does not meet the three criteria set out in the "Unit Tests" section: 1. it's not the latest version of Python 3 available in any distro we can feasibly use for testing 2. It's not the default in any of the Linux distros identified in the 2024.1 PTI 3. It isn't used to run integration tests at the beginning of the 2024.1 (Caracal) cycle Add to that the fact that libraries are beginning to drop support [2], add further that py38 will go EOL roughly 6 months after the 2024.1 release (no more security updates), I don't see a reason to wait until a key library forces us to make a change during the development cycle. I'd prefer to do it now. [0] https://governance.openstack.org/tc/reference/pti/python.html#specific-comma... [1] https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... [2] https://review.opendev.org/c/openstack/requirements/+/884564