20:03:02 <jbryce> #startmeeting
20:03:03 <openstack> Meeting started Tue Sep  6 20:03:02 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:03:22 <soren> Wait, what? http://wiki.openstack.org/Governance/PPB?action=diff&rev2=58&rev1=57
20:03:50 <soren> Oh, Keystone and Dashboard. Duh.
20:04:06 <jbryce> yes
20:04:17 <notmyname> this means we have a larger quorum now?
20:04:23 <jbryce> soren are you interested in staying on the lists?
20:04:51 <soren> jbryce: Interested, yes, but take me off anyway.
20:05:07 <jbryce> notmyname: probably something we should determine. quorums aren't always a majority but that was what we had used from the beginning
20:05:48 <johnpur> 14 members now?
20:06:02 <jbryce> soren: i don't have a problem with leaving previous members on as "emeritus" members. you're all likely to have good input (like creiht) even if you're not actively voting
20:06:06 <jbryce> johnpur: correct
20:06:23 <johnpur> sounds like 8 for a quorum
20:06:30 <soren> Can we update the PPB page to denote how people are members? ("PTL for X", "Elected (expires XX)" "appointed")
20:06:50 <johnpur> soren: +1
20:06:53 <mtaylor> ++
20:06:54 <jbryce> i'll just copy the governance version
20:07:01 <jbryce> once i finish it. = )
20:07:19 <mtaylor> jbryce: no! copy it before you finish it!
20:08:04 <soren> I think it's really confusing to have the openstack-poc team have members who aren't on the PPB.
20:08:42 <pvo> o/ sorry. got pulled away for a sec
20:09:07 <johnpur> should we tell pvo the penalty for being late?
20:09:27 <pvo> I buy the next round?
20:09:33 * jk0 hopes it has to do with buying rounds of drinks at the next summit
20:09:37 <jk0> :P
20:09:59 <jaypipes> ok, nine minutes in... shall we get to the agenda?
20:10:43 <jbryce> #topic API proposal
20:10:46 <jbryce> http://wiki.openstack.org/Governance/Proposed/APIManagement
20:11:22 <jbryce> jorgew updated it based off the meeting last week
20:11:44 <vishy> jbryce: weren't we going to do a vote on who owns apis first?
20:12:38 <vishy> as in 1) project owns apis and guidelines. 2) project owns apis and ppb owns guidelines. 3) ppb owns apis and guidelines
20:12:39 <jbryce> i think it's kind of encompassed in this. ppb owns basic overall guidelines (whatever we determine those to be) and projects own all the details of the api for their software
20:13:20 <vishy> jbryce: can we vote on that first, before we address jorge's specific breakdown?
20:13:35 <jorgew> That's already discussed here: http://wiki.openstack.org/Governance/Model
20:13:36 <jbryce> sure
20:13:47 <jbryce> #info VOTE: Pick one: 1) project owns apis and guidelines. 2) project owns apis and ppb owns guidelines. 3) ppb owns apis and guidelines
20:14:00 <ttx> 2
20:14:01 <jbryce> #2
20:14:05 <mtaylor> 2
20:14:22 <notmyname> 1
20:14:31 <jaypipes> 2
20:14:32 <pvo> #2
20:14:39 <jk0> #3
20:14:42 <jk0> #2, sorry
20:14:51 <creiht> jk0: newb :)
20:14:53 <johnpur> 2
20:15:07 <vishy> 2
20:15:45 <jaypipes> to be clear, "guidelines" refers to the recommendations about the API structure only, right? jmckenty last week alluded to style guidelines being the purview of the PPB, which I do NOT agree with...
20:15:55 <vishy> are we missing jmckenty and anotherjesse?
20:15:58 <jbryce> #agreed Projects own their own API, PPB owns guidlines; 8 in favor, 1 in favor of project owning api + guidelines completely
20:16:17 <jbryce> vishy: looks like it
20:16:25 <vishy> jaypipes: defining the guidelines is the next discussion, but I agree that they should be very light guidelines
20:16:30 <jbryce> jaypipes: i think we can define what that means
20:16:31 <vishy> and ewan as well :(
20:16:40 <johnpur> i thought it sounded a bit quiet today...
20:16:45 <jaypipes> jbryce: k
20:16:59 * jaypipes goes back in hole.
20:17:16 <jbryce> ok
20:17:35 <jbryce> so...now that we agree on #2, how do people feel about the proposal as a more detailed explanation of #2?
20:18:18 <pvo> seems the sticking point last week was the role of the api guide
20:18:29 <mtaylor> jbryce: do we get to nitpick language here - or are we just approaching the overall idea?
20:18:36 <pvo> the 'api coordinator'
20:19:11 <vishy> i'm not totally sold on the idea of an api coordinator, but I don't think we want the ppb to be debating every api guideline individually
20:19:14 <jorgew> pvo: Moved api-gudline/draft stuff  of the proposal
20:19:19 <johnpur> i may have issues with the following: When a release enters the QA/soft feature freeze stage, the API Coordinator will verify that the API Guidelines have been followed. If they have not, and cannot be corrected before the release is branched, the non-conformant portions of the API will be placed into a separate namespace (to be determined by the API Coordinator), and the following warning will be prepended to its document
20:19:19 <jaypipes> jbryce: I'd like more detail on the expectations of when the PTLs are required to liaise with the coordinator on proposed new API additions/changes
20:19:37 <jbryce> mtaylor: i don't mind nitpicking but i like to start with the broad ideas generally
20:19:44 <mtaylor> jbryce: great
20:20:17 <johnpur> my concern is that we don't want to be jerking the consumers of the API around, particularly at the late stages of a release cycle.
20:20:23 <mtaylor> johnpur: ++
20:20:33 <jorgew> jodnpur:  That deals with handling the problem of a timed release before the coordinator has had time to ensure the guidelines are followed — this can be avoided
20:20:35 <jaypipes> jbryce: I withdraw my last comment... failed to read the penultimate paragraph fully...
20:21:43 <johnpur> it makes more sense to be proactive, in that an API is not made "available" until it is in "compliance"
20:22:11 <jorgew> johnpur:  I agree, but not sure how to handle that with time releases
20:22:12 <jbryce> some of it comes down to what the role of the api coordinator is? enforcer or advisor?
20:22:27 <jorgew> end of the day the PTL may decide not to ship the API
20:22:37 <jorgew> and avoid the message
20:22:54 <ttx> jorgew: we could have an API freeze at some milestone
20:22:56 <jaypipes> jorgew: the issue is whether other projects have coded against that API or not...
20:22:58 <johnpur> and screw anyone who has developed against the interim api
20:23:02 <jaypipes> ttx: +++
20:23:11 <jorgew> jbryce:  PPB is the enforcer end of the day.
20:23:29 <jorgew> ttx: I like that idea
20:23:40 <johnpur> ttx: sounds like that is a good idea
20:23:55 <mtaylor> ttx++
20:24:10 <ttx> jorgew: note that all freezes can get exceptions
20:24:19 <ttx> but that's what they are then -- exceptions.
20:24:28 <jorgew> jaypipes:  I think that's a good point. We need to distinguished between an API that's done and one that isn't
20:24:49 <jbryce> i'd almost rather just leave it up to the ptl. like notmyname says...if we just mention this and discuss issues as they come up it will usually work out.
20:25:10 <jorgew> jaypipes: so if somene integrates with an API that's not done then beware — that's the point of the message anyway
20:25:23 <ttx> then we can have projects consumed (think Glance or Keystone) freeze APi sooner than consumers (Nova, Swift)
20:26:02 <jaypipes> jbryce: but if Swift changes its API halfway through the release series, I code something to that API, then the PTL decides to drop that new API stuff, that presents issues... (just using Swift as an example, notmyname, nothing personal!)
20:26:26 * creiht notes that jaypipes always uses swift for bad examples ;P
20:26:32 <jaypipes> creiht: :P
20:26:38 <johnpur> like we mentioned last week, it is not reasonable to assume that folks are coding against the latest official release... there probably isn't any serious work being done against a cactus platform right now
20:26:40 <jaypipes> creiht: and good examples, too, btw :)
20:26:51 <jorgew> jaypipes: I would encourage projects to integrate on full releases — rather than inteurm ones — that was in my old proposal.
20:27:29 <ttx> johnpur: I agree that paragraph sounds a bit like "if we discover too late we fucked up, we just change the API at the very last minute"
20:27:32 <johnpur> jorgew: then no-one would be using Keystone right now, right?
20:27:46 <jaypipes> jorgew: the problem lies in when core projects need to integrate with incubated ones (think: Keystone). That integration must occur prior to integration freeze, otherwise all the functionality involved in the integration of the incubated project will be experimental..
20:27:54 <jbryce> the way that gets fixed is the same without or without ppb override though. we have to talk where we integrate.
20:27:54 <jorgew> johnpur:  We've never had a full releaso of compute.  Consider that when we get 1.1 out all of Rackspace will be using it — so that makes it a good target for devs even if we're working on 2.0
20:28:27 <soren> jorgew: Er.. What?
20:29:06 <ttx> soren: I think he means "compte API"
20:29:13 <mtaylor> if the guidelines are published though - an API being in non-compliance by release time should be a pretty weird abberation ... I mean, I don't expect vish to just completely ignore the API guidelines and then scramble to fix it all at the end
20:29:13 <ttx> compute*
20:29:21 <jorgew> jaypipes:  I agree there need to be extceptions, but  eventually you get to a stable API and you can integrate to that
20:29:29 <jbryce> mtaylor: ++
20:29:37 <jorgew> soren: yea I mean compute
20:29:59 <soren> ttx: We've not had a release of openstack that offers the full openstack compute api 1.1.
20:30:04 <jbryce> if we publish guidelines (which again are probably going to be pretty broad) i'm not too worried about rogue ptls ignoring it all
20:30:08 <vishy> mtaylor: have you been reading my ToDo list?
20:30:10 <soren> We *have* released an Openstack compute api 1.1
20:30:17 <soren> And we *have* release openstack compute.
20:30:22 <jaypipes> OK, let me throw out a situation that is going to happen in the first few months of the Essex release series as an example...
20:30:32 <creiht> we have rogue ptls?
20:30:35 <soren> Just sayin'.
20:30:55 <jaypipes> We are splitting the unified API endpoint into a segregated registry and image mover API in Glance. This is a backwards-incompatible change.
20:31:27 <jorgew> jaypipes:  Not sure I understand?
20:31:29 <devcamcar> beating an old horse, but the openstack api was dropped on us with little regard for what capabilities actually existed in nova
20:31:30 <jaypipes> When should we "finalize" such a backwards incompatible change with the API coordinator? Also, when should the cutoff for reversing such a decision be?
20:32:07 <johnpur> jaypipes: isn't this an argument for versioning?
20:32:13 <jaypipes> jorgew: trying to discuss these things with a concrete example of something I *know* is coming shortly...
20:32:25 <jaypipes> johnpur: we already have versioning.
20:32:46 <jbryce> jaypipes: what is in or not in the api is up to the ptl. the guidelines and adherence to them is probably not going to deal with individual features that may not be backwards compatible
20:32:54 <johnpur> the new incompatible API needs to be versioned up, and the old api needs to be supported
20:32:56 <jaypipes> johnpur: but we need to discuss after what point in the release series that backwards incomptaible changes to an API can  be made..
20:33:05 <jbryce> following versioning might be
20:33:16 <jorgew> jbryce: +1 the coordinator doesn't deal with individual features
20:33:22 <jorgew> in the API
20:33:24 <johnpur> jaypipes: got it
20:33:29 <jaypipes> that's really not what I'm asking :)
20:33:37 <jaypipes> I'm asking what that cutoff date/point should be!
20:33:53 <jbryce> jaypipes: if you follow the guidelines to version and support the old version, you can cutoff whenever you want
20:33:56 <ttx> jaypipes: I'm not sure we need to encode the freezes in the Api coordinator job description
20:34:14 <jorgew> jaypipes:  I think that's up to the coordinator, PTL to nagotiate — probably with some input from the PPB.  I don't think we can come up with a rule that fits all cases
20:34:43 <ttx> jaypipes: it's definitely something to discuss, for example at the summit
20:34:44 <johnpur> jaypipes: and a good question that is! i would expect that the changes would be finalized and complete by ttx's api freeze at the latest
20:34:53 <jaypipes> jbryce: OK, but Nova will be consuming *some* version of the Glance API, and when should we cut off changes to a dependent API to allow Nova to stabilize on something... I guess that is what I am asking.
20:35:20 <ecarlin> the reality is, until an api contract version is final and stable (which should happen at a release), it is subject to change.  there is a level of risk when integrating with non-release apis.  services that leverage each other and want to take advantage of new functionality may want to do that, but they need to coordinate with the consumed service PTL closely.
20:35:23 <jaypipes> jbryce: or is the decision "decide among PTLs with advice from the API coordinator"?
20:35:32 <jbryce> jaypipes: that's what i'd prefer
20:35:37 <jaypipes> jbryce: k, thx.
20:35:44 <johnpur> jaypipes: but only an issue if nova is dependent on new functionality, else they can use the downlevel version
20:35:48 <jaypipes> jbryce: sorry, just wanted some clarification on that
20:35:50 <ecarlin> versioning provides a stable contract even when non-backwards compatible features are introduced
20:36:01 <johnpur> if they rely on the new version, the pyls have to coordinate
20:36:18 <johnpur> s/pyls/ptls
20:36:22 <jorgew> jonhnpur: right!
20:36:51 <jaypipes> OK, I think I have a good understanding of the proposal now. Thanks for the clarifications.
20:37:03 <jbryce> so...circling back around...where does that leave us with johnpur's question about this point?
20:37:45 <jorgew> sorry, which point?
20:37:51 <johnpur> jbryce: combining mtaylors and ttx's responses may answer the point
20:38:06 <notmyname> so the PTLs coordinate how their respective project work together. and the devs are the ones actually doing the coding. so what problem is the API coordinator solving that makes it worth the extra complexity, bureaucracy, and overhead?
20:38:18 <ttx> jbryce: I think that end of paragraph should be removed
20:38:29 <johnpur> having an api freeze in the cycle, along with PTL's that are not rogue, we shouldn't get into the situation that is described
20:39:12 <ttx> notmyname: if I understand correctly, the API coordinator is there to bitch about Api guidelines and consistency, a bit like the Release Manager is tehre to bitch about release dates.
20:39:12 <johnpur> agree with ttx.
20:39:14 <ecarlin> shouldn't when to freeze the api contract be up to the PTL?
20:39:39 <jorgew> ttx:  Right!
20:39:42 <notmyname> ttx: about which we've had many "discussions". and probably more and this coming summit :-)
20:39:57 <johnpur> ecarlin: i think the ptls can use some guidance
20:39:58 * mtaylor looks forward to that
20:40:11 <ttx> notmyname: indeed -- that's why I wouldn't encode anything in te API coordinator job description
20:40:17 <jorgew> ecarlin:  Yes, but they should coordinate with the API guy
20:40:34 <ttx> notmyname: as the process / dates / etc. should be discussed at every summit.
20:40:50 <ttx> s/discussed/revised/
20:40:53 <ecarlin> sure, but it seems like each service may move at different paces and we should embrace that.  the only requirement is to have a stable contract at the release
20:40:55 <jorgew> ttx: Right and they should be open, documented, and testable
20:41:23 <ecarlin> it might behoove a service to freeze earlier (e.g. keystone) but the ptl would know when that makes sense
20:41:23 <jorgew> at least the processes and guidlines, goals
20:41:24 <johnpur> ecarlin: don't make me slap you with a trout! we just went over that!
20:41:55 <ecarlin> i like fish :-)
20:42:10 <jbryce> if we remove this section from the last paragraph, is this a proposal that we want to vote on:
20:42:12 <jbryce> "When a release enters the QA/soft feature freeze stage, the API Coordinator will verify that the API Guidelines have been followed. If they have not, and cannot be corrected before the release is branched, the non-conformant portions of the API will be placed into a separate namespace (to be determined by the API Coordinator), and the following warning will be prepended to its documentation:
20:42:12 <jbryce> This is a work in progress; the API this specification describes is not stable, and may disappear or change in incompatible ways in future releases."
20:42:30 <jbryce> or does anyone have more to discuss about it?
20:42:57 <jaypipes> jbryce: I am ready to vote on it as-is.
20:43:04 <johnpur> i still have problems with that
20:43:27 <ttx> johnpur: even when it's removed ?
20:43:28 <jbryce> johnpur: MORE problems? = )
20:43:46 <notmyname> ttx: so we are adding another gatekeeper?
20:44:04 <jorgew> jbryce: I wouldn't remove it all together.  Need to make sure that guidlines are adhered to at some point in time for relarase.  And that there's a process to handel stuff when they are not
20:44:05 <ttx> notmyname: I'd rather say "advisor"
20:44:11 <notmyname> like the release manager (who has control over when stuff gets released) this adds another gatekeeper over what gets released
20:44:11 <johnpur> it needs to be clear that the apis have a defined freeze point in the release cycle, at which point other services and developers can count on the api for the release
20:44:15 <devcamcar> so who exactly will be the API coordinator?
20:44:20 <notmyname> ttx: can the advice be ignored?
20:44:32 <johnpur> and it won;t be randomly changed or removed
20:44:37 <creiht> do we need a gatekeeper for the gatekeepers?
20:44:38 <jbryce> devcamcar: we'd decide that after we decide to have one or not
20:44:41 <notmyname> devcamcar: and how chosen and recalled and for what term?
20:44:54 <ttx> notmyname: "The design and specification of a project's API is controlled by its Project Technical Lead"
20:45:03 <jorgew> johnpur:  I live that idea
20:45:29 <ttx> notmyname: I guess if the PTL repeatedly ignores the guidelines, he exposes his project to the wrath of the PPb
20:45:46 <jbryce> johnpur: to me that sounds like a guideline to be added to the set of guidelines rather than something for the overall proposal of having guidelines
20:46:04 <jorgew> jbryce:  Like that even better :-)
20:46:11 * jbryce wonders if creiht used to watch a lot of mystery science theater 3000
20:46:20 <johnpur> jbryce: ummm, ok
20:46:26 <ttx> notmyname: that said, I'm not sure the proposal will pass :)
20:46:37 * vishy nominates creiht to be the api coordinator
20:46:39 <johnpur> but we need to removed the offending language, right?
20:46:45 <creiht> awww
20:46:46 <creiht> :/
20:47:04 <creiht> I was hoping johnpur would get nominated, he seems pretty passionate about it :)
20:47:18 <notmyname> I was hoping we wouldn't have one ;-)
20:47:46 <creiht> well that too :)
20:47:47 <johnpur> i totally bequeath my api role to creiht, he will be awesome!
20:47:59 <jaypipes> notmyname: I would say "advisor", too. PTLs are responsible for their projects only. The API coordinator should be thinking about consistency and integration across ALL OpenStack projects.
20:48:05 <jbryce> johnpur: i removed that section from the last paragraph
20:48:13 <johnpur> jbryce: thx
20:48:20 <notmyname> jaypipes: but can they be ignored? because if not, then it's not really and advisor
20:48:29 <jaypipes> huh?
20:48:43 <jaypipes> an advisor is an advisor. they advise. they don't dictate.
20:49:26 <jorgew> notmyname:  It's the PPB that has the power over api-consistency at the end of the day
20:49:27 <pvo> jaypipes: ++
20:49:46 <ttx> jorgew: over "consistency" in general.
20:49:57 <notmyname> if it's only advisory, why does there need to be a role for an appointed person?
20:49:58 <jorgew> ttx: right
20:50:11 <notmyname> jorgew: I disagree. I don't think the PPB has power over the API
20:50:28 <notmyname> it's not a power that we should vote for ourselves to have
20:50:39 <johnpur> maybe the role should not be "appointed" by taken on by a community member that is passionate about this?
20:50:44 <jorgew> notmyname:  It needs to be someones job…just like we have release managers and doc coordinators ect.
20:50:56 <soren> notmyname: If the PPB can delegate it, it must hold it to begin with.
20:50:57 <jbryce> you don't think there's any value in having some consistency between projects?
20:51:15 <notmyname> I think there is value in consistency
20:51:16 <creiht> the ppb doesn't designate who the release manager or doc coordinators are
20:51:32 <johnpur> jbryce, you just sent us into recursion from last week's meeting!
20:51:35 <devcamcar> i guess the question is - do we think we're inconsistent now? is this role being created to "fix" something?
20:51:42 <devcamcar> trying to understand scope
20:51:46 <notmyname> but I think that is achieved by people talking to one another, not an official role
20:51:58 <soren> creiht: Indeed. That doesn't mean it shouldn't, though.
20:52:11 <creiht> so why should it then?
20:52:19 <soren> creiht: Who else should?
20:52:30 <jbryce> notmyname: i think there's value in writing down what the people talking to one another agree to and making it available to new projects and the developers across projects
20:52:58 <notmyname> jbryce: that certainly doesn't rise to the level of someone's job
20:53:00 <jbryce> and users who have these apis as their main contact point with the software
20:53:01 <johnpur> jbryce: we should vote, and also schedule time at the DS for further discussion
20:53:42 <creiht> soren: I dunno, but these types of positions seem to magically appear periodically :)
20:53:42 <jbryce> #info VOTE: Should we approve that API process proposal: http://wiki.openstack.org/Governance/Proposed/APIManagement
20:53:54 <notmyname> johnpur: further discussion after a vote?
20:53:58 <soren> creiht: Yes. I think that's a problem.
20:54:00 <ttx> creiht: or predate the PPB itself
20:54:17 <johnpur> notmyname: there are a lot of details to work out
20:54:35 <creiht> how can you vote on something that is lacking a lot of details?
20:54:55 <johnpur> creiht: you get Erik's trout slap!
20:55:07 <jaypipes> what details need to be worked out? :(
20:55:18 <jbryce> jaypipes: the actual guidelines
20:55:24 <devcamcar> maybe we should vote on whether the API coordinator should be nominated by PPB or a community member like release management?
20:55:37 <jaypipes> jbryce: yes, but that's not what we're voting on...
20:55:40 <devcamcar> seems that there is a lot of debate around that
20:55:53 <jorgew> The guidlines should be developed seperately
20:55:55 <jbryce> creiht: i'd love to know every detail before making every decision, but it doesn't seem like it works out that way usually.
20:56:11 <jaypipes> jbryce: we're voting on whether to proceed with a process whereby the PPB votes on guidelines for API development/maintenance and whether someone should have the role of being the API coordinator.
20:56:18 <jbryce> jaypipes: correct
20:56:19 <johnpur> we are setting policy, not deciding every detail
20:56:40 <jaypipes> jbryce: ok. I stand by my earlier statement that I am ready to vote on that. :)
20:56:58 <notmyname> johnpur: no, the PPB seems to be in the business of implementation, not guidelines
20:57:09 <pvo> notmyname: I don't see that
20:57:15 <jbryce> jaypipes: i like your summary
20:57:16 <jorgew> notmyname:  That's not the intent
20:57:28 <jorgew> PTL owns inmplementation
20:57:39 <notmyname> release dates, workflow, tools, now apis?
20:57:41 <johnpur> a separate discussion/vote can be taken on whether the API coordinator is "appointed" or a community member with a desire
20:57:42 <ttx> 3min left
20:57:43 <devcamcar> jorgew: but not design?
20:58:01 <jbryce> let's try this one more time
20:58:10 <jaypipes> notmyname: how has Swift followed the "release date implementation" that the PPB has supposedly "enforced"?
20:58:10 <jorgew> devcamcar:  And design — coordinator only ensures inter-projcet consistency
20:58:18 <ttx> tbh, usually the work starts first, the person gets influence and then uses that influence to get traction from PTLs
20:58:22 <jbryce> #info VOTE: should the PPB set basic guidelines for APIs across projects
20:58:23 <jorgew> and overall guidlines
20:58:34 <jaypipes> yes.
20:58:37 <creiht> jaypipes: they tried not to, then were told to stop by the chair of the ppb
20:58:44 <creiht> err tried to follow
20:58:47 <johnpur> +1
20:58:49 <devcamcar> +1
20:58:52 <ttx> here we are talking about nominating someone, rather than let random API-concerned community members gather influence on the subject
20:59:01 <mtaylor> +1
20:59:06 <jbryce> +1
20:59:08 <jaypipes> +1
20:59:09 <jk0> +1
20:59:16 <ttx> +1
20:59:22 <pvo> +1
20:59:34 <notmyname> -1
20:59:40 <jaypipes> creiht: really? seems to me that Swift has set their own release schedule.
20:59:45 * creiht sighs
20:59:48 <notmyname> jaypipes: really
20:59:57 <creiht> jaypipes: after the autonomoy discussion they did, and were told not to
21:00:12 <jbryce> #agreed PPB should set basic guidelines for APIs across projects. 8 +1, 1 -1
21:00:14 <creiht> ask ttx
21:00:14 <ttx> creiht: I haven't seen change in that area yet.
21:00:20 <jbryce> we're out of time
21:00:31 <creiht> ttx: you and notmyname were in discussions to do that, then were told not to by jbryce
21:00:37 <creiht> with the whole autonomby
21:00:39 <creiht> thing
21:01:05 <jbryce> #endmeeting