<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 12, 2019 at 11:47 AM Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/11/19 9:12 am, Corey Bryant wrote:<br>
> <br>
> On Mon, Nov 11, 2019 at 2:33 PM Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a> <br>
> <mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>>> wrote:<br>
> <br>
>     On 7/11/19 2:11 pm, Corey Bryant wrote:<br>
>      > Hello TC members,<br>
>      ><br>
>      > Python 3.8 is available in Ubuntu Bionic now and while I<br>
>     understand it's<br>
>      > too late to enable voting py38 unit tests for ussuri, I'd like to at<br>
>      > least enable non-voting py38 unit tests. This email is seeking<br>
>     approval<br>
>      > and direction from the TC to move forward with enabling<br>
>     non-voting py38<br>
>      > tests.<br>
> <br>
>     I was a bit fuzzy on this myself, so I looked it up and this is what<br>
>     the<br>
>     TC decided when we passed the resolution:<br>
> <br>
>      > If the new Zuul template contains test jobs that were not in the<br>
>     previous one, the goal champion(s) may choose to update the previous<br>
>     template to add a non-voting check job (or jobs) to match the gating<br>
>     jobs in the new template. This means that all repositories that have<br>
>     not yet converted to the template for the upcoming release will see<br>
>     a non-voting preview of the new job(s) that will be added once they<br>
>     update. If this option is chosen, the non-voting job should be<br>
>     limited to the master branch so that it does not run on the<br>
>     preceding release’s stable branch.<br>
> <br>
> <br>
> Thanks for digging that up and explaining. I recall that wording and it <br>
> makes a lot more sense now that we have a scenario in front of us.<br>
> <br>
>     (from<br>
>     <a href="https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests</a><br>
> <br>
>     )<br>
> <br>
>     So to follow that process we would need to define the python versions<br>
>     for V, then appoint a goal champion, and after that it would be at the<br>
>     champion's discretion to add a non-voting job on master in Ussuri. I<br>
>     happened to be sitting next to Sean when I saw this thread, and after<br>
>     discussing it with him I think he would OK with having a non-voting job<br>
>     on every commit, since it's what we have documented. Previous<br>
>     discussions established that the overhead of adding one Python unit<br>
>     test<br>
>     job to every project was pretty inconsequential (we'll offset it by<br>
>     dropping 2.7 jobs anyway).<br>
> <br>
>     I submitted a draft governance patch defining the Python versions for V<br>
>     (<a href="https://review.opendev.org/693743" rel="noreferrer" target="_blank">https://review.opendev.org/693743</a>). Unfortunately we can't merge it<br>
>     yet<br>
>     because we don't have a release name for V (Sean is working on that:<br>
>     <a href="https://review.opendev.org/693266" rel="noreferrer" target="_blank">https://review.opendev.org/693266</a>). It's gazing in the crystal ball a<br>
> <br>
> <br>
> Thanks very much for getting that going.<br>
> <br>
>     little bit, but even if for some reason Ubuntu 20.04 is not released<br>
>     before the V cycle starts, it's inevitable that we will be selecting<br>
>     Python 3.8 because it meets the first criterion ("The latest released<br>
>     version of Python 3 that is available in any distribution we can<br>
>     feasibly use for testing") - 3.8 is released and it's available in<br>
>     Ubuntu 18.04, which is the distro we use for testing anyway.<br>
> <br>
>     So, in my opinion, if you're volunteering to be the goal champion then<br>
>     there's no need for any further approval by the TC ;)<br>
> <br>
> <br>
> Sure, I can champion that.<br>
<br>
Thanks!<br>
<br>
> Just to be clear, would that be Ussuri and V <br>
> python3-updates champion, similar to the following?<br>
> <a href="https://governance.openstack.org/tc/goals/selected/train/python3-updates.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/goals/selected/train/python3-updates.html</a><br>
<br>
Yes, for V it will be similar to that but s/train/v.../ only simpler <br>
because you already did the hard bits :) The goal champion for that is <br>
the one who gets to decide on adding the non-voting py38 job in Ussuri.<br>
<br></blockquote><div><br></div><div>Alright I'll definitely sign up to be champion for V.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For U the proposed goal is <a href="https://review.opendev.org/691178" rel="noreferrer" target="_blank">https://review.opendev.org/691178</a> - so it <br>
will both update the Zuul template from train->ussuri and drop the py27 <br>
job (the former is a prerequisite for the latter because of reasons - <br>
see <a href="https://review.opendev.org/688997" rel="noreferrer" target="_blank">https://review.opendev.org/688997</a>). That one is a little more <br>
complicated because we also should drop Python 2 functional tests before <br>
we drop the py27 unit tests, and because things have to happen in a <br>
certain order (services before libraries). OTOH we're only dropping <br>
stuff in this release and not adding new voting jobs that could break. <br>
Currently gmann has listed himself as the champion for that, but I know <br>
he's looking for help (we can have multiple champions for a goal). <br>
Somebody somewhere already has an action item to ask you about it :)<br>
<br></blockquote><div><br></div><div>For Ussuri, I'll get in touch with gmann and see where we can help.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Granted it's easier now that we mostly just have to switch the job <br>
> template to the new release.<br>
> <br>
>     I guess to make that official we should commit the python3 update Goal<br>
>     for the V cycle now... or at least as soon as we have a release name.<br>
> <br>
> <br>
> How far off do you think we are from having a V name? If just a few <br>
> weeks then I'm fine waiting but if over a month I'm more concerned.<br>
<br>
Sean's patch has the naming poll closing on 2019-12-16, and we have to <br>
wait for legal approval from the OSF after that. (Ideally we'd have <br>
started sooner, but we were entertaining proposals to change the process <br>
and there was kind of an assumption that we wouldn't be using the <br>
existing one again.)<br>
<br>
My take is that we shouldn't get too bureaucratic here. The criteria are <br>
well-defined so the outcome is not in doubt. There's no reason to delay <br>
until the patch is formally merged. We operate by lazy consensus, so if <br>
any TC members object they can reply to this thread. I'll flag it in IRC <br>
so people know about it. If there's no objections in the next week or <br>
say then the openstack-zuul-jobs team would be entitled to take that as <br>
approval.<br></blockquote><div><br></div><div>That works for me. I'll check back in a week if nothing else comes up.</div><div><br></div><div><div>Thanks,</div><div>Corey</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
cheers,<br>
Zane.<br>
<br>
>     This is happening a little earlier than I think we anticipated but,<br>
>     given that there's no question what is going to happen in V, I don't<br>
>     think we'd be doing anybody any favours by delaying the process<br>
>     unnecessarily.<br>
> <br>
> <br>
> I agree. And Python 3.9 doesn't release until Oct 2020 so that won't be <br>
> in the picture for Ussuri or V.<br>
> <br>
> <br>
>      > For some further background: The next release of Ubuntu, Focal<br>
>     (20.04)<br>
>      > LTS, is scheduled to release in April 2020. Python 3.8 will be the<br>
>      > default in the Focal release, so I'm hopeful that non-voting unit<br>
>     tests<br>
>      > will help close some of the gap.<br>
>      ><br>
>      > I have a review here for the zuul project template enablement for<br>
>     ussuri:<br>
>      > <a href="https://review.opendev.org/#/c/693401" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/693401</a><br>
>      ><br>
>      > Also should this be updated considering py38 would be non-voting?<br>
>      > <a href="https://governance.openstack.org/tc/reference/runtimes/ussuri.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/runtimes/ussuri.html</a><br>
> <br>
>     No, I don't think this changes anything for Ussuri. It's preparation<br>
>     for V.<br>
> <br>
> <br>
> Ok. Appreciate all the input and help.<br>
> <br>
> Thanks,<br>
> Corey<br>
<br>
</blockquote></div></div>