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