19:00:11 <jbryce> #startmeeting
19:00:12 <openstack> Meeting started Mon Apr 18 19:00:11 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:16 <jaypipes> o/
19:00:18 <dendrobates> o)
19:00:47 <jbryce> agenda is on the bottom of http://wiki.openstack.org/Governance/PPB
19:01:25 <jbryce> looks like 4 of us here so far....we'll give the others a couple of minutes to straggle in
19:02:05 <vishy> o/
19:03:12 <jbryce> did you make it out of dfw finally vishy?
19:03:21 <vishy> eventually
19:03:29 <vishy> 11 hours from sat to sfo
19:03:31 <vishy> :(
19:04:20 <jaypipes> vishy: not in Canada?
19:04:38 <ewanmellor> Hi, sorry I'm late -- had trouble getting on freenode.
19:04:45 <jaypipes> ewanmellor: no worries, mate.
19:05:09 <jbryce> ok...let's get going
19:05:24 <jbryce> #topic "sessionizing" blueprints for summit
19:05:49 <jbryce> so josh was interested in this one...i think he's planning on joining in a minute, but i've heard this question from a couple of people as well
19:05:58 <ttx> jbryce: ok
19:06:14 <jbryce> i saw vishy sent out an email that touched on it a little bit for nova
19:06:35 <vishy> josh will be here in a few
19:06:46 <ttx> jbryce: what was the question exactly ?
19:07:11 <jbryce> the questions i've gotten have been around the use of blueprints for design summit + coding...do they need to create 2 blueprints (one for session and one for code) or just one that will then be used going forward
19:07:29 <ttx> the same one will be used, if its reusable.
19:07:37 <jbryce> ok
19:07:47 <ttx> sometimes the session ends up spawning multiple smaller blueprints
19:08:10 <ttx> in which case it cas be set as a prereq so that the link is preserved
19:08:26 <ttx> ideally 1 session = 1 feature = 1 blueprint
19:08:32 <jbryce> ok
19:08:39 <dendrobates> ttx isn't all this pretty well documented?
19:08:55 <jbryce> dendrobates: apparently not
19:09:07 <jbryce> dendrobates: there are a couple of wiki pages, but people still have questions
19:09:10 <ttx> we have too many sessions and not enough slots, so we try to regroup them
19:09:22 <ttx> I agree it's not documented very well.
19:09:25 <jbryce> and i think the docs cover the happy path
19:09:45 <ttx> We always discover a few days before the summit that we have 60 sessions for 50 slots
19:09:52 <jbryce> yep
19:10:05 <jbryce> which is the other question i hear. if my blueprint doesn't get discussed...what next?
19:10:08 <ttx> so we play a grouping game... which ends up screwing the 1=1=1 rule a bit :)
19:10:17 <jaypipes> I've now read all the proposed blueprints. There are quite a few overlaps.
19:10:54 <ttx> jbryce: you mean if the BP doesn't get a session at the summit ? or is refused for the summit ?
19:11:26 <ttx> there are 3 steps...
19:11:34 <ttx> one is the session at the summit
19:11:44 <vishy> =
19:11:46 <ttx> the other is formal acceptation in the "diablo plan"
19:11:51 <ttx> the last one is the merge proposal
19:11:58 <ttx> only the last one is *necessary*
19:12:08 <ttx> but the previous two usually help the last one a lot
19:12:35 <ttx> especially if you don't want to star tworking on something that will get rejected in the end
19:12:39 <jbryce> ok
19:12:45 <dendrobates> or duplicate work
19:12:51 <ttx> I think vish's email is good
19:13:27 <jaypipes> ttx: but as vishy eloquently wrote on his ML post, people can certainly work on stuff without a blueprint... and just propose code for merging.
19:13:28 <jbryce> joshuamckenty_: we're talking blueprints...did you have other q's?
19:13:44 <ttx> jaypipes: certainly. It's just more risky.
19:14:38 <jbryce> and blueprints are nice for bubbling information up through ttx's releasestatus script for people who don't see every merge proposal
19:14:44 <vishy> bak
19:15:15 <vishy> I was carrying my laptop open so it didn't disconnect and I managed to hold in the power and hard reboot it
19:15:22 <vishy> FAIL
19:15:47 <comstud> epic fail!
19:16:01 <jbryce> i might take a stab at updating some of the wiki pages about blueprints
19:16:15 <jaypipes> vishy: we were just discussing that your explanation of th eblueprint process (and that someone doesn't *have* to use blueprints) was a good explanation.
19:16:15 <jbryce> joshuamckenty_: last chance before we move on to next topic if you've got any remaining questions
19:16:28 <joshuamckenty_> I'll mail em
19:16:34 <joshuamckenty_> Driving
19:16:43 <jbryce> haha...focus on that then
19:16:49 <jaypipes> yes, please :)
19:16:54 <joshuamckenty_> Tnx
19:16:58 <jbryce> #topic openstack-common
19:16:58 <ttx> jbryce: keep me posted, I'll help
19:17:04 <vishy> jaypipes: thanks, that helps.  I lost scrollback
19:17:08 <jbryce> ttx: thanks...i'll definitely want you to review
19:17:14 <jaypipes> notmyname: here?
19:17:24 <notmyname> indeed
19:17:35 <jbryce> we had some good discussion on the list already around this
19:17:42 <jaypipes> notmyname: cool, just wanted to make sure you were here for the openstack-common discussion..
19:17:46 <vishy> so i think the discussion on the ml was that openstack-auth should be separate
19:17:54 <jaypipes> ++
19:18:21 <vishy> so i think there is a good potential start for openstack-common which is prep for splitting out NaaS and Vaas
19:19:02 <vishy> so we can start moving some common nova code there that will be shared by the services
19:19:06 <jaypipes> vishy, notmyname: do we agree that openstack-common is the place to put duplicated "utility" code and stuff like common WSGI handling code, etc?
19:19:10 <jbryce> besides the specific items, does everyone think the PTLs co-manage openstack-common makes sense?
19:19:27 <vishy> it doesn't get us that far when it comes to glance/burrow/swift, but at least it starts getting some visibility
19:19:53 <ttx> jbryce: I think it's OK. If they disagree they should call the PPB to decide.
19:19:59 <vishy> jaypaipes: yes
19:20:03 <jaypipes> vishy: so, should we just propose pieces of code for openstack-common?
19:20:11 <vishy> jbryce: yes i think it will get its own ptl eventually
19:20:31 <jaypipes> vishy: on the ML or just to the PTLs? (I would prefer the main ML, I think)
19:20:55 <jbryce> ++ for ML
19:21:56 <notmyname> it's not clear to me if the proposed -common project is for smaller subprojects or more or a common code library
19:22:09 <jaypipes> notmyname: the latter I believe.
19:22:13 <jbryce> notmyname: i think the latter
19:22:27 <notmyname> vishy: ? same view?
19:22:39 <dendrobates> i agree
19:22:53 <jaypipes> notmyname: for "smaller common subprojects", could you elaborate? an example?
19:23:11 <vishy> jaypipes: I think it going to have to be one big move on the nova-side to support the split of NaaS and VaaS
19:23:15 <vishy> I made a blueprint for it
19:23:37 <notmyname> not sure I have one yet, but I think it would be things like the start of the auth projects. they would eventually grow to need their own structure, but could start in a -common project
19:23:56 <notmyname> basically, anything that is an internal service that all projects can use
19:23:57 <jaypipes> vishy: sorry, are you talking about openstack-cmmon stuff?
19:24:06 <notmyname> perhaps stats or map/reduce tools
19:24:10 <notmyname> log processing, etc
19:24:11 <ttx> vishy: note there already is a "NaaS project" BP, maybe that duplicates it ?
19:24:31 <jbryce> jaypipes: he's talking about splitting out some things that are in nova that would be shared by compute, network and volumes and putting it in -common
19:24:36 <ttx> notmyname: config file parsing / options processing ?
19:25:17 <jaypipes> notmyname: I would say if the project has some standalone service, it would go into its own project, but if it is only *library* code that can/should be used by all projects, it would go into openstack-common. I would say log processing would go into openstack-common, but a map-reduce project would be a separate project?
19:25:27 <jaypipes> jbarratt: ah, sorry.
19:25:31 <notmyname> ttx: those are less stand-alone, so I would say no (using the model of subprojects vs code library)
19:25:58 <jaypipes> #agreed
19:26:29 <ttx> notmyname: oh right
19:26:36 <jbryce> ok...let me see if we've got consensus around a proposal here
19:26:57 <jaypipes> notmyname, vishy: there's a lot of code (usually found in files called util.py) that is duplicated across the projects. Those would be a good first start I think?
19:27:44 <jmckenty> jaypipes and vishy - without being the crazy guy to point out the elephant, doesn't this drift back into the "coding standards" discussion that stalled openstack-common the first time?
19:27:49 <notmyname> my opinion on a -common project is a place for smaller projects that can stand alone but aren't (or aren't yet) complex enough to need their own governance structure. IMO, -common should be a place where these smaller things can live without neglect from not having PTLs etc
19:27:58 <jaypipes> jmckenty: yep. ;)
19:28:17 <jmckenty> notmyname: I would try and avoid cramming the "incubator" projects (DUPLO) into common
19:28:27 <jmckenty> but I agree we need a "common" area for them
19:28:31 <vishy> notmyname: if that is the case, we need a different place to put shared code
19:28:47 <jmckenty> I like the semantics of -common for shared libraries
19:28:49 <ttx> jmckenty: +1
19:28:49 <jbryce> openstack-common will be made up primarily of library code that may be used by multiple projects. initially, it will be co-managed by the other projects' PTLs who will determine the best options for inclusion and the process for code acceptance. at some point, it will make sense for openstack-common to have its own PTL.
19:28:59 <jmckenty> and -duplo for subprojects that aren't yet distinct
19:29:35 <jaypipes> jmckenty: DUPLO?
19:29:41 <jmckenty> but really, -duplo projects are still going to have their own repos, right?
19:29:52 <vishy> jmckenty: right
19:29:53 <jmckenty> ah, sorry. DUPLO is big, baby lego
19:30:04 <jaypipes> heh, ok.
19:30:07 <jmckenty> if openstack == lego, openstack incubation == duplo
19:30:12 <jaypipes> gotcha :)
19:30:20 <ewanmellor> Couldn't we have "incubator" projects just stand on their own?  A map-reduce project, for example, can just live on Launchpad/github somewhere.  It doesn't need to be openstack- anything.
19:30:30 <jaypipes> jmckenty, vishy: yes, I would assume DUPLO projects would get their own repo entirely
19:30:33 <ttx> yes, I expect -duplo projects to be separated when they start. And lead by their original PTL untli they get their own
19:30:33 <jmckenty> right, that's what I meant
19:30:55 <jmckenty> so back to -common
19:30:56 <jbryce> i think incubation and common are distinct
19:31:04 <jbryce> yes
19:31:08 <ttx> for example, vish would lead a separated "volumes" projetc until it gets its own PTL, but it would have its own repo as soon as it's split
19:31:18 <jmckenty> can we agree that PPB can own -common as far as coding standards?
19:31:26 <jaypipes> notmyname: OK, so would you go along with openstack-common being for common library code, not stand-alone projects?
19:31:36 <jmckenty> and we can hope that those standards would drift back into the distinct projects as well go along
19:31:41 <vishy> ttx: yes but splitting is a challenge unless we have  a place to put common code
19:32:04 <vishy> does openstack-volumes import nova to get shared files such as manager.py / service.py etc.?
19:32:17 <vishy> or do we put it into openstack-common?
19:32:27 <jmckenty> I think it goes into common
19:32:40 <ttx> vishy: both options are valid. I'd prefer it to go to -common ultimately
19:32:41 <jmckenty> but that means we need to prioritize any merge prop related to -common
19:32:48 <jmckenty> so that we don't block multiple projects
19:32:51 <vishy> my thought is that we put it into common and nova / NaaS / VaaS imports it
19:32:53 <jmckenty> er, subprojects
19:32:55 <jaypipes> vishy: I would prefer that code that is shared go into openstack-common, I mean that's what it was intended for. The issue is going to be agreeing on the coding standards and style of code that goes in there :)
19:33:19 <jaypipes> vishy: that was precisely the intent of openstack-common, yes.
19:33:33 <jaypipes> so, from openstack.common import logging...
19:33:42 <vishy> jmckenty: i think the subprojects can subclass / override common code so they don't have to be blocked
19:33:56 <jmckenty> right, I meant factoring OUT the common code
19:33:59 <jmckenty> to make it available
19:34:06 <vishy> ah right
19:34:12 <ewanmellor> And also we'll have to be stricter on the interface for things like manager.py.  The interface to that probably isn't well enough defined to be split out yet.
19:34:28 <jmckenty> that's a tough Order of Ops problem
19:34:50 <vishy> ewanmellor: all this stuff is vital to prepare for separate projects though
19:34:53 <jmckenty> we need to factor it out first, so we can start prototyping against it in multiple projects, so we end up with the right data points on what the interface needs to be
19:35:09 <ewanmellor> vishy: I agree entirely.
19:35:12 <jmckenty> but of course, we'll have more points of impact if we change it later
19:35:35 <vishy> we also need good tooling to make it easy for devs to work with multiple projects
19:35:35 <vishy> something like svn-externals
19:35:51 <jmckenty> Can I suggest stronger version promises for openstack-common
19:35:52 <jmckenty> ?
19:35:57 <jaypipes> OK, so can we agree on a process for getting stuff into openstack-common? Do we just use merge proposals?
19:36:13 <jmckenty> e.g., rather than supporting just a few versions back, we need to support at least <N>?
19:36:19 <vishy> so I have a blueprint for this work, but the scope is a little undefined at the moment
19:37:01 <jmckenty> vishy: I think something like externals is a first step, but I can feel the arguments for paste building...
19:37:06 <ttx> jaypipes: who is responsible for the -common merge proposals ? All -core teams combined ? A subgroup of interested dudes ?
19:37:31 <dendrobates> I vote for all -core teams
19:37:41 <jmckenty> ttx: I would vote for just PPB for the time being
19:37:44 <jaypipes> fine by me.
19:37:49 <jaypipes> either way.
19:37:49 <jmckenty> all of -core is a lot of developers
19:38:08 <jmckenty> I think arguing over the standards bit will be easiest with a subset
19:38:27 <ttx> jmckenty: yes that's what I was thinking.
19:38:30 <jaypipes> well, it's the developers who will have to use and be comfortable using the code in openstack-common. The last thing we want is people bitching about the code in a common library.
19:38:40 <jmckenty> but maybe go to all of -core if it's disputed?
19:38:40 <dendrobates> if we limit the group too much, reviews will be hard to come by
19:38:59 <jmckenty> hence my proposal that they get bumped in priority
19:40:00 <jaypipes> how about this: goes to PPB devs. If not a consensus agreement, throw it to ML for discussion on best practice/code style?
19:40:10 <ttx> or maybe, two approvals including one PPB review ?
19:40:18 <jmckenty> ttx: +1
19:40:48 <jmckenty> With a goal to document the approved coding standards and turn it back over to -core within 3 releases?
19:41:18 <jaypipes> sure
19:41:23 <jaypipes> sounds like a plan.
19:41:38 <ttx> right, I don't expect the standards to become an issue after a few cycles
19:41:43 <jbryce> member:openstack-common will be made up primarily of library code that may be used by multiple projects. initially, it will be co-managed by the other projects' PTLs who will determine the best options for inclusion. at some point, it will make sense for member:openstack-common to have its own PTL. code will be accepted using the standard merge proposal process with a requirement of 2 reviews including at least one from a m
19:41:43 <jbryce> of the PPB
19:42:03 <jbryce> ?
19:42:12 <vishy> yes,  and we can use the design summit discussion to scope the initial move of code / tooling and select a team to start working on it
19:42:40 <jaypipes> #agreed
19:42:41 <jmckenty> I would amend co-managed to be by the PPB, rather than just PTLs, only so that we have a good mechanism to talk about -common support of upcoming subprojects
19:42:48 <jmckenty> but I'm not attached
19:43:02 <jbryce> i'm ok with that amendment if there aren't other objections
19:43:09 <ttx> #agreed
19:43:10 * jmckenty can get vishy to represent for the disenfranchised
19:43:19 <jmckenty> #agreed
19:43:31 <ewanmellor> #agreed
19:43:34 <jbryce> dendrobates, notmyname?
19:43:38 <ttx> having the PPB manage it is more coherent with the approval rule
19:44:00 <notmyname> thinking
19:44:00 <dendrobates> I'm fine with it.
19:44:56 <jbryce> notmyname: that's a lot of thinking
19:45:05 <notmyname> heh
19:46:03 <jbryce> last call for objections
19:46:04 <notmyname> I'm not a big fan of -common as a shared code library, but if that is what the consensus is, the above proposal is good
19:46:07 * jmckenty plays jeopardy music
19:46:48 <jbryce> well...it does seem to be the consensus for now
19:46:56 <jmckenty> notmyname: you can +0 it
19:46:59 <jmckenty> or even -0 it
19:47:12 <jmckenty> and then later you can say I told you so
19:47:52 <jbryce> we can also change the charter later or address shared services in some better way
19:48:07 <jbryce> #agreed openstack-common will be made up primarily of library code that may be used by multiple projects. initially, it will be co-managed by the PPB who will determine the best options for inclusion. at some point, it will make sense for openstack-common to have its own PTL. code will be accepted using the standard merge proposal process with a requirement of 2 reviews including at least one from a member of the PPB
19:48:19 <jbryce> #topic coordination between other open initiatives
19:48:27 <jbryce> so jmckenty....want to lead this one?
19:48:46 <jmckenty> yup
19:48:58 <jmckenty> So I met with the Nimbus, OpenNebula and Globus folks
19:49:12 <jmckenty> and told them that I thought their projects were the walking dead
19:49:22 <jbryce> haha
19:49:25 <jmckenty> and that they should join forces with OpenStack before we made them irrelevant
19:49:26 <ttx> jmckenty: you know how to please them.
19:49:33 <jbryce> i have a hard time imagining you saying something like that, josh
19:49:39 <jmckenty> So they're very interested in collaborating
19:49:54 <jmckenty> I showed a chart comparing the number of users in IRC, the number of commits, etc
19:49:58 <jmckenty> it was compelling
19:50:23 <jmckenty> So they'd like to figure out how to work with openstack without giving up their individual branding
19:50:26 <jmckenty> and, hence, their funding
19:50:49 <jmckenty> There are some logical points of collaboration, particularly the new subprojects
19:51:01 <jmckenty> e.g., NaaS, the queue service, some of the unified auth proposals, etc
19:51:29 <jmckenty> I also see possibilities with MapReduce / computable object store, or some of the distributed filesystem support (Sheepdog, ceph)
19:51:58 <dendrobates> I have talked to opennebula and eucalyptus about collaborating on NaaS, they are interested.
19:51:59 <jmckenty> so the thinking was, to put together some guidelines for "ambassadors" to these other projects
19:52:01 <notmyname> ttx: these are some of the issues that I was thinking of when I was talking with you the other day about release processes. I think these issues are related
19:52:29 <jmckenty> Open questions:
19:52:39 <jmckenty> 1. Do the relevant organizations need to join OpenStack?
19:52:40 <ttx> notmyname: how ?
19:52:51 <jmckenty> (E.g. Argonne or Fermi Labs, John Hopkins, Notre Dame, etc)
19:53:09 <jmckenty> 2. License compatability
19:53:26 <jmckenty> My bias is that all openstack projects should continue to be Apache2
19:53:38 <jmckenty> which precludes wholesale donations of code, but so be it
19:54:00 <ewanmellor> Does it preclude donations from all of those people?
19:54:05 <jmckenty> no
19:54:10 <jmckenty> just some
19:54:21 <ewanmellor> Do you know which ones?
19:54:33 <jmckenty> I'd have to go back through the list
19:54:34 <notmyname> jmckenty: agreed on licensing
19:55:07 <jmckenty> 3. Can the PPB recommend commercial partners without getting into a tricky position?
19:55:26 <jmckenty> E.g., can I tell Argonne to talk to Dell and RCB about a test cloud using OpenStack?
19:55:42 <jmckenty> 4. Our relationship with the OCC and the Science Data Cloud project
19:56:05 <jmckenty> I'm going to bring up the OCC again next week when we're talking about governance,
19:56:23 <jmckenty> especially since they're getting ready to switch the Science Data Cloud to OpenStack
19:57:05 <jmckenty> But it may be a lot easier for these organizations to structure any type of cloud collaboration within the OCC (where they're already members, and which is perceived as 'neutral' to the different projects)
19:57:15 <jmckenty> Is that workable for us?
19:57:16 <notmyname> ttx: we can discuss at the summit (don't want to get off track here)
19:57:23 <ttx> notmyname: ok
19:57:50 <jaypipes> jmckenty: #agreed
19:58:53 <jbryce> jmckenty: that's a lot...
19:58:59 * jbryce thinking like notmyname
19:59:16 <jmckenty> Basically, item 4. is a more general question of "How do we make it easy for academic organizations to join/participate?", and "Should we take advantage of the OCC for it?"
19:59:28 <jmckenty> I'm happy to defer this to the in-person meeting next week
19:59:34 <jmckenty> just wanted to put it under everyone's hat
20:00:00 <jbryce> yeah...we're up against our hour anyway
20:00:09 <jbryce> let's defer to next week and think about it in the meantime
20:00:10 <ewanmellor> Could you give me that list of potential academic collaborators again?
20:00:39 <jmckenty> two secs...http://opencloudconsortium.org/members/
20:00:46 <ewanmellor> I will ask the "how do academic orgs collaborate" question of a few people at Cambridge U who've done this many times before.
20:01:04 <jmckenty> Plus Notre Dame and Fermi Labs
20:01:29 <jmckenty> jbryce: sounds good
20:01:52 <jmckenty> actually, can we get a quick show of hands of who'd like to be involved in this?
20:02:07 <jmckenty> if it's much less than the full PPB, we can make a working group and it'll make scheduling easier
20:02:18 <jbryce> i'm interested
20:03:10 <ewanmellor> Me
20:03:31 <jaypipes> jmckenty: sure
20:03:38 <jbryce> ok
20:03:48 <jbryce> #topic next meetings
20:04:10 <jbryce> is there a time that works for doing an in person meeting at the design summit?
20:04:35 <jmckenty> Something involving beer?
20:04:38 <jbryce> i know the summit sessions are already packed in, so yanking everyone out for an hour during the day may not be ideal....
20:04:50 <ttx> jbryce: beer o clock, one of those days ?
20:04:51 <jbryce> jmckenty: that's what i'm thinking
20:04:56 <jmckenty> The breakfast meeting last time was rough to get everyone to on time
20:05:02 <dendrobates> yeah, evenings are best
20:05:02 <jbryce> yep
20:05:10 <jmckenty> there are three sponsored parties, which night is free so far?
20:05:27 <jbryce> not sure any night is free
20:05:38 <jbryce> but we might just squeeze in some time before a party
20:05:43 <ttx> the wed night is mostly free
20:05:55 <dendrobates> parties are optional in my book, we can always arrive late
20:06:02 <jbryce> wed works for me
20:06:43 <jbryce> we'll plan for wednesday evening
20:07:17 <jbryce> and then for our regular time, does anyone have a pref for moving from 2000 UTC thursdays?
20:08:03 <ttx> I'd prefer 1900 UTC, any day but Tuesday.
20:08:55 <ttx> is this every week or every two weeks ?
20:08:59 <jmckenty> every week
20:09:02 <ttx> ok
20:09:08 <jmckenty> unless there's nothing on the docket
20:09:11 <notmyname> I'd prefer 1900 UTC
20:09:18 <jmckenty> I'm fine with 1900
20:09:18 <jaypipes> no objections from me.
20:09:25 <jbryce> ok
20:09:31 <jbryce> works for me
20:09:33 <jbryce> i'll send a note out
20:09:33 <ttx> cool.
20:09:39 <jmckenty> doublecool
20:09:44 <jbryce> that's all i've got
20:09:46 <dendrobates> one last thing
20:09:56 <jbryce> #topic open discussion
20:10:15 <dendrobates> Rackspace is sponsoring a mini NaaS summit on Monday before the summit
20:10:25 <dendrobates> it will be in the summit hotel.
20:10:42 <dendrobates> I just wanted to make sure everyone knew about it.
20:11:00 <jmckenty> I didn't
20:11:05 <dendrobates> All the parties are going to try and agree on a starting point
20:11:07 <jmckenty> time and date?
20:11:22 <jmckenty> e.g., room and start time
20:11:31 <dendrobates> Erik Carlin in planning it
20:11:36 <jmckenty> k
20:11:40 <dendrobates> It is monday, that is all I know
20:11:40 <jmckenty> that's Easter Monday, right?
20:11:45 <dendrobates> yep
20:11:53 <dendrobates> I complained about that
20:11:55 <jmckenty> I've got children who will be all sugared up
20:12:03 <jmckenty> will see what I can do
20:12:14 <dendrobates> me too.  I will be arriving late to the meeting.
20:12:17 <jbryce> jmckenty: bring the kids
20:12:37 <ttx> my plane arrives monday evening, so will miss it
20:12:43 <jbryce> ttx: mine too
20:12:46 <jbryce> anyone have anything else?
20:13:16 <ttx> nope.
20:13:23 <jmckenty> not for now
20:13:46 <jbryce> thanks guys
20:13:52 <jbryce> see you all in a week
20:13:58 <jbryce> #endmeeting