I’m curious to know what the process is for Ansible Content to move out of the community.general collection into their own collection or being included in an existing collection. community.general is such a large collection. It seems to be the catch-all for wayward plugins. Is it because there aren’t enough to warrant their collection?
There are only three LVM modules for example. While there aren’t enough to be in their own collection, would they not fit into a collection like ansible.posix?
Looking forward to learning more about this process.
As for wayward plugins, I think that comment fits. really just “is used but has no direct maintainer tied to them”. I think if folks have a want to maintain or move them out, they can follow the docs and move them out but it is under the assumption that the maintainers follow a few guidelines (mainly continuing releases and having the collection included in community distro) and abide by CoC.
CC @felixfontein for more links or comments if they have them.
Thanks for the link @thedoubl3j . Curiosity satisfied.
While maintaining a collection sounds like a good way to give back to the Ansible project and community, I’m probably not a good candidate for doing that. Not much of a programmer.
As for moving the LVM modules to ansible.posix: AFAIK ansible.posix is a Supported collection (i.e. RH offers commercial support on it), so the content moved there (instead of community.general) was quite restricted on the initial move. I don’t know what’s ansible.posix’s current policy is for adding completely new content. So that is probably the main problem with moving content from community.general to ansible.posix.
And for splitting community.general up into smaller collections: that is brought up regularly as well, the main reason why this isn’t happening is that someone would have to maintain these smaller collections. We already moved some content out where there were active maintainers; some of these collections are still maintained, some others are now unmaintained. Right now PRs to community.general have a chance of being merged even if there are no active maintainers for that piece of code, and there are regular releases. But once something has been moved to its own collection, it can easily happen that nobody maintains that collection anymore and it is impossible to get new releases for it or get PRs merged. That’s currently the main reason why community.general is still there, and even growing (there are folks who want to contribute new content, but not have to maintain a whole collection just for that).
I’m sure this is a big issue for the project. A big desire for new and shiny things, but little desire to keep them updated. What does it take to maintain a collection? I’m sure having written at least a module or other plugin would be helpful, which is on by to-do list, for fun/experience if nothing else.
Make sure CI keeps working. This regularly requires some work, especially around new ansible-core releases (and also inbetween when you test against ansible-core devel);
Review, potentially test, and (if acceptable) merge PRs that others create for fixing bugs or adding new features. (If you want to fix everything yourself and implement all features yourself this isn’t necessary that much, but then you have another big chunk of work )
“Regularly” do releases (like when some new bugfixes are there, or new features, so that these fixes and features can actually be used by users).
Especially 1. and 3. usually aren’t that much work, but only if you do them often enough that you’re familiar enough with them. Otherwise you spend a lot of time familiarizing yourself with the details every time it needs to be done.
2. can vary from little to a huge amount of work, depending on how popular the collection and its content is, and how many others help with this. Thoroughly reviewing PRs is a lot of work, and it helps a lot if you know the code it changes well enough.
Tool to adjust the GHA CI matrix, assuming that a standardized CI matrix is used, for example the one from https://github.com/ansible-collections/collection_template/blob/main/.github/workflows/ansible-test.yml. This could allow adding new ansible-core versions (including copying tests/sanity/ignore-2.x.txt over), or removing existing ones (synchronized with meta/runtime.yml?). Obviously it won’t work with special purpose CI matrixes.
Having this as a GitHub bot would be also nice, especially the “add a new stable branch” operation. Automatically getting a PR once a new stable-2.x branch is created in ansible/ansible would be neat.
Tool to simplify releasing a collection, assuming a simple release model (releasing from main, or a previous major release from stable-X). Half of this is doing git operations, so this probably needs some integration with git (or GitHub using the gh CLI tool).
I guess there could be more, maybe other collection maintainers can weight in
Ah, I think I may have been unclear - when I say “toolkit” I’m really saying “docs” because we’ve been working on things like the Meetup Toolkit, Docs Toolkit, and so on. If the issue is “familiarisation”, then we could perhaps collect feedback from maintainers and write up some best practices?
Is it because there aren’t enough to warrant their collection?
)