Thomas Huth <th...@redhat.com> writes:
> On 14/02/2023 08.40, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> writes: >> [...] >> >>> We don't have to drop python 3.6. It is a choice because >>> of a desire to be able to use some shiny new python >>> features without caring about back compat. >> I read this on Friday, and decided to let it sit until after the >> weekend. Well, it's now Tuesday, and to be frank, it's still as >> offensively flippant as it was on Friday. It shows either ignorance of >> or cavalier disregard for the sheer amount of work some of us have had >> to put into keeping old versions of Python viable. > > I'm a complete python ignorant, too, so I'm a little bit surprised of > the amount of pain that these scripts are causing. > > No matter of that fact, I think Peter still has a point that we have a > real conflict here with our current support policy. So this either > means that Python was the wrong choice for our needs (since it is > moving too fast and causing too much friction), or we should really > rethink our support policy. > > I guess we're too deep into the Python rabbit hole already, and I'm > not aware of any other good solutions (back to Perl scripts? No, > thanks!), so it's likely quite impossible to tune that knob. > > Thus we should maybe really start talking about our support policy > now. I think the main problem is likely the sentence "Support for the > previous major version will be dropped 2 years after the new major > version is released". Maybe we should shorten that time frame to 1 > year. I think this should be a fair approach. Generally I recommend avoiding installing a new LTS until at least the first tick release has ironed out the obvious bugs. A year seems like a fair grace period to update to the next LTS. Those that like sitting on old maintained LTS releases are less likely to be tracking the bleeding edge of development anyway and likely are happy with their distro provided packages. BTW my next testing/next finally updates the last few Ubuntu 20.04 to 22.04 systems which also allows removing a few tsan and clang hacks in the process. Progress might not be a straight line but it averages out in that approximate direction ;-) > The 2 years caused some confusions in the past already, since > e.g. Debian only supports the previous major release for only one more > year, and macOS also releases a major version each year ... so IMHO we > could shorten the time frame for the previous major release to 1 year > instead. People then could still continue building QEMU on CentOS 8, > but they have to be aware that they might install other software like > Sphinx manually if they want to continue using QEMU with docs there. > What do you think? Works for me at least. -- Alex Bennée Virtualisation Tech Lead @ Linaro
