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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
