On Fri, 2022-07-15 at 14:44 +0200, Radosław Piliszek wrote:
On Fri, 15 Jul 2022 at 11:59, Thomas Goirand <zigo@debian.org> wrote:
Not only for the interpreter, if we could find a way to test things in Debian Unstable, always, as non-voting jobs, we would see the failures early. I'd love we he had such a non-voting job, that would also use the latest packages from PyPi, just so that we could at least know what will happen in a near future.
Well, we can have periodic and experimental, master-only jobs to test things on Debian unstable because it's always interesting to see the upcoming breakage (or better yet - be able to pinpoint it to a certain change happening in Debian unstable that caused it).
for the nova ci we have moved centos 9 stream jobs to the periodic-weekly pipeline and we are going to monitor it in our weekly meeting. i dont really have any objection to adding a debian testing or debian stable based job there too. be it in the form of a tempest job or tox job. we dont really have the capsity either in review bandwith or ci resouce to have enstable distros in a voting or non voting capsity on every patch i.e. check and gate pipelines. but a weekly periodic its proably doable. one thing we have to be carful of however is a concern i raised last cycle with extending 3.6 support. some of the 3.6 deprecated fature were drop in 3.10 and more feature that were depfreced in later releases are droped in 3.11. while we can try and support the newr releases 3.9 compatiable will be needed for a long time. so if 3.11 or 3.12 is fundementaly in compatibel with 3.9 due to a libary change ectra that will be problematic sicne cento 9 derived distro will be on 3.9 for several years to come. i dont actully know the exact lifecycle uels for how often new centos/rhel majory reseas happen but its usuarly aroud the .6 release of the current release that the .0 release of the next majory version happen so every 5 years or so. i really dont know the plans for rhel 10 but for rhel9/centos 9 lifetime 3.9 will be the python version used so we need to balnce fast moving distors like debian and slow moving distors like centos and enable both. that might mean we will ahve to drop some deps, avoid some features or utilise compatablity libs in some cases similar to six or mock the lib vs unittest.mock so when fixing any 3.11 incompatiablity we need to still maintain 3.8 compatiablity for zed and 3.9 compatiblity in AA+ i woudl guess it will be the CC or DD release before we coudl consdier droping 3.9 suppot but i think we could drop 3.8 in AA.
The job would only utilise the interpreter and the helper binaries (like ovs) - all targets I can think of are capable only of using pip-installed deps and not Debian packages so that part we cannot really cover reliably at all. If that makes sense to you, we can work towards that direction. The biggest issue will still be the bootability/usability of the infra image though.
-yoctozepto