Open Stack

 ---- On Thu, 14 Nov 2019 03:43:29 +0800 Corey Bryant <corey.bryant at canonical.com> wrote ----
 > 
 > 
 > 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. 

I saw the review now and that too works well and matches the TC resolution. Once we have V cycle testing runtime (zane patch) reflecting the  3.8 as required version then
we are good to merge that. 

-gmann

 > 
 > -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
 >