[Vote ended on 2022-02-02] Simplify the inclusion process

[felixfontein]

Summary

@tadeboro suggested in ansible-collections/ansible-inclusion#24 (reply in thread) to allow inclusion of new collections into minor releases of Ansible. Adding new collections is a backwards compatible operation (in fact we already did that in the past, when splitting out collections from community.general and community.network), so this is compatible with semantic versioning.

The main pro argument is that we will remove the pressure to get all inclusion requests ready, reviewed and processed by two dates per year. Instead, we can process every such request whenever someone has time, and include each of them when ready. There will still be cut-off dates (last possible inclusion date for Ansible 6 would be the same date as last major version bumps allowed for already included collections, or 1-2 weeks earlier, whatever we prefer) - but the current mixing of the roadmap with the inclusion process dates will get simplified to one single date.

What do you think? Main questions:

1. Do we want to allow this? (+1) Yes, (-1) No.
2. If we allow this, when should be the last possible date for a new Ansible X release to include new collections? (a) At the same day that allows already included collections to do backwards-incompatible changes by releasing a new major version? (b) A week before that? (c) Even more before that?

I would suggest that we first collect ideas on this for ~2 weeks (you can simply write things like 1: +1; 2(a), or more text to elaborate what you think). By then we hopefully have converged to a combined proposal that we can have a Yes/No vote on (for another two weeks).

[briantist]

1. +1 -- in addition to easing the burden of lumping all inclusion requests into two dates, I imagine it will also be encouraging for maintainers, knowing that they only have 2 chances a year. I could see being pretty discouraged if I was trying to get a collection included and missed a date, knowing it would take 6 months to be considered again.
2. +0 (abstain) for now, my gut feeling is that a new collection should possibly have an earlier cutoff to deal with the unexpected (everything seemed fine, but adding it to the package caused some issue, or some doc didn't render, or whatever), but I'm not familiar enough with what happens yet to say. tl;dr, I will probably go with the crowd on this one.

[tadeboro]

In an ideal scenario, adding a new collection should not be a big deal like it is today because this only happens twice a year. So my idea is to make the new collection inclusion process a normal part of the Ansible package development cycle.

This would mean that we would allow adding new collections in minor releases and that we do not set any special dates for those newly-included collections when it comes to major Ansible releases. If collection is included in Ansible by the time the major versions of included stuff are frozen, it gets released with X.0.0. If not, it will wait a few weeks for X.1.0 and that is it.

In short: q1: +1; q2: a

[gundalow]

Good proposal, though I'll need to think on it a bit.

Would the answers (or process) be different if we were spinning content out of one collection to another?
ie, if we move some collections out of community.general and update meta/runtime.yml I believe that's a MAJOR version jump, so that couldn't be included in the next minor release of ansible.

[felixfontein]

@gundalow the process would be exactly the same. Previously we already did add split-out collections in minor versions. What we didn't do in the past (and won't do in the future) is replacing the split-out parts of an existing collection with redirects, as that is a breaking change.

(We could maybe revisit this once the collections in question no longer support Ansible 2.9, since with ansible-base 2.10 and ansible-core 2.11+ redirects work. Then the main question is whether adding a new collection dependency requires a new major release or not. But that discussion is not related to the current topic, so let's not have it here :) )

[gundalow]

@gundalow the process would be exactly the same. Previously we already did add split-out collections in minor versions. What we didn't do in the past (and won't do in the future) is replacing the split-out parts of an existing collection with redirects, as that is a breaking change.

Thanks for the clarrification.

(We could maybe revisit this once the collections in question no longer support Ansible 2.9, since with ansible-base 2.10 and ansible-core 2.11+ redirects work. Then the main question is whether adding a new collection dependency requires a new major release or not. But that discussion is not related to the current topic, so let's not have it here :) )

Agreed.

[jillr]

1: +1
2: a, but b would also fine by me if a majority prefers that. When there is no longer pressure to hit 2 dates in a whole year it's easier to say "oh I missed it, no big deal I'll go in the next one" so I don't feel strongly on the cut-off.

[felixfontein]

Vote on simplified proposal

The proposal is:

We allow to add new collections to the Ansible package in every minor version. New collections (once passing reviews and a vote by the steering committee) can be added at any time, but will only make it into a new major release of Ansible if they are added before the feature freeze date. If they are approved after the feature freeze, they have to wait for the first minor release after the major release.

The voting period is two weeks, until 2022-02-02. Please use +1/-1 to express your approval / rejection of this simplified proposal. Thanks!

[felixfontein]

+1

[gundalow]

+1

[briantist]

+1

[tadeboro]

+1

[anupamaloke]

+1

[jillr]

+1

[jamescassell]

+1

[Andersson007]

+1

[acozine]

+1

This seems like a good kind of flexibility to incorporate into our process, with plenty of advantages and no serious disadvantages.

[sdodsley]

+1

[tima]

+1

[cybette]

+1

[markuman]

+1

[acozine]

Summary of votes:
13 votes of +1, including 8 steering committee members (felixfontein, tadeboro, gundalow, andersson007, acozine, jillr, briantist, markuman) and 5 community votes.
No -1 votes so far.

[felixfontein]

I agree on 13 votes of +1, but there are 9 steering committee members (jamescassell is missing in your list).

So I think it's safe to say this has been approved! 🎉

[acozine]

Ah, apologies, I was scanning for IRC nicks instead of GitHub user names.

[acozine]

Thanks @anupamaloke, @sdodsley, @tima, @cybette for reviewing and voting!

[felixfontein]

PR adjusting the Ansible 6 roadmap accordingly: ansible/ansible#76932

[felixfontein]

PR extending the ansible-inclusion repo's README: ansible-collections/ansible-inclusion#37

[Andersson007]

FYI: i've checked https://github.com/ansible-collections/overview and haven't found any places saying that inclusions are possible only in major releases. Though created a PR to fix formatting / wording ansible-collections/overview#195. If someone takes a look, it would be great