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!
Long story short: I think it’s better to have maintained content (modules, inventory plugins, whatever) in a collection that’s not part of the Ansible Community Package than having unmaintained content there. The latter sounds like an accident waiting to happen.
If there’s an alternative in another collection, I tend to deprecate and remove the content from c.g / c.n even if this collection isn’t included in ACP.
DISCLAIMER: I’m not involved in c.g / c.n. People who are might think differently and, if they do, I don’t want to contradict them and would follow their lead.
I am involved in c.g and I second @mariolenz on that assertion. I think ACP is bloated as it is and cat-herding doing quality assurance for all those collections is not really feasible.
I say we should take any and every opportunity to make the ACP package leaner, but I am aware this opinion is not shared by many, so not pressing on it.
For this specific case, I would cast my vote on not keeping the code within c.g/c.n collections.
I support allowing content to move from collections in the ACP into collections outside the ACP.
When most modules migrated into collections and we moved away from the “everything-included” model of Ansible, the promise to the community was that the move would maintain pre-existing functionality for pip install ansible.
Today the collections model is mature, and at least some of the modules included in the community collections are outdated (either because the module code is old/unmaintained, or because the tasks the module performs are less relevant, or both). We can migrate little-used modules out of the ACP, either by removing them entirely, or by moving them to collections that are not included in the package. There is a well-documented path to reinstating them, if someone wants to follow it.
(While doing that I noticed that the current rules aren’t explicitly written down. Or at least I was unable to find them. If anyone finds them, please point me to them )
Please add your comments / suggestions to the PR. If there are no more suggestions / discussion for a few days, I’ll start a vote.
I closed the vote. There are 6 SC and 3 community members in favor of accepting the proposal and merging this PR, and zero SC and zero community members against. Since the quorum of SC members is 6, the proposal and the PR are therefore accepted.
)