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-upd... 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... 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.