18:02:34 <gotmax> #startmeeting Ansible Community Meeting
18:02:34 <zodbot> Meeting started Wed Nov  2 18:02:34 2022 UTC.
18:02:34 <zodbot> This meeting is logged and archived in a public location.
18:02:34 <zodbot> The chair is gotmax. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:02:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:34 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:02:38 <briantist> o/
18:02:42 <gotmax> #topic Intros and Info
18:03:01 <gotmax> .hello gotmax23
18:03:02 <zodbot> gotmax: gotmax23 'Maxwell G' <gotmax@e.email>
18:03:28 <briantist> 🤔what is that `.hello` command?
18:03:39 <briantist> never seen hat before
18:03:46 <gotmax> #info ansible-core 2.14.0rc2 was released earlier this week: https://groups.google.com/g/ansible-devel/c/dZWVmORHkxo
18:04:12 <gotmax> briantist: It's a zodbot command. It queries the Fedora Account System to get your name and email.
18:04:30 <briantist> I see
18:04:35 <gotmax> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr maxamillion: Community meeting is starting now
18:04:42 <gotmax> We probably should clean up that list
18:04:46 <acozine> o/
18:05:05 <briantist> we had basically switched to @room mentions instead of individuals a while ago I thought
18:05:19 <gotmax> I borrowed those from the last meeting
18:05:42 <cybette_> plus @room mentions won't alert those on IRC I think
18:05:44 <briantist> I added a text notification for `@room` in IRC to adjust, since I missed a bunch of meetings when that first started 😅
18:05:55 <cybette_> ah :)
18:05:58 <gotmax> IMO, we should either completely git rid of it or make a list somewhere were people can opt in/out
18:06:10 <samccann> o/
18:06:10 <cybette_> o/
18:06:10 <ptoal[m]> Hi
18:06:10 <gotmax> Correct about IRC
18:06:11 <felixfontein> sorry, I almost screwed up the time :)
18:06:12 <felixfontein> o/
18:06:26 <gotmax> #chair briantist cybette feyo[m]
18:06:26 <zodbot> Current chairs: briantist cybette feyo[m] gotmax
18:06:29 <gotmax> #chair felixfontein
18:06:29 <zodbot> Current chairs: briantist cybette felixfontein feyo[m] gotmax
18:06:29 <chadmf[m]> o/
18:06:36 <maxamillion> .hello2
18:06:37 <gotmax> #unchair feyo[m]
18:06:37 <zodbot> Current chairs: briantist cybette felixfontein gotmax
18:06:37 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
18:06:38 <gotmax> Oops
18:06:47 <mariolenz[m]> o/
18:06:51 <maxamillion> o/
18:06:55 <gotmax> #chair maxamillion chadams[m] mariolenz[m]
18:06:55 <zodbot> Current chairs: briantist chadams[m] cybette felixfontein gotmax mariolenz[m] maxamillion
18:06:55 <felixfontein> #chair mariolenz[m] maxamillion
18:06:55 <zodbot> Current chairs: briantist chadams[m] cybette felixfontein gotmax mariolenz[m] maxamillion
18:07:10 <felixfontein> gotmax: I guess it's best if you continue :)
18:07:25 <gotmax> Okay :)
18:07:34 * gotmax tries to silence Element
18:08:01 <gotmax> I lead meetings from IRC, but then Element keeps beeping
18:08:06 <gotmax> Anyways...
18:08:22 <gotmax> We have two active votes:
18:08:46 <gotmax> #info [Vote ends on 2022-11-08] Collection Removal Policy: add a paragraph about Collection Requirements violations
18:08:51 <gotmax> #link https://github.com/ansible-community/community-topics/discussions/158
18:09:02 <gotmax> #info [Vote ends on 2022-11-04] Change release cadence and schedule of Ansible from 7.0.0 on to couple more tightly to ansible-core
18:09:07 <gotmax> #link https://github.com/ansible-community/community-topics/discussions/157
18:09:29 <felixfontein> #info Ansible 7 feature freeze is coming up next week: 2022-11-07 is the last day collections can make backwards-incompatible changes and still be included in Ansible 7!
18:09:51 <gotmax> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:10:35 <mariolenz[m]> We have some time for the first vote you mention, but the second one will end the day after tomorrow. Would be great if we could some more votes there.
18:10:52 <felixfontein> #info The discussion on un-flat-mapping community.general and community.network (https://github.com/ansible-community/community-topics/issues/147) needs more attention!
18:11:07 <gotmax> Yeah, I was wondering about the status of that
18:11:29 <gotmax> #topic Proposal: Remove flat-mapping from community.general and community.network
18:11:35 <gotmax> #link https://github.com/ansible-community/community-topics/issues/147
18:11:39 <maxamillion> oof, that's quite the topic
18:11:51 <felixfontein> indeed :)
18:12:02 <gotmax> This keeps devolving into a discussion about splitting up these collections
18:12:21 <gotmax> I agree that's an important discussion, but I think it should be a separate one
18:12:25 <felixfontein> ...which has its own bag of problems :)
18:12:37 <gotmax> Yup :)
18:12:58 <felixfontein> if we would have more time until feature freeze, having that discussion first would be better IMO
18:13:20 <gotmax> felixfontein: So what's the status of this? I saw some PR was merged?
18:13:40 <felixfontein> but feature freeze happens to be next week, and it looks like the VScode plugin doesn't seem to want to add a similar workaround as ansible-lint to stop suggesting the internal long FQCNs
18:14:07 <gotmax> Is there a ticket about the Vscode plugin discussion?
18:14:10 <felixfontein> the preparation PRs got merged which remove potential conflicts, but these are also useful on their own
18:14:23 <felixfontein> there is: https://github.com/ansible/vscode-ansible/issues/573
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:25 <felixfontein> it's actually a problem with the language server, but the issue is still in the vscode repo
18:15:46 <felixfontein> (as far as I understand these two repos belong to the same team anyway)
18:16:07 * gotmax is not super happy about how this was handled
18:16:29 <gotmax> It's been like this for a while, and now we have to scramble to fix it before the freeze
18:16:50 <felixfontein> yes, I fully agree
18:17:10 <felixfontein> fest came a bit in the way as well
18:17:28 <gotmax> It seems like we don't really have a choice here
18:18:01 <gotmax> #link https://github.com/ansible/vscode-ansible/issues/573
18:18:01 <felixfontein> we basically have three choices, essentially the ones sorin sums up in https://github.com/ansible-community/community-topics/issues/147#issuecomment-1287758770
18:18:14 <mariolenz[m]> I'm not sure that I really understand this flat-mapping issue, but at the spur of the moment I should say that there are more dis-advantages than advantages. That is, to flat-mapping and not to remove it.
18:18:31 <felixfontein> a) unflatmap, b) accept the new long FQCNs, c) split the collection up (and unflatmap the resulting ones), or d) adjust tools
18:18:40 <felixfontein> d) doesn't seem to happen, except for ansible-lint at the moment
18:19:16 <felixfontein> mariolenz[m]: I agree. unfortunately without it community.general and community.network will look a lot uglier, as all modules will end up in a single directory
18:19:24 <gotmax> b and c don't seem tenable right now
18:19:39 <felixfontein> (community.general has 558 modules)
18:20:04 <felixfontein> gotmax: I fully agree on c). b) is probably debatable, I personally would hate it though :)
18:20:48 <felixfontein> (also b would also be a lot of work, since all examples in c.g would have to be adjusted)
18:21:41 <felixfontein> for community.network the long names are worse, because there's this single directory network/ in plugins/modules/ that contains everything, so every long name contains a redunant network: community.network.network.<vendor>.<module>
18:22:10 <acozine> I'm not sure I'm following this entirely - we've done part of the groundwork for moving away from flatmapping in these two collections, and as a result the old flatmapped FQCNs won't work now? Is that correct?
18:22:16 <mariolenz[m]> Well, having 500+ modules within one directory might be considered "ugly". On the other hand, the alternatives don't look better to me.
18:22:33 <acozine> And now we're debating what to do for the current release?
18:22:57 <felixfontein> acozine: the preparations are not really relevant here, they work fine no matter whether we remove flatmapping or whether we keep it
18:23:08 <acozine> okay, thanks
18:23:18 <felixfontein> mariolenz[m]: that's my thought as well
18:24:22 <felixfontein> acozine: we can ignore the problem for this release (which happens next monday), but then we have to suffer the consequences for another half a year basically
18:24:48 <felixfontein> (well, we could also make that adjustment in a minor release, but that would feel more itchy to me)
18:25:07 <gotmax> We're kind of pushed into a corner here :(. We don't even have time for a proper vote before the freeze.
18:25:47 <felixfontein> yes, unfortunately...
18:27:00 <gotmax> If we keep the long names as deprecated redirects, that's not a breaking change, but with the potential regressions of doing that it does seem iffy for a minor release.
18:27:19 <felixfontein> gotmax: indeed.
18:27:37 <felixfontein> (I would definitely keep redirects, even when doing this in the upcoming major release)
18:28:11 * gotmax agrees
18:28:50 * gotmax is not sure what's the best way forward here
18:29:53 <gotmax> I would like to ask the devtools team again to apply the same workaround from ansible-lint to the language server
18:29:53 <felixfontein> I guess we won't get `ansible-doc -l` to include special code for c.n and c.g to remove the extra parts
18:29:54 <Warkdev[m]> And the winner is...
18:30:09 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:34 <gotmax> But you're right; fixing ansible-lint and the language server doesn't fix ansible-doc
18:30:41 <mariolenz[m]> community.general and community.network look to me like they're there to have a place for all those modules that didn't make it into a "proper" collection. Don't hurt me, but... how about killing them?
18:31:06 <gotmax> There's a lot of important stuff in there
18:31:32 <felixfontein> yes. (and it's not the first time someone suggested killing it :) )
18:32:09 <felixfontein> the problem is that there's nothing *that* important in there that someone wants to maintain it in a separate collection, but a lot of things that are still important, at least to a certain set of users which uses it
18:32:26 <felixfontein> there are also some things in there which are probably fully dead (neither used nor maintained), but it's hard to tell which one these are
18:32:28 <acozine> mariolenz: what do you mean when you say "killing" them?
18:32:32 <mariolenz[m]> OK, it's just been a suggestion. If you want to keep it alive, I'm fine with it :-)
18:32:38 <acozine> get rid of those modules entirely?
18:32:44 <felixfontein> acozine: I would assume, deprecate everything and remove it in a couple of versions
18:32:48 <acozine> remove the collection from the package?
18:33:17 <gotmax> zypper and pacman are in there
18:33:27 <acozine> ah, and hope that someone steps up to create new collections for the most useful modules?
18:33:30 <felixfontein> mariolenz[m]: I'm using a couple of the modules and plugins in there and I would really like them to survive, also in another collection, but community.random_unrelated_things_felix_likes isn't the best collection name ever ;-)
18:33:41 <mariolenz[m]> acozine: Deprecate and don't put any work into them.
18:33:49 <felixfontein> ufw is also in there
18:33:51 <Warkdev[m]> felixfontein: I love that name!
18:33:58 <gotmax> Removing those would make ansible unusable on Arch and OpenSuse
18:34:01 <acozine> I also use several modules from c.g
18:34:01 <felixfontein> Warkdev[m]: except that typing it sucks ;)
18:34:34 <gotmax> And the yaml callback plugin ;)
18:34:38 <Warkdev[m]> And why can't we unflat? Seems a couple of files only..
18:35:12 <acozine> I might be motivated to create a `community.useful` for those, but explaining to anyone else why the collection has the specific content it does would be hard
18:35:16 <felixfontein> Warkdev[m]: once it's flat it's hard to see which modules belong together, and there's a long list of ~600 files in plugins/modules/ then, making development a bit harder
18:35:33 <acozine> it wouldn't really be a collection, or at least it wouldn't have a theme we could readily communicate
18:35:34 * gotmax notes that we've been discussing this for 25 minutes ;)
18:35:37 <felixfontein> acozine: yes... also picking out what should end up in it would be hard :)
18:36:44 <felixfontein> I think the only realistic choice we right now have is a) unflatmap, or b) ignore the problem for now. anything else seems to resolve to b), since it needs a huge amount of work to implement (and keep it working) it that nobody wants to commit
18:36:56 <felixfontein> (and 'for now' probably means 'for a long time')
18:37:42 <Warkdev[m]> felixfontein: can't we keep a list somewhere in the repo?
18:38:15 <felixfontein> Warkdev[m]: sure, we do it indirectly in the git history, and also indirectly in the meta/runtime.yml redirects, but that information will quickly get out of date
18:38:23 <gotmax> Yeah, I splitting up c.g is a huge task. I don't think it's fair to throw that suggestion around like it's easy.
18:38:41 <gotmax> s/I//
18:39:00 <felixfontein> the splitting itself is not *that* much work, but providing basic infrastructure to the resulting collections will be very resource consuming
18:39:39 <maxamillion> +1 that
18:39:55 <maxamillion> it's clerical to split, it's a giant pile of work for all the rest ;)
18:40:17 <gotmax> The whole effort (splitting, identifying the new groupings, finding maintainers and people to administer/release/maintain the new collections) is what's difficult
18:42:07 <felixfontein> in the beginning of c.g we moved some groups of modules out which depended on other collections, to make sure that community.general does not really depend on other collections (just because a few modules in it do), and bascally everything move out for that reason is dead, or looks pretty dead
18:43:25 <felixfontein> the other parts that got moved out are still more or less alive, but several of them also have trouble finding active maintainers I think
18:43:47 <felixfontein> and these were the parts that had at least one very active person at the time it was moved out
18:44:11 <gotmax> felixfontein: For ansible 7, what would be your preference? Rushing to flatmap or leaving as is?
18:44:39 <felixfontein> I think rushing to flatmapping would be best for the users
18:44:59 <mariolenz[m]> <acozine> "I might be motivated to create a..." <- Actually, I think that might be a good idea. Deprecate community.general and move the modules that people need to another collections. This way, we could find out what modules people really use. If nobody asks us to move a module to the new collection, we can get rid of it.
18:45:02 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:12 <gotmax> While the large c.g. is not the best solution, I think it's much better than creating a bunch of smaller ghost collections
18:45:15 <felixfontein> for the developers leaving as is is probably better, but I think the pain this is causing users counts more
18:45:38 <maxamillion> I think I'm missing something, what's the user pain?
18:46:03 <felixfontein> mariolenz[m]: one problem is that we don't know what folks use (and my privacy loving heart is very happy about that, while at the same time I'd really like to know which parts are still actively used :) )
18:46:14 <gotmax> ansible-doc shows the wrong names; ansible-lint and the language server suggest the wrong names
18:46:45 <gotmax> For example, `community.general.packaging.os.zypper` instead of `community.general.zypper`
18:46:49 <maxamillion> felixfontein: nvm, I just re-read the issue
18:46:52 <felixfontein> maxamillion: VScode recommends them to use long names, docs.ansible.com doesn't mention these at all, ansible-doc -l also shows the long names, ansible-lint doesn't recommend them, and the long names are *long*
18:46:55 <mariolenz[m]> BTW, splitting c.g looks like a lot of work but I don't see how it would be helpful. We'll still have the same problems.
18:46:56 <maxamillion> yeah, rgr
18:47:03 <gotmax> The former is an implementation detail which should *never* be relied upon
18:47:34 <felixfontein> mariolenz[m]: I thnk the assumption is to unflatmap the resulting collections, since they have a smaller number of modules that can happily live in the same directory
18:47:59 <gotmax> mariolenz[m]: We'd eliminate the problems with the long names being visible and causing problems
18:48:24 <gotmax> The issues with maintenance and purportedly dead modules would remain
18:48:37 <maxamillion> felixfontein: so is the proposal to switch back to symlinks?
18:49:18 <felixfontein> maxamillion: symlinks are pretty undesirable, since Python packaging converts them to copies (in the ansible package)
18:49:21 <maxamillion> I feel like I can't brain this right as I read the ticket
18:49:37 <felixfontein> also sooner or later ansible-doc, ansible-lint, and vscode might start following symlinks, and then we have the problem back
18:50:33 <mariolenz[m]> felixfontein: The alternative is to maintain modules that nobody uses.
18:50:58 <felixfontein> what I can do: a) merge some open PRs (I originally wanted to keep 1-2 more days open), then unflatmap the c.g repo, and then release a alpha version 6.0.0a1 so we can see whether there are potential problems... and then decide whether we want to keep it or undo it until say Friday
18:51:39 <felixfontein> mariolenz[m]: if there would be any easy way of finding out which modules aren't used, we would have deprecated them already :)
18:52:04 <mariolenz[m]> How about creating a community topic about the future of community.general and community.network?
18:52:10 <maxamillion> felixfontein: alright, so .... what's the proposed solution then? is that outlined in the issue ticket and I'm somehow missing it as I read through this?
18:52:13 <gotmax> felixfontein: I think that's a good plan for now
18:52:24 <acozine> I think the only way to find out which c.g modules people use is to remove c.g and then listen for the yelling.
18:52:32 <gotmax> mariolenz[m]: I think that's a good idea
18:52:41 <felixfontein> mariolenz[m]: you mean like https://github.com/ansible-community/community-topics/issues/4 ? :)
18:53:10 <felixfontein> acozine: yes, and that's a very user-unfriendly way of finding out
18:53:29 <felixfontein> we might lose quite a few users who are pissed off and never report back what they were using
18:53:34 <acozine> felixfontein: yup, -1 do not recommend
18:53:38 <gotmax> I'd like to move on to open floor for the last couple minutes
18:53:41 <felixfontein> (I guess the same goes for deprecating everything and see who complains)
18:54:05 <gotmax> Right now, I think the most pressing question is whether we should flatmap or do nothing for Ansible 7
18:54:26 <mariolenz[m]> Nope, that's about new content.
18:54:29 <felixfontein> maxamillion: I think the proposed solution is unflatmapping, what I described above and in https://github.com/ansible-community/community-topics/issues/147#issue-1402385749
18:54:49 <gotmax> Is anyone here strongly opposed to that?
18:54:51 <felixfontein> mariolenz[m]: that discussion was closely coupled with the discussion on how these collections should continue at all
18:55:08 <Warkdev[m]> acozine: funny how in any domain, this remains the last ultimate resort solution 😅
18:55:34 <felixfontein> maybe let's do a quick vote here, +1 for removing flatmapping (my proposal) or -1 for doing nothing for Ansible 7
18:55:45 <gotmax> WFM
18:55:46 <maxamillion> felixfontein: sorry, I promise I'm not trying to be dense but I have read that three times and still don't understand what the proposal is
18:55:54 <gotmax> +1 to removing flatmapping
18:56:10 <felixfontein> maxamillion: I wish we should have more time to discuss it in more detail... I can explain it to you later if you want
18:56:14 <felixfontein> +1
18:56:19 <mariolenz[m]> +1 to removing flatmapping
18:56:31 <maxamillion> felixfontein: no no, all good
18:56:35 <felixfontein> maxamillion: basically unflatmapping = remove the directories in plugins/modules/, copy everything directly into plugins/modules/
18:56:38 <maxamillion> I'll just abstain from voting :)
18:57:10 <felixfontein> #chair
18:57:10 <zodbot> Current chairs: briantist chadams[m] cybette felixfontein gotmax mariolenz[m] maxamillion
18:57:10 <acozine> I'm +1 to removing flatmapping, though so far I have not felt any pain
18:57:29 <gotmax> There's four +1s
18:57:38 <felixfontein> acozine: you probably don't use the VScode extension or rely totally on `ansible-doc -l` to find module names ;)
18:57:41 <acozine> we knew we would need to address those legacy catchall collections eventually
18:57:50 <felixfontein> true
18:57:50 <acozine> nope, I don't
18:57:59 <briantist> +1 for de-un-dis-flatmapping
18:58:05 <felixfontein> let me guess, you use the docsite (as I do)? ;)
18:58:09 <acozine> curvemapping?
18:58:22 <acozine> felixfontein: yep, plus a lot of them I just "know" at this point
18:58:32 <felixfontein> acozine: yes, true...
18:58:40 <acozine> but I have an unfair advantage
18:58:49 <felixfontein> apparently one of the official recommendations in Ansible trainings is to use `ansible-doc -l | grep xxx` to find modules
18:59:09 <felixfontein> (sorin mentioned that somewhere, I forgot where)
18:59:13 <acozine> ouch
18:59:30 <gotmax> #agreed Informally agreed (+5,0,0) to flatmap community.general before the 2022-11-07 Ansible 7 freeze
18:59:36 <gotmax> Hows's that for the meeting notes?
18:59:44 <felixfontein> sounds good to me
18:59:56 <acozine> w00t for documenting hte conversation
19:00:07 <gotmax> felixfontein++
19:00:12 <felixfontein> I'll work on that tonight to get an alpha release out as soon as possible, so that folks can try the result out (and see whether they notice anything)
19:00:28 <gotmax> #topic Open Floor
19:00:40 <gotmax> I'll give this five minutes, but feel free to leave ;)
19:00:47 <Warkdev[m]> felixfontein: No risk of module name collision doing so?
19:00:47 <felixfontein> I'll also prepare a PR for community.network, ompragash[m] / andersson007_[m] will have to decide how to continue with that one
19:01:01 <felixfontein> Warkdev[m]: nope, that would have alrady been a collision now
19:01:07 <acozine> Warkdev: shouldn't be, those modules all originally came out of kitchen-sink Ansible, so they have unique names
19:01:14 <felixfontein> Warkdev[m]: right now we have redirects from the correct names to the long (internal) ones
19:01:37 <felixfontein> there were collisions in the unit test tree structure, but the preparation PRs removed these
19:01:45 <felixfontein> (by renaming, not by deleting the tests :) )
19:02:29 <gotmax> Do we want to keep the meeting at 18:00 UTC or move it to 19:00 to account for winter time?
19:02:38 <felixfontein> oh right, that was another topic for today...
19:03:09 <gotmax> Yup :)
19:03:25 <acozine> heh
19:03:37 <felixfontein> I'm +1 for moving it to 19:00, but I can also live with 18:00 (what we have now)
19:03:37 <gotmax> Not sure if this should be a ticket
19:03:40 * bcoca uses mars time
19:03:54 <gotmax> I'm also +1 to moving it
19:04:01 <acozine> +1 for moving the time
19:04:04 <felixfontein> btw, we did use to move it, but then at some point we stopped because we voted and not enough folks were for moving it
19:04:44 <briantist> I don't care if we move it or not. I always have conflicts anyway so I just adjust 🤷‍♂️
19:04:46 <Warkdev[m]> +1
19:04:56 <gotmax> Just to be clear, it would stay at 2:00 p.m. EST and 8:00 p.m. CET
19:05:17 <felixfontein> when does US switch to winter time btw? this upcoming weekend? or the one after that?
19:05:27 <gotmax> This upcoming weekend
19:05:32 <felixfontein> ah
19:05:34 <cybette_> this coming weekend (Nov 6)
19:05:35 <bcoca> i always find out 25h late
19:05:39 <gotmax> It's the first Sunday in November
19:05:41 <briantist> I assume it's within the next week or so because I already see the WWG meeting has moved on my calendar lol
19:05:47 <briantist> that's how I know it's coming lo,l
19:06:49 <felixfontein> ok, I guess we'll start 19:00 UTC then next week...
19:06:59 <felixfontein> except if someone does #startmeeting one hour earlier :)
19:07:11 <felixfontein> then we'll probably have a two hour meeting ;)
19:07:15 <gotmax> My wifi just went out
19:07:32 <cybette_> will need to update the remindbot too
19:07:43 <gotmax> Okay, back
19:08:06 <felixfontein> cybette_: good point
19:08:17 <felixfontein> cybette_: can you do that?
19:08:44 <cybette_> #action cybette_ to update remindbot to start meetings at 19:00 UTC from next week (Nov 9) onwards
19:08:45 <felixfontein> (I'm not sure who can actually do that, and even if I could I have no clue how to do it, I'd probably grep for someone else doing it in my logs ;) )
19:08:48 <cybette_> yep :)
19:08:53 <felixfontein> thanks :)
19:09:12 <gotmax> I see +1s from Warkdev[m], felixfontein, myself, and acozine
19:09:31 <gotmax> Anyone else :)?
19:09:36 <felixfontein> and no -1 or 0 explicitly written so far
19:10:19 <gotmax> #agreed Informally agreed (+4,0,0) to move the community meeting to 19:00 UTC so it stays at 2:00 p.m. EST / 8:00 p.m. CET
19:10:43 <gotmax> Anything else before we finish off?
19:13:03 <mariolenz[m]> <felixfontein> "mariolenz: if there would be any..." <- But that's the idea. We deprecate community.general and create a new collection. If people use a module, they should open an issue to include it into the new collection. If nobody does, it's a module nobody uses.
19:14:25 <gotmax> I have to go, so I'll end this, but feel free to continue the discussion :)
19:14:27 <gotmax> #endmeeting