14:30:30 #startmeeting Docs Working Group aka DaWGs 14:30:30 Meeting started Tue Jun 30 14:30:30 2020 UTC. 14:30:30 This meeting is logged and archived in a public location. 14:30:30 The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:30:30 The meeting name has been set to 'docs_working_group_aka_dawgs' 14:30:43 #topic introductory chatter 14:30:45 who's around? 14:30:52 just barely here 14:31:04 you wanna be a chair anyway? or a footstool? 14:31:30 I would prefer a nice chaise lounge 14:31:33 heh 14:31:33 hei :) 14:31:38 #chair cbudz felixfontein 14:31:38 Current chairs: acozine cbudz felixfontein 14:32:01 cbudz: you can choose the style and length of your chair 14:32:39 fantastic 14:32:48 agenda for today begins with https://github.com/ansible/community/issues/521#issuecomment-648254778 14:32:52 and continues below 14:33:02 (below that comment, I mean) 14:33:42 I was working a bit on the Ansible porting guide generation 14:33:43 * gundalow waves 14:33:48 (next to changelog) 14:33:54 hey gundalow! 14:33:56 #chair gundalow 14:33:56 Current chairs: acozine cbudz felixfontein gundalow 14:34:18 #topic porting guide and changelog updates 14:34:21 the code is in https://github.com/ansible-community/antsibull/pull/103 and an example in https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f 14:34:25 * samccann life goal to be a comfy cushion 14:34:42 (the porting guide is at the bottom: https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst ) 14:34:58 samccann: I can have look, I know this is not documented by my PR 14:35:06 while working on that, I had some questions, which I put into the agenda :) 14:35:12 hi baptistemm! 14:35:16 #chair baptistemm 14:35:16 Current chairs: acozine baptistemm cbudz felixfontein gundalow 14:35:36 hó I'm involved in an unexpected meeting 14:35:45 yep 14:35:56 speak up at the right (or wrong?) time and you get sucked in 14:36:14 don't worry, we're a nice group 14:36:36 felixfontein: those are good questions 14:36:58 thanks baptistemm !! 14:37:01 I guess there's the general question what will happen with the Ansible documentation now that ansible-base and ansible can (and will) diverge 14:37:15 I do think we'll need a way to allow separate access to the ansible-base porting guide 14:37:25 agree 14:37:33 I guess this affects all of https://docs.ansible.com/ansible/ 14:38:07 the module docs are a separate section already 14:38:34 yes, but if ansible 2.13 is based on ansible-base 2.12 (for example), it will get more fun 14:38:41 "fun" 14:38:49 also when ansible-base 2.10 is out, while ansible 2.10 is not yet out (which will happen this fall) 14:38:55 yes, "fun" indeed :) 14:39:16 I don't know whether this topic was already discussed internally 14:40:28 yeah, we need a general page of "here are the two ways to use Ansible in the collections ecosystem - as an integrated package from PyPI, or as a pick-n-mix system of an ansible-base and a set of collections" 14:41:40 why initially we were not keeping 'ansible' as a name, only ansible-base and ansible community distribution, but since we are now 'reusing' ansible .. it gets back to being very confusing 14:41:50 and an ansible-base-specific changelog is part of that 14:42:20 bcoca: indeed! especially since ansible-base and ansible are not synchronized 14:42:59 hmmmm 14:43:00 why i keep calling it ACD to try to keep the confusion from growing 14:43:02 so maybe a lot of stuff has to be moved to https://docs.ansible.com/ansible-base/, and https://docs.ansible.com/ansible/ will be something new? 14:43:16 bcoca: me too, and them I'm told all the time that ACD shouldn't be used anymore ;) 14:43:48 that would be terrible for SEO though, break a millin links, and even more confusing for users 14:43:54 yeah 14:43:57 *million 14:44:14 well, we are breaking links anyways .... 14:44:31 bcoca: the module links yes, but now everything else is on the line too ;) 14:44:43 it's more the SEO I'm worried about 14:45:02 you cannot sell a car and still call it a motorcycle, we can keep the 'old docs' and just reference it as EOL and point to the 2 NEW products 14:46:11 is there a possibility that ansible (i.e. ACD) will change its name again until september? (not that I want this) 14:46:11 I think we maintain the docs at `/ansible` and start a new section at `/ansible-base` as part of an evolution 14:46:48 there are two parts to this discussion 14:47:05 one is about "how do we accurately document versioning in the new ecosystem" 14:47:16 and the other is about "how do we help users find the documentation they need" 14:48:09 and there's a fundamental question about what do we want to encourage people to do/read/see 14:48:34 samccann: cidr_lookup is not a filter that's why I did not document it. It's a parameter for ipaddr 14:49:06 do we want to encourage using the integrated package, whatever we call it? or do we want to encourage people to "build their own" from collections 14:49:18 acozine: an interesting question is also whether the ansible-base docs will contain documentation of the ansible.builtin modules/plugins 14:50:05 we've committed to backwards compatibility of a kind, providing a "kitchen sink" option 14:50:35 felixfontein: that is also tied into this question of what behavior we want to encourage 14:50:37 and someone decided that the kitchen sink solution re-uses the old name 14:50:48 yeah 14:51:23 that's at least partly for SEO purposes 14:52:21 acozine: but we also commited to NOT be backwards compatible with same kitchen sync ... we have many promisses at odds with each other 14:53:11 acozine: which i know puts docs team in really bad position of trying to write down the truth and yet still comply with the marketing 14:54:37 bcoca: that's the "accurately document" part of it in tension with the "encouraging certain behavior" part of it 14:55:28 he, as expected from docs .. much better wording 14:55:38 :) 14:57:40 the trouble is, I'm not sure what behavior we want to encourage . . . do we want people to embrace the build-your-own ethos? In that case, the integrated package is ONLY for limited backwards compatibility (not that all old behavior is still included, but that you can install most modules in a single package) 14:57:41 thanks for looking into it baptistemm 14:58:26 acozine: that's a good question. is that something that RH management wants to decide? or that the community has to decide? or core team? or ...? 14:58:42 samccann: I wonderered if it would not have beeen easier to write code to export all filters and function and put a heading for each of them 14:58:43 last I heard, marketing wants to encourage Ansible, not ansible-base 14:58:55 samccann: I can document them in another PR 14:59:06 thanks baptistemm ! 14:59:21 baptistemm: I have a few grammar "nits" on that PR - I'll add them as suggestions 14:59:51 acozine: even in French I usually do typo, I won't be offended that you correct my wording 15:00:35 samccann: so marketing wants people to use Ansible (and not ansible-base + modules), even though that's not Supported? 15:00:35 on the question of the Porting Guide, though, I think we need to build the ansible-base Porting Guide by itself for each version, and we also need to build the correct version into an all-inclusive Ansible Porting Guide for the PyPI package 15:01:21 from one source, two output pages 15:01:22 acozine: I agree, the ansible-base porting guide should be a separate document (that can be 'included' in the ansible porting guide) 15:01:26 felixfontein - this comes from 3 months ago discussion so we'll need to check back and see what current thinking is, but yeah, last i heard we didn't want to encourage ansible-base + one or two collections as the common user experience 15:01:53 portingguide - sounds like ... a POLL to me! 15:01:55 :-) 15:01:59 lol 15:02:11 heh 15:02:16 i'm here for realz now... aren't you glad? :-) 15:02:19 #chair samccann 15:02:19 Current chairs: acozine baptistemm cbudz felixfontein gundalow samccann 15:02:28 now you can create a poll! 15:02:46 is there some special way to create one? 15:02:54 I guess it comes kind of automatically from when the ansible-base docs end up in docs.ansible.com/ansible-base, and the ansible-specific docs need to move out of ansible/ansible 15:03:07 not that I know of 15:03:09 samccann: oh, maybe not 15:03:17 I thought it might involve Special IRC Powers 15:03:28 acozine: the problem is that diff groupins of 'we' want diff things and are going in diff directions 15:03:29 POLL : have an ansible-base porting guide as a separate document, with that same information also pulled into the Ansible porting guide... +1 if you agree 15:03:31 poll on irc I doubt this is possible 15:03:33 nope... just write `POLL:` followed by the question 15:03:42 +1 15:03:46 homemade polling 15:03:47 +1 15:03:48 +1 15:03:55 ansible-base already has its own changelog 15:04:06 i would go further, separate ansible-base as its all new 'own docs' 15:04:30 don't mess w my poll dude! That's a separate, deeper discussion 15:04:32 :-) 15:05:01 bcoca: I guess a lot of docs belong to ansible-base, while some belong to ansible, and there will be a lot of inter-linking (which will be especially fun when versions diverge a lot) 15:05:48 also f.ex. filter docs: some of them are not part of ansible-base - should they be documented in ansible-base, or not? 15:05:49 #info have an ansible-base porting guide as a separate document, with that same information also pulled into the Ansible porting guide - poll 3 agree, 3 didn't vote 15:06:04 heh, slackers 15:06:08 #info ansible-base has its own changelog.rst already 15:06:09 heh 15:06:31 are we done with porting guide conversation? 15:06:31 https://github.com/ansible/ansible/blob/stable-2.10/changelogs/CHANGELOG-v2.10.rst 15:06:43 * baptistemm can'tvote on things he does not understand 15:07:02 samccann: I guess so, well, as much as we are done with the general topic of docs separation ;) 15:07:03 felixfontein: yeah, I was working on the Filters page, and there are quite a few marked with "these filters have moved to X collection" . . . 15:07:12 baptistemm: that is very good and honest of you 15:07:34 bcoca: did you already work on making filter/test/... plugins documentable? 15:07:47 yes 15:07:53 acozine: my manager is not always that I that honest :) 15:07:56 what topic are we on now? 15:08:02 felixfontein: what did you mean by `every new ansible version can have new porting guide entries (should only be deprecations though)` 15:08:24 samccann: still the changelogs/porting guides 15:08:30 thanks :-) 15:08:40 acozine: collections can deprecate things in minor releases, and since ansible releases can contain newer minor (though not major) releases of collections, new deprecations can show up all the time 15:09:16 ah, I see 15:09:24 * baptistemm forgot word happy 15:09:34 baptistemm: ah, that makes more sense 15:10:04 in theory collections could also add breaking_changes, major_changes and removed_features changelog entries in minor versions (even though they shouldn't!), so these could also show up later in a porting guide 15:10:12 that's why I added a section in the porting guide for every release 15:10:18 (resp. for every release that has content) 15:10:35 hmm I thought breaking changes in a collection had to be a major release wrt semver? 15:10:37 * acozine goes back to look at the sample page 15:10:42 link? 15:10:59 https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst 15:11:28 #info sample porting guide https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst 15:11:32 for the porting guide, I grouped first by category (breaking change, deprecated, ...) and then by collection 15:12:14 IMO it makes more sense, since usually people are most interested in breaking_changes and don't want to read the whole thing just to find all breaking_changes from all collections 15:12:30 yeah it makes sense to me as well 15:13:32 gosh we have a lot of nagging to do to get usable changelogs from all these collections 15:14:20 samccann: indeed. and a list of links for the ones who don't want to use antsibull-changelog or provide a changelog.yaml file 15:14:26 what do folks think is the best approach? Log an issue in each collection? 15:14:26 the organization looks good 15:14:46 samccann: probably compiling a list of things we need to know first, and then create an issue in every collection 15:14:52 or something equivalent for collections not on github 15:15:15 do we have a list of things we need to know? :-) 15:15:39 I'm not sure, we have some items probably, but I'm not sure we know whether that's all or whether we forgot something ;) 15:15:53 it's probably also a good time to create a list of repository URLs 15:16:31 felixfontein: there's something odd about the internal links on that page - if you click on a heading in the text, you jump back to the top TOC 15:16:32 ok how about I create an issue on ansible-collection/overview and we can compile a list there ? 15:16:41 samccann: that sounds awesome 15:17:23 acozine: it sends you to the toc entry, and click that one sends you back to the section. that's how github is rendering .rst files apparently 15:17:31 samccann: sounds good! 15:17:48 #action samccann create an issue on ansible-collection/overview to gather the list of things we need to know to get collection changelogs into the Ansible changelog.rst - in preparation for creating issues in each collection repo on what they need to do 15:18:00 ahhh, it's rst, not the generated html, right 15:18:07 the resulting data should in the end live near to https://github.com/ansible-community/ansible-build-data/blob/main/2.10/acd.in 15:19:00 I guess for the ACD changelog, we also want to be able to write some text for every release? 15:19:08 #info ansible build data (aka included collections ) - https://github.com/ansible-community/ansible-build-data/blob/main/2.10/acd.in 15:19:46 (that's displayed at the beginning of a version's section, like here before 'Unchanged collections': https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#v2-10-0a2) 15:20:58 hm, we didn't record the discussion about the porting guides, did we? 15:21:38 the vote got #info'ed 15:21:39 we added an info about there being a separate porting guide for ansible-base etc. I don't know what else was final info 15:21:55 ah, perfect 15:22:07 I guess the main problem is the amount of non-final information :) 15:22:15 * acozine breathes in, breathes out 15:22:18 resp. the non-final information which we have to work with 15:22:36 lol 15:23:01 yeah usually I would sprinkle a few more infos but I was behind today... so *shrug* 15:23:12 I thought this non-final info was just in mty company 15:23:22 baptistemm: I think it's specific to humanity 15:23:38 #info how and when we split anible-base docs from ansible (aka acd) docs is a deeper discussion for later 15:23:38 there's not enough infos for non-humans ;) 15:23:40 baptistemm: sadly, no 15:23:56 yes, though not for much later probably 15:24:16 when ansible-base 2.10 is released, ansible 2.10 will follow ~1 month later (according to current extremely tentative schedule) 15:24:20 #action samccann add Splitting ansible-base from Ansible docs to agenda 15:24:27 I'm heading to the pool, but I'll work on missing ippadr fonction, it's fun to test code 15:24:30 I guess the problem should be better solved until then :) 15:24:39 thanks so much baptistemm !! 15:24:42 enjoy the water! 15:24:44 no prob 15:24:46 * samccann wishes she was heading to the pool 15:24:49 we've been talking for a while about changing the overall organization of the documentation to focus more on users than on products 15:25:21 yeah we can get into that in a separate meeting. It might even need its own supplemental meeting just to focus on that for an hr 15:25:43 I suspect we could have an all-day summit on the topic ;-) 15:25:46 I don't want to sound harsh and I don't know the whole storey, but the ansible docs is a bit patchy, lot of stuff scattered 15:25:47 oooch 15:26:01 yeah that's part of the problem baptistemm 15:26:05 baptistemm: that's great feedback, thanks 15:26:29 I agree it's hard to find things 15:26:53 I don't know how one people knowing nothingh about ansible could be driven to learning things in the correct order and with the correct amount of information 15:26:54 if you have specific examples, please post them here (maybe after your swim) 15:27:13 we have 3 min left 15:27:18 * samccann human clock 15:28:07 baptistemm: yes, that's a hard problem 15:28:16 samccann: woopsie 15:28:23 we need to prioritize what needs to be done by ansible-base release, and what needs to be done by ansible release 15:28:58 obviously not in 2 minutes but I guess my question is - do we want a supplemental meeting this week? (it being a short week in the USofA)? 15:29:04 I guess docs.ansible.com/ansible/latest/ must only switch to 2.10 once ansible 2.10 is released, so a new home for ansible-base needs to be found until its release 15:29:27 I might not have much time for another meeting, though I'll probably listen in 15:29:35 or do we want to continue here for another 20 min or so and try to list priorities? 15:29:47 felixfontein: we may have even a little more time, it sounds like we may release 2.10 without updating `latest` 15:29:54 it might be a good idea to ask internally - like the core team, management, marketing, ... - what they think about this 15:30:20 acozine: that's even worse ;) then docs.ansible.com/ansible/2.10/ would be docs for ansible-base, and not ansible 15:31:21 my nickel - we won't have time to pull ansible-base out of the docs into its own home before it releases 15:31:54 felixfontein: isn't that going to reflect reality for a while? when is the planned release of the PyPI `ansible` package? 15:32:19 acozine: I think it is (very very tentatively) ~one month after ansible-base's current planned release, i.e. mid september 15:32:58 how it continues depends on how fast (or not fast) ansible-base 2.11 will be released, and how fast ansible wants to release (no idea whether this has been talked about) 15:33:03 gundalow: abadger1999: might know more 15:33:05 #info ansible-base tentatively comes out in mid Aug, and Ansible (acd) in mid Sept (dates subject to change for sure) 15:33:44 samccann: so, for your priorities list 15:33:52 so someone who wants to use ansible-base is doing something like pip install ansible-base? 15:34:15 or yum install ansible-base? 15:34:22 yeah whichever 15:34:44 i guess I'm still stuck on who's using ansible-base w/o ansible in that one month or so window 15:35:01 samccann: my guess is, very few people 15:35:09 and given very limited people to do this work, how does that fit into our priority list 15:35:17 btw, for people using `pip install ansible` there will be some more challenges 15:35:25 same for `pip install ansible-base` 15:35:38 especially until ansible-2.10 is released 15:35:49 if it's very little people using ansible-base on its own, can we just put a section in the porting guide (for ansible-base) on how to get it and say the docs still reflect full ansible for now 15:36:10 felixfontein can you elaborate on the problems? 15:36:21 https://github.com/ansible/ansible/issues/70348 15:36:38 the problem is: if you have ansible-2.9 installed, and install ansible-2.10, your ansible binaries will be gone 15:36:45 (that's due to the way pip works) 15:36:51 if you install with pip, that is 15:36:59 system package managers should do better 15:37:25 is that a permanent problem? 15:37:29 and if you install ansible-base next to ansible-2.9 (which pip won't disallow since they are different packages), you will end up with a broken installation 15:37:33 ah, I think I saw this conversation yesterday - you have to uninstall first? 15:37:37 yes 15:37:54 once nobody is using ansible-2.9 or older anymore, or upgrading from a version before 2.10, the problem is gone 15:38:06 but the change from pre-2.10 to 2.10+ will be rough 15:38:22 #info pip install ansible-base will have a problem requiring users to uninstall first or use --force.. see https://github.com/ansible/ansible/issues/70348 15:38:47 what happens when we go from ansible-2.10 to ansible-basee 2.11 for example? 15:38:55 that will be no problem 15:39:11 ok so this is just the upgrade problem... so should be in the porting guide, right? 15:39:20 it's essentially a one-time problem - except that people don't upgrade right now, but over the next n years 15:39:24 does this problem affect only `ansible-base`? or also the new, collections-based `ansible` package? 15:39:31 so it will show up again and again for several years 15:39:34 ooch 15:39:48 acozine: it also (and in particular) affects the new ansible package 15:40:04 if someone does `pip install --upgrade ansible` once ansible 2.10 is out, they end up with a non-working ansible 15:40:09 #info this upgrade problem is only for pre 2.10 to 2.10+ upgrades, but users will do this at their own pace so needs solid docs 'somewhere' that will linger and be noticable to cover this 15:40:13 (assuming they had 2.9 or older installed before) 15:40:24 It's the tension from 2.9 or less to 2.10 or greater 15:40:35 we need to add a big `Before you upgrade, check which version you have installed now. If it is <= 2.9, uninstall first` message in a bunch of places 15:40:45 yep 15:40:48 yes 15:40:51 (typing slow, on phone, today, sorry) 15:41:22 that seems like a priority PR 15:41:32 #action samccann create a priority issue to track this upgrade problem in prominent places besides the porting guide 15:41:38 @acozine: big +1 to that :-) 15:42:13 what does pip install --upgrade ansible actually do? 15:42:26 i would have thought nothing until ansible 2.10 comes out 15:42:36 https://github.com/ansible/ansible/issues/70348 15:42:36 samccann: it first installs ansible-base (among other dependencies), then uninstalls ansible-2.9, and then installs ansible-2.10 15:42:57 yes but not until 2.10 comes out right? (not 2.10 ansiblebase) 15:43:03 samccann: and doesn't notice that installing ansible-base overwrote the binaries, and uninstalling ansible-2.9 also clears the binaries (and also the Python package) ansible-base installed 15:43:16 so a lot of files from ansible-base are missing 15:43:37 wiped by uninstalling ansible-2.9 (since it also provides these files) 15:44:48 samccann: if someone installs ansible-base next to ansible-2.9, they destroy their 2.9 installation. same if these are installed in the other order. and if one is removed, the other one is left mostly dead 15:45:30 @samccann Yes-ish. 15:45:32 (this already happened in the past, probably multiple times; the problem I know about is the pypi package docker-py which was renamed to docker, and which both install the same Python module) 15:45:51 felixfontein: ah, so we are in good company . . . 15:45:59 or at least, we aren't the first to hit this particular snag 15:46:12 acozine: yes. this came up as an issue for the docker_* modules for years 15:46:26 ok maybe the best approach would be if y'all add 'this should be documented' comments to that issue so we know what kind of docs details to add? 15:46:43 there's even code in the docker modules to tell the user that they apparently installed both packages, and that they have to remove both and then re-install one to make it work 15:46:43 @samccann Right now there's pre-releases of ansible and ansible-base on pypi so `pip install --upgrade ansible` isn't broken yet but `pip install --upgrade --pre ansible` is (as is specifying the version number explicitly: `pip install ansible==2.10.0a1`) 15:46:57 or maybe yeah, like I said, I'll open a docs issue and ask y'all to add details in case I miss some 15:47:38 abadger1999: it will be special fun when ansible-base 2.10 is released, and people install it with pip "next" to ansible 2.9 (or older) 15:47:51 yeah. 15:48:23 I asked in #pypa if there was a conflicts tag in pip a month or so ago for just that reason :-( 15:49:03 was the result something like "yes there is, but pip ignores it"? (from what I remember from yesterday) 15:49:14 The answer was, no there isn't. 15:49:15 so the error folks would run into is `command not found: ansible-playbook` 15:49:21 ah. in the end, same result... 15:49:28 But we found the Obsoletes tag which is ignored by pip yesterday. 15:49:31 acozine: yes 15:49:48 abadger1999: ah, that's what I remembered then 15:49:53 ok here's the issue -https://github.com/ansible/ansible/issues/70392 15:49:57 Obsoletes and Conflicts are often intimately related.... until there's an implementation I wouldn't know if Obsoletes is sufficient or not. 15:50:03 please add details there so we don't lose this thread 15:50:56 #info tracking issue for upgrade problems - https://github.com/ansible/ansible/issues/70392 15:51:16 samccann: I added the error message 15:53:14 I added a summary of what leads to destruction 15:53:19 thanks everyone! 15:54:02 now we've gone 23 minutes over 15:54:25 in a good cause, though 15:54:38 isn't that the case most times? :) 15:54:45 yes! 15:55:32 #info need to set priorities for docs for ansible-base release and ansible release 15:55:49 open the floor? 15:55:59 * samccann ponders what that really means or came from 15:55:59 #topic open floor 15:56:33 it's from parliamentary procedure . . . Robert's Rules of Order, where the chair literally controlled who "had the floor" and so could speak 15:57:14 don't know why I made that past tense 15:57:26 yeah but wondering was it a literal floor that you had to stand in to talk 15:57:44 probably 15:58:03 in the days before audio systems, you probably needed to be in the middle to be heard 15:58:04 * felixfontein thinks of a floor with a trapdoor which can be used to get rid of the speaker if they talk too much :D 15:58:05 and now that we used open floor to talk about... open floor... 15:58:11 HAHAHAHAHA!!! 15:58:11 heh 15:58:25 "it's getting boring. let's open the floor!" 15:58:25 it's the hallowed tech tradition of recursion 15:58:49 * acozine feels herself falling 15:59:00 I'm glad our floor is virtual ;) 15:59:27 me too . . . and someday someone is actually going to step onto the open floor and ask a question 15:59:29 or make a comment 15:59:31 or something 15:59:39 virtually, of course 16:00:23 but it seems today is not that day 16:00:42 as always, chat welcome in the channel any time 16:00:55 :) 16:01:04 and anyone can add items to https://github.com/ansible/community/issues/521 for the next meeting's agenda 16:01:06 just add a comment 16:01:36 thanks abadger1999 bcoca cbudz felixfontein samccann 16:01:46 and baptistemm in abenstia 16:01:52 thanks a lot everyone! :) 16:01:52 er, absentia 16:02:09 #endmeeting