On 26/10/18 5:09 AM, Thomas Goirand wrote:
On 10/22/18 9:12 PM, Zane Bitter wrote:
On 22/10/18 10:33 AM, Thomas Goirand wrote:
This can only happen if we have supporting distribution packages for it.
IMO, this is a call for using Debian Testing or even Sid in the gate.

It depends on which versions we choose to support, but if necessary yes.

If what we want is to have early detection of problems with latest
versions of Python, then there's not so many alternatives.

I think a lot depends on the relative timing of the Python release, the various distro release cycles, and the OpenStack release cycle. We established that for 3.7 that's the only way we could have done it in Rocky; for 3.8, who knows.

I don't really understand why you're writing that it "depends on which
version we choose to support".

The current version of the resolution[1] says that we'll choose the latest released version "we can feasibly use for testing", while making clear that availability in an Ubuntu LTS release is *not* a requirement for feasibility. But it doesn't require the TC to choose the latest version available from python.org if we're not able to build an image that we can successfully use for testing in time before the beginning of the release cycle.

[1] https://review.openstack.org/613145

That's the kind of answer which I found
very frustrating when I submit a bug, and I'm being replied "we don't
support this version". My reasoning is, the earlier we detect and fix
problems, the better, and that's orthogonal to to what version of Python
we want to support. Delaying bugfix and latest Python version compat
leads to nowhere, and best is to test with it if possible (even in a
non-voting mode).

I agree that bugs with future versions of Python are always worth fixing ASAP, whether or not we are able to test them in the gate.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to