[tc] Add non-voting py38 for ussuri
sean.mcginnis at gmx.com
Sun Nov 10 10:44:24 UTC 2019
> 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.
> 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.
> Thomas Goirand (zigo)
More information about the openstack-discuss