Apologies if this has come up before and/or beaten to death.
I wonder if it makes sense to prune a lot of modules in core and extras; take them out of those repos and let them be their own projects – which get installed by Galaxy (or even by pip, as I think that would take advantage of many man-years of work on pip, PyPI, etc.)?
Advantages:
- There will be a lot less PRs for the core team to go through => less work => less stress
- Core team members can spend more time on solidifying the core and less time having to know about a bunch of specialized modules. Let the subject matter experts concentrate on the modules that they know and care about and can easily test.
- PRs to core can get merged sooner – there is a substantial backlog at the moment.
- Modules can be developed quicker, without being couple to an ansible release. Many of the modules could probably have a faster development cycle, but are held back by the fact they are released with ansible.
I think the “batteries included” approach (as people often speak of in referring to Python) is a great one, but there are some conditions under which things work better and others where it doesn’t work as well. I think “batteries included” works well when you have a reasonable number of batteries that are well-understood and stable and not likely to change much and are used by a large proportion of the population. There are probably a bunch of ansible modules that fit this criteria but probably also a lot that don’t fit these criteria, because they have evolving feature sets, are developing quickly, are very specialized and used by a small number of users, are difficult to test without having expensive hardware, etc. If you look at Python, you’ll find that they are very discerning about what they will accept into the core. And they are clear that not accepting things into core is not only a benefit to them (less stuff to maintain), but it’s often better for the code in question (it can evolve much faster when not coupled to a Python release).
Thoughts?
Not speaking for the core team, but here's my $0.02:
I think most people agree in principle with what you're saying. The
question is, how is it best achieved?
This was precisely the rationale for the Core/Extras split -- which
has yet to pay full dividends.
The need for Core is clear. Perhaps it could be smaller.
The need for Extras is also clear: there needs to be a space for
promotion/relegation of modules.
The focus, for now, is Ansible 2.0. Once that's out the door, the
focus will move to making the most of the Core/Extras split, with a
more solid platform to work from. That will be the time to have such a
discussion in earnest, I suspect.
--g
Marc,
Ansible already makes it easy for you to use 'non official' modules
and other plugins, it was designed for this since the start. Just drop
it in a appropriately named directory adjacent to your play, in your
role or set in your ansible.cfg.
So why do so many people submit the plugins instead of using and
sharing them directly?
One of the reasons is that they prefer 'official' modules as they
already trust the ansible project and that extends to the plugins
included. Those included in the project tend to have a normalized
interface, this is something we strive for to keep the user experience
from diverging too much (we can use your validate_certs vs verify
parameter as an example). Another reason is that the core team looks
at function reuse and sharing and we push the PRs in that direction.
Please note that we are currently closing issues much faster than they
open, but we still have a large backlog to deal with from when this
was not the case. I agree not everything needs to be in ansible and
that there are still improvements to make, we have opened other
threads in ansible-devel to discuss this with the community and have
been trying to improve the process as we go. One of those is to make
both galaxy and extras a better place to share, discussions over which
are still ongoing.
We have also instituted a freeze on features during releases, as
another complaint was about release instability, this is why we
currently are on 1.9-RC2. This of course impacts the merge rate of PRs
that add features, we try, but we have not been able to have it both
ways 
.