[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