15:01:06 <chandankumar> #startmeeting RDO meeting - 2016-07-27
15:01:06 <zodbot> Meeting started Wed Jul 27 15:01:06 2016 UTC.  The chair is chandankumar. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:06 <zodbot> The meeting name has been set to 'rdo_meeting_-_2016-07-27'
15:01:06 <openstack> Meeting started Wed Jul 27 15:01:06 2016 UTC and is due to finish in 60 minutes.  The chair is chandankumar. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:12 <openstack> The meeting name has been set to 'rdo_meeting___2016_07_27'
15:01:17 <dmsimard> silence you
15:01:18 <chandankumar> #topic Roll Call
15:01:20 <trown> o/
15:01:24 <jschlueter> o/
15:01:25 <dmsimard> \o
15:01:29 <mengxd> o/
15:01:31 <social> o/
15:01:34 <rbowen> o/
15:01:35 <coolsvap> o/
15:01:36 <imcsk8> \o/
15:01:43 <apevec> o/
15:02:01 <chandankumar> #chair trown dmsimard jschlueter mengxd social richm coolsvap imcsk8 apevec
15:02:01 <zodbot> Current chairs: apevec chandankumar coolsvap dmsimard imcsk8 jschlueter mengxd richm social trown
15:02:12 <jjoyce> o/
15:02:19 <chandankumar> #chair jjoyce
15:02:19 <zodbot> Current chairs: apevec chandankumar coolsvap dmsimard imcsk8 jjoyce jschlueter mengxd richm social trown
15:02:44 <chandankumar> So starting with first topic
15:03:00 <flepied> o/
15:03:01 <adarazs> o/
15:03:01 <chandankumar> #topic  Newton2 testday re-run on July 28-29 ?
15:03:08 <chandankumar> #chair flepied adarazs
15:03:08 <zodbot> Current chairs: adarazs apevec chandankumar coolsvap dmsimard flepied imcsk8 jjoyce jschlueter mengxd richm social trown
15:03:15 <chandankumar> apevec, please go ahead
15:03:26 <number80> o.
15:03:27 <apevec> we have passed CI since yesterday, so let's do testday re-run asap
15:03:33 <apevec> i.e. this week
15:03:36 <chandankumar> #chair number80
15:03:36 <zodbot> Current chairs: adarazs apevec chandankumar coolsvap dmsimard flepied imcsk8 jjoyce jschlueter mengxd number80 richm social trown
15:03:43 <number80> too short notice maybe?
15:03:54 <social> tuesday?
15:03:55 <apevec> yeah, but delying is not better
15:04:06 <number80> next week would still leave one month between M2 test day and M3
15:04:14 <weshay> o/
15:04:20 <chandankumar> #chair weshay
15:04:20 <zodbot> Current chairs: adarazs apevec chandankumar coolsvap dmsimard flepied imcsk8 jjoyce jschlueter mengxd number80 richm social trown weshay
15:04:22 <number80> yeah, no more delay
15:04:27 <dmsimard> I especially want to do this week because after that trown is away
15:04:28 <apevec> so early next week might be a compromise
15:04:35 <apevec> ah
15:04:39 <dmsimard> and trown is important for test days :)
15:04:49 <trown> aww
15:04:56 * dmsimard hugs
15:04:57 <rbowen> ok.
15:05:07 <social> friday?
15:05:09 <apevec> so let's start this week but welcome any testers next week
15:05:17 <dmsimard> We could maybe compromise on *one* day, friday
15:05:20 <apevec> I mean, that's given all the time :)
15:05:21 <dmsimard> instead of the usual two
15:05:44 <apevec> Friday is off for some parts of the world
15:05:54 <apevec> that's why we traditional had two days
15:06:02 <apevec> to cover all TZs and cultures
15:07:26 <apevec> so let's just start tomorrow
15:07:36 <Duck> quack
15:07:37 <rbowen> It's short notice, but I think we can get word out.
15:07:48 <dmsimard> yeah let's all help getting the word out
15:07:51 <dmsimard> we can do it ;)
15:07:55 <apevec> rbowen, short notice in twitter age is 1s  :)
15:08:10 <rbowen> Sure, but even there, timezones.
15:08:17 <rbowen> Our aussie friends are already in bed.
15:08:22 <apevec> rbowen, hence day1/day2
15:08:26 <rbowen> yep
15:08:27 <dmsimard> let's do a formal vote for this week vs next week ?
15:08:34 <rbowen> Sure.
15:08:34 <chandankumar> thisweek
15:08:37 <apevec> this
15:08:40 <rbowen> this
15:08:42 <adarazs> this
15:08:43 <dmsimard> this week
15:08:46 <trown> this week
15:08:48 <flepied> this
15:08:51 <number80> next
15:09:00 <coolsvap> i am fine with either
15:09:09 <trown> number80 is feeling contrary today :P
15:09:11 <jschlueter> either
15:09:33 <number80> trown: I'm consistent with myself even it means I'm minority :)
15:09:41 <chandankumar> 7-thisweek, 1-next week, 2-either
15:09:54 <dmsimard> democracy :D
15:09:56 <trown> number80: as you shoud be :)
15:10:00 <dmsimard> not like that silly USA democracy (just kidding)
15:10:19 <rbowen> How are the superdelegates voting on this issue?
15:10:32 <Duck> #chair duck
15:10:42 <apevec> dmsimard, speaking of that, we need better bot-spam protection here, but we'll take that offline
15:10:48 <chandankumar> #chair Duck
15:10:48 <zodbot> Current chairs: Duck adarazs apevec chandankumar coolsvap dmsimard flepied imcsk8 jjoyce jschlueter mengxd number80 richm social trown weshay
15:10:52 <apevec> ok, let's record decision here?
15:10:56 <Duck> thanks
15:11:30 <chandankumar> action items?
15:11:31 <dmsimard> #agreed test days will occur this week July 28th and 29th
15:11:35 <dmsimard> right ?
15:11:39 <apevec> yep
15:11:44 <number80> *nods*
15:11:44 * jschlueter nods
15:11:54 <apevec> action for getting word out?
15:11:56 <rbowen> I'll send the relevant announcements.
15:12:13 <dmsimard> I'll retweet and repost and spam the announcements
15:12:27 <chandankumar> #action rbowen to getting word out for Newton2 testday re-run on 28-29 July
15:12:47 <chandankumar> ok moving to next topic
15:12:55 <chandankumar> #topic Package Review Status
15:13:13 <chandankumar> https://bugzilla.redhat.com/show_bug.cgi?id=1329341
15:13:24 <chandankumar> is the Newton package Review tracking Bug
15:13:32 <chandankumar> number80, please go ahead.
15:13:33 <number80> #info tripleo-ui is moving forward
15:13:50 <number80> we have newer nodejs, and honza submitted an initial package
15:13:51 <apevec> we need moar reviewers!
15:13:58 <number80> YES
15:14:13 <number80> or send me more matcha-flavored kitkat
15:14:15 <apevec> so please everybody feel free to do even informal reviews
15:14:24 <apevec> that all helps
15:15:13 <jruzicka> OK, I'll try to do some.
15:15:27 <number80> pradk: could you check pifpaf and cotyledon reviews btw?
15:15:34 <chandankumar> me too will help in doinf some review
15:15:37 <number80> AFAIK, there are higher prio changes
15:15:40 <pradk> number80, will do
15:15:45 <number80> thank you :)
15:16:00 <number80> we also need to push -tests packages reviews
15:16:16 <chandankumar> Currently i think two is in Queue
15:16:22 <chandankumar> Sahara-tests: https://bugzilla.redhat.com/show_bug.cgi?id=1318765
15:16:41 <apevec> yeah, those two are in my queue, horizon is looking good, will approve it
15:16:51 <chandankumar> Horizon-tempest: https://bugzilla.redhat.com/show_bug.cgi?id=1355886
15:16:57 <number80> yeah, I haven't followed guidelines changes esp. naming and splitting so if someone could write it up somewhere
15:16:58 <apevec> for sahara, still need to think about giving exception for JARs
15:16:59 <chandankumar> apevec, Thanks :-)
15:17:08 <number80> yeah
15:17:18 <apevec> building them for src will be "interesting"
15:17:23 <apevec> s/for/from/
15:17:44 <apevec> it _could_ be viewed as test fixtures, dunno
15:18:44 <number80> well, we need to build them frpm sources at some point
15:18:46 <chandankumar> number80, is naming and splitting related to test packages writeup?
15:18:55 <chandankumar> or something else
15:19:01 <apevec> number80, back to tripleo-ui https://review.openstack.org/#/c/344932/8/packaging/tripleo-ui.spec I didn't understand we gave free-pass to bundle deps tarball inside upstream source tarball ?
15:19:24 <number80> chandankumar: they're guidelines we need to write so that future tests packages remain consistent
15:19:42 <chandankumar> number80, i will do that
15:19:42 <apevec> chandankumar, yes, I'll need to convert my BZ comment into docs
15:19:51 <apevec> chandankumar, or you can :)
15:19:57 <number80> apevec: free-pass to bundle sources in packages, not in the upstream tarball
15:20:01 <jruzicka> bz2doc
15:20:12 <number80> AFAIK, it will prevent us to have tripleo-ui in DLRN
15:20:29 <chandankumar> jruzicka, nice project idea
15:20:31 <apevec> chandankumar, should fit in https://www.rdoproject.org/documentation/rdo-packaging-guidelines/#tests-packaging
15:20:42 <apevec> chandankumar, ah actually Alfredo already updated that
15:20:50 <number80> I have no opinion on having a separate package for deps or not, two sources in one packages works for me
15:21:05 <apevec> it's good having folks doing work behind your back :)
15:21:33 <apevec> number80, I'm not sure how that fits trunk packaging?
15:21:51 <apevec> we only want to have one variable i.e. actual upstream source changing
15:22:02 <apevec> deps cannot be bundled in that
15:22:13 <apevec> also how do you re-generate source tarball for git?
15:22:21 <apevec> it can only be pure source from git
15:22:27 <number80> apevec: it can be fixed by using spectool for everything that is not Source0
15:22:35 <apevec> we cannot pull from npm repos during source tarball generation from git
15:22:45 <apevec> number80, nope
15:22:50 <number80> ?
15:22:51 <apevec> that's network access during the build
15:23:26 <apevec> also https://review.openstack.org/#/c/344932/8/packaging/tripleo-ui.spec@7
15:23:40 <apevec> there aren't instructions how to generate the tarball
15:23:59 <number80> I think that honza is raising the topic of having proper releases in openstack-dev
15:24:51 <apevec> but that's not enough, for trunk builds we need setup.py sdist to work
15:25:05 <jruzicka> I'm pretty sure two sources instead of one will generate some work sooner or later so evade if possible ;)
15:25:30 <apevec> yeah, I suggested separate SRPM for deps
15:25:33 <number80> apevec: we need to solve that problem somehow, in the future, we'll have to deal with more javascript and maybe go projects
15:25:35 <jruzicka> 1:1 is always simpler then 1:N
15:25:56 <jruzicka> hardcoded scalars need change into vectors and things get funny
15:26:00 <number80> separate SRPM for deps works for me, i have really no preference
15:26:20 <apevec> ok, let's continue that on existing rdo-list thread
15:26:33 <number80> *nods*
15:27:26 <chandankumar> action items here?
15:28:10 <chandankumar> #action apevec to approve python-horizon-tests-tempest package
15:28:38 <apevec> #action apevec to followup on tripleo-ui packaging  thread on rdo-list
15:29:08 <chandankumar> apevec, with related to sahara tests, will i try building jar files from source?
15:29:22 <apevec> #action apevec to revisit givign exception for JARs
15:29:41 <apevec> chandankumar, that won't be just like that, and should be fixed upstream
15:29:57 <chandankumar> ok
15:30:03 <apevec> upstream should be shipping binaries
15:30:05 <apevec> err
15:30:07 <apevec> should NOT
15:30:07 <dmsimard> #undo
15:30:07 <zodbot> Removing item from minutes: ACTION by apevec at 15:29:22 : apevec to revisit givign exception for JARs
15:30:12 <dmsimard> #action apevec to revisit giving exception for JARs
15:30:14 <dmsimard> nit :p
15:30:22 <apevec> thanks :)
15:30:30 <apevec> actually
15:30:32 <apevec> #undo
15:30:32 <zodbot> Removing item from minutes: ACTION by dmsimard at 15:30:12 : apevec to revisit giving exception for JARs
15:30:34 <chandankumar> Anything more on this topic?
15:30:38 <apevec> just a sec
15:30:54 <apevec> #action apevec to revisit giving exception for JARs in sahara-tests
15:31:01 <apevec> not JARs in general :)
15:31:21 <dmsimard> are we going to have the same issue with stuff like zookeeper ?
15:31:35 <apevec> yes, but that's separate thing
15:31:42 <apevec> it's also in opstools now
15:31:44 <dmsimard> ok, let's not open that pandora's box now
15:31:50 <dmsimard> ah, how convenient
15:32:07 <apevec> plan is to have maven support in CBS, that's under investigation
15:32:21 <apevec> but separate topic
15:32:21 <dmsimard> next topic ?
15:32:23 <apevec> yes
15:32:26 <chandankumar> will i move to next topic?
15:32:32 <chandankumar> #topic pin some versions according to upper-constraints.txt
15:32:47 <chandankumar> https://trello.com/c/guK9Ag12/157-dlrn-builds-must-reflect-what-is-tested-upstream
15:32:57 <chandankumar> flepied, Please go ahead
15:33:15 <apevec> that's heads up, it's in progress
15:33:21 <flepied> it was just to inform that there will be some packages moving backward
15:33:41 <trown> back to the future?
15:33:42 <dmsimard> backward in contents but epoch will be forward, correct ?
15:33:55 <apevec> yes, we'll be switching centos7-master to have pinned versions for libs, clients, middlewares and such
15:34:26 <apevec> dmsimard, so contrary to the previous trunk2trunk upgrades talk, this won't be upgradeable
15:34:37 <apevec> i.e. we won;t be bumping Epoch for this
15:34:58 <dmsimard> how does that work, isn't epoch decided by the time at which the package is built ?
15:35:10 <apevec> there will be separate dlrn which will keep building all from master
15:35:10 <number80> I'd rather not support trunk-to-trunk updates
15:35:13 <dmsimard> or is epoch decided by the time of the commit that is being built, then ?
15:35:19 <number80> stable-to-trunk yes
15:35:40 <apevec> Epoch is in rpm spec
15:35:54 <apevec> and it is bumped when upstream changes versioning
15:35:55 <number80> the upgrade path matrix for trunk-to-trunk is just too large
15:36:02 <dmsimard> er, my understanding of epoch is the timestamp embedded in the package version
15:36:15 <apevec> e.g. when openstack changed from timebased Version to semver
15:36:29 <jruzicka> dmsimard, [epoch].1.0.0
15:36:32 <number80> dmsimard: nope, it just preempt RPM normal version compare workflow
15:36:34 <apevec> dmsimard, ah no, that's different
15:36:51 <apevec> That's part of generated Release by DLRN
15:37:01 <number80> so it can mess up badly performance of RPM dependency engine and sometime completely break it
15:37:03 <dmsimard> apevec: but since the timestamp will move forward, the package version will be detected as more up-to-date and thus should be upgradeable, no ?
15:37:23 <dmsimard> that's what we're relying on for in-gate reviews using the repo that was just built vs current-passed-ci
15:37:24 <apevec> dmsimard, no, Version which is == upstream version will go back
15:37:34 <apevec> e.g. current OSC is 2.6.1, pin is 2.6.0
15:37:37 <dmsimard> oh
15:37:39 <dmsimard> right
15:37:41 <dmsimard> ok
15:38:02 <trown> hmm
15:38:23 <trown> I guess priorities should take care of it
15:38:28 <apevec> nope
15:38:41 <apevec> if you're upgrading, yum priorities do not help
15:38:46 <trown> ah right
15:39:02 <apevec> but afaik trunk CI is always from scratch install
15:39:05 <apevec> so we should be good
15:39:09 <dmsimard> apevec: what about we keep the internal dlrn pinned on releases and the third-party dlrn CI we spoke of yesterday would be the one building master of everything
15:39:11 <trown> there are definitly minor update jobs in progress
15:39:17 <number80> who needs trunk-to-trunk upgrades?
15:39:18 <dmsimard> to detect spec-breaking changes
15:39:23 <trown> number80: CI
15:39:37 <number80> trown: why not testing stable-to-trunk upgrades?
15:39:38 <trown> number80: for testing minor upgrades
15:39:41 <dmsimard> trown: stable to trunk, yes, trunk to trunk ?
15:39:45 <number80> trunk-to-trunk is too much work
15:39:52 <number80> we don't have manpower for that
15:39:53 <apevec> which job is that, link?
15:40:10 <weshay> looking for ooo upgrade tests? or other
15:40:10 <number80> or you'd have to accept that changes can take one or two days to be reviewed
15:40:32 <trown> https://ci.centos.org/view/rdo/view/tripleo-periodic/job/tripleo-quickstart-upgrade-minor-mitaka-to-mitaka/
15:40:39 <weshay> :)
15:40:40 <number80> trade-off to support trunk-to-trunk upgrades is just a bad deal in all cases
15:40:41 <apevec> ok, stable is fine
15:40:50 <apevec> we're doing this on master
15:40:54 <trown> https://ci.centos.org/view/rdo/view/tripleo-periodic/job/tripleo-quickstart-upgrade-minor-master-to-master/
15:40:58 <apevec> damn :)
15:41:00 <number80> even on master
15:41:10 <trown> it has never passed though
15:41:12 <number80> such changes in master will end up in next stable
15:41:13 <trown> so we cant break it
15:41:15 <apevec> trown, ah cool
15:41:48 <dmsimard> 18 minutes left in meeting
15:41:57 <number80> bad idea
15:42:02 <weshay> we're waiting on one new feature before adding upgrades to the pipeline
15:42:35 <dmsimard> trunk to trunk isn't expected to work
15:42:35 <number80> what we want is not to break upgrades for users, not for development snapshots
15:42:40 <dmsimard> I don't think grenade even tests for that upstream
15:43:07 <apevec> grenade is testing N-1 to N
15:43:16 <trown> we have jobs for that too
15:43:28 <number80> N-1 to N snapshots is something we should
15:43:30 <trown> but I do not see minor upgrades being such a big deal
15:43:31 <number80> *do
15:43:40 <apevec> but I don't see bad to have master2master upgrades running starting from RC
15:43:48 <weshay> it's the same code path as major in ci
15:43:59 <number80> apevec: actually from M3 would work for me
15:44:21 <number80> at this stage, we should not introduce disruptive changes
15:44:29 <apevec> yep, and we'll break this now, before M3
15:44:29 <number80> but before that, it's not realistic
15:44:59 <apevec> number80, doesn't hurt to start working on that job, it just won't be in the promotion
15:45:05 <trown> cool, so we could have minor to minor periodic job for the whole cycle, but not care much about it until after M3
15:45:06 <apevec> anyway, next topci
15:45:12 <number80> I'm fine with having the job running
15:45:29 <chandankumar> apevec, my network went done, sorry for that
15:45:33 <chandankumar> #topic Status of Automate stable packages releases
15:45:35 <number80> but fixing this job failure before M3 is not something we want to do
15:45:47 <trown> cool
15:45:51 <weshay> aye
15:46:07 <chandankumar> flepied, again your topic i think
15:46:09 <number80> ?
15:46:26 <number80> we're still working on this w/ fbo
15:46:40 <number80> lemme find the review
15:46:54 <chandankumar> https://www.redhat.com/archives/rdo-list/2016-July/msg00140.html
15:46:55 <number80> https://review.rdoproject.org/r/#/c/1727/
15:47:04 <flepied> yes that's also a heads-up that we are going to merge branches to simplify the way we deal with stable branches
15:47:19 <fbo> https://review.rdoproject.org/r/#/c/1732/
15:47:23 <fbo> and ^
15:47:51 <flepied> #link https://trello.com/c/URAtrhLU/86-automate-stable-packages-releases
15:47:52 <dmsimard> flepied: merge branches, you mean re: no lazy branching ?
15:48:08 <apevec> yes
15:48:33 <flepied> dmsimard: yes we'll use only one branch per stable release
15:48:40 <dmsimard> thank god
15:48:54 <dmsimard> let's do this before M3
15:49:05 <dmsimard> expecting some things to break as a result
15:49:15 <flepied> any help welcome on the tasks on the card
15:50:09 <chandankumar> I think no action item on this, can i move to next topic then?
15:50:16 <flepied> yep
15:50:22 <chandankumar> #topic overlap between dashboards.rdo and future status.rdo
15:50:38 <dmsimard> So today we have https://dashboards.rdoproject.org/rdo-dev
15:50:51 <rbowen> WHICH IS ALL GREEN!
15:51:00 <dmsimard> which is all green
15:51:01 <flepied> \o/
15:51:04 <rbowen> :)
15:51:09 <chandankumar> yay!
15:51:16 <dmsimard> but eventually I'd like to have something more like https://demo.cachethq.io/ ( http://status.rdoproject.org/ WIP )
15:51:28 <chandankumar> https://www.redhat.com/archives/rdo-list/2016-July/msg00140.html
15:51:37 <dmsimard> that would emcompass monitoring and general status of the RDO land in a user-friendly way
15:52:15 <flepied> I think we should consider the personas we are targeting
15:52:35 <rbowen> I don't find the overlap harmful.
15:52:38 * chandankumar reminds we have 8 mins left.
15:52:48 <dmsimard> If we're okay with overlap, I don't mind, I just wanted to point it out
15:53:05 <rbowen> We also have http://rdoproject.org/stats/ which tracks other aspects of the community, by the way, as long as we're considering overlap.
15:53:06 <flepied> a more technical dashboard could be useful to track other stuff like number of reviews, stats of gerrit/git
15:53:31 <dmsimard> rbowen: TIL about r.o/stats
15:53:41 <trown> whoa TIL too
15:53:44 <dmsimard> where does that even come from
15:53:44 <trown> thats pretty neat
15:54:35 <dmsimard> okay, so, that's it for me on that topic :)
15:54:44 <chandankumar> #topic RFE provide stable DLRN interface for TripleO CI
15:55:02 <dmsimard> define stable dlrn interface
15:55:19 <chandankumar> it is a just a query from someone related to this https://github.com/openstack-packages/DLRN/issues/22
15:55:27 <weshay> aye..
15:55:29 <adarazs> yes
15:56:01 <weshay> just wondering if that is tracked on the rdo board
15:56:03 <dmsimard> so what I hear is that we should be doing releases of dlrn so that people can pin to that if they want to
15:56:09 <adarazs> I don't really like the title. what we need is to make DLRN not too trigger happy about checking out the code change (not the spec repo change) when we want to build something locally.
15:56:33 <dmsimard> but pinning to a release of dlrn is sort of complicated, changes to spec files or rdoinfo/rdopkg could not be backwards compat
15:56:44 <adarazs> previously there was a hack to achieve that, now it's not possible without code editing.
15:56:45 <dmsimard> adarazs: oh, that's different
15:57:01 <jruzicka> dmsimard, I don't think it's about pinning DLRN, but about building specific versions of packages
15:57:09 <dmsimard> jruzicka: yeah I just got that
15:57:11 <adarazs> we just need to build single rpms from upstream changes.
15:57:15 <apevec> adarazs, I'd like to keep that open until jpena is back next week
15:57:15 <weshay> jruzicka, ya
15:57:22 * chandankumar reminds we have 3 mins left
15:57:41 <apevec> I did propose --local-source or something like that to address tripleo-ci use-case
15:58:02 <adarazs> apevec: sounds good to me, do you think jpena will be able to take that on?
15:58:22 <flepied> I tried to reproduce the problem today but I failed to reproduce
15:58:44 <apevec> he surely will, but I'd like to also use this opportunity to rethink dlrn i/f in general
15:58:53 <apevec> we might want to decompose it
15:59:02 <apevec> so e.g. we could run it as post-commit job
15:59:11 <adarazs> flepied: how did you try it? try checking out a custom change in DLRN/data and try to build. DLRN will reset it to master.
15:59:14 <flepied> adarazs: could you drive me to an example after the meeting?
15:59:32 <adarazs> flepied: sure.
15:59:45 <apevec> yeah, just update the DLRN issue with examples
15:59:53 <apevec> so that jpena can catch up next week
15:59:56 <adarazs> good idea.
16:00:04 <chandankumar> apevec, next topic?
16:00:10 <apevec> yes
16:00:16 <chandankumar> #chair for next meeting
16:00:16 <zodbot> Current chairs: Duck adarazs apevec chandankumar coolsvap dmsimard flepied for imcsk8 jjoyce jschlueter meeting mengxd next number80 richm social trown weshay
16:00:28 <chandankumar> #topic chair for next meeting
16:00:35 <jruzicka> heh. I can.
16:00:50 <chandankumar> #action jruzicka to chair for next meeting
16:01:12 <chandankumar> We are running out of time, so i am going to close the meeting
16:01:16 <rbowen> +1
16:01:18 <chandankumar> #endmeeting