<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant <<a href="mailto:corey.bryant@canonical.com">corey.bryant@canonical.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"><div dir="ltr"><div dir="ltr"><div>Hi All,</div><div><br></div><div>I'd like to enable py37 unit tests in the gate.</div><div><br></div><div>== Background ==</div><div><br></div><div>I work on OpenStack packaging for Ubuntu. During the Rocky release (Ubuntu Cosmic) I tried to fix py37 bugs upstream as I came across them. There ended up being a lot of py37 issues and after a while, due to time constraints, I resorted to just opening bugs and disabling py37 unit tests that were failing in our package builds. Luckily enough, even though Cosmic ships with python3.6 and python3.7, python3.6 ended up being chosen as the default for Cosmic.</div><div><br></div><div>== Defaulting to python3.7 ==</div><div><br></div><div>The next release of Ubuntu opens in just a few weeks. It will default to python3.7 and will not include python3.6. <span class="gmail-m_2526886702665799690gmail-im">My hope is that if I can help enable py37 unit tests upstream now, we can get a wider view at fixing issues soon.</span></div><div><br></div><div>== Enabling py37 unit tests ==<br></div><div><br></div><div>Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have reviews up to define the py37 zuul job and templates here:  <a href="https://review.openstack.org/#/c/609066" target="_blank">https://review.openstack.org/#/c/609066</a></div><div><br></div><div>I'd like to start submitting reviews to projects to enable openstack-python37-jobs (or variant) for projects that already 
have openstack-python36-jobs in their .zuul.yaml, zuul.yaml, 
.zuul.d/project.yaml.</div><div><br></div><div>== Coinciding work ==<br></div><div><br></div><div>There is python3-first work going on now and I completely understand that this is going to cause more work for some projects. It seems that now is as good of a time as ever to catch up and test with a recent python3 version. I'm sure python3.8 and beyond will be here before we know it.<br></div><span class="gmail-m_2526886702665799690gmail-im"></span></div><div><br></div><div>Any<span class="gmail-m_2526886702665799690gmail-im"> thoughts or concerns?</span></div><div><span class="gmail-m_2526886702665799690gmail-im"></span></div><div><div dir="ltr"><div><span class="gmail-m_2526886702665799690gmail-im"><br></span></div><div><span class="gmail-m_2526886702665799690gmail-im">Thanks,</span></div><div><span class="gmail-m_2526886702665799690gmail-im">Corey<br></span></div></div></div></div></blockquote><div><div><br></div><div>I'd like to start moving forward with enabling py37 unit tests for a subset of projects. Rather than putting too much load on infra by enabling 3 x py3 unit tests for every project, this would just focus on enablement of py37 unit tests for a subset of projects in the Stein cycle. And just to be clear, I would not be disabling any unit tests (such as py35). I'd just be enabling py37 unit tests.<br></div><div><br></div><div>As some background, this ML thread originally led to updating the python3-first governance goal (<a href="https://review.openstack.org/#/c/610708/">https://review.openstack.org/#/c/610708/</a>) but has now led back to this ML thread for a +1 rather than updating the governance goal.</div><div><br></div></div><div>I'd like to get an official +1 here on the ML from parties such as the TC and infra in particular but anyone else's input would be welcomed too.  Obviously individual projects would have the right to reject proposed changes that enable py37 unit tests. Hopefully they wouldn't, of course, but they could individually vote that way.<br><div><br></div></div></div><div class="gmail_quote">Thanks,</div><div class="gmail_quote">Corey<br></div></div></div>