Sorry, but I don’t understand. Are you looking at fixing support for some Ubiquiti devices in community.routeros
so you don’t have to rely on community.network
anymore? Or are you talking about something else?
Ultimately just weighing in that I use both community.network.edgeos_XX and community.network.routeros_command but I would be happy pulling these via collections so removal of either from the community package seems OK to me.
I’ve been having some issues with Ubquiti routers since they still don’t ship with python3 so looking at possibly adding some other functionality in a new edgeos_xx module so we can carry on managing them via Ansible
community.network.routeros_command has been removed a long time ago, it’s only a redirect that points to community.routeros.command. So you can already stop using community.network for it
The edgeos_XX modules currently are only part of community.network (as far as I know), so someone (maybe you? ) would need to move them to a separate collection.
When do we want to start a vote on removal? I want to give folks a chance to chime in (thank you, @virtualguy, for your feedback!), but I also don’t want this to linger on forever.
How about starting a vote during the next days? That’s also in line with my suggestion from 12 days ago that we should wait for two weeks
Let’s start the vote now. I’ll announce it and will invite people via Bullhorn. It ends on 2024-09-26, so please vote.
UPDATE: has been closed as incorrect, apologies
- Remove collection from Ansible 12
- Keep collection in package
- Remove collection from Ansible 12
- Keep collection in package
Does this vote also include deprecating the collection upstream or just removing it from the package?
As far as I understand the comments above, the vote should be about deprecating the collection itself and, after this has been done, deprecate it in / remove it from the Ansible Community Package.
It’s unfortunate that @Andersson007 didn’t make this clear in the vote.
Actually, now that I’m reading the comments again… we were talking about officially deprecating the collection itself and remove it from Ansible 11 and not wait until 12.
Right, that’s why I wanted to clarify the scope of the proposal before casting a vote.
@mariolenz @gotmax23 i should’ve waited a bit more, didn’t want it to last indefinitely long, sorry. Could you please suggest the formulation? I’ll update the poll after that and will move the vote end time correspondingly.
I’ve tried to change it, but it’s not possible. So feel free to create another vote, sorry once more
Based on the discussion above, I think we should vote on the following: First deprecate the community.network
collection itself since there’s nobody really maintaining anymore, then deprecate it in Ansible 10 and remove it from Ansible 11 as officially unsupported.
If you prefer to keep the collection in 11 and remove it from 12, please vote Reject
. If there’s no majority for removing it from 11, I would open a new vote to remove it from 12.
- Accept
- Reject
- Accept
- Reject
I voted reject
. Ansible 11 is being released in 2 months, and I don’t think that’s a long enough deprecation period. I do support deprecating it immediately and removing it in 12.
The vote on removing community.network
from Ansible 11 has been rejected. A majority of the Steering Committee voted against it.
Based on the discussion above and the fact that the vote on removing community.network
from Ansible 11 has been rejected by the majority of Steering Committee members, I would like to start another one:
First deprecate the community.network
collection itself since there’s nobody really maintaining it anymore, then deprecate it in Ansible and remove it from Ansible 12 as officially unsupported.
- Accept
- Reject
- Accept
- Reject
The vote ended today, and we have a clear decision to deprecate community.network
itself and eventually remove it from Ansible 12: 9 SC and 1 community votes in favor of this, without a single vote against it.