Open Stack

On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter <zbitter at 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-process.html#unit-tests
> )
>
> 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.html

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191112/b9bdd434/attachment-0001.html>