[tc] Add non-voting py38 for ussuri

Zane Bitter zbitter at redhat.com
Mon Nov 11 19:32:20 UTC 2019

On 7/11/19 2:11 pm, Corey Bryant wrote:
> Hello TC members,
> Python 3.8 is available in Ubuntu Bionic now and while I understand it's 
> too late to enable voting py38 unit tests for ussuri, I'd like to at 
> least enable non-voting py38 unit tests. This email is seeking approval 
> and direction from the TC to move forward with enabling non-voting py38 
> tests.

I was a bit fuzzy on this myself, so I looked it up and this is what the 
TC decided when we passed the resolution:

> If the new Zuul template contains test jobs that were not in the previous one, the goal champion(s) may choose to update the previous template to add a non-voting check job (or jobs) to match the gating jobs in the new template. This means that all repositories that have not yet converted to the template for the upcoming release will see a non-voting preview of the new job(s) that will be added once they update. If this option is chosen, the non-voting job should be limited to the master branch so that it does not run on the preceding release’s stable branch.


So to follow that process we would need to define the python versions 
for V, then appoint a goal champion, and after that it would be at the 
champion's discretion to add a non-voting job on master in Ussuri. I 
happened to be sitting next to Sean when I saw this thread, and after 
discussing it with him I think he would OK with having a non-voting job 
on every commit, since it's what we have documented. Previous 
discussions established that the overhead of adding one Python unit test 
job to every project was pretty inconsequential (we'll offset it by 
dropping 2.7 jobs anyway).

I submitted a draft governance patch defining the Python versions for V 
(https://review.opendev.org/693743). Unfortunately we can't merge it yet 
because we don't have a release name for V (Sean is working on that: 
https://review.opendev.org/693266). It's gazing in the crystal ball a 
little bit, but even if for some reason Ubuntu 20.04 is not released 
before the V cycle starts, it's inevitable that we will be selecting 
Python 3.8 because it meets the first criterion ("The latest released 
version of Python 3 that is available in any distribution we can 
feasibly use for testing") - 3.8 is released and it's available in 
Ubuntu 18.04, which is the distro we use for testing anyway.

So, in my opinion, if you're volunteering to be the goal champion then 
there's no need for any further approval by the TC ;)

I guess to make that official we should commit the python3 update Goal 
for the V cycle now... or at least as soon as we have a release name.

This is happening a little earlier than I think we anticipated but, 
given that there's no question what is going to happen in V, I don't 
think we'd be doing anybody any favours by delaying the process 

> For some further background: The next release of Ubuntu, Focal (20.04) 
> LTS, is scheduled to release in April 2020. Python 3.8 will be the 
> default in the Focal release, so I'm hopeful that non-voting unit tests 
> will help close some of the gap.
> I have a review here for the zuul project template enablement for ussuri:
> https://review.opendev.org/#/c/693401
> Also should this be updated considering py38 would be non-voting?
> https://governance.openstack.org/tc/reference/runtimes/ussuri.html

No, I don't think this changes anything for Ussuri. It's preparation for V.


More information about the openstack-discuss mailing list