---- On Tue, 12 Nov 2019 22:12:29 +0800 Corey Bryant corey.bryant@canonical.com wrote ----
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter zbitter@redhat.com wrote: 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.
Thanks for digging that up and explaining. I recall that wording and it makes a lot more sense now that we have a scenario in front of us.
(from https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... )
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
Thanks very much for getting that going. 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 ;)
Sure, I can champion that. Just to be clear, would that be Ussuri and V python3-updates champion, similar to the following? https://governance.openstack.org/tc/goals/selected/train/python3-updates.htm... Granted it's easier now that we mostly just have to switch the job template to the new release. 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.
How far off do you think we are from having a V name? If just a few weeks then I'm fine waiting but if over a month I'm more concerned.
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 unnecessarily.
++ on not delaying the process. That is the main point of the goal process schedule also. To be clear, are we going to add the py3.8 n-v job as part of v cycle template (openstack-python3-v*-jobs) ? I hope yes, as it will enable us to make the one-time change on the project's side. Once we are in V cycle then template can be updated to make it a voting job.
If not as part of the template (adding n-v job explicitly in Ussuri cycle and then add the V template once V cycle starts. ) then it will be two changes per project which I would like to avoid.
-gmann
I agree. And Python 3.9 doesn't release until Oct 2020 so that won't be in the picture for Ussuri or V.
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.
Ok. Appreciate all the input and help. Thanks,Corey