The core team has mostly only released packages to pypi, the Ansible
site and a PPA, never to the downstream distributions. We stopped
adding packages to our site as they were not really used and most of
the distributions had their own packages already. It made more sense
when we were still a new project that most distros didn’t know about,
much less included in their repos, that is not the case anymore.
Especially now that it is almost trivial to create your own package if
needed with existing tools, just point at pypi or github for the
sources.
Understood re: the responsibility of packaging, pushed down to the subject matter experts with packaging concerns.
My concern relates to enabling collaboration. For me, the Ansible project represents a point of collaboration, where users share concerns, and work together. While it is normal for patches to be first introduced locally for the people with an itch to scratch, a key value of open source is the ability to contribute upstream changes, and share the overhead. So, where should this collaboration happen? Where should these patches be shared? If the “community” has patches against a release such as Ansible 2.9, where should they be posted to, such that others can also access them?
To me, for packages to be held downstream in a RPM .spec file for an extended period of time, is a small failure to collaborate. It is a papercut. But, enough deep papercuts, or many papercuts leads to bleeding.
Now, it’s possible that Ansible 2.9 should die - and the packagers are being hostile. Or, perhaps a company like Red Hat might be forced to support a product long past it’s normal end of life. In such a case, a company like Red Hat might be forced to set up their own test infrastructure and provide headcount to support these older releases. But, it doesn’t look like we are truly there yet. I still see patches on Ansible 2.9. You still have automated tests and builds running. Everything is still set up to support Ansible 2.9 in Github. It is still a place where changes can be shared. This makes it a choice to block merges.
I’m not sure where you get your numbers about 2.9 being the ‘current’
used by most, it’s not even the ‘current’ available in many distros:
Gentoo: ansible-base 2.11.6 (this is really ansible-core but i think
packager didn’t want to deal with name changes every version)
Arch: ansilbe 4.7.0-1 (community package, which includes ansbile-core 2.11.6.)
ubuntu (20.04 focal: 2.9.6
ubuntu (21.04) hirsute: 2.10.7 (which is ansible-base)
ubuntu (21.10) impish: 2.10.7
debian bullseye: 2.10.7
freebsd 13: 2.9.23 (14 is due soon, not sure what they are using yet)
It’s probably just me - but most of those are not “many users” to me. A lot of older Ubuntu out there, and almost nobody I know uses Debian, FreedBSD, Arch, or Gentoo. For me, I checked the distributions that were important to me, and everything is 2.9 today.
Those are just the ones I have at hand, I’m pretty sure you’ll find
others with 2.9, 2.10 and 2.11 just depending on how aggressive the
distros are at updating versions and their own release schedules. As
for @sivel, he responded mostly with RH/fedora/Centos as that is what
he mostly deals with daily, I deal with the ones above, so that is
what I can respond to easily.
Yes, but @sivel confirmed that outside of Red Hat’s subscription services, 2.9 really is what is common still. He didn’t use these words, but he confirmed that 2.11+ support was entering CentOS Stream, which is confirmation that it is not deployed beyond CentOS Stream.
In the end the decision about not updating 2.9 comes to a policy,
which was created due to limited core resources, we cannot maintain X
versions forever, specially since the value of X changes depending on
who is asking, I still get requests to update 1.7 and 1.9. We also
cannot revise it any time a distro chooses to stay on a specific
version (for example,Debian was pinning a version due to licensing in
some files not passing their tests), it just does not scale.
I totally agree. You shouldn’t support all releases forever. But, you do support 2.9 right now. And, I took a look through the patches - and while they are small and few, they are not “security fixes only” as @sivel suggested, nor are they “critical fixes only” as I summarized. There was a choice made to include or exclude particular patches, as there should be. But, a very trivial request to ensure that Ansible 2.9 can reliably work against an Oracle Linux target machine, that has been in 2.11 for most of 2021 without apparent issue, was blocked. It’s a one line change. So, let’s avoid extremes here. Changes are being made to 2.9, and a very trivial change was rejected. This was a choice. It was probably less effort to merge the change, than to argue with me.
This policy has been clearly stated and in place for many years (you
can check the versioned documentation, it is in git after all) and I’m
confident that our record would speak against any perceived bias, as
long as you are willing to examine all the facts.
I looked the changes, and from my perspective - many trivial changes have been introduced over the last year. I think “allow Ansible to remotely manage Oracle Linux 8” is both a trivial change, and an important enough change to merge.
You disagree?
