Possibly unmaintained collections in Ansible 10

This is a follow-up to Possibly unmaintained collections in Ansible 9.

unchanged-dependencies.py 10.0.0 8.0.0:

Additionally, I’ve been approached by people who think that these collections also look unmaintained:

  • google.cloud
  • vyos.vyos There has been a new release today both on GitHub and Galaxy
2 Likes

ansible.posix should definitely stay. I’m not sure about the others.

4 Likes

I agree, ansible.posix should stay, even though it doesn’t look very maintained, but it’s also far from unmaintained. TBH I never really understood what’s going on with it and if it does have dedicated maintainers, and if yes, who these are :slight_smile:

2 Likes

I think ansible.posix doesn’t test with ansible-core 2.17, which is a problem. But I might be wrong there. Anyway, even if they don’t and start to do now this doesn’t mean they’ll release another version. And that’s what I’m checking. This is a very simple way to find unmaintained collections, but it’s easy to do and I haven’t find a better one until now. At least not if you want to do it semi-automatically.

Anyway, this is just a list of possibly unmaintained collections :smirk:

I’ll create separate discussions for every collection. This thread is just to keep track.

2 Likes

While one may be able to make the case that ansible.posix doesn’t appear actively maintained, and hasn’t released a new version in a while, or potentially even updated it’s testing, it is an officially supported and certified collection. I cannot say how quickly a github issue may take to resolve, but at a minimum for AAP customers, regardless of whether it has an official maintainer at Red Hat right now, it will get support and fixes (fixes would obviously go out publicly too).

I do know that the team that is largely responsible for all of the internally supported collections, is aware that there is no official owner, and assigning maintainership is being looked into.

In short, I’d ignore ansible.posix, and probably any certified collection that is also owned by RH.

Out partner engineering team does also reach out to partners in regards to certified collections that RH does not maintain, when they haven’t updated or released a new version at least yearly iirc.

4 Likes

@sivel No worries. As I’ve said, this is just a just a list of possibly unmaintained collections.

However, I don’t want to ignore it or any other certified collection that is also owned by RH. There’s a risk of missing collections that really are unmaintained if I do.

BTW I haven’t created a discussion about removing ansible.posix yet. If I do, we should move the discussion there. At the moment, it looks like the outcome would be to not remove the collection. So I guess I won’t.

But please don’t discuss ansible.posix here any further. Open your own thread, or comment in the thread to remove the collection if I decide to open one. At the moment, there’s no question about removing the collection from the community package.

4 Likes

(In case it’s unclear, the “you” in most of @mariolenz’s message isn’t directed (directly) at @sivel, but at everyone looking at this thread. Including myself :slight_smile: )

2 Likes

+1, just providing whatever clarification I could, and insight into how some of these things are managed.

3 Likes

Pointed out in an unrelated topic, but an old bullhorn had a deprecation announcement for some of these collections - The Bullhorn #123.

1 Like

Thanks @samccann, this is really helpful! I’ve created discussions on those collections and linked them in my list. I’ve also mentioned them on Matrix in order to get them in the next Bullhorn.

1 Like

Leave ansible.posix with me. I’ll get back to you in ~10 days (lots of folks out next week due to US holidays).

2 Likes