Should we allow moving content out of community.general and to collections that are not part of Ansible?

Quoting myself from

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.

A concrete case where this came up is Removal of avi modules from by chandanapatnala · Pull Request #506 · ansible-collections/ · GitHub - the avi_* modules are pretty unmaintained there (the only change so far was fixed: variable 'rsp' referenced before assignment by rothman857 · Pull Request #218 · ansible-collections/ · GitHub), but vmware.alb is available on Galaxy with the same modules (apparently), and its actively worked on.

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.

1 Like

The following is an updated version of my proposal from Should we allow moving content out of community.general and to collections that are not part of Ansible? · Issue #167 · ansible-community/community-topics · GitHub,

We allow to move content out of c.g and c.n to other collections outside of Ansible under the following conditions:

  1. The new collection is appropriately licensed and does not require a CLA to contribute.
  2. 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.
  3. 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.
  4. 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

  1. motivate that collections where content is moved go through the review process and will also be included, and
  2. 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.)