19:00:17 <felixfontein> #startmeeting Ansible Community Meeting
19:00:17 <zodbot> Meeting started Wed Nov 11 19:00:17 2020 UTC.
19:00:17 <zodbot> This meeting is logged and archived in a public location.
19:00:17 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:17 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:21 <felixfontein> so, who's around?
19:00:43 <dericcrago> \o
19:01:12 * gundalow waves
19:01:24 <felixfontein> abadger1999: acozine: dericcrago: dmsimard: gundalow: jtanner: lmodemal: samccann: agaffney: geerlingguy: tadeboro:
19:01:28 <felixfontein> I'm sure I forgot some
19:01:34 <felixfontein> #chair dericcrago gundalow
19:01:34 <zodbot> Current chairs: dericcrago felixfontein gundalow
19:01:36 <samccann> \o
19:01:40 <felixfontein> #chair samccann
19:01:40 <zodbot> Current chairs: dericcrago felixfontein gundalow samccann
19:01:55 <abadger1999> Good day
19:01:56 <felixfontein> every time I plan to pre-compile a list of nicks, and then I forget again... :)
19:01:59 <felixfontein> #chair abadger1999
19:01:59 <zodbot> Current chairs: abadger1999 dericcrago felixfontein gundalow samccann
19:02:09 <felixfontein> #topic agenda: https://github.com/ansible/community/issues/539#issuecomment-725234986
19:02:11 * agaffney looks up
19:02:36 <agaffney> I have no idea what's going on, but it's a welcome break from writing a helm chart
19:02:38 <felixfontein> andersson007_ isn't around for today's meeting. he told me how he wants to vote for the first topic though :)
19:02:41 <tadeboro> o/
19:03:01 <felixfontein> agaffney: we have the weekly community meeting right now, I just thought I can also ping you if you're interested :)
19:03:05 <felixfontein> #chair agaffney tadeboro
19:03:05 <zodbot> Current chairs: abadger1999 agaffney dericcrago felixfontein gundalow samccann tadeboro
19:03:26 <felixfontein> #topic announcements
19:03:37 <felixfontein> #info ansible-base will be renamed to ansible-core, I think for 2.11
19:03:53 <felixfontein> does anyone else has something to announce?
19:04:04 <samccann> so the ansible-xxx that will be in Ansible 2.11 will be ansible-base, right?
19:04:40 <abadger1999> samccann: correct
19:04:49 <felixfontein> yes, I think so. we'll have ansible-base 2.10 in ansible 2.11, and ansible-core 2.11 will get included in ansible 2.12
19:04:57 <felixfontein> (assuming ansible itself won't be renamed as well)
19:04:59 <abadger1999> ansible-2.12 is where ansible-core will show up.
19:05:05 <agaffney> is the rename to ansible-core going to cause another pip-related issue on upgrade?
19:05:08 <samccann> #info docs team is discussing how to split up the docsite to support independent releases of ansible-core and Ansible. See https://etherpad.opendev.org/p/ansible-documentation-split for scratchpad of current ideas. We meet on Thursdays 10:30am ET on #ansible-docs
19:05:19 <abadger1999> agaffney: webknjaz thinks so.
19:05:31 <abadger1999> agaffney: I think it won't be as bad for users of the ansible package.
19:05:33 <felixfontein> agaffney: probably depends on how it is done, I hope not, but could well be
19:05:50 <abadger1999> But there will be cornercases.
19:06:16 <abadger1999> I think pip install ansible==2.9.0 ; pip install --upgrade ansible==2.12.0  will work out of the box.
19:06:32 <abadger1999> But a user could do pip uninstall ansible-base afterwards and break everything.
19:06:40 <abadger1999> I'll have to test that, though.
19:07:07 <abadger1999> Err..... actually.....
19:07:37 <abadger1999> going from 2.9.0 to anything will probably break i nthe same way as upgrading 2.9 => 2.11.....
19:07:56 <abadger1999> i should have written pip install ansible==2.10.0 ; pip install --upgrade ansible==2.12.0
19:08:28 <felixfontein> if someone does `pip install --upgrade` after upgrading from ansible 2.10 to ansible 2.11, and there's an update for ansible-base but not for ansible-core, I guess the result will not be good.
19:08:45 <abadger1999> felixfontein: yeah, that would break things.
19:08:56 <abadger1999> actually..... that might be worse breakage.
19:09:10 <felixfontein> yep
19:09:31 <abadger1999> it wouldn't break immediately on upgrade from ansible-2.10 to ansible-2.12.... it will break at some indefinite time in the future.
19:09:43 <felixfontein> and if ansible-base and ansible-core update at the same time, fun things can also happen
19:10:04 * bcoca waits for next rename, probably by friday
19:10:20 <abadger1999> relrod, webknjaz: felixfontein pointed out a way that the ansible-core rename will be worse than the ansible => ansible-base rename.
19:10:56 <abadger1999> felixfontein: I suppose refusing to install if ansible-base is installed is the best way to handle that.
19:11:14 <felixfontein> abadger1999: I think so too, which would lead to the same fun as for 2.9 -> 2.10
19:11:20 <abadger1999> Yep.
19:11:28 <samccann> without reopening pandoras box - is there a one-sentence summary on why the rename is needed?
19:11:43 <abadger1999> The core team would have to tell us.
19:11:58 <abadger1999> sivel: ^ Can you summarize why the rename to ansible-core is necessary?
19:11:59 <felixfontein> "because someone said so"?
19:13:13 <agaffney> I personally like ansible-core better than ansible-base, but I also don't have to personally deal with the fallout
19:14:21 <felixfontein> ok, I'm not sure whether sivel is around, so let's maybe start with the main topics of this meeting :)
19:14:39 <gundalow> +1
19:14:44 <abadger1999> yeah, can do.... I think relrod is catching up but maybe we can revisit in open floor.
19:14:46 <felixfontein> there are two topics which we should talk about today - one is the continuation of the last two meetings, the other one the continuation of several more meetings ;)
19:14:52 <sivel> I just sat down for lunch
19:14:54 <felixfontein> abadger1999: sounds good
19:15:07 <felixfontein> sivel: enjoy your lunch then, we'll talk about it in open floor
19:15:09 <sivel> in short, Marketing doesn't like the name ansible-base/base/Base
19:15:22 <sivel> So they approached produt management, who approached us
19:15:25 <geerlingguy> how about ansible-foundation? :D
19:15:40 <sivel> we were in favor, PM and Marketing finalized and approved the rename
19:15:47 <geerlingguy> ansible-bedrock
19:15:51 <samccann> ok thanks for the summary sivel
19:16:01 <felixfontein> sivel: thanks. and for how long this time? :)
19:16:16 <sivel> felixfontein: hopefully for a while. internally we have always called it "core"
19:16:34 <geerlingguy> new meme: every time I upgrade ansible, ansible explodes until I format my hard drive and start over
19:16:36 <felixfontein> let's hope so :)
19:16:55 <felixfontein> #topic Should we accept new content in community.general (and community.network)?
19:17:16 <gundalow> yes*
19:17:20 <geerlingguy> felixfontein: I have to run to lunch, but my opinion is still a hard no on that
19:17:31 <felixfontein> this is a discussion we started two weeks ago. last week we boiled it down to a list of options (https://github.com/ansible/community/issues/539#issuecomment-721928283)
19:18:02 <felixfontein> after a bit of discussion with andersson007_ this morning, I added another item, and ended up with 5 options: https://github.com/ansible/community/issues/539
19:18:09 <felixfontein> sorry :)
19:18:09 * geerlingguy campaigns to re-merge all collections back into community.general otherwise, since it will become the de-facto 'blessed' ansible content repository
19:18:11 <felixfontein> https://github.com/ansible/community/issues/539#issuecomment-725234986
19:18:27 <felixfontein> #info 5 possible options listed in https://github.com/ansible/community/issues/539#issuecomment-725234986
19:18:46 <felixfontein> The options range from (1) absolutely no new content to (5) allow all new content that passes review
19:19:02 <felixfontein> (n+1) allows more than (n) (or at least that was the intention)
19:19:17 <geerlingguy> "(Right now, we are somewhere between 3 and 5.)" — right now I'm somewhere between #1 and could be paid off handsomely to maybe consider #2
19:19:18 <felixfontein> I hope you all thought a bit about this since last week :)
19:19:45 <geerlingguy> Anything from iii, iv, and v == community.general becomes ansible-modules-extra v2.0
19:19:48 <felixfontein> geerlingguy: I mean with 'right now' what's currently happening, not what the current opinion is :)
19:19:58 <geerlingguy> ah yes
19:20:22 <geerlingguy> anyways, I gotta eat, so have to run, but my vote is strongly i, and maybe someone could convince me after a long discussion that ii might have some merit.
19:20:44 <felixfontein> does someone wants to discuss the five points, or suggest some more? or should we go right at voting?
19:20:56 <gundalow> i - Moved the problem else where. Means there is a massive overhead of having to host and maintainer a new collection. If we go down that route we'd need a lot better toolding, and likely literally hundreds of repos under gh/ansible-collections/
19:21:19 <agaffney> there are a lot of pros and cons for this one, but it's somewhat side-stepping the issue that the barrier to entry is somewhat higher without allowing new content in community.general, because creating/maintaining/publishing your own collection is "hard"
19:21:22 <geerlingguy> gundalow: I thought the idea is that people would create their own collections
19:21:31 <geerlingguy> the answer there is making it not so onerous to maintain collections
19:21:36 <gundalow> ii - Similar to `i`, Do we really want collections containing a single collection, will people maintain them?
19:21:41 <geerlingguy> kind of like roles
19:21:42 <felixfontein> agaffney: I agree
19:22:23 <geerlingguy> otherwise if we are going to give up on trying to make collections easier to build, maintain, and update, then I might understand level iii-v
19:22:24 <abadger1999> One thing I thought about this week: it doesn't seem that bad to move content later.
19:22:25 <samccann> we talked about a `community.beta` or some better name, that would be a proving ground for new modules.
19:22:34 <felixfontein> gundalow: I think for some content, one plugin/module per collection is an acceptable start (when it is clear there will be more in the future). for others, not really
19:22:57 <geerlingguy> abadger1999: already we are annoyed by the difficulty of *cleanly* (e.g. no user disruption and well-tested process) moving content from c.kubernetes to somewhere else
19:22:59 <samccann> so `community.beta` would become the techpreview/unstable/user beware this stuff will move if it's popular
19:23:03 <gundalow> yup, I think `nagios` is my go to example here, there's only been a single module for years
19:23:04 <geerlingguy> it doesn't seem frictionless
19:23:05 <felixfontein> abadger1999: depends on how long 2.9 will stay and how many people will use 2.9 instead of 2.10+
19:23:08 <abadger1999> I think it's pretty transparent for end users as long as  runtime.yml entries in community.general gets updated appropriately.
19:23:27 <abadger1999> Ugh.  yeah.
19:23:48 <abadger1999> And I suppose... how long we care about 2.9.
19:23:50 <felixfontein> also moving later makes it potentially impossible to update ansible-base's ansible_builtin_runtime
19:24:12 <felixfontein> which means that people need to install community.general even if they just want to use community.xyz because they need it for the redirects
19:24:19 <aminvakil> samccann: that's good, but what about this: how and when modules will move from community.beta to c.g or other collections or its own collection?
19:24:31 <abadger1999> geerlingguy: what are the points of friction because I couldn't think of any (not thinking about 2.9, though)
19:24:34 <geerlingguy> all these things point to "let's not make one massive repository to dump everything into" IMO
19:24:35 <tadeboro> I think the available options cover the whole spectrum of options. That being said, my preferred option would be ii with an added clause that the things covering one "area" should move out of c.g as soon as possible.
19:24:39 <felixfontein> but maybe let's keep that subject for later, and continue with the current question: no more new content for c.g/c.n?
19:25:05 <samccann> aminvakil: yeah we'd need a process around that...but it helps c.g from becoming yet another dumping ground of seldom/not maintained modules over time.
19:25:13 <geerlingguy> abadger1999: testing the redirects, writing and maintaining docs that help users make the transition, adding the routing info from the old collection, planning release of old collection where redirects will occur...
19:25:22 <gundalow> I'm confused on the difference between `iii` and `iv`
19:26:09 <abadger1999> geerlingguy: ah.... you're talking about the maintainer work.  Not the user experience.
19:26:22 <geerlingguy> I know we want to be happy and kind to end users in all this—but the whole reason for this collections migration in the first place was to try to make ansible maintainable again. My opinion is that if we open the floodgates—even a tiny smidge—it turns c.g into ansible-modules-extra-next
19:26:25 <felixfontein> gundalow: iv) is iii) with an exemption: if someone (like this meeting) can be convinced that something new should be in c.g, it can still be added
19:26:32 <geerlingguy> maintainer burnout is real :P
19:26:32 <agaffney> gundalow: IV sounds like a lower barrier of entry, since you don't have to explain why it shouldn't be in its own collection
19:26:34 <gundalow> felixfontein: ah, thanks
19:26:43 <sivel> ansible_builtin_runtime is already be frozen, although I suppose on a 1 off basis we might consider changes, but I cannot gaurantee we will
19:26:50 <sivel> s/be//
19:26:51 <felixfontein> ah, the other way around
19:26:57 <abadger1999> geerlingguy: yes it is.... otoh, that is true both at the front end and hte backend.
19:27:14 <felixfontein> sivel: I think we agreed with nitzmahone that we can have one more change beginning of next year
19:27:23 <felixfontein> sivel: which is why I dislike later moves
19:27:51 <sivel> I'll make sure I get clarification as well :)
19:27:55 <abadger1999> You're talking about maintainers getting overloaded at the point when they decide to move the content.  Disallowing new content into c.g means overloading them when they first generate the content.
19:28:39 <agaffney> slightly higher initial barrier of entry for module author vs. more work for c.g maintainers in the long term
19:28:54 <felixfontein> agaffney: I think it's more than 'slightly'
19:29:00 <felixfontein> at least right now
19:29:20 <gundalow> I'm happy to accept action items to make it easier to own/manage/maintain a collection
19:29:30 <agaffney> I haven't actually created a collection, but my impression is that it's not much harder than creating a role and publishing it to galaxy
19:29:52 <sivel> agaffney: I'd say the most intensive process is setting up CI
19:29:54 <felixfontein> agaffney: if you want to do it properly with changelog, CI, ..., it is definitely some work
19:29:56 <bcoca> one extra step, there is a build/package
19:30:04 <tadeboro> Creating collection is not that hard. Setting up a CI/CD is a bit of an PITA, but still.
19:30:12 <bcoca> sivel: that is not required to create and publish a collection (advised, yes)
19:30:24 <felixfontein> tadeboro: creating it is still not that easy, if you've never done it before
19:30:45 <bcoca> but same with roles,  not hard to create/publish, but if you want CI/Cd .. that is eveyr project
19:30:48 <agaffney> the other side of that is that content discovery will be harder with one-off modules in one-off collections
19:31:01 <felixfontein> it probably would be nice to have a 'one click solution', maybe some github app where you can create a new collection repo with everything already set up?
19:31:07 <agaffney> but that's already kind of an issue with the collection split
19:31:21 <jtanner> content discovery is the key feature of galaxy
19:31:31 <felixfontein> how hard is it to get hold of a namespace on galaxy? I think 'back then' every user got their own, but is that still the case now?
19:31:37 <bcoca> was already an issue with roles having plugins .. but actually collection makes it easer to find em
19:31:49 <bcoca> iirc, open a ticket
19:32:00 <tadeboro> felixfontein: So majbe we should work on improving the create-a-new-collection experience instead of stashing everything in one place that has just happens to have everything set up already?
19:32:19 <gundalow> tadeboro: I think making it easier has to be done either way
19:32:23 <felixfontein> bcoca: that's an additional barrier for random users who just want to create a small module
19:32:51 <felixfontein> tadeboro: yes, but there's also the time until the point it is easy enough that we have to consider :)
19:33:15 <bcoca> felixfontein: less than they had before, also 'random module' is not a good thing to distribute
19:33:34 <bcoca> having it 'orphan in anyonymous colleciton' is slightly better than orphan in well known and included collection
19:34:06 <gundalow> So to recap where we are
19:34:27 <abadger1999> Yeah, making a new collection that goes into the ansible tarball could be a significant undertaking and likely that barrier gets higher as time goes on.
19:34:50 <agaffney> at this point, I think I'd vote for option #3, if only because this problem has multiple facets and isn't easy to solve, and it's a good middle-of-the-road option
19:34:59 <abadger1999> I think we should probably make some temporary rule that expires when tadeboro's suggestion is implemented.....
19:35:21 <felixfontein> agaffney: I agree, and that is also andersson007_'s favorite option
19:35:40 <gundalow> A) Sounds like everybody is OK blocking groups of modules from been added to community,general or community.network. Therefore we should enforce that now
19:35:40 <gundalow> B) We need to identify and document the painpoints on creating/maintaining a collection
19:36:09 <abadger1999> I'm good with ii as well.
19:36:16 <felixfontein> abadger1999: I don't think we're making permanent rules anyway, it's all valid for a time until it needs to be adjusted again :)
19:36:19 <abadger1999> Sorry.
19:36:21 <abadger1999> iii
19:36:47 <agaffney> heh, that's why I used Arabic numerals :)
19:36:52 <abadger1999> Yeah :-)
19:37:05 <felixfontein> agaffney: I did use them, but github changed them to roman...
19:37:17 <agaffney> hah
19:37:37 <felixfontein> (probably because it's a enumeration inside a list item)
19:37:42 <abadger1999> felixfontein: that's true :-)  It does help if we know what our parameters are.
19:37:46 <russoz> hey guys, I've been reading quietly, but my $0.02 - I agree we should streamline the creation of new collections (heck, we should write an ansible playbook for that, shouldnt we?). On top of that, I think we might benefit from having a couple of objective criteria for new modules in c.g, other than just the number of files
19:38:12 <abadger1999> felixfontein: with option iii are we committing to creating community.incubator now?
19:38:16 <felixfontein> #chair russoz
19:38:16 <zodbot> Current chairs: abadger1999 agaffney dericcrago felixfontein gundalow russoz samccann tadeboro
19:38:19 <russoz> like: must not add any lines to ignore files (I'm trying to clean those, so yep, a bit of a grunt)
19:38:28 <bcoca> depends on scope of 'create', ansible-galaxy init 'creates a collection'
19:38:37 <gundalow> russoz: Morning :)
19:38:44 <russoz> morning! :)
19:38:44 <felixfontein> #chair bcoca sivel jtanner geerlingguy
19:38:44 <zodbot> Current chairs: abadger1999 agaffney bcoca dericcrago felixfontein geerlingguy gundalow jtanner russoz samccann sivel tadeboro
19:38:49 <gundalow> ============================
19:39:03 <felixfontein> looks like I forgot to add some people, if anyone more wants to get chaired, ping me
19:39:04 <bcoca> setting up ci/cd is very diff isusue and has to do more with repo management and a requirement to be part of the distribution vs being publishe din galaxy
19:39:06 <gundalow> How about we change topic to "How can we make it easier to setup a collection"?
19:39:23 <russoz> like: if this modules releases changes more than X times/week => it should be on its own
19:39:24 <jtanner> what's the delta between creating a role and creating a collection? i don't remember a lof of grief over the process for creating a role
19:39:26 <abadger1999> bcoca: we're talking about the former here, not the latter.
19:39:30 <felixfontein> gundalow: I think if we start discussing that now, we'll never get to topic #2 for today
19:39:34 <bcoca> i would divide taht in 'for publishing to galaxy/including in ansible community distribution'
19:39:47 <bcoca> yes, but that is not clear in the wording
19:40:17 <gundalow> felixfontein: fair point, maybe we should just move to that anyway
19:40:26 <agaffney> jtanner: I think it's just the build step, but the reason there's grief here is because we've also taken away the option of creating a PR in ansible/ansible to add your module
19:40:40 <tadeboro> I would prefer ii, but iii is also fine with me if we revisit the decision later when other things are in a better shape.
19:40:49 <jtanner> yeah, well the later has gone away for good reason
19:40:49 <felixfontein> in any case, if we decide to cut all new stuff for c.g, I think we should maybe make an exception for existing PRs, or at least still give them a chance
19:40:51 <russoz> I recall reading somewhere about how much time the postgresql modules were taking in the CI => we should definitely have a criteria for that (like it cannot be more than 5% the total time - or 10% or whatever makes sense)
19:41:21 <felixfontein> gundalow: do you think we can answer the 'more content for c.g/c.n' question without discussing further how to make collection creation easier?
19:41:24 <agaffney> jtanner: of course, but just thinking about it from an outside contributor's perspective
19:41:49 <jtanner> i heard grief over the module submission process for years and it lead to people thinking we should "lower the bar"
19:41:52 <felixfontein> russoz: one reason they take so much time in CI is because they actually have good tests. most modules take almost no time in CI because they have no tests at all.
19:42:19 <bcoca> almost tempted to say, that is good barrier to entry
19:42:50 <agaffney> *some* barrier to entry is a good thing here, and some people are always going to complain that they can't do a drive-by code dump
19:42:51 <gundalow> As the owner of community.general the bar will not be lowered
19:43:26 <bcoca> i mean adding a collection to ansible package
19:43:45 <felixfontein> right now we only allow new stuff into c.g/c.n which actually has tests
19:44:07 <gundalow> felixfontein: I think it's `ii` or `iii`. Maybe we say `ii` and label all `iii` content to see what else could be done with it
19:44:15 <bcoca> i would argue ux gets overlooked just cause things pass tests
19:44:39 <jtanner> my suggestion: gather list of "why I can't just make my own collection" and focus on those issues, instead of further bloating c.g. and c.n.
19:44:46 <russoz> felixfontein: noted. not sure how to move forward without creating too many barriers
19:44:47 <felixfontein> bcoca: that is definitely possible
19:45:02 <abadger1999> agaffney: I think you've indirectly hit on soemthing.....I think initial code quality isn't really that important compared to "I'm going to maintain this" vs "I want to dump this code on someone else"
19:45:10 <agaffney> jtanner: "why not both?"
19:45:15 <felixfontein> gundalow: I currently prefer iii, at least until the process of creating new collections is simplified enough
19:45:27 <tadeboro> bcoca: This is why we require integration tests: they are playbooks that demonstrate how modules will be used.
19:45:35 * gundalow ======================
19:45:35 <gundalow> ======================
19:45:36 <gundalow> ======================
19:45:37 <gundalow> ======================
19:45:51 <jtanner> =.
19:45:56 <bcoca> usage test  existing is not same as good ux
19:46:01 * felixfontein *pling*
19:46:02 <gundalow> POLL: Are people OK with (for at least the moment) `ii New content only in areas that already have content, i.e. new GitLab modules would be accepted, new RandomNewCodeHoster modules would not be accepted.`
19:46:09 <abadger1999> -1
19:46:09 <gundalow> +1
19:46:12 <felixfontein> -1
19:46:14 <aminvakil> -1
19:46:18 <jtanner> -1
19:46:19 <tadeboro> +1
19:46:21 <daniel-wtd> +1
19:46:21 <russoz> -1
19:46:25 <felixfontein> andersson007_ -1's this one as well
19:46:40 <felixfontein> geerlingguy is +1 (or -1 because he tends to (i))
19:46:47 <samccann> +1
19:47:07 <agaffney> +1 on ii, with the addendum that there be an effort to break that existing content area into a new collection
19:47:22 <gundalow> All those saying -1, please state `i`, `ii`, ...
19:47:30 <gundalow> ie state your prefered option
19:47:38 <felixfontein> agaffney: everyone who wants to help with creating and maintaing collections for the areas, is welcome to step up!
19:47:46 <jtanner> (i)
19:47:49 <bcoca> +1 with same ^ and also i would add, there can be exceptions made if sufficient support from maintainers .. in case the 'golden module' is submitted
19:47:56 <abadger1999> iii
19:47:59 <aminvakil> iii
19:48:00 <russoz> (iii)
19:48:06 <felixfontein> iii
19:48:09 <geerlingguy> -1 (i)
19:48:12 <felixfontein> andersson007_ says iii
19:48:13 <dericcrago> i
19:48:15 <felixfontein> geerlingguy says i
19:48:19 <agaffney> felixfontein: I say that with no intention to help with maintaining collections, in full honesty
19:48:25 <felixfontein> ah he just wrote it himself :)
19:48:30 <gundalow> agaffney: honesty is OK :)
19:48:53 <samccann> i or ii is my preference
19:49:01 <felixfontein> agaffney: I'm already set up and am maintaining some breakout collections, and I don't want to have a whole group of them :)
19:49:03 <bcoca> i have the intentino, but honestly, not the time
19:49:03 <geerlingguy> felixfontein: the problem with the idea of 'until collections are easier' is—if we don't _FORCE_ collection maintenance to be easier by making us have to make it easier now, it ain't ever gonna happen
19:49:07 <geerlingguy> it will never be anyone's priority
19:49:24 <geerlingguy> right now collection maintenance is not easy, but there are tons of quick wins that can make it way easier
19:49:26 <agaffney> bcoca: yeah, I guess that's more where I am. although, it's more a matter of motivation than time
19:49:41 <bcoca> felixfontein: the breakout should assuem people with the time and dedication, its no good to breakout if its going to overwhelm you
19:49:48 <abadger1999> I would change to i or ii but only after there's an alternative way to easily get new content into ansible
19:49:53 <geerlingguy> like galaxy incorporating docs, making publishing easy by having galaxy do it (like docker hub, vagrant boxes, et all does it)
19:50:03 <felixfontein> bcoca: I agree, but if we want to break out all areas, someone needs to do it :)
19:50:10 <abadger1999> for instance, i or ii with community.incubator would be okay with me.
19:50:12 <bcoca> felixfontein: does not mean you
19:50:39 <bcoca> abadger1999: isnt that just creating an alternate c.general?
19:50:39 <felixfontein> bcoca: definitely not me. but people who want to do that don't grow on trees
19:50:40 <geerlingguy> If it were as easy to publish a collection to galaxy as it is a role, I don't think we'd even have a discussion
19:50:46 <dericcrago> what is the end goal for c.g in a year (or 2) from now: bigger, smaller, the same, non-existent?
19:50:55 <samccann> +1 to community.incubator
19:50:58 <bcoca> felixfontein: agreed, why it has to be clear what code will rot, imho
19:51:08 <aminvakil> abadger1999: +1 and it matters how modules from community.incubator will get out to other collections
19:51:30 <bcoca> dericcrago: seems like there is no unified goal there, i think all of the above
19:51:45 <geerlingguy> -1 to community.incubator, it's another 'blessed' collection IMO. Any kind of central collection that is a conglomerate goes against what I think is the very reason collections exist!
19:51:56 <felixfontein> bcoca: I today looked at a PR of russoz fixing some sanity errors in modules/cloud/google/, and seeing how the modules there look... *shudder* I think quite of them are already rotten
19:52:15 <felixfontein> will community.incubator get included in ansible?
19:52:16 <aminvakil> without procedure for process of moving things out of community.incubator, i'm not sure about that
19:52:25 <bcoca> what about 'incubator' w/o being community. so you can push/test ci/cd against your plugin/module w/o having to set it up?
19:52:25 <felixfontein> and will it have CI (and if yes, who takes care of it)?
19:52:43 <samccann> yeah it has to have a process - it either graduates within a year to a collection, or gets deprecated and deleted
19:52:48 <geerlingguy> -1 to blessed collections of any kind. +1 to making it easier for people to maintain collections so the 'average joe' could create and publish one and push updates to it as easily as someone could do roles on galaxy today
19:52:52 <samccann> community.incubator that is
19:53:13 <geerlingguy> samccann: if we could automate that deprecation/deletion cycle I'd be less -1 to it
19:53:14 <samccann> and my nickel is no, community.incubator is never part of Ansible
19:53:22 <bcoca> geerlingguy: i agree, that woudl be best case
19:53:28 <geerlingguy> e.g. the day a module is added, timer is started. One year later it is deleted, full stop
19:53:39 <aminvakil> samccann: +1
19:53:40 <geerlingguy> if it didn't graduate then it's gone
19:53:53 <abadger1999> felixfontein: yes, if community.incubator doesn't get included in ansible it defeats the purpose of having it.
19:53:54 <daniel-wtd> sounds reasonable
19:53:56 <felixfontein> then we need a graduation process, and people implementing it
19:54:07 <dericcrago> geerlingguy - what if incubator wasn't included in the distribution so there was incentive to get it properly collection'd
19:54:12 <samccann> the reason I like `community.incubator` is it 'lowers' the barrier to entry, but it's not a full entry. It's just a foot in the door. and if the developer doesn't keep maintaining or finding an apropriate home over time, it gets deleted
19:54:22 <russoz> felixfontein: it seems to me a number of modules have spun-off ansible project a while ago, for the obvious reasons, and we keep carrying them legacy versions around, while the bright and shiny new versions are being maintained elsewhere by their owners
19:54:31 <geerlingguy> that would be even better, but the incentive would be way less
19:55:10 <abadger1999> samccann: I would hinge deletion on whether it has a maintainer rather than time based.  But I do think that ability to delete from an incubator is an important thing for it.
19:55:12 <felixfontein> russoz: true... it's still hard to decide how to proceed without really knowing the modules
19:55:14 <gundalow> Do any other projects/programming languages have the concept of an incubator?
19:55:14 <gundalow> Or anything else that self destruct unless it finds a sponsor to graduate it?
19:55:27 <jtanner> apache as a foundation has an incubator
19:55:27 <aminvakil> abadger1999: if incubator is included in ansible, what's the difference between it and general?
19:55:30 <geerlingguy> (I hate being Mr. Negativity, but I just feel like if we burn the community three times, we're going to completely lose a lot of it)
19:55:37 <tadeboro> gundalow: Apache Foundation
19:55:42 <jtanner> but apache doesn't try to lump everthhing together in a blob
19:55:56 <geerlingguy> gundalow: Helm just went through getting rid of a central repository
19:56:00 <felixfontein> aminvakil: things are automatically deleted, so people should never ever use it for production, so content in there has not much chance of actually graduating :)
19:56:03 <geerlingguy> they made it easier for people to submit and maintain things on Helm Hub
19:56:35 <bcoca> ^ whichi s the 'galaxy approach' ... and i think that is better than relying on the kitchen sync package
19:56:43 <gundalow> geerlingguy: Thanks for saying that (burning community)
19:57:00 <gundalow> It's important to remember
19:57:00 <bcoca> unless community burns back (torches!)
19:57:30 <abadger1999> aminvakil: Right now, community.general wears many hats.  (1) Colletcion for all miscellaneous content that used to live in ansible/ansible (2) Place where people who want to contribute content but don't want to learn and maintain all the extra baggage that goes into making a collection that can make it into the ansible tarball.
19:57:35 <russoz> pitchforks!
19:57:37 <geerlingguy> gundalow: that's my biggest concern, it's hard enough with people going 'cloud native' and thinking configuration doesn't matter anymore, plus terraform eating some market—if we told people last year that "we will have some growing pains with collections, but look at all this data showing they'll make maintenance better"!
19:57:52 <geerlingguy> And then 6 months later we have community.general (and/or incubator) showing the same problems
19:58:27 <geerlingguy> then that jpmens post will be just as relevant in the collections-based world, except now we have two problems: Ansible is more complex with collections, plus the big centrally-manage collections are just as unmaintainable as ansible/ansible used to be
19:58:32 <gundalow> yup, totally agree with that
19:58:49 <abadger1999> aminvakil: The idea of community.incubator would be to separate out those two.  community.general can slowly shrink over time as content is moved out and no new content is moved in.  community.incubator can contain new content that needs more contributors to reach the critical mass of having their own collection.
19:58:49 <gundalow> So on that point, we will be doing fortnightly PRs days
19:58:58 <jtanner> i think if we collectively keep trying to persist the model of <=2.9, we'll keep repeating the same problems it had
19:59:05 <geerlingguy> that's not gonna solve the problem
19:59:13 <geerlingguy> we could have PR days every day and it won't solve the problem
19:59:25 <bcoca> yeah, cannot rename the repo and expect the same issues to go away
19:59:29 <felixfontein> in the long term, definitely
19:59:30 <geerlingguy> again, I hate to be so negative, I just think we're barking up completely the wrong tree
19:59:51 <samccann> which tree should we be barking up? making collection maintenance easier?
20:00:11 <geerlingguy> the right thing IMO: make it easy to maintain collections (right now it is far from it). Make it easy and straightforward to get collections into ansible ('community edition')
20:00:13 <bcoca> samccann looking at inclusion into ansible package
20:00:23 <geerlingguy> samccann: yes, that's the #1 issue IMO
20:00:33 <geerlingguy> as a role maintainer who is trying to maintain collections, here's my experience:
20:00:38 <russoz> +1 geerlingguy
20:00:52 <geerlingguy> 1. Roles — I maintain over 100, and it is very easy, and I can focus mostly on code concerns and features.
20:00:55 <abadger1999> geerlingguy: yep, I think that's the best end goal.
20:01:21 <agaffney> perhaps we should look at the Terraform model (at least for inspiration). they did a similar split with the providers. they don't ship everything with ansible, but they make it automatic to fetch them when referenced
20:01:26 <geerlingguy> 2. Collections - I maintain 2, and I've spent way more time working on dumb issues getting them into galaxy, trying to have documentation show up for end users, figuring out test integration, trying to get them working with ansible versions, etc.
20:01:50 <geerlingguy> the ratio of time spent fighting the tooling vs. time spent actually working on code is radically bad on the collection side of things
20:01:52 <bcoca> geerlingguy: well, part of that is roles were soo limited you were not expected to do those things
20:02:04 <geerlingguy> but galaxy took care of everything, which is part of my point.
20:02:05 <bcoca> and if it broke with ansible x.y .. well .. that is life
20:02:12 <bcoca> no, it really didnt
20:02:21 <geerlingguy> it auto-imports roles
20:02:26 <bcoca> it ignores most issues
20:02:27 <geerlingguy> I know it doesn't do packaging
20:02:38 <abadger1999> geerlingguy: the problem being that we're not going to get there in time for 2.11 (We'll be hard pressed to design workable policy for 2.11 and I highly doubt we'll have time to then work to automate and ease the learning curve sufficiently  for those policies until 2.13.)
20:03:02 <jtanner> ah, well yeah that is a fundamental model change in galaxy under the covers. roles were only indexed, whereas collections have to a published artifact that lands in pulp
20:03:32 <geerlingguy> My point is *AS AN END USER* (taking off my 'has done a lot of internal work lately'), collections are like 1000x more daunting than roles
20:03:36 <bcoca> roles mostly had very little checking overhead, collections carry much more responsibility, specially with documentation .. but its also bigger value to user
20:03:55 <bcoca> geerlingguy: end user of collections or author of collections
20:03:58 <geerlingguy> and part of the reason I hammer that drum is there are a lot more community members who might contribute roles and playbooks than Python modules and plugins
20:04:09 <felixfontein> and one problem is that a lot of things for collections aren't specified yet. especially with regard to documentation.
20:04:09 <jtanner> geerlingguy: yeah, i agree ... i think things can be done to make that more automated (if the org had the desire and the time)
20:04:14 <tadeboro> And what jtanner said right now is what enterprise users actually want. I talked to some of our customers and their experiences with roles are ... not the best.
20:04:16 <geerlingguy> bcoca: both—and speaking as someone who writes way more not-module-code than module code
20:04:35 <bcoca> geerlingguy: for that i would still continue using roles, but i know that im in minority there
20:04:57 <bcoca> collections are more complex by nature, they deliver a LOT more than roles
20:05:18 <daniel-wtd> isnt it possible to 1) implement an easy way to automatically install collections, as soon as they are named in a task/role and b) split community.general in smaller, more focussed collections? firewalld for example is in the posix collection, but iptables is in builtin and ufw is in community.
20:05:31 <bcoca> not saying we should not create tooling to make coll author life's easier, but there is an expected overhead compared to roles
20:05:50 <geerlingguy> true, true, but right now the gap is a chasm.
20:05:56 <felixfontein> daniel-wtd: part of the reason things are already spread out is that some stuff is Supported by RH, while other isn't
20:06:07 <geerlingguy> It's like going from an iPad to CLI-only Linux. Most people can't make that leap.
20:06:09 <bcoca> geerlingguy: i dont disagree, but also look at the diff in scope and features, big chasm also
20:06:29 <felixfontein> daniel-wtd: and for the rest... splitting c.g completely up needs a lot more work on maintaining a long list of collections
20:06:34 <bcoca> roles have some yearss, collections are new, its expected teh tooling is not all there .. but we do need to make it better
20:06:41 <felixfontein> daniel-wtd: but in general that would be great :)
20:07:25 <daniel-wtd> hmhm, I thought it would be easier to maintain some focussed collections like community.firewall or community.storage instead of a huge general
20:07:39 <geerlingguy> bcoca: all true. But my main overarching point is still "if the problem was that centralized content is unmaintainable at certain volumes... how is having one/few central collections with the same volume of content going to solve that problem?"
20:07:44 <geerlingguy> We can't just clone felixfontein 8 times
20:07:44 <bcoca> geerlingguy: even with the tooling, always expect more overhead with collections, since there is more to maintain, docs alone is a good example
20:08:17 <felixfontein> daniel-wtd: depends what you mean by maintaining :) if you mean making sure that CI is not broken, and sanity checks don't fail, a big collection is easier since there are less places where you have to work on
20:08:31 <bcoca> geerlingguy: totally agree, why my thinking is to eventually move away from that approach, but that is not the general thinking
20:08:43 <daniel-wtd> felixfontein: understood :)
20:08:50 <gundalow> daniel-wtd: that is one option, we did a load of research into that and we found that people didn't contribute to more that one area under (say) storage
20:09:09 <felixfontein> daniel-wtd: if you mean proper maintaining with implementing bugfixes, features etc., having smaller collections is definitely better
20:09:14 <abadger1999> geerlingguy: actually... that is one option....  Not cloning felixfontein himself.  But making sure that the number of empowered community maintainers goes up in proportion to the amount of content being added.
20:09:17 <geerlingguy> For end users, having everything in ansible/ansible was desireable for the 'one place to look' angle
20:09:47 <jtanner> minus roles
20:09:54 <geerlingguy> abadger1999: we still run into the same problems at scale that we hit with ansible/ansible though, just differently
20:10:02 <bcoca> ^ plenty of peopel asked us to ship roles in ansible/ansible
20:10:04 <abadger1999> overall, whether things are all in one collection ofr in many, our success at keeping that ratio healthy is what will determine whether end users get a good experience or not.
20:10:22 <daniel-wtd> yup
20:10:32 <geerlingguy> bcoca: We've avoided shipping roles in k8s collection, too specific for a generic group of plugins
20:10:33 <gundalow> daniel-wtd: Look at the tabs under https://stats.eng.ansible.com/apps/collections_structure/ to see about people contributing to more than on subdirectory under `lib/ansible/modules/`
20:10:53 <geerlingguy> I honestly wish roles could remain standalone and weren't being forced (someday?) into collections
20:10:56 <bcoca> geerlingguy: taht is the beuaty of collections, its up to maintainer to decide scope
20:11:02 <abadger1999> geerlingguy: no.
20:11:17 <bcoca> geerlingguy: if ihad my way, it would never be forced
20:11:47 <abadger1999> If we don't maintain a healthy ratio then whether we have a single collection or a lot of collections, then end users are still screwed.
20:11:57 <felixfontein> abadger1999: +1
20:12:25 <bcoca> i would say the issue is that 'we' dont need to maintain all this .. nor ship it
20:12:31 <felixfontein> ok. I think we really need to switch topics now.
20:12:35 <daniel-wtd> but this also intends, that someone really cares about the modules/plugins
20:12:38 <abadger1999> It does make it easier for us to communicate to end users that they're screwed (Collection A B and C are going to be removed because we don't have maintainers for them) but that doesn't help the users of A B and C any more than if that content was in a single collection.
20:12:41 <felixfontein> I guess we have to continue next week with this topic
20:13:02 <bcoca> then there will be diff collections, well maintained, badly maintained , the big issue is making it clear to users in a  good way, which is which
20:13:13 <abadger1999> I think in determining what to do here, we may have to decide on rules for who gets to decide.
20:13:14 <felixfontein> abadger1999: at least they can still manually install existing versions of the collections
20:13:16 <gundalow> =========
20:13:16 <gundalow> =========
20:13:16 <gundalow> =========
20:13:16 <gundalow> =========
20:13:21 <gundalow> OK, we will swap topics now
20:13:25 <geerlingguy> heh
20:13:36 <felixfontein> #topic Content moving, resp. adding new collections (with old content) to Ansible 2.10.x: https://github.com/ansible/community/issues/539#issuecomment-720085434
20:13:39 <abadger1999> It seems like you and andersson007_ are the main maintainers of c.g right now and you are in agreement on what course you want to take.
20:13:39 <bcoca> abadger1999: i think that should not be judge by inclusion in ansible,but by feedback in galaxy
20:14:09 <felixfontein> talking about inclusion of collections into ansible... :)
20:14:20 <daniel-wtd> ^^
20:14:49 <felixfontein> we decided we want to move stuff out of c.g/c.n (and maybe some more collections), and we started creating collections for the content, but so far we haven't really talking about when / whether we include the new collections into ansible 2.10.x
20:15:16 <felixfontein> also there are some more collections, like dellemc.openmanage, cisco.nso, infoblox.nios_modules, which contain content that's still in c.g/c.n
20:15:42 <felixfontein> so we have two things:
20:16:01 <bcoca> wll, but they have diff namespaces, so you have dupe of function but not direct conflict
20:16:10 <felixfontein> 1. accept the new collections (with almost only existing content from other collections) into 2.10.x as soon as they satisfy the points from our checklist? or do we have more conditions?
20:16:27 <felixfontein> 2. and what with collections like dellemc.openmanage, cisco.nso, infoblox.nios_module which might have some additional stuff alrady?
20:17:03 <felixfontein> bcoca: yes, like the docker modules are now in community.docker, and they were (and still are until they are removed in 2.0.0) in community.general
20:17:33 <bcoca> i would say you dont need to include those collections, since most of the peopel wont use em and those that need em have easy way to include
20:17:42 <felixfontein> so including the new collections in ansible allows users to already try the new collections, and the real switch for everyone will happen with ansible 2.11 where c.g/c.n will have redirects to the new collections, with the old content removed
20:17:47 <abadger1999> I would be okay with (1) and (2) being added.  they become tech previews since the redirects aren't added yet.  In my ideal world there's some commitment from the maintainers to push some subset of bugfixes to the old collection as well.
20:18:28 <bcoca> when it comes to a brand/tech taht is of that level, you really only want it if you invested in it already and at that point having it as additinoal collections should not be big barrier
20:18:41 <felixfontein> bcoca: a good reaosn for including them is that the old modules usually get no new features, and maybe not all bugfixes, and if they are included users can easily try them out
20:19:00 <felixfontein> from a technical POV including them into 2.10.x is trivial
20:19:07 <felixfontein> it's more a policy decision
20:19:40 <felixfontein> there's also kubernetes.core; I don't know what's it's state, geerlingguy I guess you know better, should it already get included in 2.10.x?
20:19:41 <bcoca> i would deprecate old modules and point to new collections
20:20:02 <bcoca> specially if you know they wont be updated
20:20:12 <geerlingguy> Technically yes—though we don't have redirects set up from community.kubernetes yet.
20:20:19 <felixfontein> bcoca: deprecation is not optimal since people then have to start using FQCNs to get rid of the deprecation warnings, but if they just wait two months until 2.11 is out they don't need them anyore
20:20:25 <geerlingguy> Kinda stalled on that until we get things finished for redhat.openshift and community.okd
20:20:32 <geerlingguy> (which are the same collection :P)
20:20:36 <abadger1999> The big thing I think of as a problem is being able to draw a bright line between collections that can go into 2.10.x and those that have to wait for 2.11.x.  If we can draw that bright line then I'm okay with it.
20:20:39 <bcoca> felixfontein: thought the target of this was 2.11
20:20:53 <bcoca> ^ what abadger1999 said then
20:21:06 <gundalow> I have to drop off, thanks all
20:21:15 <felixfontein> abadger1999: I guess collections in group 1 (almost 100% content that's already in 2.10.x) should be allowde, for collections in group 2 I guess it depends
20:21:24 <bcoca> i had not realized 2.10 was going to include new colelctions in minor releases
20:21:31 <felixfontein> bye gundalow!
20:21:41 <daniel-wtd> cya gundalow
20:21:57 <felixfontein> bcoca: it can do that, it already contains new modules/plugins in most minor releases
20:22:13 <felixfontein> so why not also new collections
20:22:23 <bcoca> yeah, that is what i had not realized
20:22:38 <bcoca> i was discussing from 2.11 view
20:23:02 <felixfontein> bcoca: ok
20:23:04 <bcoca> though i would not have done new modules/plugins in minor to beging with, but no tardis
20:23:39 <felixfontein> bcoca: I thought it was one of the big advantages of collections to be able to have new features (which includes new modules/plugins) faster than having to wait for the next major ansible release
20:23:53 <bcoca> collections, yes, ansible package .. not same thing
20:24:26 <agaffney> felixfontein: that only really applies when fetching collections explicitly rather than relying on the bundled collection with ACD
20:24:35 <bcoca> at that point you didnt need collections if you are going to do same with ansible
20:24:45 <abadger1999> gregdek's vision had been that ansible is like the fedora linux distro.  Linux distros do include net-new packages inside of an existing release. So I could see us eventually including net-new collections into an already released ansible.  however, I think we're struggling to decide what the criteria are for nt-new collections in 2.11 so I don't think we can do that for 2.10.
20:24:49 <felixfontein> would be nice if ansible would have semantic versioning, same as collections, then it would be more obvious
20:25:18 <bcoca> felixfontein: i think there is consensus around that, just takes work
20:25:35 <felixfontein> abadger1999: I agree
20:25:59 <bcoca> ^ at that point i would say 'ansible' is already on semantic
20:26:33 <felixfontein> bcoca: no, since you have breaking changes in 2.x.0 releases
20:26:47 <abadger1999> ansible is not on semantic versioning.  If we were the last release would have been 2.12.  And the February release would be 3.0.
20:27:16 <felixfontein> I wouldn't mind switching versioning for ansible, but I'm not sure who can actually decide that :)
20:27:19 <abadger1999> (For ansible-base/ansible-core, 2.10 would have been 3.0 and the ones since then would be 3.0.1, 3.0.2, etc)
20:27:40 <bcoca> felixfontein: well some bugfixes are 'breaking' to those that relied on them, i go by 'feature set' and 'deprecations/removals'
20:27:48 <agaffney> ansible seems to semantic versioning concepts, but it uses the "y" (in x.y.z) version component for major releases
20:27:48 <abadger1999> yeah, I mentioned my thoughts on it to gundalow this morning, he's going to look into who to talk to about that.
20:27:58 <agaffney> *seems to follow
20:28:17 <felixfontein> abadger1999: great! :)
20:28:29 <felixfontein> that's something I've been waiting for for some time now ;)
20:28:35 <felixfontein> (but it's relatively low priority for me)
20:28:43 <felixfontein> ok. so about our current topic.
20:29:07 <abadger1999> agaffney: yeah that's sort of true.  Although the version sometimes bumps unnecessarily and also it's about playbook compatibility rather than cli or API compat.
20:29:08 <felixfontein> is anyone against including the new collections which consist only of existing 2.10 content to be included in 2.10.x once they satisfy the conditions from our checklist?
20:29:11 <bcoca> in any case, im pretty out of date, thought 'ansible' was continuing the existing policies/behaviours for a few versions, but its alredy departed
20:29:22 <felixfontein> https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst <--- checklist
20:30:45 <abadger1999> +1 to allowing collections those in for 2.10
20:31:01 <abadger1999> s/allowing collections those/allowing those collections/
20:31:07 <felixfontein> that is mainly for collections such as community.docker, community.kubevirt, community.postgresql, community.routeros
20:31:16 <felixfontein> (not sure about community.okd, but probably also true for kubernetes.core)
20:31:27 <felixfontein> I'm also +1
20:32:18 <felixfontein> VOTE: include (+1) or not include (-1) these collections (and similar ones that have almost 100% 'old' content) in 2.10.x?
20:32:22 <felixfontein> #chair
20:32:22 <zodbot> Current chairs: abadger1999 agaffney bcoca dericcrago felixfontein geerlingguy gundalow jtanner russoz samccann sivel tadeboro
20:32:23 <abadger1999> felixfontein: You asked about additional policies...  Can we add "Maintainers commit to pushing security fixes to the old location"?
20:32:23 <felixfontein> +1
20:32:32 <tadeboro> +1
20:32:34 <abadger1999> +1
20:32:42 <bcoca> +1 but i would start deprecating 'old content'
20:32:47 <russoz> +1
20:32:55 <cyberpear> +1
20:32:56 <bcoca> its confusing for users to have 2 toosl for same thing in same box
20:33:08 <felixfontein> abadger1999: I would expect they do that anyway, not sure whether we can enforce it though
20:33:52 <felixfontein> bcoca: forcing people to change all their roles/playbooks for only < 2 months just to get rid of deprecation warnings is a bit extreme
20:33:54 <geerlingguy> +1
20:34:13 <cybette> +1
20:34:23 <geerlingguy> bcoca: yeah, it's going to be confusing and/or annoying — at least we can make it a little less confusing
20:34:28 <bcoca> they dont need to change it in 2months, well .. unless that is new deprecation period
20:34:36 <felixfontein> sounds like the 'new collections' feature of the combined changelog generator will get into action soon ;)
20:34:54 <abadger1999> Yeah, I'm thinking something like, the maintainer opens a github PR to add the collection to ansible-2.10.5.deps and they need to state that they will continue to push security fixes to the old location as well.
20:34:54 <felixfontein> bcoca: they need to change, since precisely for these two months the old name will trigger a deprecation warning
20:35:20 <bcoca> the warning is to avoid failure when removed, not to remove to avoid warning
20:35:26 <geerlingguy> abadger1999: bcoca and to that point, it gets really tricky trying to backport changes across repos
20:35:41 <felixfontein> bcoca: the modules/plugins are replaced with redirects, so the remove is not visible to users. (except for 2.9 users.)
20:35:43 <bcoca> felixfontein: and only cause i assume that in the end the 'old content' is being removed
20:35:50 <bcoca> then redirect now?
20:36:01 <felixfontein> that's a breaking change and disallowed by semver
20:36:11 <bcoca> how is it breaking?
20:36:14 <felixfontein> c.g 2.0.0 can do breaking changes, c.g. 1.x.0 can't
20:36:24 <bcoca> the whole point of the reidrects is 'not to break'
20:36:26 <felixfontein> it's breaking for 2.9 users, and for ansible-base 2.10 users who installed the collection manually
20:36:54 <bcoca> how so? the runtime redirect is  int he collection itself
20:37:11 <felixfontein> bcoca: the new collections won't be added as collection dependencies to c.g
20:37:12 <bcoca> so if they have the collection installed, that will be used
20:37:33 <felixfontein> so if they just upgrade c.g to a newer version, suddenly some things will stop working because they didn't install the other collections as well
20:38:04 <bcoca> ah, but that was an issue with how you do redirects and not provide the dependencies
20:38:08 <bcoca> that is a choice
20:38:46 <felixfontein> #agreed collections that contain almost 100% content from existing ansible 2.10 collections will get included in ansible 2.10.x once satisfying all additional conditions
20:39:13 <felixfontein> bcoca: true, but we want to reduce dependencies, not add new ones, so we add redirects and no dependencies in 2.0.0
20:39:20 <felixfontein> and not earlier
20:39:30 <felixfontein> also it would still be a breaking change for 2.9 users, since redirects don't work for them
20:39:47 <bcoca> well, if you make that choice, yes it breaks, but not by nature of the redirect, just conflicting directives
20:40:02 <felixfontein> ok, for the additional conditions
20:40:34 <felixfontein> VOTE: additional conditions are: (1) satisfy https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst, (2) satisfy that + promise to backport security fixes, (3) satisfy that + something else (needs more discussion)
20:40:50 <felixfontein> (just state 1, 2, 3)
20:40:54 <felixfontein> #chair
20:40:54 <zodbot> Current chairs: abadger1999 agaffney bcoca dericcrago felixfontein geerlingguy gundalow jtanner russoz samccann sivel tadeboro
20:41:02 <felixfontein> 2
20:41:09 <abadger1999> 2
20:41:12 <tadeboro> 2
20:41:22 <russoz> 2
20:41:34 <felixfontein> (the link is the collection requirement checklist we used for inclusion in 2.10 earlier this year, for everyone not familiar with it)
20:41:39 <geerlingguy> 2
20:41:53 <geerlingguy> (security fixes only though!)
20:42:11 <felixfontein> geerlingguy: some might also backport bugfixes or even features, but that's voluntarily
20:42:15 <abadger1999> <nod>
20:42:40 <felixfontein> similar to backporting fixes from collections to stable-2.9
20:42:50 <felixfontein> possible, but not required
20:43:36 <felixfontein> ok, looks like this is answered as well :)
20:44:02 <felixfontein> #agreed the additional conditions are satisfying the points of https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst, and promising to backport security fixes to the old collection
20:44:50 <felixfontein> I guess the next step would be to look at all collections which have significant new content, and decide what to do with them
20:44:59 <felixfontein> but for that we actually have to know which ones contain new content
20:45:25 <abadger1999> <nod>
20:45:27 <felixfontein> I haven't analyzed that for infoblox.nios_modules, dellemc.openmanage and cisco.nso, so no idea
20:46:33 <abadger1999> Would something like "Sign off by the collection maintainer that the partial content comes from" be okay?
20:46:36 <felixfontein> geerlingguy: I guess you know more about community.okd and kubernetes.core, so I guess feel free to ask for inclusion when you think they are ready for that
20:46:53 <felixfontein> ok. we're 46 minutes over time already (again :) ).
20:46:57 <felixfontein> #topic open floor
20:47:04 <felixfontein> does anyone have something for the open floor?
20:47:04 <geerlingguy> felixfontein: yeah we'll be ready... sometime
20:47:05 <abadger1999> I have one thing for open floor
20:47:24 <abadger1999> Tentative proposed schedule for ansible-2.11
20:47:32 <felixfontein> \o/
20:47:39 <abadger1999> And ***EXTREMELY TENTATIVE*** proposed schedule for ansible-2.12.
20:47:43 <geerlingguy> ...tomorrow!
20:47:49 <felixfontein> yesterday?
20:48:06 <abadger1999> #info Prposed ansible-2.11 and 2.12 schedules: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
20:48:17 <abadger1999> :-)
20:48:38 <felixfontein> that was quick ;)
20:49:13 <abadger1999> Getting approval from other people inside the rht fence.  If anyone here, in the community, has feedback too, that would be appreciated.
20:49:32 <felixfontein> so 2.11 goes from beta to final in the first half of February 2012, and 2.12 has a completely new schedule
20:49:37 <geerlingguy> sounds reasonable
20:49:53 <felixfontein> is there a reason that 2.12 will come out that soon after 2.11?
20:50:07 <felixfontein> or in other terms, "shortly" before c.g/c.n 3.0.0 are released?
20:50:08 <abadger1999> The big thing for 2.11 is that I've vastly reduced the number of milestones (alpha/beta/rc) before the 2.11.0 final release because I don't think there's many things that can block that release.
20:50:38 <abadger1999> 2.12 is more tentative... it has a lot of pre-releases so that we can test against the ansible-core-2.11.0 release.
20:51:52 <felixfontein> I wonder whether we should adjust the c.g/c.n 6 month cycles. but I guess that also depends what happens with ansible 2.13, 2.14, ...
20:52:06 <abadger1999> felixfontein: Yeah.... I would like to have more time between 2.11 and 2.12 honestly... but I also think that we want to have a chance to test the ansible-core-2.11 release with ansible-2.12 when there's still a chance to find blockers in the ansible-core code.
20:52:42 <abadger1999> Which means that we need to start the release process when ansible-core starts producing pre-releases.
20:53:14 <abadger1999> felixfontein: I also felt like end users will probably want an ansible release soon after the new ansible-core release comes out.
20:53:21 <felixfontein> I guess that means that c.g 3.0.0 will only be included in ansible 2.13, and ansible 2.12 will still have c.g 2.x.y
20:53:49 <abadger1999> felixfontein: But if you can think of reasons we shouldn't do that, we can adjust the schedule and put in rationale.
20:54:03 <abadger1999> <nod> yeah, it could.
20:54:21 <felixfontein> the reasons for releasing 2.12 that early totally make sense to me :)
20:54:42 <felixfontein> it's just that it is unfortunate for the chosen schedule of c.g/c.n, but maybe that's another reason why more content should be moved out soon ;)
20:54:49 <felixfontein> makes releasing more flexible
20:54:53 <abadger1999> yeah.
20:55:50 <abadger1999> options: adjust ansible-2.12 schedule to be later, adjust c.g/c.n schedule to be earlier, just deal with it because 3-4 months later we'll pick up the changes.
20:56:09 <felixfontein> I'm currently tending to the third option (just deal with it)
20:56:19 <felixfontein> because it is not as bad as the first two :)
20:56:22 <abadger1999> 2.12 is a ways off so I'm open to discussing that... just want to be sure we list our rationale and pros and cons.
20:56:31 <abadger1999> <nod> :-)
20:56:52 <daniel-wtd> I have to drop off. cya :)
20:56:59 <abadger1999> Thanks for attending :-)
20:57:06 <abadger1999> Okay, that's all from me on this subject.
20:57:17 <felixfontein> sounds good.
20:57:32 <felixfontein> since nobody else mentioned that they have something for the open floor, let's close the meeting
20:57:35 <felixfontein> at almost 2 hours :)
20:57:45 <felixfontein> #endmeeting