Thanks Andrei — and thanks for writing this up in detail rather than just calling the vote.
You’re right on the substance, and I want to correct the record on my own self-check first, because four of its claims don’t survive contact with the repository:
-
“No test/sanity/ignore*.txt — no errors ignored” — false. The files exist at tests/sanity/ignore-2.19.txt … ignore-2.22.txt, 519 entries each, byte-identical across all four. I checked test/sanity/ — the path as worded in the checklist — and never looked at tests/sanity/, which is where ansible-test actually reads them from. Of those 519, 217 per file named a code on the must-not-ignore list, plus 96 undocumented-parameter entries whose only two permitted exceptions don’t apply. There were also zero justification comments, which is itself a requirement.
-
“524 modules” — the collection has 1,027 (457 write + 570 _info).
-
“README declares ansible-core 2.19+ / Python 3.11+” — the README said 2.16 / Python 3.10 while meta/runtime.yml says >=2.19.0 and CI tests 3.11–3.13. The README was wrong and advertised a floor nothing had ever tested.
-
“ansible-test sanity passes” — it had not run on main since 2026-09-23, and did not run again while this work was in progress. An earlier step in the same job was failing, so sanity and units were skipped on every push after it.
That last point is the one that matters most, because it was hiding the actual state: the commit this work is based on carried 1,625 validate-modules errors. The merge eecbc03e kept the three-fragment extends_documentation_fragment block from one parent and dropped the retry / user_agent / waiter fragments the other parent had added, so 509 modules documented four options they accept nowhere. Our own sync_doc_fragments.py could not see it — it added an option fragment only when it also found an inline copy to strip, so a module with neither the inline text nor the fragment was reported as “nothing to do”, and --check never asserted the fragments were referenced at all.
On the documentation you were right too, and it is not a handful of modules: 372 documented at least one option as a single-line flow mapping. Only 4 of 1,027 modules documented check mode or idempotency.
And the ignore files were the design, which is the part I have least to say in defence of: check_sanity_ignore.py enforced BASELINE_TOTAL, a budget with headroom, and devel.yml documented copying ignore-2.21.txt to ignore-2.22.txt when a new core minor arrives. That is the opposite of what the requirements ask for.
What has changed — all of it verifiable on #18, which is the first green CI run on this repository since 2026-09-23:
|
before |
after |
validate-modules errors |
1,625 |
0 |
| ignore entries per file |
67, of which 25 forbidden |
36, none forbidden, all justified |
| modules with flow-style option docs |
372 |
0 |
| modules documenting check_mode / idempotency |
4 |
1,027 |
| collection guards passing |
15 / 19 |
19 / 19 |
ansible-test sanity is 24/24 on 2.19 / 2.20 / 2.21, with 518 script tests, 10,940 unit tests and 2,364 contract tests passing. The ignore guard is a ratchet now: it fails on any must-not-ignore code, requires a justification per entry, and caps both the per-code count and the total, which may only decrease. Four checks that were already red on main for unrelated reasons are fixed as well, since a pipeline that fails early is how all of this stayed invisible.
Two things I am not claiming. 1,509 option descriptions (26%) are still under 25 characters — “ALB ID.”, “Desired state.” They are readable now, not informative, and filling them in needs per-option product knowledge; generating them mechanically is the thing you objected to, so I have left it as authoring work rather than automating it. And no integration run is claimed, because the targets need a real account.
On the wider question, I don’t think I can defend 1,027 modules — most of them niche — as package material, and you and Felix are right that usefulness rather than size is the metric. I would rather apply the compliance work to a curated subset covering the products most users actually need (compute, network, storage, containers, core databases, identity, DNS, logging) and keep the full catalogue on Galaxy, where it already is and installs fine. I’d like to bring a concrete candidate list to the discussion rather than assert it here.
If it’s useful to the committee, I’d ask that the vote on this collection be separated from the broader package-shape proposal, and that this request be re-reviewed against the remediated state — but that is the committee’s call, not mine, and I would rather you had an accurate picture either way.
Thanks again for the detail. It’s a fair review, and the two things you flagged are the two things that were actually wrong.