On 16.06.24 00:06, Jonathan Wiltshire wrote:
Control: tag -1 moreinfo
On Fri, Apr 26, 2024 at 03:05:00PM +0200, Lee Garrett wrote:
I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).
If upstream uses semver then 7.3 -> 7.7 implies new features. Along with a
10MiB diff this is usually a good indicator that it's inappropriate for
stable.
Ack, fair point. I have reviewed the upstream changelog, and the only added
collection between 7.3 and 7.7 is microsoft.ad (out of ~100 collections).
The trouble with a package's time spent in sid as an indicator of
reliability isn't so much the package itself, but all the differences
around it like library versions. We've been bitten by that assumption
before now.
Indeed, that has happened e.g. with the python3-jinja2 dependency in the past.
However, this only happened in major version upgrades of ansible. Newer deps
would warrant a bump in major version number.
I should also mention that I ran this version on my bookworm machine in that
timeframe, and I extensively use ansible for $work.
Are there known issues for users which you can target with fixes rather
than a wholesale backport?
Not exactly. While "ansible" (the package) is a curated collection of smaller
projects, it would theoretically be possible to redo that work by hand with
stricter selection criteria. In practice however I'd have to review ~100
individual projects, which is IMHO not feasible. I'm also unsure how I'd convey
that info to users, as it would neither be ansible 7.3, nor ansible 7.7 in
practice, but something else entirely.
Since this is a fairly large leaf package (~3.7m LoC), I'd more treat it like
other large projects (libreoffice, firefox-esr, etc.) with slightly relaxed
s-p-u criteria.
On a sidenote: While ansible-lint and python-mitogen depend on ansible, this is
just a leftover from the package split in bookworm. They should depend on
ansible-core instead.
If there was an easy way to leave out the few new features, I'd be happy to do
so. I'm mostly worried about the upgrade path from bookworm to trixie. A lot of
collections have added deprecation warnings that will notify users to migrate
away from a certain collection, or use different parameters for the module. And
those are mostly not included in 7.3 yet. One example is the postgresql module:
https://salsa.debian.org/python-team/packages/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst#id765
There are several others in the changelog under the sections "deprecated
features" in each release.
As I have several large playbooks for different $work projects, upgrading
ansible and only then noticing things have been removed is a major PITA. I'd
much rather have the deprecation warnings pop up during a playbook run, allowing
me to fix the deprecated code over time, before upgrading. We're doing our users
a much better service this way.
So in overall I think the bugfixes+deprecation warnings outweigh the slightly
higher probability of regressions from potential new features.
Otherwise maybe bookworm-backports is a better place for this, so users can
choose to take slightly more risk for features, or stick with the released
version and put up with known quantity bugs.
That's an option, I'd see this however complementary to this s-p-u. The package
soon in testing will be three major releases ahead.
Thanks,
