18:00:24 <felixfontein> #startmeeting Ansible Community Meeting
18:00:24 <zodbot> Meeting started Wed Aug 12 18:00:24 2020 UTC.
18:00:24 <zodbot> This meeting is logged and archived in a public location.
18:00:24 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:24 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:29 * gundalow waves
18:00:30 <felixfontein> #chair gundalow andersson007_
18:00:30 <zodbot> Current chairs: andersson007_ felixfontein gundalow
18:00:32 <SerenityNow> hey :)
18:00:34 <felixfontein> so who's here?
18:00:37 <felixfontein> #chair SerenityNow
18:00:37 <zodbot> Current chairs: SerenityNow andersson007_ felixfontein gundalow
18:00:40 <felixfontein> hi SerenityNow!
18:01:58 <samccann> helloooooo
18:01:59 <gundalow> (just finishing up in another meeting with abadger at the moment)
18:01:59 <felixfontein> abadger1999: acozine: cyberpear: samccann:
18:02:03 <felixfontein> #chair samccann
18:02:03 <zodbot> Current chairs: SerenityNow andersson007_ felixfontein gundalow samccann
18:02:03 <SerenityNow> This is prajith, im from RHHI team @ RedHat, maintainer of gluster ansible collection :)  (first time here)
18:02:21 <felixfontein> SerenityNow: welcome to the community meeting!
18:02:21 <abadger1999> Greetings.
18:02:26 <felixfontein> #chair abadger1999
18:02:26 <zodbot> Current chairs: SerenityNow abadger1999 andersson007_ felixfontein gundalow samccann
18:02:35 <felixfontein> #topic agenda: https://github.com/ansible/community/issues/539
18:03:03 <felixfontein> about today's agenda: I think we should first talk a bit about backporting, since that should be pretty quick, and then continue with moving content, in particular the gluster collection
18:03:08 <felixfontein> is that ok for everyone?
18:03:10 <gundalow> +1
18:03:20 <andersson007_> ok
18:03:24 <SerenityNow> cool,
18:03:30 <samccann> sure
18:03:52 <felixfontein> or is there anything else that someone wants to have discussed ASAP?
18:04:26 <gundalow> #topic Backports
18:05:09 <felixfontein> background: now that c.g/c.n 1.0.0 have been released, there's a stable-1 branch from which 1.x.0 will be released, i.e. all non-breaking changes can/should be backported to stable-1
18:05:42 <felixfontein> we discussed earlier that we want to use a/the bot to make this easier, and/or let module maintainers merge the backports by shipit'ing them
18:06:00 <felixfontein> right now, we neither have a bot which can help with that, nor do we have much things merged anyway
18:06:15 <felixfontein> so my question would be: how should we handle backports right now?
18:06:31 <felixfontein> so far, I've tried to tag all PRs which need backporting (or could be backported) with a label
18:07:00 <felixfontein> the most efficient thing is probably for one person to simply open all PRs, open links to the commits, and just cherry-pick them one-by-one directly to stable-1
18:07:29 <felixfontein> alternatively, we can create backport PRs for every one of the merged PRs, or let the PR authors create the backport PRs
18:07:30 <gundalow> There are bots that will create backport PRs if a label gets added, (from a quick google, not tested) https://github.com/tibdex/backport
18:07:41 <abadger1999> <nod>  And then open a single PR with all of those changes?  (like the docs team's backportpalooza days)?
18:08:13 <felixfontein> abadger1999: either that (and disable squash merge for that PR), or just push them directly to stable-1
18:08:31 <felixfontein> we should just avoid to squash them to make it easier to revert them
18:08:40 <abadger1999> <nod>  The only issue with pushing directly is if that causes CI to fail.
18:08:44 <samccann> fwiw docs does this before a release (after the stable-xx is created)... but it's not sustainable. We peter out after the release
18:08:52 <abadger1999> <nod> I agree squashing would not be good.
18:09:12 <abadger1999> samccann: Good to know.
18:09:16 <felixfontein> samccann: it would definitely not be a long-term solution
18:09:20 <samccann> yeah a bot would be helpful.
18:09:28 * samccann ponders if we could use a bot in docsland as well
18:09:42 <felixfontein> gundalow: should we try the bot approach? (i.e. do you have time to get one up and running?)
18:10:18 <gundalow> felixfontein: I can have a quick test of some bits tomorrow
18:10:23 <felixfontein> we mainly have to get something working (either via bot or manually) before we release 1.1.0 on 2020-08-18 ;)
18:10:36 <gundalow> Some appear to be GitHub actions, so no services to host/run
18:10:47 <felixfontein> gundalow: that would be great!
18:11:06 <felixfontein> what does everyone think about using a bot?
18:11:18 <baptistemm> +1
18:11:22 <felixfontein> #chair baptistemm
18:11:22 <zodbot> Current chairs: SerenityNow abadger1999 andersson007_ baptistemm felixfontein gundalow samccann
18:11:36 <baptistemm> as long as it does what are in the above requirements
18:11:46 <felixfontein> or asked differently: does anyone want to discuss another solution?
18:11:50 <abadger1999> +1
18:12:00 <andersson007_> if it's safe enough it's ok
18:12:03 <abadger1999> (for using a bot)
18:12:06 <felixfontein> baptistemm: I guess for now, the bot would be triggered by setting a label, which limits the people who can do that to the ones who can merge
18:12:17 <samccann> +1 to a bot (and not just because I'd like to steal the process for docs... :-)
18:12:34 <felixfontein> also the bot should just create PRs (at least for now), merging is still done manually (or later via ansibullbot)
18:12:44 <baptistemm> felixfontein: but I meant also for not squashing, how to handle CI, backport failure
18:12:56 <gundalow> For repos apart from c.general and c.network I think bot is good, as maintainers can add label as they hit merge
18:13:08 <felixfontein> baptistemm: the bot would (I think) create a PR, for which tests will run
18:13:34 <felixfontein> gundalow: ansibullbot could add a label when merging too, right?
18:13:35 <andersson007_> "automaticaly created PRs" sounds good
18:13:43 <baptistemm> should we ask all collections included in ansible to do the same ?
18:13:55 <gundalow> felixfontein: yes, though would need to decide how that label gets added
18:14:13 <gundalow> I think the technical bits are OK. it's the non-technical bits that need resolving
18:14:26 <felixfontein> gundalow: true :) I guess for now we do it manually, until we have time to discuss and implement that
18:14:29 <felixfontein> true
18:16:26 <gundalow> felixfontein: I'll have a play tomorrow
18:16:31 <felixfontein> gundalow: sounds good!
18:16:35 <felixfontein> should we vote on this?
18:16:59 <felixfontein> (I guess the result is pretty clear anyway)
18:17:17 <gundalow> I'll test a few things and report back in here tomorrow
18:17:24 <gundalow> what's next?
18:17:33 <felixfontein> cool!
18:17:43 <felixfontein> I think the next topic is moving content, and in particular the gluster collection
18:18:04 <felixfontein> #topic moving content between collections after 1.0.0 is released, and the gluster collection
18:18:23 <felixfontein> abadger1999 summarized the situation for gluster here: https://github.com/ansible-collections/community.general/issues/761
18:18:31 <felixfontein> #info summary of situation (for gluster): https://github.com/ansible-collections/community.general/issues/761
18:18:42 <felixfontein> there are two things to consider:
18:18:59 <felixfontein> 1) due to semver we cannot remove content from community.general before 2.0.0
18:19:28 <felixfontein> 2) ansible-base is frozen, but we could maybe update ansible_builtin_runtime.yml for ansible-base 2.10.1
18:19:44 <felixfontein> (at least if that change is considered a bugfix - no idea if core team will accept it though)
18:20:56 <felixfontein> about: "community.general updates to 2.0.0 before ansible-2.10.0-beta1 with the content moved out." from that issue: that would screw up our deprecation cycles
18:21:05 <abadger1999> yeah.
18:21:41 <abadger1999> Well..  We can bump the version numbers.
18:21:41 <abadger1999> No one complains when they have more time.
18:21:43 <SerenityNow> felixfontein if ( due to semver we cannot remove content from community.general before 2.0.0), then is it correct understanding that, gluster-collections could go only on further 2.10.x releases?
18:22:11 <gundalow> Regarding `2`, if `ansible==2.10.0` is released *after* `ansible-base==2.10.1` (which may include updated ansible_builtin_runtime, does that change anything?
18:22:23 <felixfontein> SerenityNow: the gluster collection could already be in 2.10.0 IMO, it would just not automatically be redirected to when the short names of the modules are used
18:22:38 <felixfontein> gundalow: I think it would
18:23:29 <felixfontein> when comparing the roadmaps for ansible-base and anbisible: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_10.rst#expected https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst#release-schedule
18:23:44 <felixfontein> ansible-base 2.10.0 is supposed to be released this week, and 2.10.1 probably ~3 weeks later
18:24:24 <felixfontein> ansible 2.10.0rc1 is scheduled for 2020-09-08, which is roughtly 3 weeks after ansible-base 2.10.0 is supposed to be released
18:24:32 <abadger1999> felixfontein: I would support that (gluster in 2.10.0 but hte short names don't redirect to it).  I'm not sure it's the best way, but it is probably the way to get the collection included that impacts other people/things the least.
18:25:12 <felixfontein> so I think we could manage to release rc1 after ansible-base 2.10.1 is released (and the ansible_builtin_runtime.yml update is in there), we would be fine and the modules from the gluster collection are used
18:26:42 <felixfontein> gundalow: do you think it is possible to get ansible_bulitin_runtime.yml adjusted for ansible-base 2.10.1?
18:27:37 <gundalow> nitzmahone: Could we update entries (no adding new entries) in `ansible_bulitin_runtime.yml` in ansible-base 2.10.1
18:28:13 <nitzmahone> generally yes, if there are bugs that are preventing things from working
18:28:42 <gundalow> nitzmahone: context: Some content is being span out of community.general into a dedicated collection. So although we could do ansible-base -> community.general -> gluster.gluster. That means people would need to pull in the huge c.general collection, which I'd like to avoid
18:28:47 <felixfontein> this would not be a bug that prevents things from working, but still a bug since the modules in c.g are dead and will get deprecated
18:29:05 <felixfontein> (because they live in another collection)
18:29:42 <nitzmahone> We don't want to use runtime as a perpetual running map of the current state of the world- it needs to be effectively frozen very soon, because if stuff is moving and people aren't putting redirects in place, it's going to break anyway.
18:30:37 <nitzmahone> I expected that we'd have some late-breaking changes to it, and I'm not opposed in general, but I think once ACD has actually released, we're going to need a really good reason to touch the builtin routing file after that
18:31:13 <felixfontein> ACD would probably wait with rc1 for ansible-base 2.10.1 if that change goes into ansible-base 2.10.1
18:31:15 <nitzmahone> Things will likely get spun out of c.g all the time- we can't be updating routing when that happens
18:31:24 <felixfontein> (or at least I would vote for that, no idea who has the final decision)
18:32:16 * cyberpear arrives late
18:32:36 <felixfontein> in this case it should have been removed already months ago, since the gluster collection has been around since end of april, but it probably got lost because the gluster collection team didn't knew what to do, and we didn't knew about them
18:32:45 <gundalow> #chair cyberpear
18:32:45 <zodbot> Current chairs: SerenityNow abadger1999 andersson007_ baptistemm cyberpear felixfontein gundalow samccann
18:32:54 <felixfontein> #chair nitzmahone
18:32:54 <zodbot> Current chairs: SerenityNow abadger1999 andersson007_ baptistemm cyberpear felixfontein gundalow nitzmahone samccann
18:33:22 <nitzmahone> Yep, like I said, I'm fine with changes like that until ACD actually releases- after that, the chain needs to be preserved by the collections
18:33:23 <felixfontein> (the beginning of the alphabet is over-represented)
18:33:38 <abadger1999> felixfontein: Yeah, I think I'd mark ansible-2.10.1 release as a blocker for ansible-2.10.0 if we're going to do this.
18:33:39 <gundalow> nitzmahone: change will also be preserved by collection
18:35:03 <felixfontein> I think this sounds good :)
18:36:02 <felixfontein> should we do this? i.e. 1) include gluster in ansible 2.10.0, 2) adjust ansible_builtin_runtime.yml for ansible-base 2.10.1 to redirect gluster modules to the gluster collection, 3) delay ansible 2.10.0rc1 until ansible-base 2.10.1 has been released?
18:36:24 <gundalow> I'm happy with that
18:36:45 <felixfontein> is anyone opposed to that?
18:36:47 <gundalow> Have all collections reached 1.0.0 anyway?
18:36:52 <samccann> +2
18:36:58 <felixfontein> gundalow: unfortunately not
18:37:05 <samccann> haha ok stacking the vote on that one... sorry :-)  but yep, I like it
18:37:17 <cyberpear> sounds good to me
18:37:22 <gundalow> felixfontein: so extra bit of time might be needed there anyway
18:37:52 <cyberpear> generally, I think we could move content between collections w/o breakage via runtime.yml redirect, depending on how strictly we interpret semver... do we have explicit inter-collection deps?
18:38:12 <baptistemm> is there a tool to check last release of collections of ansible_bulitin_runtime.yml ?
18:38:20 <felixfontein> cyberpear: I guess that would be the next topic ;) (also what to do with the gluster modules in c.g)
18:38:27 <baptistemm> release _version_
18:38:37 <felixfontein> baptistemm: doing a new release (without publishing it) is the most effective way to do it
18:40:10 <felixfontein> abadger1999: btw, `if t.TYPE_CHECKING:` type-checking imports can cause code to fail during runtime
18:40:26 <SerenityNow> felixfontein also what to do with the gluster modules in c.g :-  if gluster_collections are included in 2.10.0 then i could probably raise a PR to remove gluster modules from community general, (that is if thats the right approach, ) &&( if i have interpretted correctly)
18:41:07 <felixfontein> SerenityNow: removal is not acceptable because of semver. they need to be deprecated and removed eventually, and maybe some redirect is needed (that has to be discussed)
18:41:39 <SerenityNow> felixfontein owh okay,
18:42:01 <cyberpear> can we redirect non-removed plugins -- use the redirect version if it's installed; otherwise use the internal version?
18:42:14 <nitzmahone> no
18:42:30 <nitzmahone> routing directives stop the lookup
18:42:50 <nitzmahone> I dorked with something like that, but it makes a horribly complicated code path WAY more horrible
18:43:01 <cyberpear> fair enough
18:43:31 * acozine waves, very late
18:43:35 <felixfontein> #chair acozine
18:43:35 <zodbot> Current chairs: SerenityNow abadger1999 acozine andersson007_ baptistemm cyberpear felixfontein gundalow nitzmahone samccann
18:44:09 <abadger1999> felixfontein: Ouch, you'll have to show that to me.  I didn't know that could happen
18:44:11 <felixfontein> I think that removing and simply redirecting (without former deprecation) would violate semver if we don't add a dependency on the collection we redirect to
18:44:31 <felixfontein> abadger1999: with PYthon 3.8 I got:
18:44:32 <felixfontein> File "/home/felix/projects/code/github-cloned/antsibull/antsibull/build_ansible_commands.py", line 41, in <module>
18:44:35 <felixfontein> ) -> t.Dict[str, SemVer]:
18:44:37 <felixfontein> NameError: name 'SemVer' is not defined
18:44:38 <cyberpear> agreed, in that case the dep on the older major version would be required
18:45:07 <abadger1999> I know you can quote SemVer there... but I didn't think you'd have to.
18:45:28 * abadger1999 will have to look up the docs to see if it's expected that you have to use a string in that case.
18:46:39 <felixfontein> hmm, for the gluster modules, I guess we could simply deprecate them for 2.0.0, remove them in 2.0.0 and add a redirect (with another deprecation for removal of redirects in 3.0.0) but not add a dependency
18:47:05 <felixfontein> I'd like to avoid adding dependencies, they are hard to get rid off later on :)
18:49:46 <felixfontein> there are 20 collections which have not reached 1.0.0
18:50:17 <felixfontein> https://gist.github.com/felixfontein/2876b20d632edebc3c7157559eda1bc0
18:50:32 <baptistemm> wow, trying to coordinate some many external collection in ansible not going to be funny
18:50:35 <felixfontein> oh wait
18:50:37 <felixfontein> maybe less
18:51:07 <felixfontein> I need to update the build file first
18:51:41 <gundalow> baptistemm: yup, there is a reason I wanted to large dumping grounds (c.general & c.network)
18:51:57 <felixfontein> 18
18:52:15 <felixfontein> the list is here: https://gist.github.com/felixfontein/2876b20d632edebc3c7157559eda1bc0
18:54:51 <abadger1999> So, are we at the stage of recording that as a few actions?
18:55:28 <felixfontein> the first part, yes
18:55:42 <felixfontein> not sure what to do with the gluster modules in c.g afterwards
18:55:47 <abadger1999> #action abadger1999 will talk to the core team about ansible-2.10.0 blocking on the release of ansible-base-2.10.0
18:56:12 <felixfontein> #action do you mean ansible-base 2.10.1 blocking the release of ansible 2.10.0?
18:56:15 <felixfontein> ah
18:56:15 <felixfontein> #undo
18:56:15 <zodbot> Removing item from minutes: ACTION by felixfontein at 18:56:12 : do you mean ansible-base 2.10.1 blocking the release of ansible 2.10.0?
18:56:44 <abadger1999> Yeah, same thing but I may have phrased it poorly.
18:56:46 <abadger1999> #undo
18:56:46 <zodbot> Removing item from minutes: ACTION by abadger1999 at 18:55:47 : abadger1999 will talk to the core team about ansible-2.10.0 blocking on the release of ansible-base-2.10.0
18:57:10 <abadger1999> #action abadger1999 will talk to the core team about ansible-base-2.10.1 blocking the release of ansible-2.10.0
18:57:39 <abadger1999> #action abadger199 will let robyn know of potential to slip if ansible-base-2.10.1 isn't released  before ansible-2.10.0rc1
18:58:06 <felixfontein> considering current schedules, it will probably slip by 2-3 days
18:58:09 <abadger1999> #action abadger1999 will add gluster.gluster to the ansible-2.10 collections
18:58:22 <felixfontein> (ansible-base is released on thursday, ansible on tuesday)
18:59:11 <baptistemm> as SerenityNow is here, there is something to do on the gluster.gluster collection to make is suitable ?
18:59:24 <abadger1999> #info the plan for gluster.gluster is: . 1) include gluster in ansible 2.10.0, 2) adjust ansible_builtin_runtime.yml for ansible-base 2.10.1 to redirect gluster modules to the gluster collection, 3) delay ansible 2.10.0rc1 until ansible-base 2.10.1 has been released?
18:59:33 <felixfontein> it would be good if the gluster collection would have 1.0.0 released by 2020-08-18 as well
18:59:40 <abadger1999> SerenityNow: ^
18:59:50 <SerenityNow> felixfontein noted
19:00:08 <felixfontein> good :)
19:00:20 <abadger1999> Who wants the action item to add the redirects for gluster.gluster?
19:00:30 <felixfontein> I can do that
19:00:38 <abadger1999> Cool :-)
19:00:47 <felixfontein> #action felixfontein adjust ansible_builtin_runtime.yml to redirect gluster modules to gluster.gluster
19:00:53 <felixfontein> (or create PR for it, that is...)
19:01:09 <baptistemm> I can do either this evening
19:01:16 <SerenityNow> apologies for yet another noob doubt here, but , [off talk] , once the repo was up a few months back, i kind of launched 1.0.0 on galaxy.collections to test them  , felixfontein just wanted to ask you if its the same?
19:01:23 <SerenityNow> felixfontein ^^
19:01:31 <abadger1999> For removal, I guess we need to deprecate the gluster plugins in community.general and then remove them after the deprecation cycle is up?
19:01:40 <SerenityNow> *ansible.galaxy.
19:01:52 <felixfontein> SerenityNow: hmm, if 1.0.0 was just a test release, better go to a polished 2.0.0 then :)
19:02:11 <felixfontein> or 1.1.0 or something like that, if you don't break backwards compatibility
19:02:21 <felixfontein> abadger1999: I'd say so
19:02:29 <baptistemm> +1 for 1.1.0 release
19:02:31 <SerenityNow> felixfontein  sounds good :)
19:02:39 <SerenityNow> cool
19:02:42 <felixfontein> should we do the full cycle (i.e. deprecate soon, delete for 3.0.0), or a very short cycle (delete for 2.0.0)?
19:03:04 <baptistemm> SerenityNow: I did not see tag 1.0.0 in the gluster git repo though
19:03:16 <felixfontein> we could also remove them in 2.0.0 and then add redirects (with another deprecation for removal in 3.0.0)
19:03:22 <abadger1999> I'm okay either way.  I could see a short cycle as benefitting end users.
19:03:55 <felixfontein> I would only start deprecating them once ansible-base 2.10.1 has been released, i.e. only for community.general 1.2.0
19:03:55 <baptistemm> the same for me
19:04:54 <felixfontein> POLL: a) deprecate for removal in 2.0.0; b) deprecate for removal in 2.0.0, then add deprecated redirects for another major version; c) deprecate for removal in 3.0.0 (and potentially redirects afterwards)
19:04:55 <SerenityNow> baptistemm i meant at galaxy.ansible.com, it had asked me for a version number to which i gave 1.0.0, so now https://galaxy.ansible.com/gluster/gluster -> has install version 1.0.0 ( released a month ago)
19:05:27 <felixfontein> SerenityNow: we're talking about 1.0.0 because most collections are in the 0.x.y realm right now (or used to be, most of them have 1.0.0 released or even something afterwards)
19:05:50 <baptistemm> SerenityNow: yes I understand but I would expected to find in the git repot the tag 1.0.0 corresponding to the release.
19:06:09 <felixfontein> SerenityNow: the 1.0.0 boundary is important because from 1.0.0 you are bound to all semantic versioning rules, while for 0.x.y you can do essentially what you want
19:06:21 <felixfontein> (w.r.t. backwards compatibility)
19:06:29 <felixfontein> #chair
19:06:29 <zodbot> Current chairs: SerenityNow abadger1999 acozine andersson007_ baptistemm cyberpear felixfontein gundalow nitzmahone samccann
19:06:36 <felixfontein> any opinions on the above poll?
19:06:46 <baptistemm> a
19:06:46 <cyberpear> since it's early in the life, probably fine to just remove it for 2.0.0; but it still seems very low cost to keep the redirects "indefinitely"
19:06:47 <SerenityNow> baptistemm yep will do that
19:06:56 <SerenityNow> felixfonteinoh okay!
19:07:03 * acozine searches backscroll for the poll meaning
19:07:46 <felixfontein> cyberpear: I mainly want to remove the actual modules, the redirects are very lightweight ;)
19:08:14 <nitzmahone> Remember that tombstoned removals are also instant and fatal, so they shouldn't be used except for plugins that are truly dead (since hitting a tombstone during a collection search stops the search)
19:08:15 <acozine> ah, is this about the gluster modules? i'd vote for a.
19:08:16 <abadger1999> Would redirects mean that we needed to add a dependency o nthe gluster.gluster collection, though?
19:08:30 <baptistemm> SerenityNow: https://github.com/gluster/gluster-ansible-collection/issues/5 also have a look to this checklist
19:08:52 <felixfontein> nitzmahone: I guess for later moves we need to have redirects without deprecation, to avoid the short names triggering deprecation warnings for users
19:08:55 <abadger1999> (if so, that's a slight counter to  "lightweight ")
19:09:00 <SerenityNow> felixfontein (" the 1.0.0 boundary is important because from 1.0.0 you are bound to all semantic versioning rules, while for 0.x.y you can do essentially what you want") -> since i missed out on this before,  would 1.1.0 be okay for the next updated release?
19:09:04 <SerenityNow> baptistemmchecking
19:09:23 <SerenityNow> baptistemm ah yes im already working on this :-)
19:09:31 <felixfontein> abadger1999: I would not add a redirect
19:09:51 <nitzmahone> abadger1999: I wouldn't- the point is to let these things be independent, but if someone's using old content that points at c.g, a newer version of c.g can fail and say "hey you need this"
19:09:51 <felixfontein> SerenityNow: if you didn't add breaking changes between 1.0.0 and 1.1.0, that's totally fine!
19:10:03 <nitzmahone> (for the future)
19:10:04 <abadger1999> I think I'm (a)
19:10:09 <felixfontein> SerenityNow: 1.1.0 can have new features and backports, but no breaking changes (like feature/module/plugin removals)
19:10:09 <SerenityNow> felixfontein cool,
19:10:37 <SerenityNow> felixfontein ah cool then, it does not have any changes to modules or plugins
19:10:55 <SerenityNow> apart from the checklist changes of course
19:10:58 <felixfontein> I'm for (b), second choice would be (a)
19:11:14 <andersson007_> a
19:11:16 <felixfontein> SerenityNow: then 1.1.0 is fine (maybe even 1.0.1, whatever you prefer)
19:11:23 <abadger1999> nitzmahone: Hmmm... okay... so it's kind of policy?  if the collection thinks it's okay to fail right away (in it's release and support cycle), then they don't need to depend.  But if they think it should continue working for some deprecation cycle, they would need to depend?
19:11:32 <baptistemm> 1.0.0 seems quite similar to actual repo status
19:11:36 <felixfontein> a) means we'll have tombstone entries from 2.0.0 on
19:11:39 <samccann> distracted, so abstaining on this vote
19:11:42 <SerenityNow> felixfontein okay.
19:11:50 <felixfontein> (which would be ok since ansible-base's redirects have been adjusted)
19:12:17 <baptistemm> 1.0.1 would be ok for the version AFAIK
19:12:28 <felixfontein> so we have 3 x a, and 1 x b, and 1 x abstain right now
19:12:52 <felixfontein> ah wait, I forgot about baptistemm; it's 4 x a, 1 x b, 1 x abstain
19:13:08 <felixfontein> anyone else has an opinion?
19:14:35 <felixfontein> ok, that was a long-running poll, with a lot of parallel discussion :)
19:14:44 <nitzmahone> abadger1999: I'd say in general collections should *not* depend on new collections only because of content that was moved out of the original if the point is to allow granular installation (or maybe during a deprecation period, but meh). Again, that's a policy choice with tradeoffs both ways...
19:15:04 <felixfontein> #info community.general will deprecate the gluster modules for removal in 2.0.0, and then add tombstone entries
19:15:15 <nitzmahone> DO NOT add tombstones for those
19:15:22 <felixfontein> nitzmahone: why not?
19:15:45 <felixfontein> nitzmahone: we just voted on it, all wanted removal without redirects afterwards
19:15:48 <nitzmahone> That will prevent them from running if `collections: [community.general, gluster.whatever]`
19:16:34 <felixfontein> hmm. that's a good point. redirects with deprecation would be ugly then, too, though.
19:16:40 <nitzmahone> Either preserve the redirects indefinitely, or deprecate the redirects and just remove them later (that works).
19:17:12 <nitzmahone> That's what I was saying earlier- make sure you understand the ramifications of tombstone. That basically scorched-earth's the plugin name for unqualified lookups
19:18:04 <nitzmahone> How so? A redirect with deprecation will only show a dep warning when the plugin is accessed via that redirect, which is exactly what you want if a future release will remove the redirect/
19:18:09 <felixfontein> hmm, but this will sooner or later be a problem for regularly deprecated + removed modules
19:18:43 <felixfontein> especially when people use more common names for modules, like if some cloud collection deprecates and then removes their `vm` module
19:18:52 <nitzmahone> basically "hey, you're using this through a redirect that's going away, fix your content to bypass the redirect"
19:18:55 <baptistemm> a) for me would means update redirect in ansible-base, keep redirecting in c.g until 2.0
19:19:24 <felixfontein> baptistemm: c.g can't redirect in 1.x.y IMO since that violates semver - we are breaking an existing use-case
19:19:36 <felixfontein> (for people who have c.g installed, but not the gluster collection)
19:19:52 <baptistemm> ok, I thought you wanted to break exceptionally this rule
19:20:19 <felixfontein> baptistemm: no, I'd prefer to stick to semver rules :) we shouldn't create a bad precedent
19:20:29 <baptistemm> understood
19:20:34 <felixfontein> baptistemm: I don't mind removing earlier than the regular deprecation cycle though
19:20:45 <felixfontein> hmm
19:20:51 <felixfontein> #undo
19:20:51 <zodbot> Removing item from minutes: INFO by felixfontein at 19:15:04 : community.general will deprecate the gluster modules for removal in 2.0.0, and then add tombstone entries
19:21:00 <felixfontein> #info community.general will deprecate the gluster modules for removal in 2.0.0
19:21:11 <nitzmahone> +1 ;)
19:21:31 <SerenityNow> cool !
19:21:47 <felixfontein> so what should we do in 2.0.0? simply remove the modules without anything, remove them and add redirects, add deprecated redirects, or add tombstones (which we really shouldn't do)
19:22:25 * baptistemm afaik 5 m
19:22:28 <felixfontein> if we use redirects with deprecation, we would annoy people using the `collections:` keyword (see nitzmahone's example above)
19:22:36 <nitzmahone> It's early enough that 1) is probably ok, but 2) or 3) is better depending if you want to keep the redirects around forever. You can always choose 2) and deprecate later
19:22:44 <felixfontein> if we use redirects without deprecation, we cannot remove the redirects without proper advance warning
19:23:51 <abadger1999> I lean towards 1 for practicality but we'll probably have to start doing 3 in the future
19:24:09 <felixfontein> we could also do 2) and just redirect forever without deprecation
19:24:34 <nitzmahone> That's probably the ideal for most things
19:25:39 <felixfontein> nitzmahone: you mean 1) or 2)?
19:25:44 <nitzmahone> dep warnings/tombstone issues from lazy `collections` searches can also always be bypassed by using FQ plugin names in content, but it's mainly just a trip-hazard
19:25:57 <nitzmahone> Sorry, 2) is ideal for most things IMO
19:27:09 <felixfontein> hmm, should we continue this discussion next week? I'm not sure how many people are still actively listening :)
19:27:35 <nitzmahone> Really just a matter of how long you want to let people run without altering their content. If it's forever, it's 2), if it's $time, it's 3). If it's "not at all", it's 1). The reality will probably be case-by-case mixtures of all 3
19:27:46 * nitzmahone is ready for lunch ;)
19:27:50 <baptistemm> I'n not sure I understand implications of all these things
19:28:13 <baptistemm> so I rather read everyline hoping to understand and prevent giving any opinion
19:28:36 <andersson007_> i'm trying to listen felixfontein :) 22.30
19:29:12 <felixfontein> baptistemm: redirect with deprecation or tombstoning is good if everyone uses FQCNs all the time, and redirect without deprecation (or no redirect) is good for people using the `collections:` keyword
19:29:13 <baptistemm> maintaining permanent redirect just for that, makes me a bit "afraid"
19:29:50 <nitzmahone> yay flexibility ;)
19:29:54 <baptistemm> felixfontein: thanks I did not know it would work differently
19:30:45 <samccann> fwiw, 'over  time' docs will be sprinkling FQCN everywhere (and suggesting that's the preferred approach).
19:31:02 <samccann> ^^ in our rst examples etc
19:31:09 <felixfontein> the good thing about redirects is that there's not much to maintain
19:31:36 <baptistemm> felixfontein: ok, so do you think it won't be a nightmare to maintain life long this redirect
19:32:07 <baptistemm> honnestly I prefer let people with knowledge and responsibility to choose
19:32:21 <felixfontein> baptistemm: I don't think so, I'd just keep it until forever, and only reconsider them if someone complains that the module/plugin has been removed from the destination collection
19:33:05 <abadger1999> baptistemm: +1 to that point of view.
19:33:12 <felixfontein> baptistemm: nitzmahone would count as one such person since he's intimiately familiar with runtime.yml ;)
19:33:28 <felixfontein> but I guess in 1-2 years we will all know a lot more from practice
19:33:38 <abadger1999> I don't think I'd try hard to say no to a "forever" redirect but it's not my preference.
19:34:05 <felixfontein> we could add a redirect in 2.0.0 without a deprecation, and still later add a deprecation (and eventually remove it)
19:34:47 <nitzmahone> Yeah, it's not so much a matter of "maintain"- redirects for moved content should be static on the source side and the redirect "chain" maintained by the destination owner wherever possible. This is how the builtin redirects work in ansible-base- we're not going to track future moves. It's up to the collections to maintain the chain and keep things working.
19:34:52 <felixfontein> we can keep the question open until later this year
19:35:05 <SerenityNow> felixfontein concluding, :-) (its 1.00 am here) i will tag you once i create a PR, for gluster-collections,
19:35:22 <felixfontein> SerenityNow: sounds good, I'll try to look at it! :)
19:35:45 <SerenityNow> felixfontein also  tag accordingly
19:36:01 <SerenityNow> * i will tag accoringly for upcoming release
19:36:13 <SerenityNow> felixfontein thanks!
19:36:20 <felixfontein> yw!
19:36:38 <SerenityNow> thanks everyone! :-)
19:36:43 <baptistemm> Bye SerenityNow
19:36:50 <baptistemm> thanks for keeping awake so long
19:37:04 <felixfontein> indeed, thanks SerenityNow!
19:37:19 <SerenityNow> bye! no worries,  really glad i could attend the meeting :-)
19:38:01 <felixfontein> about redirects: so how about adding redirects in 2.0.0 (without deprecation), and then revisiting this later (after 2.0.0 has been released) to decide whether we want to eventually remove them? I hope that by then we have more experience with this
19:38:22 <nitzmahone> that sounds like a good compromise
19:39:48 <felixfontein> POLL: should we add redirects for the gluster modules in 2.0.0 without deprecation, and revisit this question (about removing them eventually, with or without a deprecation) somewhen after 2.0.0 has been released?
19:39:49 <abadger1999> That's fine by me.
19:39:52 <felixfontein> +1
19:40:06 <samccann> +1
19:40:15 <abadger1999> +1
19:40:41 <nitzmahone> +1
19:40:48 * nitzmahone -> lunch
19:41:16 <felixfontein> enjoy lunch!
19:41:45 <felixfontein> #chair
19:41:45 <zodbot> Current chairs: SerenityNow abadger1999 acozine andersson007_ baptistemm cyberpear felixfontein gundalow nitzmahone samccann
19:42:05 <acozine> +1
19:42:58 <cyberpear> +1
19:44:24 <felixfontein> anyone else?
19:44:50 <baptistemm> I let you choose
19:45:11 <felixfontein> #info we add redirects for the gluster modules in 2.0.0 without deprecation, and revisit this question (about removing them eventually, with or without a deprecation) somewhen after 2.0.0 has been released (6 x +1, 1 x abstain)
19:45:23 <felixfontein> in that case we have chosen :)
19:45:25 <felixfontein> #topic open floor
19:45:41 <felixfontein> since we've already 45 minutes overtime, is there anything else?
19:45:53 <baptistemm> nope
19:45:54 <acozine> felixfontein: are you going for a record?
19:46:10 <samccann> :-)
19:46:14 <abadger1999> hee hee
19:46:17 <acozine> do we need a "meeting overage leaderboard"?
19:46:28 <acozine> (or Hall of Shame?)
19:46:39 <felixfontein> acozine: I think the record is still held by the DaWGs meeting ;)
19:46:50 <acozine> yep, probably
19:46:56 <acozine> we're a wordy bunch
19:47:09 <felixfontein> :)
19:47:22 <felixfontein> and there are a lot of things to discuss, both in #ansible-docs and here
19:48:44 <acozine> anyway, nothing else from me ;)
19:49:31 <baptistemm> same for me
19:50:05 <samccann> all quiet here
19:50:14 <felixfontein> good. let's stop then!
19:50:16 <felixfontein> thanks everyone!!!
19:50:18 <felixfontein> #endmeeting