On Tue, Nov 12, 2019 at 11:47 AM Zane Bitter <zbitter@redhat.com> wrote:
On 12/11/19 9:12 am, Corey Bryant wrote:
On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter <zbitter@redhat.com <mailto: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.
Thanks!
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...
Yes, for V it will be similar to that but s/train/v.../ only simpler because you already did the hard bits :) The goal champion for that is the one who gets to decide on adding the non-voting py38 job in Ussuri.
Alright I'll definitely sign up to be champion for V. For U the proposed goal is https://review.opendev.org/691178 - so it
will both update the Zuul template from train->ussuri and drop the py27 job (the former is a prerequisite for the latter because of reasons - see https://review.opendev.org/688997). That one is a little more complicated because we also should drop Python 2 functional tests before we drop the py27 unit tests, and because things have to happen in a certain order (services before libraries). OTOH we're only dropping stuff in this release and not adding new voting jobs that could break. Currently gmann has listed himself as the champion for that, but I know he's looking for help (we can have multiple champions for a goal). Somebody somewhere already has an action item to ask you about it :)
For Ussuri, I'll get in touch with gmann and see where we can help.
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.
Sean's patch has the naming poll closing on 2019-12-16, and we have to wait for legal approval from the OSF after that. (Ideally we'd have started sooner, but we were entertaining proposals to change the process and there was kind of an assumption that we wouldn't be using the existing one again.)
My take is that we shouldn't get too bureaucratic here. The criteria are well-defined so the outcome is not in doubt. There's no reason to delay until the patch is formally merged. We operate by lazy consensus, so if any TC members object they can reply to this thread. I'll flag it in IRC so people know about it. If there's no objections in the next week or say then the openstack-zuul-jobs team would be entitled to take that as approval.
That works for me. I'll check back in a week if nothing else comes up. Thanks, Corey
cheers, Zane.
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.
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