During the Ansible 12 release cycle, we communicated to collection maintainers far in advance of the release by mass filing issues that major changes were expected in Core 2.19 and that they should make sure their collections were tested and compatible. I’m not sure if we weren’t clear enough about when this work had to be completed by (i.e., by the Ansible 12 feature freeze) or if the issues were just ignored or if there were other RH-internal factors at play, but several collections were not compatible with Core 2.19 in time for the Ansible 12 feature freeze, and we only found out about this after fact.
Overall, this situation was not ideal, and it created schedule delays and extra work for the release managers and last-minute decisions that the Release Management WG had to make without a complete formal vote from the Steering Committee. I created this thread to have a retrospective and to figure out ways to improve communication with collection maintainers and prevent something like this from happening in the future.
I think filing issues was a good start, but I think we need to more clearly communicate a due date (we could prefix issue titles with [DUE BY 20XX-XX-XX], for example, where that date is the feature freeze or a little before it in the issue titles) and perhaps follow up with maintainers after a certain amount of time.
I like this, it follows the format we use for Forum Posts with due date, ie votes.
We need to be mindful whatever do if dates change.
I think every mass created GitHub issue should link to a Forum Post, and reinforce that’s where the discussion should happen, do all collection maintainers can learn and support each other.
The Ansible Community Engineering team and Ansible Partner Engineering teams both report to me. So I believe we can improve this with more careful wording on the communications that Ansible engineering sends out, and being explicitly about the context (community or Partner).
Yeah, I’ll chime in here. There’s a few kind of difficult points with this I think, which have kinda been mentioned but I’ll give my thoughts on…
Dates. The issues filed were not initially super clear on when things needed to be fixed up by. That would be a huge help, especially for any folks in the situation we’re in, where we don’t have a dedicated team handling just the collection itself, and we need to be able to sort out how to prioritise that amongst a lot of other things we’re working on.
Partner Engineering vs Community package stuff. There’s kinda two completely separate streams of support for anyone who is a Partner and distributes packages on Automation Hub, which makes it rather confusing which versions of which packages we’re expected to support for how long for Certification/Partners vs inclusion in the Ansible community package versions. Additionally, while we do get email communication from Partner Engineering we often find it kind of confusing; there’s a lot information in that mailing list (which is great!) but I think it kinda falls afoul of… well, naming/versioning confusion in a lot of ways wrt ansible-core v.s. Ansible etc. Especially since these versions have totally different support lifecycles, seemingly.
There’s sort of confusing mixed messages at points that I recall getting around like. minimum ansible-core supported versions for Partner packages, which need to be respected for certification. But these can be a bit confusing when it comes to the Ansible community package, which seems to operate on a very different lifecycle and minimum version requirements, seemingly, but equally the collection needs to be certified which is a Partner requirement in order to be continually included in the Community package. So there’s… overlapping requirements, almost. They don’t conflict I think but it can cause confusion and miscommunications when both teams want something but we’re given slightly different communication from both.
I think the lifecycle docs were clarified a bit, which helps. But… yeah, communication around it is a bit funky still.
And since we have to handle seemingly both keeping things up to date for use in AAP and also the Community package, not quite separately but trying to track both requirements as they’re a bit divergent is tricky. It… almost feels like the Partner engineering email lists would probably benefit from being more aware of the Community lifecycle and possibly also keeping us up to date there if possible, so that all the information is there and can be presented kinda at once or side by side.
But. ultimately yeah the main things are. Clearer timelines when issues like that are filed and… dunno, maybe a bit more awareness between the two teams as to what’s going on on the other side of the fence and being a little more careful about how stuff is phrased, to be very clear which requirement applies where and why, that sort of thing.
I’ll reply in more detail to @gundalow and your posts when I have time (you both raised very good points — thank you!), but I wanted to clarify that, as fair as I know, this is not the case. I recall that some collections were initially grandfathered into the Ansible package during the early days of the Ansible community package, but for all new collections, the Community package review process and Red Hat certification are separate processes.
Also, one note: we (community) know nothing about the communication between Partner Engineering and collections, while everything on the community side happens out in the open (discussion on Matrix, on the forum, issues in repos). The first ever (to my knowledge) insight I got into communications by Partner Engineering was this post in the chocolatey repository.
Regarding the ansible-core 2.19 situation, it also didn’t help that even inside the Ansible organization of Red Hat, not much testing (or none at all?) seemed to have happened from quite some teams. I hope this already has been discussed inside Red Hat, since to be honest it paints a pretty bad picture.