Open Stack

On 19/10/18 11:17 AM, Zane Bitter wrote:
> I'd like to propose that we handle this by setting up a unit test 
> template in openstack-zuul-jobs for each release. So for Stein we'd have 
> openstack-python3-stein-jobs. This template would contain:
> 
> * A voting gate job for the highest minor version of py3 we want to 
> support in that release.
> * A voting gate job for the lowest minor version of py3 we want to 
> support in that release.
> * A periodic job for any interim minor releases.
> * (Starting late in the cycle) a non-voting check job for the highest 
> minor version of py3 we want to support in the *next* release (if 
> different), on the master branch only.
> 
> So, for example, (and this is still under active debate) for Stein we 
> might have gating jobs for py35 and py37, with a periodic job for py36. 
> The T jobs might only have voting py36 and py37 jobs, but late in the T 
> cycle we might add a non-voting py38 job on master so that people who 
> haven't switched to the U template yet can see what, if anything, 
> they'll need to fix.

Just to make it easier to visualise, here is an example for how the Zuul 
config _might_ look now if we had adopted this proposal during Rocky:

https://review.openstack.org/611947

And instead of having a project-wide goal in Stein to add 
`openstack-python36-jobs` to the list that currently includes 
`openstack-python35-jobs` in each project's Zuul config[1], we'd have 
had a goal to change `openstack-python3-rocky-jobs` to 
`openstack-python3-stein-jobs` in each project's Zuul config.

- ZB


[1] 
https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs