I’m not sure what you mean. Only include collections in the community namespace or only include collections that have their repos in ansible-collections? I don’t think including only collections in the community namespace would work, since for example community.aws depends on amazon.aws. I think this would be a problem.
I think there should have to be at least some to tests to make sure the package is not completely broken.
I’m not backing you’re suggestion, but it looks interesting. At least something that’s worth thinking about.
not suggesting 0 tests, docs should build, pkg should build, but not extensive tests on code quality/linting/etc
This does not mean code is not tested, I expect each collection repo to do so, just that you can skip most of it when doing the full package build.
and dependencies would get drawn in, just need to make sure people don’t go crazy there
One of the replies I saw about this notion (can’t recall if it’s here or someplace else) was that there is some assumed quality in the ansible package. So using something included is considered better than just finding something on Galaxy and hoping for the best so to speak. That I think was part of the ‘badge’ idea - to review and give community ‘seal of approval’ for collections that jump through what is today the inclusion checklist for the package.
After thinking about it and reading a lot of people’s opinions and POV’s on the matter, I think I would like the ACP itself to continue as it is. (option 3 in the poll).
I also want @Andersson007’s workload to be reduced where inclusions are concerned. (which more or less has been addressed in the other thread).
That said, I think I would like to have another poll weighing in on some of the ideas that came up in this thread and potentially doing them in addition to maintaining the status quo of the ACP.
This obviously would mean more work than less, but not necessarily at the detriment of the inclusion process itself.
Things I would like to vote on:
Including non-ACP collections in docs.ansible.com
A badge/reputation system. This could be something implemented in galaxy.ansible.com, or in docs.ansible.com (especially if 1. was voted in favor of). This system could reflect who (what team) reviewed and approved of the collection’s content. (core-certified, community-certified, etc)
Building smaller pip package derivatives of the ACP in addition to the ACP itself. The overhead of this might be small if these are built adjacent to the ACP in the same CI.
the funny thing, this exact discussion was taking place about ‘core time’ when we decided to move to collections to make the maintenance and support a lot easier and clearer. At the time i pointed out that community.general was just reducing and transferring the problem vs actually fully solving it. … well, it did solve it for ‘core’ …
I’ve been a bit underwater this last week, just catching up on my notifications
I’d be happy to help on this. One of my goals for the year has been to restart the community surveys, but rather than the small quarterly ones we used to do, go for a big one that covers at least a few questions from each part of the ecosystem (skippable of course, for those not using a given project), and then collate the results in a big blog post. I used to do this a shockingly long time ago and it would be nice to do it again.
I see this as a good candidate to add to that, and as a fairly “charged” topic might prompt more people to fill in the rest of the survey
I will bump this up my todo, and start drawing up a list of questions somewhere that we can work on as a group - those interested can look out for such a topic here in Project Discussions in the near future.
Just to return to this - I was out of action for a good chunk of the last month, which means the survey got pushed back too. I’m still planning it though, and hope to speak to people about possible questions in the next few weeks. I’m gutted I didn’t have it ready for DevConf though.
Hi all, I have cast my votes in the poll. Even though I think that poll is a bit of a simplification of the problem, I think it is a good start.
How long are we planning on leaving the poll open? It looks like option #2 is the most preferred one and assuming we will implement it, is there any time frame being discussed for that work? Just a friendly check
While a large amount of people have responded to this forum (thank you all), for a topic this large about the future of the ansible package I feel that we would want a lot more feedback. I personally see this Forum discussion more of “What do people think, how can we describe the pros & cons” and not a formal vote.
Option 1: Stop including new collections and deprecate the package.
Against and strictly against 54%
In favor and very much in favor 36%
Neutral 10%
Option 2: Stop including new collections, trim down the package to ansible-core + a few collections.
In favor and very much in favor 57%
Against and strictly against 25%
Neutral 18%
Option 3: No changes.
Neutral 37%
In favor and very much in favor 31%
Against and strictly against 32%
To summarize, 57 people voted so far and it looks like the majority of voters is:
against of deprecating the package entirely
but likes the idea of trimming it down to core + those key collections
I agree with @gundalow about larger feedback needed here.
Looks like the survey is coming out soon. It contains related questions.
Let’s wait for its results and see what the (hopefully) larger audience think.
I’ve just re-opened the polls. If you think we should keep it closed, please say it in a comment
I think the overwhelming missing response is: “I don’t really understand the issues in play, but I trust those who do to make reasonable decisions.” (Based on exactly one data point, for what that’s worth.)
