[tc] Add non-voting py38 for ussuri

Ghanshyam Mann gmann at ghanshyammann.com
Mon Nov 11 13:04:56 UTC 2019


 ---- On Sun, 10 Nov 2019 18:44:24 +0800 Sean McGinnis <sean.mcginnis at gmx.com> 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.

++.

We cannot add for Ussuri at this stage.  We can go with the below plan:
- Start an experimental unit tests (functional and integration are next step) job first and projects can slowly start fixing (if any failure)
those based on their bandwidth. 
- Once job pass then make it periodic or n-v to capture the new code checking on py3.8.
- Same process for functional jobs.
- Integration jobs are not required to be duplicated. they can be moved to the latest py version later. 

In future release, we iterate the results of jobs and discuss to be add in testing run time mplate. 


-gmann

 > 
 > > 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.
 > >
 > > Cheers,
 > >
 > > Thomas Goirand (zigo)
 > >
 > 
 > 




More information about the openstack-discuss mailing list