Hi Lee, Am Dienstag, den 02.02.2021, 03:56 +0100 schrieb Lee Garrett: [...]
> Backporting a new feature release will be disruptive, as ansible > deprecates many things within 2 feature releases. Meaning that an > upgrade in oldstable from 2.2 to 2.7 will likely break the playbooks for > most users there. In stable the bump would be from 2.7 to 2.9, which > will be less disruptive (but still break some playbooks). However, my > gut feeling is that most users are using stable-backports (or straight > sid) for their workstations, anyway. Thanks for your reply! That sounds like ansible is only borderline suitable for a Debian stable release in my opinion. I can understand that people upgrade to stable-backports to get new features but using sid (really?) on a production system is rather brave. I also find it strange that we assume users will use -backports and sid updates, which should regularly break their playbooks, but we don't consider to provide regular updates in supported stable releases. I have had a look at how Red Hat supports Ansible and I found this page. [1] They appear to limit full support and provide only targeted fixes for a couple of months and then urge users to upgrade to the next supported upstream version. I suggest we consider doing something similar in the future. It could be mentioned in the release notes at least. I believe it would be more transparent and fair to acknowledge that Ansible is not your typical long-term supportable package. > The other thing is that there are no unit tests (I'm currently working > on them for 2.10). In 2.3 for example there was a fatal bug that only > appeared with certain versions of python-jinja2 (it was fine in sid back > then, but broke in testing), so I'd be very hesitant to backport feature > releases without thoroughly testing them. In the future backporting (for > -security and for -backports) will get better when there are unit tests > in place. Ok, indeed the lack of unit tests and testing capabilities in general makes it difficult to maintain ansible in oldstable and stable right now. > > All in all, we could try to backport the latest version to older stable > > releases or we could walk a middle way and base the patches all on Buster > > or > > the newer buster-backports version or something in between. This would > > certainly reduce the maintenance costs in those older releases. > > > > What are your thoughts? > > I'd leave oldstable untouched; I don't believe there are any users on it > anymore. > For stable I'd backport only the security fixes, though I'm fairly > certain those won't be straight forward, as upstream does refactor > larger chunks of code in every feature release. I believe they all were > pretty low-impact CVEs, upstream tends to err on the side of caution and > give things CVEs very easily. I think it's fine to wrap them up in a > Debian release and release it via stable-updates. Fine with me. I will investigate the remaining issues in stable and try to fix as many of them as reasonably possible and get back to you. However I feel we should try our best effort for oldstable too because if you make something available and claim it is long-term supported then there are usually some users left who still use your package unless they know way beforehand about the difficulties. As I suggested we probably should make it explicit in the Debian release notes and simply announce the EOL status after support for Debian stable has ended. Regards, Markus [1] https://access.redhat.com/support/policy/updates/ansible-engine
signature.asc
Description: This is a digitally signed message part
