[tc] Add non-voting py38 for ussuri

Corey Bryant corey.bryant at canonical.com
Tue Nov 12 17:46:30 UTC 2019


On Tue, Nov 12, 2019 at 11:47 AM Zane Bitter <zbitter at 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 at redhat.com
> > <mailto: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.
>
> 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.html
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191112/08d412e3/attachment-0001.html>


More information about the openstack-discuss mailing list