21:03:15 <ttx> #startmeeting project
21:03:16 <openstack> Meeting started Tue Aug 12 21:03:15 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:20 <openstack> The meeting name has been set to 'project'
21:03:22 <ttx> Agenda for today is available at:
21:03:22 <mikal> Hi
21:03:27 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:03:53 <ttx> #topic News from the 1:1 sync points
21:03:58 <ttx> We covered all projects but Cinder this week (Cinder is having their midcycle meetup)
21:04:02 <ttx> Here is the log:
21:04:05 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-08-12-08.03.html
21:04:57 <ttx> In summary all projects are slightly behind schedule, and most of them will use FPF to drop stuff that is not proposed next Thursday
21:05:04 <ttx> #topic Other program news
21:05:09 <ttx> Any other program with a quick announcement ?
21:05:23 <annegentle> o/
21:05:28 <jeblair> o/
21:05:38 <annegentle> I have a quick psa that ties into the later agenda item; I can wait until then
21:05:52 <clarkb> I will be switching everyone to trusty by default on the 20th and updating tox
21:06:03 <mtreinish> clarkb: nice
21:06:14 <eglynn> clarkb: trusty FTW! :)
21:06:33 <jeblair> ttx: we want to move stackforge/kite to openstack/kite since it was adopted by barbican
21:06:48 <jeblair> ttx: do you sync with jraim?
21:07:04 <ttx> I can do thaht
21:07:28 <jeblair> we were also wondering about python-kiteclient
21:07:36 <ttx> it should probably move as well
21:07:46 <ttx> but then it's not like an emergency repomove
21:08:35 <dolphm> they should stay together, for sure
21:08:36 <ttx> jeblair: won't be that much around in the coming days
21:08:49 <ttx> jeblair: you got a repomove day planned?
21:09:12 <jeblair> ttx: yeah, saturday.  we'll try emailing him i guess :)
21:09:44 <ttx> ack, thx
21:09:54 <ttx> ok, moving on
21:09:57 <ttx> #topic When to open Kilo specs (mikal)
21:10:03 <ttx> mikal: ohai
21:10:06 <mikal> Heya
21:10:16 <mikal> So... I'm receiving questions on when specs for K will open
21:10:17 <ttx> I know mestery wanted to discuss that as well
21:10:19 * mestery listens closely here.
21:10:22 <mestery> ttx: ++
21:10:25 <dolphm> why are specs not open now?
21:10:29 <mikal> Given we'd said that the specs process would be more synced between projects in K
21:10:39 <mikal> I feel like we should have a unified plan for this as well
21:10:40 <eglynn> bump any still-open juno specs to kilo now?
21:10:53 <mikal> We'd felt that working on specs now was a distraction from landing J
21:11:02 <ttx> I think the main concern is the review overload. But then you could train reviewers to ignore Kilo specs until Kilo opens
21:11:05 <mikal> However, I now realize the people writing specs have little interest in fixing J bugs
21:11:14 <mestery> mikal: It's a tough nut to crack
21:11:15 <dolphm> i don't have an example today, but if we had review bandwidth and a spec proposed to a kilo/ dir today, why not give it a review? is there reason to block it?
21:11:19 <mikal> i.e. the people wanting to do one now are people only interested in landing their feature
21:11:23 <ttx> esepcially since they should not really be looking into *-specs at this point
21:11:59 <dolphm> mikal: what are you trying to stop people from doing? proposing kilo specs? reviewing kilo specs? landing them?
21:12:00 <eglynn> but the fact that they can't propose to gerrit won't stop them working on their spec surely?
21:12:01 <mikal> So I guess this was more of an informational thing
21:12:06 <ttx> dolphm: I think you don't have the same type of problems that Nova, Neutron (and possibly Cinder) have
21:12:07 <mikal> What are other projects doign for this?
21:12:19 <ttx> where the sheer noise is disturbing
21:12:24 <mikal> dolphm: distracting reviewers, and attempting to redirect that effort into things we need for J
21:12:28 <annegentle> people only want to write specs?
21:12:36 <dolphm> ttx: certainly!
21:12:38 <mikal> annegentle: yes, some people
21:12:42 <annegentle> mikal: or is it that they want assurance _all_ will land?
21:12:43 <ttx> annegentle: but write them and reviewers will come
21:12:48 <dolphm> mikal: can't reviewers just ignore kilo/ specs willingly?
21:12:51 <annegentle> mikal: as in spec,code, everything?
21:12:56 <mikal> We have vendors who have little interest in fixing bugs, and only care about landing their feature
21:13:04 <eglynn> mikal: I was thinking of just bumping all open juno specs to kilo and then asking the review team to use their judgement as to where to apply their review cycles
21:13:06 <mestery> It's hard for us to focus on Kilo spec reviews when we're still trying hard to land Juno stuff.
21:13:11 <annegentle> mikal: they'll write specs but not docs, and that needs to be nipped
21:13:14 <mikal> dolphm: sure... its more the attempt to redirect the author's efforts that we were after
21:13:17 <devananda> the sheer noise is distracting <--- this
21:13:20 <eglynn> mikal: ... with a heavy steer away from kilo specs, but not enforced
21:13:44 <devananda> folks show up in IRC pushing the "please review my spec" button over an over again
21:13:45 <mikal> I don't think moving J specs to K is a good idea for nova
21:13:50 <mikal> We have a lot of abandonded specs as well
21:13:51 <dolphm> mikal: but like you said, certain spec authors couldn't care less about stabilizing the previous release, especially if they're feature isn't in it
21:13:52 <mestery> devananda: ++
21:13:55 <mikal> Re-proposing is light weight
21:14:11 <mikal> dolphm: sure, but I was trying to change their behaviour
21:14:15 <mikal> dolphm: it didn't work
21:14:16 <eglynn> devananda: I use a mental /ignore to filter those :)
21:14:17 <dolphm> mikal: cats
21:14:37 <mikal> So, it sounds like other people are allowing K specs now?
21:14:51 <devananda> for ironic, my plan is to -2 all open specs, then wait until some time (exactly when TBD) after FF before creating the /kilo directory, and then see who reproposes
21:14:52 <mestery> mikal: Not Neutron.
21:14:59 <dolphm> mikal: how about moving abandoned specs into an abandoned/ dir at the end of a release, all at once?
21:15:16 <mikal> dolphm: we were just goign to -2 in gerrit like devananda
21:15:26 <mikal> dolphm: moving them into a dir would require merging them
21:15:31 <mikal> Which would be a lot of reviews
21:15:35 <mikal> Unless its one super review I suppose
21:15:45 <dolphm> devananda: design discussions should still go on - i don't think a -2 is particularly beneficial to anyone
21:16:00 <eglynn> mikal: I'm not a huge fan of attempting to force the hand of developers, as they tend to just workaround the restriction in any case
21:16:04 <ttx> annegentle: all those who write specs won't really be around to write docs :)
21:16:08 <mikal> dolphm: the review needs to have its paths chagned, hence the procedural -2
21:16:12 <dolphm> mikal: you're talking about abandoned reviews then?
21:16:22 <mikal> dolphm: yeah, largely
21:16:32 <ttx> It's tricky, you want to let the door open but clearly show that it's frowned upon
21:16:35 <mikal> dolphm: we don't know what's abandoned at the moment, as spec review stopped a while ago
21:16:42 <devananda> dolphm: that's exactly it. i DONT want design discussions happening between now and RC
21:16:46 <ttx> so that people know they should be usig their time doing something else at this point in the cycle
21:16:49 <mikal> dolphm: do asking people to rebase is a way they signal that they still care
21:16:52 <devananda> at least not in as much as they take away from making a stable RC
21:17:07 <mikal> s/do/so/
21:17:23 <ttx> devananda: ++
21:17:24 <eglynn> positive steer beats negative restrictions, IMO
21:17:32 <devananda> there are seriously only two things in ironic that deserve an ongoing discussion with cores - and we already have that informally
21:17:44 <dolphm> devananda: that seems like you're shooting yourself in the foot
21:18:10 <dolphm> devananda: (trying to artificially inhibit design discussions)
21:18:33 <devananda> dolphm: focusing on one thing for a short period of time means putting other things on the back burner
21:18:36 <devananda> I don't see how that's a bad thing
21:18:37 <ttx> eglynn: how would you present it in a positive way while still discouraging out-of-sync actions like this? It's tricky
21:19:01 <dolphm> devananda: normally, what we're designing for and what we're doing are closely related
21:19:03 <devananda> dolphm: we'll definitely have those design discussions with vendors and interested parties, after we do the work needed to get Juno out the door
21:19:04 <eglynn> ttx: the value proposition is making juno a release we can be proud of / can stand over etc.
21:19:28 <mikal> eglynn: I haven't had a lot of joy with that sort of angle
21:19:38 <mikal> eglynn: "do reviews, it will speed up your own review by making the queue smaller"
21:19:42 <mikal> eglynn: zero reviews occur
21:19:58 <eglynn> mikal: fair enough, much bigger and more diverse contributor base in the nova case
21:20:12 <eglynn> mikal: ... social pressures easier to apply with a smaller group
21:20:19 <ttx> eglynn: as someone who has been asking people to work on RC bugs for the last 9 releases, i would say that the beauty of the game is not a sufficient motivator
21:20:20 <mikal> eglynn: I think that's very true
21:20:33 <mikal> eglynn: also, it seems projects with a vendor driver layer seem to have a harder time
21:20:41 <eglynn> mikal: fair point
21:20:47 <ttx> it only touches a minority of contributors, the "strategic" ones
21:21:30 <eglynn> ttx: ... if all else fails, one can always try "guilting" them into doing it :)
21:21:36 <mikal> I don't feel like we reached a concensus here
21:21:52 <ttx> So. solution one is to not prevent K specs from being submitted, and teach core reviewers to ignore them
21:22:03 <dolphm> mikal: what was the question, again?
21:22:07 <ttx> solution 2 is to somehow prevent those from being filed until RC1
21:22:13 <eglynn> mikal: well a one-size-fits-all approach may not work across all the projects
21:22:21 <mikal> ttx: I am increasingly of the believe we should go with 1
21:22:25 <ttx> eglynn: it's definitely not a one-size-fits-all
21:22:33 <mikal> Yeah, agreed
21:22:34 <ttx> it's finding a solution for the largest projects
21:22:46 <eglynn> ttx: that's fair
21:22:51 <mikal> dolphm: whether opening K specs now is a mistake
21:22:52 <mestery> Ignoring specs has it's own issues, if that's a solution it's the wrong one.
21:22:57 <mestery> We hit many issues with that in Neutron during Juno.
21:22:59 <ttx> mikal: i prefer solution 1. Solution 2 is only pretending to fix the issue
21:23:07 <mikal> ttx: agreed
21:23:10 <mestery> If anything, being more proactive about responding to specs is the right approach, but that requires time.
21:23:26 <mikal> Its ok, K will be full of magical runways of awesome
21:23:29 <dolphm> mikal: well then i vote that closing them was a mistake :)
21:23:40 <mikal> We just have to get there with no one getting murdered on the way
21:23:56 <ttx> mestery: you think we can't just say "K specs will start getting reviewed when K development opens" ?
21:24:08 <ttx> that sounds like something that rings true, somehow
21:24:11 <mestery> ttx: My experience shows people get angry when their specs are ignored.
21:24:14 <mikal> ttx: that's what nova originally said
21:24:20 <mestery> While it's a fair statement, not everyone will be happy with it.
21:24:24 <mikal> ttx: and what happens now is everyone pings me and says they're sulking
21:24:25 <dolphm> mestery: when anything in gerrit is ignored
21:24:31 <mestery> dolphm: ++
21:24:33 <mikal> ttx: and declines to work on bugs instead
21:24:39 <ttx> sigh
21:24:41 <mestery> mikal: I get that too
21:24:52 <mikal> I get a lot of very weird personal email
21:25:04 <ttx> mikal: we should trade some
21:25:12 <mikal> ttx: have a gallery of the best?
21:25:25 <mestery> mikal: I bet not as weird as mine
21:25:34 <ttx> sounds like a topic for a beer
21:25:39 <mikal> Maybe neutron / cinder / nova should collude for a "big project plan"
21:25:50 <mikal> We could have a quick chat when John gets back
21:25:52 <dolphm> mikal: ttx: just reply on an mailing list
21:25:53 <mestery> mikal: :)
21:26:18 <mikal> It seems like the big project concerns aren't shared by the smaller projects
21:26:25 <jgriffith> I'm back :)
21:26:27 <dhellmann> dolphm: I reply to a lot of email asking them to resend it to the -dev list
21:26:29 <mikal> Oh, that guy
21:26:30 <annegentle> mikal: right that's my sense of it too
21:26:44 <dolphm> dhellmann: i just do that for them :)
21:26:50 <ttx> frankly, I think if you have so many people that don't care about your project that you can't get enough "normal" work done, you have a separate problem
21:26:53 <dolphm> doesn't happen all that often to me though
21:26:57 <devananda> mikal: i'm sort of surprised, given how much ironic's concerns overlap with nova's
21:26:58 <ttx> this K specs thing is just a symptom
21:26:59 <mikal> ttx: oh, agreed
21:26:59 <mestery> ttx: ++
21:27:05 <devananda> mikal: I don't consider us a large project, tho
21:27:10 <devananda> ttx: definitely
21:27:14 <mikal> ttx: is more about trying to push the distraction laser out of the path of the people who are part of the solution
21:27:16 <markmcclain> could we not just have a gerrit autoresponder for projects that want delay that includes a note of when the opening will occur?
21:27:42 <mikal> devananda: surprised that smaller projects seem less concerned you mean?
21:27:42 <ttx> mikal: in the end, it's "how to avoid the PTl pain of dealing with unreasonable requests"
21:27:50 <dhellmann> markmcclain: it wouldn't even need to be a bot, it could be a check job
21:27:53 <ttx> I think jgriffith wrote a book on it
21:28:09 <mikal> ttx: I think that pain is unavoidable
21:28:14 <mikal> ttx: because we deal with humans'
21:28:22 <devananda> mikal: surprised that smaller proejcts don't share the concerns of larger projects (+ ironic)
21:28:27 <ttx> mikal: we could do a better job of communicating expectations though
21:28:28 <mikal> ttx: I tried building a core reviewer out of lego, it didn't work out so well
21:28:54 <mikal> ttx: well, we did announce that we would freeze specs, accept no K specs, and fix bugs
21:29:03 <mikal> ttx: people just don't like it so they complain and don't fix bugs
21:29:17 <devananda> mikal: that's awesome
21:29:23 <ttx> I think you do as much as you can, we (as in me) need to ramp up developer docs and training to match
21:29:24 <eglynn> mikal: that would be my fear exactly
21:29:28 <dhellmann> there's a group working on getting corporate project managers more involved, maybe communicating these expectations is an area where that would be useful?
21:30:06 <mikal> dhellmann: if I had a mailing list of corporate project managers I could email asks to, I would use it a lot
21:30:08 <dolphm> ttx: a big page that answers the question "as a contributor, what should i be working on this week?" would be dandy
21:30:12 <ttx> mikal: at this point it's like they are just not contributing, so you shouldn't count on them for bugfixing
21:30:18 <mikal> dhellmann: "please encourage your people to focus on bug fixes for now"
21:30:26 <ttx> you may have a smaller set of contributors than you think :)
21:30:27 <dolphm> ttx: and by big page, i mean like a giant link to gerrit
21:30:33 <mikal> ttx: agreed. I also don't love drive by features by the way.
21:30:34 <mestery> I think as PTLs we already act as project managers, I don't think developers would necessarily listen to other ones either.
21:30:35 * eglynn thinks we've got to get out of the mindset that we can *tell* devs what to work on ... at most we can steer and incentivize IMO
21:30:38 <mikal> ttx: which is what a lot of this is.
21:30:38 <annegentle> bug fixes and document the features that did land.
21:31:03 <dhellmann> mikal: zehicle and sarob are involved in that, according to their blogs (also allison randall, but I don't know her irc handle)
21:31:16 <mikal> eglynn: that's probably true, although I don't know how to get there from here (at least in nova)
21:31:35 <ttx> mikal: once upon a time, everyone was attening the "project meeting" (this one) and just me shouting at people what enough to communicate cycle priorities
21:31:49 <ttx> s/what/was
21:32:03 <devananda> dhellmann: wendar
21:32:04 <ttx> we grew to the point where only PTLs attend this meeting
21:32:09 <dhellmann> devananda: thank you
21:32:10 <ttx> and they know the priorities
21:32:21 <annegentle> ttx: ah the good old days
21:32:26 <eglynn> dhellmann: these new corporate project managers would have how much leverage over the developer resources, do you think?
21:32:30 * mordred didn't attend this meeting even back then
21:32:35 * mestery reminisces.
21:32:39 <mikal> So, I feel like we should move on
21:32:41 <annegentle> mordred: ha
21:32:46 <mikal> There are other things on the agenda
21:32:48 <mikal> And this has stalled
21:32:50 <dolphm> mikal: ++
21:33:00 <ttx> #action ttx to think about how to communicate cycle priorities in the thousand-contributors times
21:33:00 <mestery> mikal: ++
21:33:02 <dhellmann> eglynn: well, it wouldn't be a matter of saying "we need you to do X" at first, but a matter of saying "don't talk to us about new features for a few weeks, we have bugs to fix"
21:33:15 <dhellmann> eglynn: setting expecatations at a different level in the organization
21:33:30 <eglynn> devananda: yeah, cool enough if it's "soft steer" like that
21:33:50 <eglynn> dhellmann: ^^^
21:33:54 <ttx> mikal: in summary, i think you should keep K specs open. We need to communicate cycle priorities better, but that's a bigger issue
21:33:57 <eglynn> darned tab completion!
21:34:18 <mikal> ttx: yeah, that's where I got ot as well
21:34:33 <mikal> ttx: I will discuss with John when he gets back from his cold meat themed music festival
21:34:33 <ttx> this meeting, and occasional ML rants are no longer enough
21:34:38 * devananda disagrees, keeps K specs closed
21:34:45 <mikal> devananda: as is your right
21:34:48 <ttx> devananda: ftw
21:34:56 <ttx> ok next topic
21:34:58 <ttx> #topic Clarification on documentation contrib workflow (eglynn/annegentle)
21:35:00 <devananda> i'll let ya'll know how it goes when we get to paris
21:35:06 <ttx> Heavyweight XML-based docbook versus new lightweight RST-based model
21:35:07 <eglynn> yeah, just something I wanted to raise on the PTLs' radar
21:35:09 <ttx> Fight!
21:35:20 <eglynn> as it could save your team some learning curve
21:35:23 <annegentle> heh no fight here
21:35:29 <eglynn> (if your project has substantial docco contribution coming down the road)
21:35:29 <ttx> eglynn: presented like this, i can't side with XML
21:35:41 <eglynn> annegentle: agreed, all sweetness & light! :)
21:35:59 <eglynn> ttx: this is more in the line of a PSA
21:36:00 <mikal> Could we perhaps use microsoft word for docs?
21:36:04 <eglynn> so basically there are now two separate contrib models for doc
21:36:04 <annegentle> next I will require video documentation
21:36:15 * annegentle stabs mikal with a spork
21:36:20 <mikal> Heh
21:36:30 <eglynn> the XML-based docbook has a significant learning curve
21:36:43 <eglynn> but the docs team is piloting a new lightweight option
21:36:56 <eglynn> based on RST that we all know and love :)
21:36:58 <dhellmann> annegentle: sporks are too sharp
21:37:14 <eglynn> so given how enthusiastic devs are for writing kilo specs in RST
21:37:24 <dolphm> xml used to be keystone's primary means of api docs, and we got less than zero community contribution. moving to MD/RST, we get quite a lot, although RST is still apparently a challenge to get even close to correct for most people
21:37:25 <annegentle> eglynn: heh quite the tie in
21:37:52 <eglynn> yep, seems that they should also be gunning to knock out the docco in the same format
21:38:16 <eglynn> annegentle: have I represented all that correctly?
21:38:22 <ttx> eglynn: now I'm disappointed. I'm addicted to conflict now
21:38:37 <eglynn> ttx: LOL :)
21:38:43 <annegentle> yes, though currently we are doing a POC with Heat only
21:38:50 <annegentle> part of this psa is also that I've got patches removing WADL from the "long form" API documents
21:39:00 <annegentle> dolphm: https://review.openstack.org/#/c/112620/
21:39:26 <annegentle> that helps with the problem of broken doc builds across repos (where the WADL breaking would break another repo's build)
21:39:39 <mikal> Is someone going to move the existing XML docs to RST?
21:39:41 <annegentle> what I'd like to do next is propose RST for the "long form" info that's left, like rate limiting, etc.
21:39:50 <mikal> Cause that person will look awesome on stackalytics
21:39:54 <ttx> die WADL die
21:39:56 <annegentle> mikal: this is a phased approach
21:40:12 <annegentle> mikal: well that person is me and I still won't match someone like Andreas Jaeger :)
21:40:36 <mikal> Heh
21:41:04 <dolphm> annegentle: my hero!
21:41:06 <annegentle> mikal: the phases are: POC for Heat (HOT Template), WADL removal for only docs on http://docs.openstack.org/api/api-specs.html
21:41:38 <annegentle> then RST proposal for API docs in each repo
21:41:39 <eglynn> annegentle: so for kilo, will the RST model become the primary vector for doc contributions from the project teams, d'ya think?
21:41:42 <annegentle> any questions?
21:41:46 <dolphm> annegentle: so, related conversation... should identity-api still exist? or should it be somehow merged into keystone-specs?
21:41:51 <eglynn> (or over a longer time horizon)
21:42:07 <annegentle> WADL remains our only solution currently for http://developer.openstack.org/api-ref.html but I'd welcome ideas
21:42:09 <dhellmann> annegentle: are you using sphinxcontrib-pecanwsme for API docs for new projects? should I get that moved to stackforge?
21:42:29 <annegentle> dolphm: I was going to propose it in keystone, but maybe in -specs is the better way?
21:42:50 <annegentle> dhellmann: I don't have a solution for extensible apis like nova neutron keystone right?
21:42:54 <dolphm> annegentle: doing it in -specs allows us to see proposed API changes as part of the design process
21:43:17 <annegentle> dolphm: right but you're the only team doing that, so my thinking is that I shop it with patchsets
21:43:33 <annegentle> dolphm: or I guess I could do ML post prior to patchsets
21:43:36 <dhellmann> annegentle: yeah, this would just be for new stuff, I'm just curious if you're actually using it in some way for non-developer docs since it's still under Dreamhosts' github account
21:43:55 <annegentle> eglynn: as for "will the RST model become primary vector" -- I have a dependency on a page-based redesign
21:44:03 <dolphm> annegentle: i'm asking selfishly here, knowing no one else uses keystone's process
21:44:12 <dolphm> for api documentation, anyway
21:44:16 <eglynn> annegentle: fair enough
21:44:24 <annegentle> dhellmann: I really would prefer a single API reference "way" -- swagger, raml, wadl, whatever
21:44:41 <annegentle> dhellmann: how you generate it I don't care
21:44:48 <dolphm> rst + jsonschema definitions :)
21:44:51 <annegentle> dhellmann: unless it's crappy
21:44:52 <dolphm> or md
21:44:53 <dhellmann> annegentle: ok, I wasn't pushing a solution, just wanting to make sure the tools you might be using were easily fixable as needed
21:45:25 <annegentle> dhellmann: seems like it
21:45:39 <dhellmann> I suspect most projects are going to be using some JSONSchema thing anyway, so the wsme doc lib might not be as useful
21:45:52 <annegentle> dhellmann: it looks like that's the compute v3 api (jsonschema)
21:45:57 <dhellmann> yeah
21:46:01 <annegentle> right
21:46:18 <ttx> ok, I think the PSA is now emitted
21:46:20 <annegentle> I still believe a lot of discussion about scope will help the docs program
21:46:28 <mikal> There is no v3 api by the way
21:46:31 <annegentle> since all of this overflow is in integrated projects
21:46:31 <mikal> It was a mirage
21:46:35 <annegentle> oh yes v3 / v2.1
21:46:43 <mikal> Ta
21:47:17 <ttx> eglynn, annegentle ready to move to open discussion?
21:47:19 <annegentle> https://review.openstack.org/#/c/85640/ for the curious/uninitiated
21:47:26 <annegentle> I'm good-to-go if eglynn is
21:47:26 <eglynn> ttx: yep
21:47:43 <ttx> #topic Open discussion
21:47:43 <eglynn> annegentle: thanks for all the additional background detail
21:47:47 <ttx> Anything else, anyone ?
21:48:18 <annegentle> someone come up with something so ttx doesn't get an early meeting end! I kid, I kid.
21:50:44 <ttx> tss
21:50:46 <ttx> #endmeeting