[tc] Add non-voting py38 for ussuri
smooney at redhat.com
Mon Nov 11 13:15:24 UTC 2019
On Sun, 2019-11-10 at 04:44 -0600, Sean McGinnis wrote:
> > 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
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)
More information about the openstack-discuss