Files

Thierry Carrez dc88521cf1 Separate goal definition from goal selection

As discussed at the PTG in Denver, one issue of the current
goal selection process is that it conflates definition of the
goal (which is ideally an iterative process) with selection of
a specific goal for a series, in a single review.

This has made it hard to process goal reviews in the past,
especially considering we need to select the set of goals
(as collectively feasibale together in a single cycle), and
not select them individually.

This change proposed to set up a three phase process. Wishlist
goals that do not have a champion ready to drive them yet should
live in the backlog etherpad. Once goals have a champion, those can
iterate through goal definition in a specific "proposed" directory.
Finally, when time comes for us to select goals for a specific
series, we can propose a set of goals in a single review (by
proposing a set of moves from the proposed repository to the
selected/series repository).

This should hopefully address the review issues that have been
plaguing the goal definition and selection process in the past, as
well as let us vote on a selection of goals using Gerrit, rather
than try (and fail) to rely on out-of-band mechanisms.

Change-Id: I9e00a0d9c3eb91ec6b1048c773d84032d3ce9f0e

2019-07-24 11:35:16 +02:00

5.2 KiB

Raw Blame History

Update Python 3 test runtimes for Train

This goal is to implement the process set out in the ../../../resolutions/20181024-python-update-process TC resolution, for the Train cycle to ensure unit testing is in place for all of the ../../../reference/runtimes/train.

In practice, this generally means adding unit tests for Python 3.7 and dropping unit tests for Python 3.5. Using the Zuul template for Train will ensure that all projects that support Python3 will be tested against the agreed runtime versions, and make it easier to update them in future.

Champions

Corey Bryant (coreycb)

Gerrit Topic

Use python3-train_.

Some existing patches that do not use the Zuul template exist under the topics py37-job_ and dropping-py35-testing_. Any of these not yet merged should be updated to use the Zuul template instead (and the topic changed to python3-train), or abandoned.

Completion Criteria

Any repositories with Python 3 unit tests are exclusively using the openstack-python3-train-jobs Zuul template or one of its variants (e.g. openstack-python3-train-jobs-neutron) to run unit tests, and the tests are passing. None of the Zuul templates that hard-code a Python3 version (e.g. openstack-python35-jobs) remain in use.

Details

The scope of this goal is all official OpenStack repositories that include at least one Zuul job that runs unit tests on some version of Python3.

The goal champions will propose patches to all affected repositories to add one of the following templates to their Zuul configuration (depending on the existing template used):

openstack-python3-train-jobs
openstack-python3-train-jobs-horizon
openstack-python3-train-jobs-neutron
openstack-python3-train-jobs-ceilometer

The patch should also remove all openstack-python3*-jobs[-horizon/neutron/ceilometer] templates from the Zuul config.

The change will be self-testing in Zuul. If py37 tests are failing, it is the responsibility of the project team to fix them so that the change can merge. Project teams should merge the change to the Zuul config before the end of the Train cycle.

Stretch Goals

Ideally the proposed patch should update setup.cfg for any repositories where the classifier contains Programming Language :: Python :: 3 to ensure it contains:

Programming Language :: Python :: 3
Programming Language :: Python :: 3.6
Programming Language :: Python :: 3.7

and no other Python 3 versions.

Also, it would be nice to update the list of default environments in tox.ini to include py37 and remove py34 and py35.

Future Process

As part of this goal, we will add support to the release management tools to have a bot submit the change as part of the process of cutting the previous release's feature branch. Graham Hayes (mugsie) has volunteered for this task.

Having done the initial switch over of the Zuul templates in Train will make those patches simpler to generate (they will need only to substitute the next release name). It will still be up to project teams to fix any test failures and merge the patch even in future release cycles.

Non-Goals

Python 2 testing remains unchanged. Repositories that unit test on Python 2 should continue to do so using the openstack-python27-jobs Zuul template, and declare support for Python 2.7 in setup.cfg. Testing of Python 2 must not be dropped before the U cycle, as detailed in the ../../../resolutions/20180529-python2-deprecation-timeline TC resolution.

References

../../../resolutions/20181024-python-update-process
../../../reference/runtimes/train
Porting to Python 3.7
../../../resolutions/20180529-python2-deprecation-timeline

Current State / Anticipated Impact

There are a handful of breaking changes between Python 3.6 and 3.7. The most notable one is PEP 479 (making it an error to raise a StopIteration exception from a function or generator), but much of the impact is in exposing pre-existing bugs which ought to be fixed anyway (non-erroneous uses are generally trivial to eliminate).

Many projects have already merged patches to test on Python 3.7, so in those cases the project should have nothing to do but merge the patch.

Because the goal champion team will prepare the patches to change the Zuul configuration, we expect project teams to require minimal effort outside of fixing any Python 3.7 incompatibilities.

5.2 KiB Raw Blame History