Open Stack

On Wed, Nov 13, 2019 at 2:01 PM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- 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
> 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.
>
> ++ 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.
>
> -gmann
>
>
My plan is to create V templates soon which will include voting py38. And
ussuri templates will have non-voting py38:
https://review.opendev.org/#/c/693401/

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
per release.

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191113/685dcc0e/attachment-0001.html>