In the past we actively decided not to allow this, but I think it’s time to rethink this, especially since we are removing collections from Ansible that are unmaintained, and having things in c.g/c.n that are not maintained in that place anymore moved somewhere else where it is maintained is a lot better IMO than keeping a unmaintained copy just for sake of not breaking playbooks when users do pip install --upgrade ansible. Users can easily install the additional collections they need.
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 year before the actual remove happens, i.e. announcing now that removal will happen in the next major release which is close to the next Ansible major release is fine).
What do you think, is this good enough to vote on, or do you have other ideas, comments on this, …?
If nobody beats me I’ll eventually combine the last few comments here into a new proposal. For now I’m keeping just this stub so this disucssion doesn’t get lost.
We allow to move content out of c.g and c.n to other collections outside of Ansible under the following conditions:
The new collection is appropriately licensed and does not require a CLA to contribute.
None of the contributors who contributed to the content in the last 6 months objects in a four-weeks period after the plan to deprecate the module has been announced.
There is a deprecation period of at least 6 months during which deprecation warnings are shown. The deprecation notice must mention that the content is moved to a collcetion outside the Ansible community package, and that users need to install that collection separately.
If community members or contributors bring up good reasons in these 6 months to not do the move, the Steering Committee will discuss these and vote on them before the content is removed.
Redirects are only added if full backwards compatibility can be ensured. If they are not used, tombstoning has to be used, and the tombstone message needs to explicitly mention the new collection and that the content in the new collection is not fully backwards compatible.
What do you think, in particular @SteeringCommittee? Does this sound reasonable / acceptable / …?
Does it really need to be a requirement to move them into another collection at all? What if it’s not maintained, and no one really wants it?
I’m fine with allowing things to move out, I just wouldn’t make it a requirement that it needs to go somewhere. It could just get deleted, and it lives in an old branch, if someone wants it later, they could always just pull it into another collection.
It’s not a requirement at all; collections can deprecate and tombstone content whenever they want. We have no rule against that. But we do have a rule that you cannot move content to a collection that’s not part of the community package.
I think the ideas behind this were to
motivate that collections where content is moved go through the review process and will also be included, and
improve the user experience by ensuring that redirects introduced in collections contained in the community package again point to the community package.
(I guess we started violating the idea behind 2) a bit ourselves by excluding collections from Ansible in the past.)
Coming to this one a bit late. I think in the case that a module is unmaintained in c.g or c.n , yes definitely we should allow it to be moved to a non-Ansible-package collection.
For the example where there is now duplicate development on a module - again, feels like your set of proposed guidelines works well and will eventually resolve this problem.
So my non-SC opinion is … start the vote on this one!