At today’s community meeting we were talking (again) about tests for all collections included in the Ansible community package, from where the discussion ended up with community.network.
Right now community.network is not actively maintained (there’s basic maintenance done by @Andersson007, but that’s basically it). The last feature release was in 2022, and in the last 12 months there only have been a few bugfixes.
One thing that might still be used more are redirects in meta/runtime.yml. There are 46 redirects to other collections, but more than half of these go to community.fortios, which we already removed from the Ansible community package, and several more to cisco.nso (which we also removed). Then there are a few redirects to community.routeros, and one to fortinet.fortimanager (for a httpapi plugin). So from the redirects, only community.routeros users might suffer from short names no longer working. (Whether anyone is still using the community.routeros shortnames is another question.)
So, what do you think? Should we keep it? Remove it? Or are you even an active user of something that’s included in community.network? Please tell us
I support removing the collection due to lack of maintenance and activity. Even the issue tracker on the collection is pretty light which does not point to the collection having many active users — or at least users who are interested in participating upstream, which is what the collection needs to survive.
I want to stress that I appreciate the work that members of the Community Team (including @Andersson007) have done to the keep the collection afloat, but the collection really needs a group of devoted maintainers who use the different modules and plugins and are familiar with the services that they interact with. My understanding is that most of the original authors of the plugins are not maintaining them anymore.
I do support moving content out of the community.network collection, even to collections that are not part of the Ansible package, provided that the removals are properly communicated in the changelog.
@felixfontein@gotmax23 how you folks summarized it all sounds fair. I don’t remember any original authors/maintainers ever responded to bot’s/mine pings… I go there from time to time to fix CI (thanks for reminder) and extremely rarely (due to a lack of changes) release it.
I support its removal from the package.
It’s been there long enough to provide backwards-compatible move after the ansible/ansible repo split.
Now everyone is aware of collections so they can install it manually if needed or move a part of its content to their own collection.
As a side-note: removing the collection from Ansible also removes the current block on removing content from the collection to outside the Ansible community package.
Also currently there are a few deprecations with removal in 8.0.0 in meta/runtime.yml; 8.0.0 there was chosen assuming that there’s a major release every 6 months, which didn’t happen for quite some time now. I guess we should modify the 8.0.0 to 6.0.0 (the next major release, whenever / if ever it comes), otherwise these redirects will still be there in 20 years
In that case, why not deprecate the collection officially due to the lack of someone maintaining it? And then we remove it, similar to frr.frr and openvswitch.openvswitch.
As far as I can see, this discussion will be mentioned in the next Bullhorn. Let’s wait until this has been released and then two or three weeks more so people can react?
I guess it would be best if the collection would declare its deprecation because no one is actively maintaing it itself on Bullhorn to begin with. Like frr.frr and openvswitch.openvswitch did. Ideally mentioning that This collection is not supported with ansible-core>2.17 or There will be no work done on making this collection work with ansible-core>2.17 or similar.
I don’t want to do this because I haven’t worked on this collection at all. I suggest someone who has worked on this collection recently (hinthint@Andersson007).
This would change the situation considerably for us. We wouldn’t start a vote on a collection that’s considered unmaintained or that we know is unmaintained, but on one that declared itself unmaintained. And denies compatibility with / supporting ansible-core 2.18, which the next Ansible Community Package will be based on.
Announce it again in The Bullhorn, to increase the chance that users saw it.
If there is still no reaction in 1-2 weeks, start a vote on deprecating the collection. Since community.network and community.general are officially governed by the SC the SC should officially decide whether they should be deprecated.
I’ve just announced it, i.e. point 1 is done.
So next:
1. If there is still no reaction in 1-2 weeks, start a vote on deprecating the collection. Since community.network and community.general are officially governed by the SC the SC should officially decide whether they should be deprecated.
I agree, let’s wait another 1-2 weeks. But when we start a vote, we should make clear that it’s both about deprecating the collection itself and removing it from Ansible 11.
BTW when do we want to remove it? We said beta1 is a feature freeze release, so I guess we have to do it before this. Correct?
Should we aim to remove it already in alpha1? I’m not sure if we have enough time since ETA is in 2 1/2 weeks, though.
I’m active user of community.network and community.routeros and currently looking at fixing support for some Ubiquiti devices so particularly interested to see how this plays out.
That said removing from community collection seems OK and a managable change to make for us and other end users.
