Hey Thomas,

I'm a Gentoo user and contributor, so I feel the pain of often being "ahead" of where OpenStack is. However, I also know that CI instability is one of the biggest time-vampires in OpenStack development.

I think we are in a pretty happy sweet spot right now: distributions are welcome to test early versions of python. I don't think I've ever seen a forward-looking compatibility change rejected. For instance, when Python 3.11 was in beta, a breakage was detected by Fedora in Ironic and fixed. This is a good example of OpenStack and distribution partners working together to make sure even the newer stuff works.

OpenStack ourselves putting these beta quality versions in the PTI is problematic though; we should ensure developers spend time building software, not tracking down python-beta bugs. As it is, we already spend an outsize amount of time and effort fixing and running CI.

There may be some value in making jobs available earlier, but not voting -- maybe in experimental queue? If folks like you, who are targeting unreleased python distributions, would like a way to check compatibility on demand. I'd happily approve a change to Ironic projects that add this as an option in the experimental queue.

Thanks,
Jay Faulkner
Ironic PTL
TC Vice-Chair

On Tue, Aug 22, 2023 at 9:17 AM Thomas Goirand <zigo@debian.org> wrote:
On 8/21/23 20:16, Ghanshyam Mann wrote:
> Hi All,
>
> Some of you are part of discussion for python 3.11 testing but If you are not aware of it,
> below is the plan for python 3.11 testing in OpenStack.
>
> Non voting in 2023.2
> -------------------------
> You might have seen that python 3.11 job is now running as non voting in all projects[1].
> Idea is to run it as non voting for this (2023.2) cycle which will give projects to fix the issue and make
> it green. As it is running on debian (frickler mentioned the reason of running it in debian in gerrit[2]), it
> need some changes in bindep.txt file to pass. Here is the example of fix[3] which you can do in your
> project also.
>
> Voting in 2024.1
> --------------------
> In next cycle (2024.1), I am proposing to make py3.11 testing mandatory [4] and voting (automatically
> via common python job template). You need to fix the failure in this cycle otherwise it will block the
> gate once the next cycle development start (basically once 891238 is merged).
>
> [1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891227/5
> [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891146/1
> [3] https://review.opendev.org/c/openstack/nova/+/891256
> [4] https://review.opendev.org/c/openstack/governance/+/891225
> [5] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891238
>
> -gmann

Hi,

This is very nice, though, IMO, it's too late. Bookworm was released
with OpenStack Zed, to which I already added Python 3.11 support (if you
guys have some patches to add on top, let me know, but as much as I
know, it was already functional).

So now, the current plan is to ... test on py3.11. Yeah, but from the
Debian perspective, we're already on Python 3.12. The RC1 is already in
Debian Experimental, and I expect 3.12 to reach Unstable by the end of
this year. Once again, I'll be the sole person that will experimenting
all the troubles. It's been YEARS like this. It's probably time to
address it, no?

I'd really love it, if we could find a solution so that I stop to be the
only person getting the shit in this world. :)

What would be awesome, would be to run Debian Unstable, with the latest
interpreter, as non-voting jobs.

Your thoughts?

Cheers,

Thomas Goirand (zigo)