Mario Lenz

+1 from me to allow removing them, even if the new collection is not part of the community package

> So my proposal would be: allow to move content out of c.g and c.n to other collections outside of Ansible, assuming it is announced in time (roughly half a...

> And here it gets complicated ;-) As opposed to a regular deprecation / removal (i.e. tombstoning), we are replacing plugins with redirects to another collection. Yes, "complicated" is the...

@ssbarnea @Andersson007 What's your opinion on redirecting vs. deprecation / removal?

> So, provided that the committee agrees on removal, maybe we should add the following points to corresponding policy? > > * we can remove stuff only if the superseding...

@felixfontein Please close this issue if done, or open a new forum topic and then close the issue with a pointer to the new discussion: [Community-topics: Archiving the repo](https://forum.ansible.com/t/4990/8)

I also tend to +1 for deprecating and later removing

@gravesm Please close this issue if done, or open a new forum topic and then close the issue with a pointer to the new discussion: [Community-topics: Archiving the repo](https://forum.ansible.com/t/4990/8)

Sorry, I couldn't attend the last meeting. But I had a look at the [discussion](https://meetbot.fedoraproject.org/ansible-community/2023-02-22/ansible_community_meeting.2023-02-22-19.04.log.html). I agree, the removal process is a lot of (manual) work. It would be great...

> Please don't forget that Ansible uses semantic versioning, so we cannot remove anything during a release cycle (except in emergencies, but I don't think this would be one). We...