Some netapp collections scheduled for removal from Ansible 10 seem to be maintained again

We have voted on netapp.aws, netapp.azure and netapp.um_info being unmaintained and removing them from Ansible 10.

However, there seem to be new maintainers and also new releases.

What should we do with them? I think the process to cancel the removal says we have to vote on this. Maybe we can do one vote on all three collections, that would be easier.

Looking at the relevant section of the removal document, I noticed that we never said by whom / when the cancellation process is triggered. My understanding so far (which is my personal opinion and not covered by the document) is that the new maintainers would ask to cancel exclusion, and we look at what happened and vote on it. But so far neither the old nor the new maintainers commented on the removal process at all.

The announcement issues:

The discussion issues:

The only comments in the above issues by anyone of the maintainers were in [Associated vote ended on 2023-07-18] Unmaintained collection: netapp.azure · Issue #234 · ansible-community/community-topics · GitHub, and about fixing a specific problem with the netapp.azure collection.

Those collections still don’t look too healthy to me. For example, netapp.aws supports ansible-core >=2.13 but tests with 2.9 - 2.13 in the CI (which hasn’t run run, anyway, since last year).

So maybe let’s keep them as scheduled for removal from Ansible 10 for now.

I did not address the pending Ansible 10 collection exclusion tickets when creating the ansible 10 directory in ansible-build-data. I guess I’ll wait for these netapp collections before removing those but handle the rest now.

@gotmax23 these shouldn’t be done directly when adding the 10/ directory anyway, but as follow-ups, so it’s easier to revert them if necessary.

In the past, I have done them all together and then used rebase and merge so the separate commits can be reverted, but I guess it doesn’t really matter.

I agree. The (possibly) new maintainers should request to keep the collection in the package. It’s not our job to monitor if collections scheduled for removal are maintained again.

So let’s keep them as scheduled for removal until someone requests us to keep them. Personally, I don’t think we should ask them to do it or inform them about this. If they want their collection to stay in the Ansible community package, it’s their responsibility to ping us. If they don’t, just let’s remove those collections as planned.