Sean and everyone else,
Pardon me, but I have to rant here... :) Please try see things from a downstream consumer point of view.
This isn't the Python 2.7 era anymore, where we had a stable python for like forever. OpenStack needs to move quicker to newer Python 3 versions, especially considering that Python 2.7 isn't an option for anyone anymore. While your proposal (ie: less jobs on Python 3.8) looks like a nice first approach, it is my strong believe that the project should quickly move to voting and full Python 3.8 testing, and preferably, have it in order, with functional testing, for the whole project, by the time Ussuri is released.
We've had this debate many times now. Nothing has changed the fact that we cannot make something an official runtime until there is an official distro out there with that as the runtime. There is not for Ussuri.
I know what's going to happen: I'll tell about a bug in Python 3.8 on IRC, and someone will reply to me "hey, that's not supported by OpenStack before the V release, please go away", even though as downstream distribution package maintainer, we don't have the power to decide what version of Python our distribution runs on (ie: both Debian Sid, Ubuntu and Fedora are quickly moving targets).
I very highly doubt that, and very much disagree that someone will say to go away. From what I have seen, the majority of the community is very responsive to issues raised about future version problems.
Fixing and working with py3.8 is not what is being discussed here. Only whether those jobs to validate py3.8 should run on every patch or not. i think the only push back you would get is if fixing py38 compatibility would break py27 or py36 support. py27 is less of a concern at this point although i know some project might support it longer then required. The point being if we had to choose between a supported python and a newer python that we dont yet support we would prefer the supported version but generaly there is a way to support all the version we care about. it just means we can use the py38 only features until
On Sun, 2019-11-10 at 04:44 -0600, Sean McGinnis wrote: that becomes our minium supported version. i think periodic jobs make more sense personally then experimental. depending on the velocity of the project there may be little different between a non voting check job and a peroidc at least for the smaller project. for larger project like nova a periodic would give more coverage then experimental and would use alot less resources but having a periodic job is only useful i someone checks it so im not sure if adding it to the default template makes sesne. i would suggest we create a python-runtime-next template that add a py38 unit test job to that that adds the job to the periodic and experimental piplines. project that will actually check the periodic jobs in there weekly meeting like neutorn can opt in those that wont dont need to add the template.
There's absolutely no excuse for the OpenStack project to be dragging its feet, apart maybe the fact that it may not be easy to setup the infra to run tests on Py3.8 just yet. It isn't a normal situation that downstream distributions get the shit (pardon my french) and get to be the ones fixing issues and proposing patches (Corey, you've done awesome job on this...), yet it's been the case for nearly every single Python 3 releases. I very much would appreciate this situation to be fixed, and the project moving faster.
Cheers,
Thomas Goirand (zigo)