18:00:51 <felixfontein> #startmeeting Ansible Community Meeting
18:00:51 <zodbot> Meeting started Wed Sep 30 18:00:51 2020 UTC.
18:00:51 <zodbot> This meeting is logged and archived in a public location.
18:00:51 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:51 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:57 <felixfontein> DING DING DING )
18:00:59 <andersson007_> hi
18:01:00 <felixfontein> :)
18:01:02 <felixfontein> who's around?
18:01:07 <felixfontein> #chair geerlingguy andersson007_
18:01:07 <zodbot> Current chairs: andersson007_ felixfontein geerlingguy
18:01:08 <geerlingguy> me
18:01:13 * gundalow waves
18:01:24 <cyberpear> o/
18:01:24 <felixfontein> abadger1999: gundalow: samccann: acozine: cyberpear:
18:01:33 <felixfontein> #chair gundalow cyberpear
18:01:33 <zodbot> Current chairs: andersson007_ cyberpear felixfontein geerlingguy gundalow
18:02:20 * samccann waves
18:02:22 <felixfontein> #topic https://github.com/ansible/community/issues/539#issuecomment-701531177
18:02:26 <felixfontein> #chair samccann
18:02:26 <zodbot> Current chairs: andersson007_ cyberpear felixfontein geerlingguy gundalow samccann
18:02:32 <felixfontein> that's the agenda :)
18:02:59 <tadeboro> I am also here.
18:03:06 <felixfontein> right!
18:03:08 <felixfontein> #chair tadeboro
18:03:08 <zodbot> Current chairs: andersson007_ cyberpear felixfontein geerlingguy gundalow samccann tadeboro
18:03:17 <felixfontein> aminvakil: are you around?
18:03:22 <felixfontein> or anyone else interested?
18:03:39 <andersson007_> i suggested several criteria for the second question https://github.com/ansible/community/issues/539#issuecomment-697308403
18:04:10 * cybette waves
18:04:12 <felixfontein> let's start with updates maybe; if anyone has something urgent to discuss, please also mention it
18:04:17 <felixfontein> #chair cybette
18:04:17 <zodbot> Current chairs: andersson007_ cyberpear cybette felixfontein geerlingguy gundalow samccann tadeboro
18:04:20 <felixfontein> hi cybette!
18:04:25 <felixfontein> now I have to watch my tab completion ;)
18:04:31 <felixfontein> #topic updates
18:04:43 <felixfontein> #info community.network 1.2.0 has been released today, community.general 1.2.0 will follow later today
18:04:52 <geerlingguy> fancy!
18:05:24 <felixfontein> #info there's a new sanity test in ansible-test which makes sure that version_added is never a patch version, and removal versions are never minor or patch versions
18:05:29 <felixfontein> that's the updates from my side :)
18:05:29 <geerlingguy> I am interested in agenda item #1 as we're finishing up `community.okd` this week and next, and would very much like to start a 2.0.0 of `community.kubernetes` and redirect content to okd
18:05:59 <geerlingguy> but can't do that so much if 2.11 doesn't end up including community.okd! (So both agenda items are important to me I guess)
18:06:30 <felixfontein> I think that both agenda items are somewhat related, as we probably don't want to move content from a collection inside ansible to a collection that's not added to ansible
18:06:35 <felixfontein> yep :)
18:06:41 <felixfontein> (sorry, was interrupted during typing ;) )
18:08:27 <gundalow> #info github.com/ansible/* will be moving from Shippable to Azure Pipelines soon (ie next month or two)
18:08:56 <felixfontein> what does that mean for github.com/ansible-collections/*?
18:09:15 <cyberpear> gundalow: any background? (how does it compare to GH Actions?)
18:09:38 <gundalow> #info github.com/ansible-collections/* can continue to use Shippable for a while, though we can move to Azure Pipelines as well and benefit from a much larger node pool compared to what we currently have with Shippable
18:09:52 <gundalow> #info For repos using GitHub Actions I don't expect any change
18:10:00 <geerlingguy> yay
18:10:17 <geerlingguy> any benefit of Pipelines over Actions?
18:10:18 <andersson007_> if this speeds up tests, that's good
18:11:15 <gundalow> #info May start off with `community.crypto` which currently uses Shippable, though doesn't have quiet the traffic as c.general
18:11:33 <andersson007_> (but shippable has very good console imo..)
18:11:50 <andersson007_> though haven't tried azure
18:11:52 <felixfontein> it will be interesting to see how it looks on azure
18:12:01 <felixfontein> is there an example of something that already uses azure?
18:12:14 <gundalow> geerlingguy: AZP has change detect which GitHub Actions don't
18:12:32 <gundalow> Ansibulbot will be updated to support copying test output
18:12:34 <geerlingguy> what does that mean?
18:12:54 <gundalow> ansible-test using git diff to know which tests to run
18:13:06 <felixfontein> don't you have the commit sha1 in github actions? from that, you can compute the changes
18:13:10 <felixfontein> (ansible-test can do it)
18:14:19 <abadger1999> Hi, sorry I'm late.
18:14:25 <felixfontein> #chair abadger1999
18:14:25 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear cybette felixfontein geerlingguy gundalow samccann tadeboro
18:14:27 <felixfontein> hi!
18:15:14 <gundalow> After AnsibleFest I expect there will be something to show
18:15:37 <gundalow> #info Panel interviews for the new Community Team members are happening this week and next
18:16:08 <gundalow> abadger1999: Hi, any other updates from yourself?
18:16:22 <geerlingguy> gundalow: ah, so the main benefit is being able to run subset of tests for larger collections
18:17:49 <abadger1999> Tracked down a couple issues with docs this week.  The major one being that the redirects were being removed.
18:18:11 <abadger1999> I'm working on a fix for that today in between interviewing people for the community team job.
18:18:35 <gundalow> Excellent, thanks
18:18:52 <samccann> opened a doc issue wrt the Azure pipeline changes - https://github.com/ansible/ansible/issues/72031  - it needs some more details on what we should change, but we definitely mention shippable in the docs
18:19:19 <abadger1999> There's a problem with the script included in the ansible tarball to rebuild the package but that will be fixed for ansible-2.10.1
18:19:48 <gundalow> samccann: good call, thanks
18:20:00 <abadger1999> That's all I have for updates.
18:21:45 <gundalow> thanks
18:21:49 <gundalow> felixfontein: what's next?
18:22:06 <felixfontein> ok. should we first talk about criteria for 2.11, or about moving content to collections currently outside ansible?
18:22:41 <gundalow> #topic Criteria for collection inclusion in Ansible 2.11
18:23:53 <felixfontein> andersson007_ wrote up some rules he considers important: https://github.com/ansible/community/issues/539#issuecomment-697308403
18:24:29 <andersson007_> yep, it was a quick look though
18:24:58 <felixfontein> I guess following the checklist in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst is one of the main requirements
18:25:49 <andersson007_> yes, it goes without saying:) should we put the requirements there?
18:26:03 <samccann> fwiw we were considering moving the checklist into docs.ansible.com
18:26:32 <felixfontein> samccann: that was the discussion from last week, right?
18:27:00 <abadger1999> yeah
18:27:11 <samccann> yep
18:27:44 <andersson007_> yes, i'm not sure the requirements will become a stable list soon
18:28:39 <samccann> The bigger issue imo is not stability - docs can be updated overnight.  It's - are the 2.10.x requirements different from the 2.11.x requirements?
18:28:55 <gundalow> How can we decide the criteria?
18:28:55 <cyberpear> I think it'd be good to have a canonical location for the requirements and have it updated whenever such requirements change.
18:29:15 <gundalow> Yup, I'm expecting this checklist to be versioned (against something)
18:30:17 <samccann> that would suggest either moving the existing checklist into docs.ansible.com before updating for 2.11, or...creating a section in the existing checklist to say the following requirements apply to 2.11.x only
18:33:44 <gundalow> Yup, I think a chunk of gh/ansible-collections/overview needs moving to docs.ansible.com
18:34:34 <abadger1999> Maybe what we should do is define some stages: (1) take https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst and make an initial policy of "[WIP]These are the necessary things to be included in 2.11.0 and beyond". (2) Vote to approve those things being in the policy (who?  whoever is in this meeting that week?) (3) Add additional criteria via votes. (4) Vote that the policy is complete
18:34:34 <abadger1999> enough for things to be added for 2.11.0.  Additions to the policy can be made, including for 2.11.0, but will only apply to collections added after that point in time.
18:35:05 <geerlingguy> I agree with gundalow that a lot of that needs to find a home in docs.ansible.com
18:35:23 <geerlingguy> abadger1999 +1
18:35:46 <samccann> question - does 2.11 Ansible correlate with 2.11 ansible-base? or will they diverge?
18:36:03 <abadger1999> I'm 30% sure they'll diverge.
18:36:12 <tadeboro> I like that percentage ;)
18:36:38 <samccann> ok then 2.11 collection requirements definitely have to be in ansible-collections/overview.  The docsite today doesn't have the ability to separate ansible-base version from Ansible version.
18:36:51 <felixfontein> about voting: I guess it makes sense to announce this a couple of weeks in advance, so that interested parties can comment on them early, and/or make sure they are around
18:37:43 <abadger1999> There's a very tentative schedule for ansible-base which places a new ansible-base release about a third of the way into 2021.  based on that, I think we'd release ansible-2.11 in January or february, before ansible-base-2.11 comes out.  ansible-2.12 would release with ansible-base-2.11.
18:37:50 <felixfontein> maybe we should create a repo for the policy, so we can use issues/PRs to comment / make changes
18:38:45 <abadger1999> felixfontein: <nod>  Or maybe samccann can specify a page in ansible/ansible and we can file a PR there?
18:39:04 <abadger1999> It could be helpful to have a separate issue tracker....
18:39:24 <felixfontein> abadger1999: c.g/c.n 2.0.0 is planned for ~end of January, so February sounds good for ansible 2.11
18:39:39 <samccann> I'm blanking on how to have a file in ansible/ansible (rst dir) that is not part of the docs build.
18:39:43 <felixfontein> ansible/ansible is probably not good since it is coupled too much with ansible-base
18:40:01 <geerlingguy> samccann: to your point ... someday we need to figure out a way to document "the ansible that people get when they install ansible with pip" "which is not ACD but I call it ACD sometimes" from ansible-base
18:40:03 <abadger1999> But if the guidelines are ending up in docs.a.c, then it would also be nice not to have two places where the document content lives.
18:40:13 <abadger1999> samccann: Oh, do we not want it to be built?
18:40:15 <geerlingguy> or just tell people "docs.ansible.com is _only_ for ansible-base and platform"
18:40:53 <samccann> geerlingguy: we will have room for both (ansible base and Ansible) on docs.ansible.com.... we just haven't figured out how we want it to work yet
18:41:19 <geerlingguy> Just tell ansible-base team that they don't get docs anymore :D
18:41:29 <samccann> abadger1999: we 'could' have the 2.11 Ansible collection requirements in /devel/ and published... but we need to be clear it is for Ansible 2.11 not ansible-base 2.11
18:41:31 <samccann> LOL!
18:41:52 <tadeboro> I would just like to add that policy should also include exclusion conditions: when some collection gets kicked out of the Ansible.
18:41:58 <samccann> The problem with publishing - once the URL is up there, we have to put in a redirect when we move it
18:42:35 <felixfontein> maybe we should not move the policy document to docs.ansible.com until the ansible and ansible-base (or ansible-core) docsites are de-coupled
18:42:38 <samccann> ...and my guess is we will have to move some things for sure... whether ansible-base gets a new URL or collections docs on docs.ansible.com
18:43:05 <samccann> yeah I feel like docs has dominated what should be a 'what do we want for collection requirements' conversation. Sorry about that.
18:43:23 <samccann> #action samccann to add where to document 2.11 collection requirements to DaWGs agenda
18:43:27 <abadger1999> tadeboro: <nod> things like orphan/retired; stable vs unmaintained...
18:43:32 <felixfontein> tadeboro: do you have something in mind? (next to 'ignores too many points of the checklist without improving after being informed in time')?
18:43:54 <abadger1999> #info eventual policy should include "when will collections be dropped from the ansible package" too.
18:43:59 <geerlingguy> samccann: but it is important because no matter what we decide, if people can't find it easily, we'll all be doing extra work trying to point people to the right place
18:44:06 <geerlingguy> (or finding it over and over again ourselves)
18:44:33 <felixfontein> geerlingguy: maybe it's best to have a place outside docs.ansible.com, but add enough links to that place from docs.ansible.com?
18:44:36 <abadger1999> samccann: If we don't want to commit to a stable docs url, then I guess we don't want to put the policy into docs.a.c now?
18:44:47 <geerlingguy> that would be acceptable
18:45:19 <abadger1999> samccann: Note.... in some ways the redirect problem doesn't change if the plan is to eventually move them into docs.a.c....
18:45:57 <felixfontein> true. in that case, we need more redirects and update the existing ones ;)
18:46:04 <abadger1999> samccann: It's just.... redirects/stubs/etc won't be a problem we can solve on the docs.a.c servers... they'd have to be solved on the external server.
18:46:14 <samccann> well if it's in a file in the ansible-collections/overview repo, then we replace the file w a pointer to the new home. if it's on docs.a.c, then it's a formal redirect.
18:47:11 <abadger1999> <nod> I'd say the redirect is probably a better user experience.
18:47:14 <samccann> I'm happy to say let's put it on docs.ansible.com and put a redirect up when we decid to move it
18:47:38 <abadger1999> But I know that we're struggling to figure out the best way to maintain our legacy redirects as it is, so....
18:47:40 <samccann> is it... gasp.. time... for .. a... POLL???
18:48:03 <felixfontein> :)
18:48:06 <felixfontein> always!!!
18:48:07 <abadger1999> :-)
18:48:51 <gundalow> samccann: :)
18:48:55 <abadger1999> samccann: care to make the proposal?
18:48:56 <samccann> POLL - We should put the 2.11 collection requirements checklist directly on docs.ansible.com/ansible/devel and add a redirect when we separate collections from ansible-base docs
18:49:03 <felixfontein> so the question is whether to a) keep the checklist at ansible-collections/overview, b) create a separate repository (which allows to have different branches for different Ansible versions, so the 2.10 checklist could live in one branch, and the 2.11 checklist in another), or c) have it already now on docs.ansible.com/ansible/latest/ or devel/?
18:49:11 <samccann> 1 means agree, -1 means disagree
18:49:16 <abadger1999> +1
18:49:17 <tadeboro> I did not have anything specific in mind when it comes to exclusion criteria. The programmer part of me just wanted to place free() relatively close to malloc() ;)
18:50:26 <felixfontein> does -1 mean it should stay at ansible-collections/overview, or does it mean "somewhere but not on docs.ansible.com"?
18:50:36 <samccann> ok which are we voting on now? +-1 or a, b, c ? :-)
18:50:39 <abadger1999> Hmmm.... felixfontein I'm thinking yes, but I'm now thinking what's our purpose?
18:50:47 <tadeboro> Is it just me or is the current vote "strange"?
18:50:51 <samccann> hahaha
18:51:06 <samccann> ok let's switch to a, b, c (felixfontein's list)
18:51:09 <abadger1999> We need to figure out hte path forward for writing the policy.
18:51:46 <felixfontein> I currently prefer b), i.e. have a separate repo for the policy, so we can version it better - one branch for 2.10, main branch for 2.11 until it is finalized, then move it to 2.11 branch, etc.
18:51:58 <samccann> keep in mind we can today support the exissting checklist on 2.10/latest, and create a separate one on /devel/ for 2.11
18:52:19 <felixfontein> then the current working version would be on `main` branch, while `stable-2.10` and `stable-2.11` would hold the finalized/current rules for 2.10 and 2.11, resp.
18:52:31 <abadger1999> there's several aspects of that.  Working backwards: (1) What's the final location of the policy? (2) How do we track and discuss proposed changes to the policy? (3) How do we bootstrap the policy so we have a skeleton that we can change?
18:52:38 <felixfontein> samccann: that only works as long as ansible-base and ansible are mostly synchronized
18:53:00 <samccann> agreed. it requires us to get our act together before 2.11 Ansible releases... which we have to do anyway
18:53:20 <abadger1999> I think we're getting into (4) Will we have one policy for all versions or one policy per version?
18:53:22 <samccann> but we can always have the policy in a separate repo until then
18:53:35 <abadger1999> I am in favor of one policy for all versions.
18:53:47 <samccann> +1 to that if it's possible
18:53:47 <gundalow> b
18:54:01 <felixfontein> +1 for one policy for all, if possible
18:54:21 <tadeboro> I also like the b option. PRs on that repo would then be mini RFC equivalents.
18:54:32 <felixfontein> I guess there isn't really need for a policy for 2.10 anyway, if we assume that 2.10 won't change anymore
18:54:47 <tadeboro> And a +1 for a single policy.
18:55:52 <tadeboro> That being said, I guess new collections can only be added in a 2.x.0 release? Or do we want to accept the more often?
18:56:12 <abadger1999> Proposal: At this point in time, have a separate repo for the policy.  When we vote that the policy is complete enough to start adding new collections for 2.11.0 we'll move it into ansible/ansible at a page location of docs' choosing and archive the initial policy repo.
18:56:20 <felixfontein> in theory, new collections are new features, so they can also be added in minor releases; though we could say we don't want that
18:56:32 <felixfontein> abadger1999: +1
18:56:57 <felixfontein> should we cancel the existing vote(s) and vote on that?
18:57:08 <samccann> :-)
18:57:10 <felixfontein> or has anyone another suggestion to compete with it?
18:57:10 <gundalow> eeeeeeeeer, not thought about when we'd accept collections. I'd assumed only in ansible 2.11
18:57:12 <tadeboro> I vote +b ;)
18:57:19 <abadger1999> yeah, cancel existing votes and vote for or against this new proposal
18:57:55 <felixfontein> VOTE: Have a separate repo for the policy. When we vote that the policy is complete enough to start adding new collections for 2.11.0 we'll move it into ansible/ansible at a page location of docs' choosing and archive the initial policy repo.
18:57:59 <felixfontein> +1
18:58:02 <abadger1999> +1
18:58:05 <tadeboro> +1
18:58:11 <felixfontein> #chair
18:58:11 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear cybette felixfontein geerlingguy gundalow samccann tadeboro
18:58:12 <andersson007_> +1
18:58:28 <samccann> +1
18:58:36 <cyberpear> +1
18:59:32 <felixfontein> anyone else?
18:59:39 <cybette> +1
19:00:16 <felixfontein> now only the g-men are missing ;)
19:00:24 <felixfontein> i.e. gundalow and geerlingguy
19:00:48 <samccann> heh
19:00:58 <geerlingguy> oops had to get a package
19:01:20 <geerlingguy> +1
19:01:28 <felixfontein> I guess the vote is pretty clear anyway
19:01:47 <felixfontein> #agreed Have a separate repo for the policy. When we vote that the policy is complete enough to start adding new collections for 2.11.0 we'll move it into ansible/ansible at a page location of docs' choosing and archive the initial policy repo. (+6)
19:01:57 <gundalow> +1
19:02:02 <felixfontein> #undo
19:02:02 <zodbot> Removing item from minutes: AGREED by felixfontein at 19:01:47 : Have a separate repo for the policy. When we vote that the policy is complete enough to start adding new collections for 2.11.0 we'll move it into ansible/ansible at a page location of docs' choosing and archive the initial policy repo. (+6)
19:02:04 <felixfontein> #agreed Have a separate repo for the policy. When we vote that the policy is complete enough to start adding new collections for 2.11.0 we'll move it into ansible/ansible at a page location of docs' choosing and archive the initial policy repo. (+7)
19:02:06 <gundalow> (had to stap away)
19:02:09 <felixfontein> :)
19:02:09 <gundalow> step
19:02:16 <gundalow> thanks felixfontein :)
19:02:27 <felixfontein> yw
19:02:54 <felixfontein> is anyone interested in having new collections in 2.10.x, or should we wait with that for 2.11?
19:03:26 <cyberpear> when is 2.11?
19:03:31 <gundalow> abadger1999: ^
19:03:34 <felixfontein> or in other words: do we already need a policy for 2.10 ASAP, or do we have more time?
19:03:44 <felixfontein> cyberpear: probably jan or feb 2021
19:03:52 <tadeboro> I would rather see new collections only in 2.X.0, starting with 2.11.0
19:04:11 <geerlingguy> 2.11
19:04:27 <felixfontein> I don't mind new collections in 2.11.y as well, but not in 2.10.y
19:04:34 <geerlingguy> I don't like the precedent set by throwing extra things into 2.10 besides bugfix-type stuff or performance improvements
19:04:35 <cyberpear> I would have said 2.10, bit my ansible time has been limited lately
19:04:46 <gundalow> I'd always assumed new modules in 2.11
19:04:53 <abadger1999> geerlingguy: We are allowing new features in.
19:04:54 <felixfontein> geerlingguy: we already have new modules/plugins and new features
19:05:03 <felixfontein> gundalow: you mean new collections, right?
19:05:07 <geerlingguy> well... new modules could make it into 2.10 _technically_ because collections already there
19:05:09 <abadger1999> You can have new modules/plugins/features inside of an existing collection.
19:05:21 <abadger1999> So it's a question of whether to allow wholly new collections too.
19:05:26 <geerlingguy> I am more worried about throwing the kitchen sink into Ansible in one release cycle
19:05:28 <gundalow> felixfontein: sorry, yes, new collections
19:05:46 <gundalow> (in multiple discussions at once)
19:05:58 <felixfontein> so far nobody wanted to have new collections in 2.10.y, is that right?
19:06:13 <felixfontein> (also nobody really wanted to have them in 2.11.y for y > 0, I think)
19:06:29 <cyberpear> I'd say take it case-by-case 2.10, hoping there's no cases to deal w/
19:06:47 <tadeboro> geerlingguy: If the criteria is strict enough, I would expect relatively few new collections in each cycle.
19:06:50 <felixfontein> for 2.11 I think we should handle that in the policy document, then we have more time to discuss this
19:07:35 <abadger1999> felixfontein: <nod>  I'm okay with a "cross the 2.10 bridge when someone asks it... definitely define it for 2.11"
19:07:39 <felixfontein> there might be a small bump of new collections for 2.11, mainly for things that were too late for 2.10 or that are split off from c.g/c.n
19:07:57 <geerlingguy> tadeboro: but IMO it's more about the precedent... I mean, Ansible already does weird things with not-really-semantic-versioning, and adding major functionality into a x.y release feels off to me
19:08:05 <abadger1999> I think there's red hat/ansible partners who want to get in as well.
19:08:21 <samccann> semi related... I was never clear on whether Ansible (the package) would be an ever-increasing set of collections, or if it would attempt to 'freeze' at what was in Ansible 2.9 (give or take a bit)...
19:08:32 <abadger1999> I think I lean towards new collections belong in the next release.
19:08:47 <geerlingguy> Ideally, collections would also be locked at the major version per ansible release—is that the case now? E.g. 2.10 will be 1.x.x only of collection, even if a 2.0.0 gets released
19:09:00 <abadger1999> But I don't have a reason for why new collections are all that different from new features inside of existing collections.
19:09:25 <geerlingguy> samccann: we risk bloating the package too... it's already gone from 16.2MB in 2.9 to 43.1MB in 2.10
19:09:27 <felixfontein> geerlingguy: that's already the case
19:09:32 <tadeboro> I would add into a policy that certified collections need to go through community revision first. The ones I used are ... not the best to put it mildly.
19:09:33 <abadger1999> geerlingguy: major version yes, but minor version no.... so you can have new features but you cannot have backwards incompatibilities
19:09:42 <felixfontein> abadger1999: I agree (to both)
19:09:55 <geerlingguy> For someone who often works in spotty Internet situations, or on slow things like Raspberry Pis, the bigger it gets the more annoying :) (though ansible-base can resolve those issue in some cases)
19:10:11 <geerlingguy> tadeboro: isn't it ironic :)
19:10:38 <tadeboro> geerlingguy: I use ansible-base + selected collections when bandwidth is problematic.
19:10:59 <geerlingguy> I'm moving towards that model, but most of the playbooks I want to use still require community.general _at least_ :(
19:11:10 <felixfontein> I'd be happy if collections would have less dependencies :) that would make it even more modular
19:11:24 <tadeboro> Yet, c.g is a beast to download ;)
19:11:29 <geerlingguy> "break up community.general" /me gets my pitchfork
19:12:05 <gundalow> I'm OK with community.general been broken down into smaller collections, though each new collection MUST have 2+ maintainers
19:12:13 <felixfontein> if you want to see how c.g would look when almost all actively maintained things have been moved out, look at community.network :P
19:12:58 <gundalow> Also once we've had the legal discussions we maybe able to remove `tests/` which from memory is 50%+ of the source
19:13:40 <abadger1999> geerlingguy: tangent: A campaign to identify the most used c.g plugins and get maintainers for those in a separate collection would seem to be a good idea.
19:14:20 <geerlingguy> gundalow: interesting... is that included in the build that's popped onto galaxy and wrapped in the distribution?
19:14:29 <abadger1999> I would be against removing tests/
19:14:34 <geerlingguy> abadger1999: yeah, sounds like a good job for gwmngilfen ;)
19:14:46 <geerlingguy> I know `make` keeps popping up in my own projects
19:14:50 <abadger1999> downstreams can test things if we include them in the tarballs.
19:14:52 <geerlingguy> I use that a lot
19:15:16 <geerlingguy> abadger1999: true, true... it's just a lotta stuff to download when we're comparing < 20MB to > 40MB
19:15:45 <gwmngilfen> So I already track chunks of c.g by label
19:16:15 <gwmngilfen> Looking at it from other angles could make sense
19:16:58 <gwmngilfen> * So I already track chunks of c.g by label - I.e. labelX made up Y% of issues
19:17:37 <abadger1999> geerlingguy: I don't think there's any future where that doesn't grow :-/
19:18:04 <abadger1999> We could ship tests separately maybe.
19:18:10 <geerlingguy> maybe a future where community distro is split into 'ansible for linux', 'ansible for windows', 'ansible for networking' :)
19:18:34 <abadger1999> collections of collections of collections (by different names) ;-)
19:18:46 <geerlingguy> but that would likely be too much time + competition to some of the more product-oriented offerings at RH
19:19:24 <gundalow> ok, 80 minutes in
19:19:56 <felixfontein> should we vote on 'no new collections for 2.10.x, x > 0'?
19:20:12 <geerlingguy> oh wow, time flies
19:20:34 <felixfontein> if we need more discussion, we should probably continue next week
19:21:17 <felixfontein> quick note: The Bullhorn issue 11 is out
19:22:14 <gundalow> felixfontein: what about if during ansible 2.10 we split out some of c.general, does that need to wait till 2.11?
19:22:42 <felixfontein> gundalow: we can't remove anything from c.general anyway, we can only deprecate and remove for 2.11
19:23:01 <felixfontein> but we can't really deprecate when the new collection isn't included in 2.10.x
19:23:15 <felixfontein> because then users can't work around the deprecation without installing additional stuff
19:23:26 <gundalow> cool, just wanted to check
19:24:24 <felixfontein> that would be an argument to allow new collections for 2.10.x
19:24:27 <felixfontein> hmm
19:24:36 <felixfontein> I guess we need more discussion...
19:25:25 <felixfontein> ok. should we stop for today?
19:25:34 <abadger1999> Yeah, sounds good.
19:25:44 <tadeboro> I would say that this use case falls under "on a case-by-case basis".
19:26:02 <gundalow> I think that's one for another day
19:26:03 <felixfontein> tadeboro: true, but even for case-by-case we need some guidelines, otherwise it's totally arbitrary :)
19:26:03 <tadeboro> +1 to end a meeting.
19:26:10 <felixfontein> #topic open floor
19:26:15 <felixfontein> thanks!
19:26:21 <felixfontein> anyone has something quick?
19:26:21 <cybette> #info Contributor Summit etherpad with proposed agenda (please contribute, especially for Thursday :)) https://etherpad.opendev.org/p/virtual-ansible-contributor-summit-october-2020
19:26:45 <felixfontein> are policies something we want to discuss at the contributor summit?
19:27:03 <felixfontein> or do we need more "internal" preparation/discussion first before we want to involve a larger audience?
19:27:11 <cybette> felixfontein: great idea :)
19:28:00 <geerlingguy> felixfontein: I thought the idea would be "if a collection removes anything, it goes to new major version, e.g. 2.x"
19:28:02 <felixfontein> it's probably a good idea to have some things summed up and prepared
19:28:09 <geerlingguy> and that would not get included in Ansible 2.10
19:28:16 <felixfontein> geerlingguy: that's definitely the case
19:28:34 <geerlingguy> And if a collection kept removing things, it would go up in numbers fast. I could imagine community.general making its way up to like version 300 by the time 2.12 is out
19:28:47 <geerlingguy> (unless it removes things in large chunks)
19:28:51 <felixfontein> geerlingguy: it would be "collection B adds stuff from collection A, gets included in 2.10.x; collection A deprecates that stuff; collection A removes the stuff in next major version (which ends up in ansible 2.11.0)"
19:29:29 <felixfontein> geerlingguy: since we have a fixed schedule, all removals for the next months will be done in 2.0.0, to be released (end of) january
19:30:37 <felixfontein> ok. let's stop this for today.
19:30:38 <felixfontein> #endmeeting