[openstack-dev] [python3] Enabling py37 unit tests

Zane Bitter zbitter at redhat.com
Wed Feb 27 17:25:17 UTC 2019


On 27/02/19 11:36 AM, Jeremy Stanley wrote:
> On 2019-02-27 11:23:19 -0500 (-0500), Zane Bitter wrote:
> [...]
>> the resolution says we should unit test "[e]ach Python 3 version
>> that was still used in any integration tests at the beginning of the
>> development cycle"
> [...]
> 
> Now I'm getting worried that the phrasing we settled on is leading
> to misinterpretation. The entire point, I thought, was that we
> decide at the beginning of the development cycle on which platforms
> we're testing, and so choose the most recent releases of those LTS
> distros.

That's a separate bullet point - the first one I quoted. There's two 
other bullet points, one of which is the one above.

> If some projects were still running jobs on an earlier
> platform at the start of the cycle,

Note that when the platform changes (as it has from Rocky->Stein), it's 
inevitable that *all* projects will still be running jobs on an earlier 
platform at the start of the cycle.

> I don't think we need to be
> stuck maintaining that testing. The beginning of the cycle is the
> point at which it's safe for them to switch to the agreed-upon
> current platform for our upcoming release under development.

Right, but until they do it's not safe for other projects to drop their 
unit tests for the old platforms that are still being tested:

https://review.openstack.org/#/c/613145/2..3/resolutions/20181024-python-update-process.rst@34

In the final version we did say that "Support for these versions can be 
dropped once all integration tests have migrated", so if everything 
moved to Bionic before the end of Stein then we could drop py35 unit 
tests then, and not keep running them on stable/stein.

You commented that you'd like to require that to happen within one 
release cycle: 
https://review.openstack.org/#/c/613145/4/resolutions/20181024-python-update-process.rst@38 
but we decided we'd leave it up to the goal champions to decide 
case-by-case.

Of course right now we're trying to retrospectively apply guidelines 
that we set up for Train and beyond to Stein, where we didn't set a 
goal, we don't have a goal champion, and the configs aren't managed 
centrally so different projects could theoretically make different choices.

cheers,
Zane.



More information about the openstack-discuss mailing list