17:01:25 <gaba> #startmeeting trac->gitlab October 15th
17:01:25 <MeetBot> Meeting started Tue Oct 15 17:01:25 2019 UTC.  The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:33 <gaba> We have an agenda here: https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf
17:01:45 <gaba> please review
17:02:07 <ahf> looks good
17:02:27 <anarcat> same
17:03:32 <gaba> ok, it seems that it may be just the 3 of us today :)
17:03:40 * catalyst is here
17:03:52 <gaba> hi catalyst! o/
17:03:59 <catalyst> hi!
17:04:18 <gaba> ok, 1st topic is review the registration of users (mail I sent to the tor@)
17:05:05 <gaba> the proposal is to have gitlab as it is and registration open (with a team moderating it)
17:05:16 <gaba> so far geko, pili and me offered to moderate gitlab users
17:05:24 <ahf> count me in there too
17:06:17 <gaba> if we see that is too much for us to handle then we close registration and get people to send a mail or similar for us to create accounts
17:06:30 <gaba> anybody disagreeing with this as a start?
17:06:47 <anarcat> not me
17:06:53 * ahf is good with it
17:07:06 <gaba> catalyst?
17:07:15 <catalyst> is this with or without namespace suffixes?
17:07:48 <gaba> not sure if we can have users created with -guest automatically when they register
17:07:49 <catalyst> (not a significant factor for me personally, but other people have said stuff about it before)
17:08:01 <gaba> we have been creating external users with the -guest
17:08:02 * GeKo is somewaht here but needs to work on the otf proposal
17:08:55 <gaba> we will see if they can be created with a suffix automatically
17:09:06 <gaba> otherwise they just get to be users with any name
17:09:10 <ahf> i think we need something like the salsa sign up app for that
17:09:40 * anarcat concurs
17:10:40 <gaba> ok
17:10:41 * ahf is checking
17:12:04 <ahf> nope, looks like we cannot define a suffix in GL itself :-)
17:12:16 <gaba> ok
17:12:17 <ahf> but, we can enable some lists of domain names we like for email. that is worth having in mind in case user spamming gets bad
17:12:32 <gaba> yes, whitelisting and blacklisting domains I think is a good idea
17:12:36 <ahf> ye
17:13:30 <gaba> it seems we have all issues resolved for this migration
17:14:29 <gaba> the document for the migration is up to date to what has been discussed and resolved at previous meetings
17:14:30 <ahf> yes \o/
17:14:36 <gaba> anybody has any question about it?
17:14:49 * anarcat goes to check the doc again
17:14:50 <gaba> or about what was resolved before or any doubt about anything?
17:15:34 <catalyst> are we going to continue looking into using Discourse?
17:15:50 <anarcat> as far as discourse is concerned, this is kind of on hold
17:15:56 <gaba> not in this specific proposal of migration. I think we should but it is a longer term project
17:16:09 <gaba> yes, on hold inside this migration project
17:16:11 <anarcat> we were hoping the blog discussion would spur this forward, but the short-term stuff on that front is to fix things up in the blog first
17:16:40 <anarcat> so maybe it will move ahead in the future, but it shouldn't be a blocker for the migration, otherwise it would mean waiting a possibly long time for the migration
17:16:57 <anarcat> in other words, discourse is punted over the web/blog people, afaik
17:17:03 <catalyst> ok
17:18:30 <anarcat> i'll mark the irc number bot as "solved" insofar as it needs work but we have a plan
17:18:44 <gaba> ok
17:20:47 <anarcat> what's our solution with trusting gitlab again?
17:20:58 <anarcat> we talked about keeping gitolite, but i'm not sure that's viable in the long term
17:21:19 <ahf> i have an idea about irc bot and integration in general but i want the ticket migration stuff to be done first
17:21:38 <anarcat> okay
17:21:38 <catalyst> gitolite is the back end for the read-write git repositories?
17:21:39 <gaba> in the short term we will continue using gitolite
17:21:48 <anarcat> catalyst: no, gitlab has its own git shell thing
17:22:00 <gaba> and I suppose some projects will move to gitlab for code too
17:22:01 <catalyst> anarcat: i meant what we're using gitolite for right now
17:22:07 <anarcat> catalyst: the concern is we might not want to trust gitlab with our most important code because the attack surface is larger
17:22:17 <gaba> catalyst: yes, we use gitolite right now
17:22:37 <anarcat> i'm talking about "Feature Comparison between Trac and Gitlab
17:22:47 <gaba> and I assume code will be mirrored into gitlab for all projects
17:22:48 <anarcat> in "Code Management", "Git"
17:22:57 <gaba> but we still use gitlab for code management
17:23:04 <anarcat> "Some people have concerns with using gitlab to merge code into some  repositories that could be more sensitive."
17:23:13 <anarcat> "Possible solution: to maintain some repositories in gitolite."
17:23:26 <ahf> isn't this tor.git only? i don't think i have heard this concern mentioned for other repos?
17:23:31 <anarcat> but okay, if "keep gitolite for some stuff" is the solution, i guess that's okay
17:23:34 <gaba> yes, i think the migration of code should be up for the mantainers
17:23:37 <anarcat> it's a concern for tpa
17:23:39 <catalyst> anarcat: right. i've heard that before. i'm wondering what the threat model is here
17:23:40 <ahf> oh!
17:23:50 <ahf> makes sense for tpa
17:23:51 <anarcat> i'm not sure how to frame this problem
17:23:53 <gaba> tpa and nick had this concern
17:24:04 <anarcat> i think the solution for this is to sign commits and auth with pgp
17:24:05 <catalyst> as far as i know nothing sensitive deploys directly out of git.tor, right?
17:24:06 <anarcat> on both ends
17:24:20 <anarcat> i don't know
17:24:38 <anarcat> i must admit i'm not super familiar with the ways of git.tpo
17:25:21 <anarcat> the document still says we're going with a cypherpunks account, so that might need changing?
17:25:38 <anarcat> oh, didn't we have some sticky stuff with labels too?
17:26:06 <gaba> oh yes
17:26:16 <gaba> let's change that in the doc
17:26:21 <gaba> sticky stuff?
17:26:32 <anarcat> i don't remember, ahf didn't you say you had some trouble with labels?
17:26:37 <anarcat> maybe in the categories migration?
17:26:39 <anarcat> i don't remember
17:27:00 <ahf> no, that was just a nice to have feature in the enterprise version
17:27:11 <anarcat> ah
17:27:22 <anarcat> well good, no problem, i like those :p
17:27:27 <anarcat> i finished reviewing the docs
17:27:28 * anarcat concurs
17:28:35 <gaba> ok, anybody else need more time to review doc?
17:28:51 * ahf is good
17:29:27 <gaba> let's talk last about dates
17:29:35 <gaba> at the end of the doc there are steps for this migration
17:29:38 <ahf> yes :-)
17:29:50 <gaba> where it says 'MIGRATION’S PLAN
17:29:52 <gaba> '
17:29:59 <gaba> Are we ok with those?
17:30:30 <anarcat> what is 4.b)?
17:30:33 <anarcat> Migrate team’s wiki documentation repository for the group.
17:30:57 <gaba> We need to migrate trac's wiki too
17:31:02 <anarcat> from what i understand, we only have one wiki now, does that mean we split the trac wiki in the migration?
17:31:09 * catalyst realizes people are looking at a different nextcloud doc
17:31:12 <ahf> 4b is very open, i have no idea how we are migrating that
17:31:17 <anarcat> right okay
17:31:20 <gaba> right
17:31:23 <anarcat> so i'd move that up one level
17:31:39 <anarcat> say point 3e) or 3bis: migrate wiki in legacy project
17:31:42 <ahf> i have the feeling wikis are something where we care less about the history than everything else though?
17:32:04 <anarcat> my rationale is that we have one wiki, and we migrate it into trac, and it's already a huge deal because we need to handle markup (and maybe history) and all that stuff
17:32:14 <gaba> so your proposal is to migrate the whole wiki into the project 'legacy'
17:32:15 <anarcat> then, like tickets, we can split it up later if we need
17:32:18 <anarcat> yeah
17:32:25 <gaba> ok
17:32:32 <anarcat> i think we underestimate the complexity of this bit, to be honest :)
17:32:37 <anarcat> the wiki is vast and old and venerable
17:32:50 <anarcat> there's a lot of shit in there, and it doesn't map super well to what gitlab offers
17:32:59 <anarcat> because right now we basically treat it as a website
17:33:01 <catalyst> how much cross referencing are we willing to lose from the Trac wiki, if any?
17:33:05 <anarcat> but gitlab offers *many* wikis
17:33:10 <anarcat> like one per project
17:33:13 <anarcat> so we need to think about how that will work
17:33:23 <anarcat> my argument is we can punt this to "later" if we move it to legacy
17:33:48 <ahf> i think we can ask teams to migrating their stuff over? and we can ask vegas leads what they think we should move over for the global side of the org? (like our meeting list page)
17:33:49 <gaba> there is a tool (that anarcat suggested) to do migration from trac into gitlab. I was hoping we could use that for the wiki
17:33:50 <anarcat> because then #links will still work and we will do the hard work of parsing the textile or creole or whatever langguage trac uses (i forgot, to be honest) into markdown
17:34:14 <ahf> i think most of the network team wiki pages could use having some manual eyes looking at them
17:34:15 <anarcat> ahf: the wiki isn't split up into teams, it's not realistic to expect a team-based approach will migrate everything
17:34:16 <gaba> I'm up for moving the wiki into legacy and then spliting after
17:34:21 <anarcat> too much stuff will be left on the wayside
17:34:30 <ahf> anarcat: no, but some of the pages that have quite a bit of activity is team pages
17:34:39 <anarcat> gaba: i'm hoping tracboat or bits of it can help us do the conversion
17:34:42 <catalyst> ahf: +1
17:34:52 <anarcat> ahf: sure, but that doesn't mean the rest isn't useful :)
17:35:09 <anarcat> and there are some "global" pages like, as you said, meetings or https://trac.torproject.org/projects/tor/wiki/org/operations/services
17:35:10 <gaba> we will need a place for team wikis and a place for the rest of the org
17:35:13 <ahf> no, but isn't that something we can solve on an on-demand basis and migrate things over as needed?
17:35:20 <anarcat> i mean just look at this https://trac.torproject.org/projects/tor/wiki/org
17:35:29 <ahf> anarcat: isn't that a page maintained by the tpa team?
17:35:30 <anarcat> ahf: no, i don't think it is :)
17:35:35 <anarcat> ahf: hahaha
17:35:38 <anarcat> ahf: haha. no. :)
17:35:52 <anarcat> it's maintained by Nobody™, AFAIK
17:35:57 <ahf> so if nobody maintains the services page, then it should just go away
17:36:04 <ahf> or some team that cares for it can start maintaining it
17:36:19 <anarcat> i'm sorry, but i don't think we can just take a scorched earth approach here
17:36:36 <anarcat> it's not because the current wiki is badly maintained or orphaned that we should just leave it to rot there
17:36:37 <ahf> migrating things that nobody owns is not a blocker IMO.
17:36:52 <anarcat> well that's why i'm proposing we migrate the wiki as a whole
17:36:58 <anarcat> i don't understand what the alternative is, actually
17:37:01 <ahf> so it can rot there :-)
17:37:04 <anarcat> i'd be happy to hear another proposal
17:37:08 <anarcat> well
17:37:15 <catalyst> ahf: so it can rot in the migrated "legacy" wiki space?
17:37:16 <anarcat> "not migrating the wiki at all" is a proposal, sure
17:37:18 <ahf> that is why i don't think it is a blocker. i'm fine with us doing it, but i don't think it should block anything :-)
17:37:26 <anarcat> i think it's a blocker
17:37:27 <ahf> ah, no, sorry, i am not saying we shouldn't move things over
17:37:38 <anarcat> okay, maybe we need to sync up :)
17:37:45 <anarcat> i propose we migrate the wiki over to gitlab
17:37:50 <anarcat> into the legacy project's wiki
17:38:07 <anarcat> that process converts the markup as best as it can, keeping legacy links and things working as much as possible
17:38:10 <gaba> +1 to move the whole trac wiki into gitlab legacy project's wiki
17:38:16 <anarcat> and marking stuff as Ticket macros as broken or something
17:38:27 <ahf> the ticket list macros?
17:38:29 <gaba> the wiki will need some work
17:38:30 <anarcat> then *later*, some nice sunny day, people pick up bits and pieces and move them to the right places
17:38:41 <anarcat> ahf: stuff like the lists in here https://trac.torproject.org/projects/tor/wiki/user/anarcat
17:38:48 <anarcat> that will die in the migration
17:38:49 <catalyst> anarcat: ok i like this plan as it seems a "least bad" option :)
17:38:51 <anarcat> we need to handle that somehow
17:38:52 <anarcat> yeah
17:38:57 <ahf> yeah, those tables
17:38:58 <anarcat> i mean i'm happy to hear another plan :)
17:38:59 <ahf> cool!
17:39:11 <anarcat> but i don't like the "let it rot in trac" plan
17:39:15 <gaba> teor also has a page that uses quite frequently https://trac.torproject.org/projects/tor/wiki/user/teor
17:39:16 <anarcat> but maybe i just misunderstood :)
17:39:17 <ahf> anarcat: are you up for looking into how we can use the tool that needs to dive into the db itself and do the migration of the wiki with that?
17:39:20 <ahf> then we can do that in parallel?
17:39:35 <anarcat> ahf: well i looked into tracboat for that, and it has a converter to markdown
17:39:36 <ahf> i have forgot the name from top of my head right now and it's on my laptop and i'm on my desktop right now
17:39:42 <ahf> yes! the tracboat tool!
17:39:43 <anarcat> tracboat?
17:39:44 <anarcat> yeah
17:39:45 <ahf> yes
17:39:45 <gaba> anarcat: it would be awesome if you can be in charge of the migration of the wiki
17:40:03 <anarcat> well it's a bit tricky, because tracboat is this kind of all or nothing thing
17:40:12 <anarcat> you give it a trac install and it spurts out a gitlab instance
17:40:20 <anarcat> so it does tickets and wiki and everything
17:40:24 <anarcat> not sure we can just pick the wiki out of that
17:40:34 <anarcat> short of rewriting yet another conversion tool
17:40:37 <gaba> can we hack it a little to only do wiki
17:40:42 <anarcat> maybe?
17:41:05 <anarcat> may i remind people here that was one my objections to writing our own converter in the first place? :p
17:41:18 <anarcat> i guess that's not very useful ;)
17:41:25 <ahf> i can remind you that tracboat didn't do everything we wanted for ticket migration
17:41:28 <ahf> in case that was forgotten
17:41:33 <gaba> :)
17:41:37 <anarcat> ugh, i guess i'm relunctant to digging into another development project, i always feel like i have my hands full
17:41:53 <anarcat> ahf: maybe we shouldn't get back in that debate then :)
17:42:04 * anarcat retracts his poorly placed reminder
17:42:11 <anarcat> anyways
17:42:18 <ahf> i can look into how much work i think it would be - i think wiki's are less work than tickets
17:42:32 <ahf> but i have no idea about all the references inside the wiki
17:42:35 <ahf> that is the only concern i have
17:42:36 <anarcat> ahf: i seem to recall i sent you links to the tracboat code for the parser
17:42:41 <anarcat> yeah, it's kind of a problem
17:42:42 <ahf> i have already stolen the markdown converter from tracboat
17:42:46 <anarcat> oh you did
17:42:49 <ahf> yes
17:42:58 <anarcat> well i guess that's the magic bit you need
17:43:01 <ahf> it is good, required some modification, but it was easier than rewriting it myself
17:43:06 <anarcat> i knew i looked at this before :)
17:43:22 <ahf> yeah, for tickets and for wiki. but i think i am not sure how to rewrite internal references, but i can look into that on friday
17:43:25 <ahf> shouldn't take too long
17:43:37 <anarcat> okay
17:43:42 <anarcat> well, if you get stuck do ping me
17:43:47 <ahf> i will for sure :-D
17:43:55 <ahf> i can do a status to you on friday i think
17:43:59 <anarcat> i would rather stand a little aside on the tech work here, as far as programming the converter is concerned
17:44:09 <anarcat> i feel you have started this project and i can help
17:44:12 <ahf> my last two fridays have been trying to run the converter on all tickets up to 30k and find bugs in it
17:44:19 <anarcat> but i feel like starting a second converter effort would be messy
17:44:22 <ahf> and that takes a bit of time where i can look into other stuff
17:44:31 <anarcat> cool
17:44:32 <ahf> anarcat: sounds fair to me!
17:44:33 <ahf> cool
17:44:39 <anarcat> https://www.xkcd.com/303/
17:44:52 <ahf> ahahaha, i have that as a t-shirt
17:45:05 <ahf> gaba: should we try to think of some dates
17:45:08 <anarcat> but yeah, i can definitely work on the systems sides, although hiro has a better grasp of that than me
17:45:20 <anarcat> where is hiro, actually... shouldn't she be in those meetings? :)
17:45:32 <gaba> yes
17:45:33 <ahf> my "internal dates" right now have been: have a "full" (for full being everything that i haven't forgotten) migration to legacy/ on gitlab by medio november
17:45:36 <gaba> next is dates
17:45:42 <ahf> and then have two weeks of asking everyone to find mistakes in that by 1st of december
17:45:59 <ahf> and then if we don't need to bull any brakes here, do the move somewhere early december
17:46:16 <hiro> I am here
17:46:27 <gaba> hi hiro o/
17:46:31 <gaba> ahf: that sounds good
17:46:34 <anarcat> hey hiro :)
17:46:38 <hiro> I need to read backlog
17:46:39 <gaba> mid november to the test
17:46:57 <gaba> hiro: i have been trying to do a summary of discussion in the pad https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf
17:47:04 <ahf> yes, i think there is buffer there for a catastrophe for ticket migration and i haven't found any yet
17:47:07 <ahf> so there is space for the wiki thing too
17:47:08 <anarcat> ahf: early december sounds a bit tricky to me because it might mean "oh well, it's mid-december already" and next thing you know, you're running the final migration on christmas eve
17:47:15 <anarcat> and you spill gravy all over gitlab
17:47:28 <anarcat> and then you're sad because you spoiled both gravy and the website ;)
17:47:34 <gaba> and the question ahf, is how we can help
17:47:35 <ahf> anarcat: i have no worries with postponing it if that is needed - i don't want to ruin people's christmas if they celebrate that
17:47:55 <ahf> gaba: when the move has happened, i really need everyone (not just peopel in here, but everyone in the org) to help look for errors in the migration
17:47:56 <anarcat> ahf: well, celebrate newton's birthday or whatever, the point is people go on vacations during that time ;)
17:48:01 <hiro> oh wow we want to open gitlab to the abysses of spam? :D
17:48:02 <ahf> anarcat: yes!
17:48:05 <anarcat> and if you want a vacation, you don't want to start a migration a week before that :)
17:48:12 <ahf> i also go to the ccc thingy after christmas
17:48:15 <anarcat> hiro: i figured you might want in ;)
17:48:24 <anarcat> ahf: madness ;)
17:48:30 <gaba> hiro: how long it would take to have salsa with gitlab?
17:48:31 <hiro> yeah I am going to CCC too
17:48:52 <hiro> I haven't looked at the registration app that debian use
17:49:07 <hiro> I suppose it's somewhere in the playbooks too
17:49:36 <ahf> i think i saw it in the playbooks and disabled it there (was my first experience with ansible so i might have messed something up)
17:50:03 <hiro> yes there are a few things there in the playbooks
17:50:12 <hiro> (also gitlab pages and so... )
17:50:23 <ahf> yeep
17:51:38 <gaba> do you have link to the playbook?
17:51:43 <gaba> s
17:52:15 <hiro> https://gitweb.torproject.org/admin/services/gitlab/dip.git/
17:53:01 <gaba> ok, anything else that we need to consider?
17:53:24 <ahf> i don't think we had a conclusion to dates?
17:53:32 <gaba> if adding salsa is a very quick thing then i think we should do it...
17:53:40 <ahf> i would think most people leave for holidays around the 22nd of december or something like that
17:54:04 <gaba> ahf: I though you said mid November. We could do the tests before holidays and do the final migration when we come back.
17:54:09 <ahf> so aiming for being able to migrate the first week of december and if anything is delayed quickly postpone it to early january sounds reasonable?
17:54:20 <gaba> yes, that sounds good
17:54:25 <ahf> mid november for having the migration done to legacy/, then ask everybody to find errors
17:54:29 <ahf> and fix those errors
17:54:36 <ahf> then do the migration early december
17:54:43 <ahf> and hopefully no errors will be there, but that is a lucky shot
17:54:46 <ahf> and we are humans
17:55:08 <gaba> sounds ok to me
17:55:22 <anarcat> i concur
17:55:29 <anarcat> being human sounds okay
17:55:32 <gaba> catalyst, hiro: sounds good?
17:55:32 <anarcat> ;)
17:55:44 <hiro> who is going to migrate the tickets in the end?
17:55:51 <hiro> will that be team responsability?
17:55:52 <ahf> me i think?
17:55:55 <anarcat> hiro: ahf: is working on a script
17:55:58 <hiro> ah ok
17:56:03 <hiro> let me know if I can help
17:56:08 <ahf> and everything gets moved to a legacy/ project
17:56:13 <ahf> so we can see what hasn't been migrated
17:56:19 <ahf> and move that afterwards if we decide to create projects for it
17:56:22 <ahf> like more specific projects
17:56:43 <anarcat> hiro: as far as tpa is concerned, i think there will be some work to change our workflow when/if we switch away from git.tpo to gitlab
17:56:44 <catalyst> gaba: sounds ok to me as a rough timeline
17:56:55 <anarcat> i mean all teams will need to adjust
17:57:00 <anarcat> but we are special in so many ways
17:57:02 <hiro> uhm are we also switching from git.tpo?
17:57:05 * ahf keeps reading 'tpa' as 'tor browser android'
17:57:21 <anarcat> hiro: i was assuming we would
17:57:28 <hiro> is everybody comfortable with that?
17:57:31 <anarcat> hiro: are we keeping gitolite forever is another way to ask this question
17:57:32 <gaba> hiro: not for all repos
17:58:22 <gaba> anything else? can we close the meeting not then?
17:58:23 <anarcat> actually, the migration plan says nothing about git repos
17:58:26 <gaba> now*
17:58:32 <anarcat> but maybe we can talk about that another time :)
17:58:46 <anarcat> it seems unclear to me what repos will migrate from git.tpo to gitlab and how and when
17:58:49 <gaba> when people think we should  meet again?
17:59:04 <gaba> about the repos: I was thinking that is up to the mantainer of the repo
17:59:10 <gaba> is a different issue than migrating tickets
17:59:18 <anarcat> okay, so it's like jenkins i guess
17:59:21 <anarcat> we get rid of trac
17:59:33 <anarcat> we don't deal with gitolite or jenkins (yet)
17:59:43 <anarcat> and people are free to jump onboard if they want
18:00:04 <anarcat> we should still think about how that will happen though, because urls would break during such a transition and we'll have to provide people support to fix that
18:00:11 <anarcat> but that can be done in another meeting
18:00:14 <ahf> let's meet two weeks for now and do status on migration
18:00:18 <ahf> with focus on wiki and tickets
18:00:28 <ahf> by then we should be able to see something and discuss it and see if our timeplan is OK
18:00:37 <anarcat> i'd like to talk a bit about repos too if poss
18:00:55 <ahf> makes sense
18:01:03 <anarcat> but 2w seems good to me
18:01:05 <gaba> October 29th is 2 w
18:01:18 <anarcat> doable
18:01:28 <ahf> argh, i am traveling that day
18:01:36 <ahf> 29, 30, and 31st i'm in zurich
18:02:02 <gaba> november 5th?
18:02:05 <gaba> it could be 3 weeks
18:02:14 <ahf> or 28th?
18:02:21 * gaba is traveling on the 28th
18:02:26 <ahf> ahhh :-d
18:02:26 <gaba> back from mozfest
18:02:29 <ahf> ok 5 is OK for me
18:02:35 <ahf> 5/11
18:02:38 <anarcat> or 25th?
18:02:43 <anarcat> we could iterate a bit faster
18:02:56 <anarcat> although i guess fridays are when ahf does the most work so it's not the best time ;)
18:03:00 <gaba> ahf: how do you feel about that?
18:03:08 <ahf> i would prefer 5/11 over 25
18:03:11 <gaba> ok
18:03:14 <ahf> i like my fridays as being less irc :-S
18:03:31 <anarcat> sounds good
18:03:36 <ahf> 5/11 cool
18:03:39 <gaba> sounds good
18:03:42 <gaba> #endmeeting