Control: tag -1 = bookworm confirmed
On Tue, Jun 25, 2024 at 03:25:53PM +0200, Lee Garrett wrote:
> 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.
Please go ahead.
Thanks,
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
