[tc] Add non-voting py38 for ussuri
corey.bryant at canonical.com
Wed Nov 13 19:43:29 UTC 2019
On Wed, Nov 13, 2019 at 2:01 PM Ghanshyam Mann <gmann at ghanshyammann.com>
> ---- On Tue, 12 Nov 2019 22:12:29 +0800 Corey Bryant <
> corey.bryant at canonical.com> wrote ----
> > 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
> > > 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
> > > and direction from the TC to move forward with enabling non-voting
> > > tests.
> > I was a bit fuzzy on this myself, so I looked it up and this is what
> > 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
> > )
> > 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
> > 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
> > 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?
> > 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.
My plan is to create V templates soon which will include voting py38. And
ussuri templates will have non-voting py38:
I was thinking we couldn't add V templates to projects until after their
stable/ussuri branches are created, which would mean one update per project
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss