20:02:45 <jbryce> #startmeeting
20:02:46 <openstack> Meeting started Tue Jul 19 20:02:45 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:02:56 <jbryce> agenda - http://wiki.openstack.org/Governance/PPB
20:03:10 <jbryce> jmckenty: are you around?
20:04:17 <jbryce> jmckenty added the trademark topic but i'm not sure exactly what he wanted to discuss around it so we'll move on
20:04:35 <jbryce> #topic Revisit project autonomy / project philosophy discussion
20:05:23 <jbryce> i sent an email out after the meeting a few weeks ago about the philosophy vote we had taken
20:05:33 <jmckenty> hi
20:05:37 <jmckenty> back, sorry I'm later
20:06:26 <jbryce> i think the 2 statements we chose between weren't particularly clarifying to come up with an overall philosophy
20:06:37 <jmckenty> do you have some alternate?
20:06:48 <johnpur> jbryce: instead of rehashing the topic can we boil it down to the core issue/decision to be made?
20:07:33 <ttx> jbryce: I think it was great progress to clarify we want a single product rather than a collection of products
20:07:40 <jmckenty> +1
20:07:47 <johnpur> agree
20:07:48 <ttx> jbryce: that doesn't mean it's the answer to life and everything
20:08:11 <jaypipes> ttx: 42.
20:08:14 <jmckenty> wow
20:08:43 <ttx> so we can further precise what we mean by "single product, made of independant but cooperating subprojects"
20:08:54 <ttx> if there are areas where clarification is needed
20:08:59 <ttx> is there ?
20:09:08 <jmckenty> well, I think there are two related statements
20:09:40 <jmckenty> the first is that subprojects should use common frameworks, tools, policies and practices whenever possible
20:09:51 <jmckenty> to support a single cohesive community
20:10:00 <jbryce> i think the core question is should every openstack project be identical in all aspects (processes, tooling), free to make all decisions on their own, or somewhere in the middle
20:10:00 <jbryce> my opinion is somewhere in the middle and i feel like our decisions to date have basically been along those lines
20:10:00 <creiht> what defines "whenever possible"?
20:10:01 <jbryce> so then the harder thing to specify is what should be shared across projects and where does the latitude come in
20:10:40 <notmyname> jbryce: I don't think your view of what was decided is the same as jmckenty/ttx
20:10:59 <jmckenty> can you clarify the difference
20:11:24 <johnpur> "whenever possible" == "do it the common way unless it is impossible to support the accepted community practices"
20:12:12 <mtaylor> (for instance - if the community practice is "write in python" but the project is "java openstack api implementation" ... then it would be impossible to fulfill "write in python")
20:12:27 <ttx> jbryce: I think we need a common set of tools. There can be some freedom of choice amongst a set of vetted options, though
20:12:33 <vishy> definitely somewhere in the middle
20:12:35 <johnpur> mtaylor: right :)
20:12:50 <jbryce_> sorry guys...i'm having some weird internet connection problems
20:12:51 <ttx> jbryce: to me, independence should be about technical choices in the code, not in the tooling
20:13:11 <jmckenty> right, but I think going forward, the number of "not according to community practice" flags will likely become a gating function on inclusion in openstack
20:13:18 <jmckenty> for evaluation of incubation, etc
20:13:23 <jaypipes> johnpur: different people have different ideas of what is "impossible to support the accepted community practices". In any case, the root of the issue is that subprojects want the autonomy to develop, manage and review code the way they wish, regardless of whether the way they want to do it is common to other subprojects.
20:13:43 <jmckenty> I wouldn't say that all subprojects want that autonomu
20:13:49 <jbryce_> i agree with ttx on the importance of common sets of tools. especially for things where the audience is likely to span multiple projects
20:13:52 <jmckenty> I'd say that it's the topic of discussion
20:13:53 <ttx> jbryce: each project is free to write the code they feel is the most appropriate
20:14:02 <ttx> that's where the PTL rules
20:14:22 <jbryce_> ttx: i fully agree and i think everyone agrees with that on the code front
20:14:27 <jmckenty> ttx: I disagree
20:14:33 <jbryce_> or maybe not
20:14:33 * mtaylor would like to toss in that, given the work of maintainng divergent tooling, there should be a pretty good reason for the set of vetted options being above one in most cases - although he does agree that at times a set of more than one is actually appropriate
20:14:34 <jbryce_> = )
20:14:34 <ttx> if they decide to drop Carrot for Kombu, that's their choice, not ours to discuss
20:14:36 <jmckenty> I think there's an openstack-wide expectation of unit tests
20:14:47 <ttx> though we /should/ encourage smoe commonality where possible
20:15:19 <jmckenty> mtaylor: as a follow-on to that, I would like to push a discussion of CI/packaging responsibilities back onto the agenda for a future meeting
20:15:30 <jmckenty> specifically, relationship between RAX and OpenStack for CI, etc
20:15:33 <ttx> When the tooling is not appropriate, we can select a set of vetted options, like the GitHub case shows.
20:15:42 <ttx> Doesn't go as fast as some would like it to go, but it will happen
20:16:00 <jmckenty> E.g., I'm standing up independent CI environments so that I can do things that I can't do within the current environment
20:16:36 <jaypipes> jmckenty: perhaps you would come to the next openstack-ci meeting? It's tuesdays from 3pm-4pm EDT on this channel.
20:16:50 <ttx> jmckenty: We also happen to set minimal expectations on code quality, true
20:16:53 <jaypipes> jmckenty: anyways, for another day...
20:16:58 <jmckenty> it's tough for me to make that - I have a standing 12-1pm PST lunch meeting on tuesdays
20:17:05 <jmckenty> anyway
20:17:06 <mtaylor> jmckenty: yes- I would love to avoid the need for you to have to do that, and yes, we should talk about it at some point
20:17:08 <jbryce> after we had the philosophy discussion, we talked about vetted set of options. i like the vetted set (could be a set with only a single option) as the way to have tooling that all ties in but gives latitude to teams to choose something that fits in their workflow. but it seemed like there was debate about the vetted set
20:17:23 <jmckenty> are there additional resolutions we should consider?
20:17:36 <jbryce> ewan seemed in favor of a single option to limit the amount of retraining
20:18:23 <ewanmellor> jbryce: I'm definitely in favour of us choosing a single source control system, whichever it is.
20:18:30 <mtaylor> ++
20:18:34 <jmckenty> ++
20:18:36 * jaypipes in favour of a single solution so that the community can enhance a single platform instead of fracturing development time working on support for multiple platforms.
20:18:46 <ttx> Also there are areas that fall in the cracks, like versioning. Should we align Swift with the rest of OpenStack, for example
20:18:58 <jmckenty> versioning is separate from tools, though
20:19:02 <jmckenty> can we finish on tools first?
20:19:09 <ttx> I think we can discuss those areas separately when the need arises
20:19:26 <ttx> jmckenty: sure :)
20:19:28 <jbryce> ttx: i agree, but i want to make sure we have clarity on the philosophy
20:19:49 <jbryce> if the philosophy is all projects are identical, then those discussions are basically about making a single decision for every project
20:20:34 <ttx> jbryce: common tooling, freedom for technical choices, with some commonality/integration sense
20:21:16 <jmckenty> ttx: I think that freedom needs to be within some reasonable guidelines - e.g., python unless there's no way to do it
20:21:20 <johnpur> projects should try to align, unless there is a valid reason not to (and "because i want to do it differently is not a valid reason)
20:21:20 <ttx> with "common" potentially meaning a set of PPB-vetted options.
20:21:23 <jmckenty> but generally yes
20:21:40 <ttx> jmckenty: sure, and we might need to more clearly defie those guidelines.
20:21:42 <ttx> define*
20:22:06 <jmckenty> my overall objective is to have as few technologies and as few tools involved as possible
20:22:15 <mtaylor> ++
20:22:21 <jmckenty> I have only 7 developers, and we're working on everything
20:22:46 <jbryce> so in terms of autonomy, openstack will have default tooling and processes that may include a vetted set of options that projects should use unless there is a pressing requirement to go outside of the established choices?
20:22:48 <jmckenty> obviously from a security standpoint, fewer technologies == smaller strike surface
20:22:52 <johnpur> jmckenty: agree, let's keep it as simple and scalable as possible
20:22:54 <jaypipes> what is good for OpenStack as a whole?
20:23:06 <jaypipes> that is the question, no?
20:24:07 <johnpur> with the understanding that being non-standard is a potential barrier to incubation/core status
20:24:11 <ttx> jbryce: what do you need to see clarified exactly ? Did he discussion already provide you the answer ?
20:24:12 <jaypipes> jbryce: I think that is a good summary, yes.
20:24:38 <ttx> the*
20:24:40 <jbryce> ttx: the problem is the previous statement gave no direction on if projects have any latitude to be different
20:25:25 <ttx> jbryce: I think your definition is good. The "pressing requirement" should potentially be challenged by the PPB.
20:25:45 <ttx> jbryce: as in "you're kidding, right ?"
20:25:59 <johnpur> ttx: :)
20:26:03 <mtaylor> ++
20:26:14 <jmckenty> ttx: can I add a suggestion?
20:26:37 <jmckenty> that we also suggest that the PTL formalize a bit the mechanism that they're proposing such an exception
20:26:43 <jmckenty> e.g., do a project-internal vote
20:26:44 <jbryce> up to this point, ppb exceptions have been the mechanism for non-standard things
20:26:46 <jmckenty> or a design summit session
20:26:49 <ttx> i.e. the PPB decides tooling for core projects. If they walk out of the path, they better have a good reason or we'll force them back in ?
20:27:44 <jmckenty> well, again I'd like to point out that having separate dev teams for swift and nova, while it's the RAX way, is probably going to be the exception in other organizations
20:28:02 <ttx> jmckenty: so you'd rather have them ask before they differ ? Rather than being different and then challenged ?
20:28:25 <jmckenty> I think it'll save churn
20:28:28 <jaypipes> jmckenty: lots of RAX devs work on Glance, Nova and Keystone at the same time...
20:28:52 <ttx> jmckenty: I think the latter is simpler, because projects don't necessarily know when they abuse their relative independence
20:28:56 <notmyname> jmckenty: and lots of companies have deployed swift independently of nova etc
20:29:15 <jmckenty> notmyname: most of those that have, though, have plans to add nova to their roster
20:29:20 <jmckenty> inap, kt, etc
20:29:29 <ttx> jmckenty: if they are being different but nobody in the PPB cares enough to raise the issue, it's probably alright to be different
20:29:39 <jmckenty> fair nuff
20:30:11 <jbryce> ok
20:30:25 <ttx> In particular, projects should be free to add new tools in areas where we don't set any standard
20:30:31 <johnpur> ttx: the issues will be at the tooling, packaging, technology areas... it will be obvious where the ppb will care i think
20:30:38 <ttx> I don't want them to be limited to our choices
20:30:56 <ttx> and then, their choice is well set to become the standard
20:30:57 <jbryce> i think i'm going to try to take points of this discussion and add them to the previous one-line statement to see if we can publish something that clarifies project relationships and the stance on autonomy with projects
20:31:00 <jmckenty> Can I start a wiki page of things I worry about?
20:31:09 <creiht> so should the ppb define how "viable options" are vetted?
20:31:10 <jmckenty> e.g., pinning to Python 3 features,
20:31:15 <mtaylor> can I also suggest that when the vetted list of tools is made, each list item gets an abstract description as well, so it's clear what a tool is there for? for instance "the project has decided it wants a gate trunk and a patch queue manager" makes the tooling implementing that make more sense?
20:31:20 <johnpur> ttx: and we need to be open to evolving the openstack set
20:31:30 <creiht> there has been very little visibility in to the vetting of github for example
20:31:32 <ttx> johnpur: sure
20:31:54 <jbryce> github or the tooling around github?
20:31:56 <jmckenty> I'd also like to look at pushing more of the PPB meetings out to the community blog, etc
20:32:00 <jbryce> github is probably a little bit of a special case as so many people are already familiar with it and many wanted to move to it
20:32:04 <creiht> jbryce: both
20:32:19 <ttx> creiht: I agree -- and popularity contest at design summits may not be the best way
20:32:27 <spectorclan_> jmckenty: i can help on blog stuff
20:32:33 <creiht> since it was just recently announced that it will be github + gerrit
20:32:50 <creiht> didn't see much in the way of community input there
20:33:03 <mtaylor> well... a) I agree with creiht
20:33:23 <jmckenty> Can I propose that we put packaging and CI into the openstack-common project
20:33:28 <jbryce> #action jbryce to put together a more detailed project autonomy statement and process for vetting options
20:33:29 <ttx> I also don't think the whole thing was handled particularly well.
20:33:39 <mtaylor> but b) I think the topic was so contentious from the get go, that most discussions around it quickly became completely useless - but it should be addressed and solved for the future
20:33:40 <johnpur> maybe i am slow, but when did gerrit come in?
20:33:48 <jaypipes> mtaylor: ++
20:33:49 <jmckenty> and then look at core team membership, voting, etc
20:34:07 <mtaylor> jmckenty: well, we've got openstack-ci project ... do you want to move CI?
20:34:22 <jmckenty> mtaylor: that way we can isolate it from a whole-community discussion, to relevant and interested parties
20:34:33 <jaypipes> johnpur: it was identified as a solution to the problem that GitHub's pull requests don't have sufficient statuses to meet existing review policy/process.
20:34:37 <jbryce> we've kind of transitioned into the next topic
20:34:39 <jmckenty> I was suggesting including CI, packaging, source control, etc. as a single project
20:34:39 <jbryce> #topic Review progress on GitHub integration
20:35:19 <notmyname> we did kinda skip over the versioning issue. (but IMO it's the same as the tooling)
20:35:20 <mtaylor> jmckenty: yeah - that's what the ci team meeting is there for - we could certainly add a mailing list (packaging is the only thing that isn't currently officially handled in the ci related stuff)
20:35:44 <mtaylor> jmckenty: and we're doing our best to start rolling out docs and the like to get folks more involved in that effort
20:35:50 <jmckenty> Is the GitHub stuff being addressed by the -ci team?
20:35:52 <jaypipes> mtaylor: can you give an update on the github progress, please, including blockers.
20:35:53 <mtaylor> yes
20:35:57 <jmckenty> ah, k
20:36:37 <ttx> notmyname: that's my view as well -- but I'd comply if the group decided otherwise.
20:36:54 <mtaylor> so, currently we've got a gerrit server up and going, have migrated the openstack-ci related code to being managed by it (eating our own dogfood first to make sure it works) and are currently in the process of getting keystone onboarded
20:37:39 <mtaylor> the tentative rollout plan is - use keystone as initial guinea pigs, then migrate a few other smaller projects (like glance) and sort out showstoppers, etc.
20:38:01 <mtaylor> once that's happymaking - then we can look at the projects with larger sets of devs, like nova
20:38:09 <mtaylor> mainly because ...
20:38:39 <jmckenty> we had 1500 commits last month on nova?
20:38:40 <jmckenty> :)
20:39:01 <mtaylor> there are a few issues that jeblair and I are working on fixing/writing code for that will slightly alter workflow, but with the smaller teams of devs re-communicating those workflow changes is less of a pain point
20:39:17 <ttx> mtaylor: so Glance would migrate from bzr to git, right ? Since LP/bzr is one of the "options", does that mean the Glance PTL decided to move to git ?
20:39:18 <mtaylor> the current todo list issue that we want to get done before migrating nova is:
20:39:35 <ttx> (trying to see the process a project must follow to move from one "option" to another)
20:39:39 <mtaylor> ttx: it does ... and I would at some point like to bring up the continuation of lp/bzr as an option
20:39:48 <jaypipes> ttx: very few Glance contribs want to move to GitHub/git, but we will follow the recommendations of monty and jim.
20:39:58 <mtaylor> but I think that's perhaps out of scope for right now
20:40:20 <jbryce> any questions around gitub progress, tooling?
20:40:30 <jmckenty> just scope
20:40:34 <jaypipes> ttx: it's more important to be on a common infrastructure than personal preference for a set of tools.
20:40:40 <jmckenty> we're moving code and review process, correct?
20:40:45 <jmckenty> but not issues
20:40:45 <mtaylor> jmckenty: yes
20:40:49 <mtaylor> jmckenty: yes.
20:40:53 <jmckenty> cool, thanks
20:41:05 <jmckenty> Can we backport dashboard as well?
20:41:08 <jmckenty> it's already on github
20:41:13 <mtaylor> I'd love to
20:41:16 <jmckenty> but not with gerrit
20:41:28 <johnpur> to jmckenty's earlier point, with smaller teams that are cross functional it would be really good if the projects had common repos, workflows, etc.
20:41:30 <mtaylor> I would really love to get all of the 'smaller' projects and/or things that are already on github looped in
20:41:38 <jmckenty> We need to get it into the official openstack account
20:41:46 <jmckenty> right now there's a piston fork, and a 4p fork
20:42:02 <ttx> jaypipes: I agree that if at one point all core projects happen to be on the same "option", the continuation of the other "option" should be questioned.
20:42:02 <jaypipes> jmckenty: yup.
20:42:07 <mtaylor> oh - speaking of that ... there's a policy thing I want to bring up regarding the official openstack account ... would now be the right time?
20:42:27 <jmckenty> yes please
20:43:04 <mtaylor> so - github does not have an option to remove push access from owners of an org ... but we have a project policy of gated trunks
20:43:17 <jaypipes> right.
20:43:22 <jmckenty> who are the org owners?
20:43:22 <mtaylor> I would like to remove all of the regular dev accounts (mine and jim's included) from the owner list of the org
20:43:29 <jmckenty> create another team?
20:43:46 <mtaylor> and have special accounts that can be used if actual org owner bits are needed - mainly to prevent accidental pushing
20:43:50 <eday> So, not to be a pain, but back after we decided to give this a shot, we were going to put up a demo and let the wider community vote on the choice of gh/lp. it sounds like we're just moving everything without that vote. Did I miss the decision to not do that, or...?
20:43:51 <jaypipes> mtaylor: shouldn't jenkins be the only owner of the trunk repo/branch?
20:44:09 <notmyname> jmckenty: mtaylor jeblair termie and myself
20:44:12 <jmckenty> jaypipes: I would add one special admin account
20:44:13 <mtaylor> jaypipes: yes. that's exactly the point I'm making - it's how to implement that
20:44:30 <jmckenty> in case the whole CI infrastructure is broken
20:44:35 <jmckenty> and we need to hot fix
20:44:41 <jmckenty> although I guess we can change the teams at that time
20:44:49 <jmckenty> eday: a valid point
20:45:06 <mtaylor> well, we were talking about adding a special admin/owner account for each person who should be allowed to log in to the website and make owner-level changes
20:45:06 <jmckenty> can we use keystone as that demo?
20:45:21 <mtaylor> the github team structure for repo ownership is actually quite sufficient to model the other things I belive
20:45:52 <ttx> eday: +1
20:46:28 <jbryce> jaypipes, mtaylor: do you have thoughts on eday's question about the gh/lp choice?
20:46:33 <jaypipes> mtaylor: ok, so do you have your answer?
20:46:43 <mtaylor> anyhow - I guess the thing is - does anyone have any objections to continuing to model the "jenkins" is the only one who can push approach
20:46:54 <jmckenty> nope
20:46:58 <mtaylor> great.
20:47:08 <ewanmellor> +1 to Jenkins being in charge.
20:47:10 <jmckenty> that commit gate is the best part about our CI infrastructure
20:47:12 <jaypipes> jbryce: about whether to put it to a community vote?
20:47:31 <mtaylor> jbryce: I hear eday -and I think that what jmckenty said about keystone being the POC is pretty good
20:48:17 <mtaylor> I wonder if there is really much need in an actual formal community vote at this point though - what _exactly_ they would be voting on, and whether it would just bring up more vitriol or not
20:48:39 <johnpur> jmckenty: +1
20:48:44 <jmckenty> we should probably do subproject-by-subproject votes
20:48:44 <ttx> mtaylor: the PPB should decide to add (or not add) github+gerrit as an "option" for code hosting
20:48:51 <heckj> Better to be open and deal with the potential vitriol about the change.
20:48:55 <mtaylor> ttx: yes. I believe that vote should happen
20:49:08 <ttx> mtaylor: once the POC proves the benefit of that option.
20:49:13 * mtaylor wasn't saying no voting - just wanting to be clear about what was being assessed
20:49:19 <jmckenty> ttx: how low for the POC - 5 days?
20:49:24 <jmckenty> low == long
20:49:48 <jaypipes> jmckenty: why? isn't the point that the subprojects disagree and that this whole discussion is about whether subprojects have the choice to do what they want or not?
20:50:19 <ttx> jmckenty: I'd like to see a few review activity before making my mind... so if there is sufficient activity in those 5 days, maybe
20:50:38 <mtaylor> can I suggest a slight alteration...
20:50:51 <jbryce> i think the ppb should vote on adding github+gerrit as a source code option based of a review of keystone as the poc
20:50:56 <jbryce> at that point, it's up to the individual projects
20:51:11 <jbryce> if the POC is ready and there's activity, we could add that on the agenda for next week
20:51:36 <jaypipes> jbryce: fine by me
20:51:56 <jmckenty> +1
20:52:01 <jbryce> 8 minutes left. more discussion on this or do we want to tackle one of jmckenty's other topics?
20:52:04 <johnpur> +1
20:52:10 <mtaylor> ok. yes. so it may be ready for a vote next week - or the week after (depending on how the testing actually goes - I'm sure there will be a few hitches we want to address after it gets some usage)
20:52:12 <ttx> mtaylor: when will keystone be POCed ?
20:52:40 <mtaylor> ttx: as soon as their devs actually sign up for accounts... we're waiting on them right now
20:52:46 <jbryce> mtaylor: let us know when it's ready to be evaluated
20:52:52 <jmckenty> The academic discussion we can push to email for now - bascially, several organizations have offered PhD students and potentially money to work on OpenStack R&D
20:52:55 <mtaylor> we could alternately make jaypipes the test case
20:53:14 <mtaylor> jbarratt: will do
20:53:20 <mtaylor> damn completion
20:53:22 <mtaylor> jbryce: will do
20:53:42 <jmckenty> Just wanted to see if it makes sense to divide the "Community" from simply "Companies" to a few classes of participating entities
20:53:50 <jaypipes> mtaylor: that's fine if you want. bcwaldon, dprince, blamar and myself will give feedback to you on a Glance move to github.
20:53:50 <jmckenty> and if the PPB as a whole is the right group to coordinate that,
20:53:53 <jbryce> #topic openstack trademark
20:53:58 <ttx> jmckenty: which asks the question of the setup of an independent body financed by a set of contributor companies
20:54:10 <jmckenty> wasn't going there yet
20:54:18 <jbryce> ha
20:54:25 <mtaylor> jaypipes: ok. I'll chat with jeblair about that - you guys might actually be a better source of feedback from a POC perspective
20:54:29 <ttx> jmckenty: if they offer money, that money needs to go somewhere.
20:54:33 <jmckenty> in fact, I still think we should use the OCC for that if necessary
20:54:54 <jmckenty> it's already running OpenStack, and already a 501(c)3 dedicated to cloud computing
20:54:59 <jmckenty> plus, they're friends
20:55:04 <jmckenty> and NASA is already a member
20:55:08 <jmckenty> which is VERY hard to do
20:55:10 <jmckenty> with a non-profit
20:55:16 <creiht> OCC = Orange County Choppers?
20:55:22 <jmckenty> Open Cloud Consortium
20:55:27 <jbryce> jmckenty: can you put something together in an email on it?
20:55:31 <jmckenty> yes
20:55:38 <jmckenty> The Qatar Foundation is interested
20:55:41 <jmckenty> as a first org
20:55:49 <jmckenty> but obviously the USC guys have been very active
20:56:01 <jmckenty> K, trademark
20:56:04 <jmckenty> in 4 minutes
20:56:19 <jbryce> on the trademark, summary is the ppb doesn't have authority over the trademark but we can certainly make recommendations
20:56:20 <jmckenty> 1. We need something akin to the Xen "FITs" definition to gate the use of "Built on OpenStack"
20:56:23 <johnpur> my understanding is that the OpenStack Advisory Board is being set up (prior to the Essex DS) and that body will adrees these sorts of issues (not the ppb).
20:56:37 <jmckenty> that advisory board has been "real soon now" for 6 months
20:56:40 <jbryce> i think the area that really needs help is technical definition around requirements to be called openstack
20:56:42 <jmckenty> I don't believe in it anymore
20:56:48 <jmckenty> jbryce: exactly
20:56:50 <jmckenty> that's FITS
20:56:54 <jmckenty> Faithful Implementation
20:56:55 <johnpur> jmckenty: i still believe!
20:56:56 <jbryce> right
20:57:05 <spectorclan_> jbryce: this team should write the specs on FIT
20:57:14 <jbryce> i'd agree with that
20:57:20 <jmckenty> 2. We need some legal protection that the trademark policy can't be changed ad-hoc
20:57:31 <johnpur> jbryce: we should get some guidance here from the powers that be
20:57:38 <jmckenty> I'm building my business on the right to say "Built On OpenStack"
20:58:04 <spectorclan_> jmckenty: I can bring in RACK lawyers on this if you need to have a discussion
20:58:04 <jmckenty> I don't think that has to be as violent as granting the trademark to a third-party
20:58:14 <jmckenty> Let's have a proposal first
20:58:20 <jmckenty> lawyers slow everything down
20:58:31 <jbryce> jmckenty: i think that's a good piece of feedback
20:58:35 <jbryce> i will follow up on that one
20:58:50 <johnpur> also, next week i would like to bring up a topic of setting up working groups within OpenStack, one of which will be a legal working group to help with these sorts of issues
20:58:58 <jbryce> 1 minute left. does anyone want to volunteer to lead up an openstack FITs effort?
20:59:07 <jmckenty> I'll lead the charge on that
20:59:12 <jmckenty> Ewan, wanna play in?
20:59:17 <jmckenty> sorry, ewanmellor
20:59:18 <jbryce> #action jmckenty to send email on academic involvement and the occ
20:59:34 <jbryce> #action jmckenty to lead an openstack faithful implementation standard effort
20:59:53 <jbryce> thanks for the time everyone
21:00:08 <ttx> jbryce: great time management :)
21:00:12 <jbryce> #endmeeting