20:03:30 <ttx> #startmeeting tc
20:03:31 <openstack> Meeting started Tue Jul 28 20:03:30 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:34 <openstack> The meeting name has been set to 'tc'
20:03:35 <flaper87> edleafe: aww :(
20:03:38 <ttx> markmcclain: doh!
20:03:48 * flaper87 is back
20:03:48 <ttx> Our agenda for today:
20:03:52 <edleafe> flaper87: maybe he'll peek in at some point
20:03:57 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:04:06 <ttx> #topic Add Stackforge Namespace Retirement resolution
20:04:10 <ttx> #link https://review.openstack.org/192016
20:04:15 <ttx> I think we are getting nearer with the latest version of this resolution
20:04:23 <ttx> No more objections from my side... anyone else ?
20:04:40 <ttx> if not, review could use MOAR votes
20:04:54 <jeblair> ++votes
20:05:16 <sdague> +R
20:05:29 <ttx> 2 more and we can pass it in-meeting
20:05:44 <sdague> ok, so moving on? seems like votes can tally when they tally
20:05:58 * devananda lurks
20:06:09 <jeblair> btw, the pecan folks have decided to leave regardless of this (related to CLA issues and our platform support)
20:06:13 <ttx> sure
20:06:14 <jeblair> it's a friendly parting
20:06:32 <ttx> but we are at 7 so I guess we can approve it now
20:06:40 <sdague> I guess that's a question, does everything in openstack need CLA check box?
20:06:49 <jeblair> sdague: pecan actually does not
20:06:52 <jeblair> have it now
20:06:59 <sdague> jeblair: right, we never required it on stackforge
20:07:06 <jeblair> but it's pretty impossible to convey that to a contributor
20:07:08 <ttx> approved
20:07:16 <ttx> #topic Introduce the "deliverables" concept
20:07:20 <sdague> jeblair: I was more thinking after the namespace is gone
20:07:24 <dhellmann> jeblair: is it possible to activate a gerrit account without signing the cla?
20:07:24 <ttx> #link https://review.openstack.org/202583
20:07:31 <jeblair> sdague: ack dhellmann: yes
20:07:35 <ttx> I refreshed this one yesterday based on the current repository status
20:07:37 <flaper87> jeblair: cool!
20:07:41 <dhellmann> jeblair: ok, cool, I never tried :-)
20:07:42 <ttx> And added the related tooling changes so that it passes tests
20:07:50 <ttx> So it should be ready for adoption, before it gets into further merge conflicts
20:07:59 <ttx> (Note that I'll update the other changes that will get wedged by this change merging)
20:08:14 <ttx> so that would be great to mertge it now before it gets out of date again, if you agree with it
20:08:23 <dhellmann> ++
20:08:27 * flaper87 has no objections
20:08:28 <sdague> ttx: so... that seems like a giant list to be kept accurate by TC, I think my only concern is I'd like to figure out a way that we're not handling 4 updates to projects.yaml every meeting
20:09:00 <ttx> more updates to projects.yaml happen off-meeting
20:09:01 <dhellmann> I think we really only need to approve additions or removals to the list, right?
20:09:04 <lifeless> I'd like to make project based updates to project.yaml be single-+2A
20:09:23 <ttx> lifeless: they are "one week, no objection"
20:09:24 <sdague> like, what's there is fine, but I'm mostly not going to vote on random changes on project.yaml in the future
20:09:27 <lifeless> 'neutron added a repo' isn't something we conceptually vote on
20:09:28 <annegentle> sdague: yeah
20:09:36 <dhellmann> lifeless: we have to be careful, because adding repos == adding voters, and we want to make sure we're doing that appropriately
20:09:37 <ttx> lifeless: you don't
20:09:38 <lifeless> ttx: k
20:09:55 <jeblair> 
20:09:56 <jeblair> Once a project has joined OpenStack, it may create additional source code repositories as needed at the discretion of its Project Team Lead (PTL) without prior approval from the TC as long as the additional source code repositories fall within the scope of the approved project mission statement.
20:10:01 <jeblair> lifeless: ^ http://governance.openstack.org/reference/new-projects-requirements.html
20:10:03 <flaper87> didn't we agree on letting some of this addition mature for a week and approve without meeting if no objections were raised ?
20:10:10 <ttx> sdague: I actually handle most projects.yaml changes after letting them mature for a week unless there are objections
20:10:11 <lifeless> jeblair: yes, exactly
20:10:34 <ttx> (as long as the PTL approves it)
20:10:35 <sdague> ttx: so... can you tag all those procedural ones with ProceduralChange or something
20:10:41 <lifeless> jeblair: what I mean is that the land-the-metadata-change-mechanics shouldn't require multiple votes from the TC
20:10:42 <sdague> so that I can filter it out of my reviews
20:10:52 <ttx> sdague: tag them ?
20:10:55 <lifeless> jeblair: and it sounds like we've already established that
20:10:59 <sdague> add a thing to the commit message
20:10:59 <flaper87> ttx: commit-tag
20:11:19 <ttx> sdague: sure, I could do that
20:11:25 <jeblair> well, 202583 is worth voting on, right?  we're introducing a concept?
20:11:26 <sdague> ttx: cool
20:11:35 <ttx> jeblair: yes
20:11:37 <sdague> jeblair: yes
20:11:59 <lifeless> jeblair: yes, of course
20:12:01 <sdague> but now there is a ton of data in there, so I wanted to make sure keeping that data fresh is more expedited in the future
20:12:06 <jeblair> ttx, sdague: how about a topic so it doesn't require a patchset update?
20:12:19 <flaper87> jeblair: that works too
20:12:21 <sdague> anything I can build a gerrit filter for, I'm happy
20:12:22 <dhellmann> jeblair: ++
20:12:35 <ttx> jeblair: something like project-update
20:12:43 <sdague> mechanism unimport to me beyond that
20:12:47 <ttx> or not-a-vote
20:13:09 <ttx> #action ttx to pick a topic name to tag all things that don't require a formal TC vote
20:13:16 <sdague> ttx: thanks
20:13:25 <ttx> (a.k.a. "project list updates")
20:13:48 <ttx> sdague: we already had those, there was just no way to quickly tell them apart
20:13:59 <ttx> that will help with building the meeting agenda too.
20:14:04 <lifeless> sdague: devstack tags - how about 'internal/external' or someting ?
20:14:14 <ttx> lifeless: next topic
20:14:27 <lifeless> ttx: yes :)
20:14:30 <ttx> Since we generate a giant merge conflict with that one anyway, I propose we fast-track the alphabetical reorder
20:14:33 <ttx> #link https://review.openstack.org/#/c/206460/
20:14:44 <ttx> it's a no-vote change
20:14:56 <dhellmann> +1
20:14:58 <ttx> will approve now unless someone screams BAD IDEA
20:15:00 * flaper87 voted anyway
20:15:03 <lifeless> doit
20:15:14 <jeblair> good idea.  i'm pretty much just going to trust that's right.
20:15:19 <sdague> ttx: it would be good to add tooling to enforce it stats alphabetic later
20:15:35 <sdague> andreas did some of that for infra files
20:15:36 <jeblair> sdague, ttx: there's some tooling in project-config you can borrow
20:15:38 <ttx> sdague: good idea
20:15:44 <sdague> jeblair: yep ++
20:16:07 <ttx> #action ttx to rebase all current patches on top of his giant change
20:16:35 <ttx> there might be off-governance tooling that will be caught unaware of the projects.yaml format change. Let me know if you spot any
20:16:57 <dhellmann> there are a couple of scripts in release-tools, but I can fix those tomorrow
20:16:59 <ttx> fungi: the election roll tooling will likely need an update
20:17:13 <ttx> ok, next topic
20:17:14 <ttx> #topic Add devstack tags
20:17:18 <ttx> #link https://review.openstack.org/203785
20:17:19 <fungi> thanks ttx
20:17:22 <ttx> sdague: care to introduce this/these ?
20:17:53 <sdague> sure, so basically it seemed useful to actually annotate what projects have facilities to come up in devstack
20:18:03 <sdague> be it in the devstack tree, or via our published plugin interface
20:18:17 <sdague> the whole conversation started on the mailing list earlier this month
20:18:42 <annegentle> I like the integration:thing-its-integrating-with
20:18:54 <sdague> I think the tag(s) are pretty self explanatory, naming is a thing
20:19:13 <ttx> sdague: there is the open question of the value of having seperate tags for mainline and plugin
20:19:17 <sdague> yeh, integration: seems fine
20:19:36 <flaper87> would it be enough to just have devstack:plugin-name ?
20:19:48 <flaper87> instead of distinguishing between upstream/downstream
20:20:07 <ttx> based on the rationale ("Knowing which components are easily brought up in [devstack] environment") I'm not sure it needs the distinction
20:20:12 <sdague> flaper87: how would you tag keystone in that way?
20:20:14 <jeblair> so the one-tag variant is something like: "integration:devstack" says "this thing works with devstack", and if you want to know how, you can check the docs...
20:20:30 <flaper87> sdague: plugin-name would be whatever you use to enable it in devstack
20:20:31 <lifeless> I quite like that
20:20:39 <lifeless> do people actually ask about *how* ?
20:20:44 <ttx> jeblair: I fear that it puts pressure on devstack people to get things mainline, while we push the other way around
20:20:51 <sdague> flaper87: so, for nova, you don't have a single thing like that
20:21:05 <jeblair> ttx: oh, but "integration:devstack" applies to plugins too
20:21:09 <lifeless> as-in, do we negatively affect people if we don't document the plugin/included status ?
20:21:10 <flaper87> sdague: could we have one? AFAIK (please correct me) most projects do
20:21:14 <flaper87> s/we/it/
20:21:16 <sdague> honestly, specifying it's a plugin
20:21:23 <sdague> is kind of useful to people
20:21:31 <ttx> jeblair: right
20:21:35 <sdague> but, that's from a devstack support perspective
20:21:52 <sdague> and I also imagined who acks the patch is different in the 2 cases
20:22:09 <sdague> because project cores should be able to ack the fact that they have a bit now
20:22:30 <flaper87> I kinda think we should now have a repo to keep track of devstack plugins + urls (or something like that)
20:22:43 <lifeless> well
20:22:43 <dhellmann> how about one tag that means there is any form of integration, and another tag that says the integration is not built into devstack itself?
20:22:49 <flaper87> but that's basically what this tag is for
20:22:50 <annegentle> lifeless: the negative effect being what though?
20:22:52 <ttx> I could go either way
20:22:57 * flaper87 just thought this through a bit better
20:23:09 <lifeless> maybe devstack could lookup the repo based on the name and pull it in automagically. But thats a devstack dev question.
20:23:13 <lifeless> annegentle: well - like sdague said
20:23:38 <jeblair> lifeless: it just about already does that
20:23:56 <markmcclain> ttx: I've got to head out for a presentation... if a real time vote pops up today... dhellmann can proxy for me
20:24:07 <ttx> markmcclain: ack
20:24:16 * dhellmann gets out a second keyboard
20:25:06 <sdague> right, personally, I'd feel more comfortable if it was 2 tags because of the support question. Because the amount of devstack plugins exceeds the number of things in the devstack tree, and would like to prevent tears prematurely when people ask me why their opendaylight doesn't work in devstack (for instance)
20:25:25 <annegentle> "There's no crying in baseball!"
20:25:33 <annegentle> right sdague I see what you mean.
20:25:34 <ttx> If we get the plugins discoverable from devstack, I don't think the extra information saying "as a plugin" is worth it
20:25:48 <lifeless> but they aren't todau
20:25:53 <dhellmann> I see this as sort of parallel to the release tags, where we have a "managed" tag and several "model" tags
20:25:56 <lifeless> so lets refactor if/when it is
20:25:56 <sdague> right, but that then means that devstack needs to maintain an authoritative registry
20:26:09 <sdague> which, sort of goes against the whole big tent thing
20:26:18 <lifeless> sdague: well no - it could infer from the name
20:26:20 <sdague> I was actually trying to push this out to the edges
20:26:23 <sdague> lifeless: some times
20:26:23 <ttx> sdague: if it doesn't (or won't in the near future) then I agree that "as a plugin" is valuable piece of info
20:26:26 <flaper87> and which is part of what this tag tries to address
20:26:28 <dhellmann> so if there's an "integration:devstack" tag to indicate support at all, and then a "devstack:external-plugin" tag to indicate that the code doesn't live in devstack, I think we'd express everything
20:26:34 <jeblair> i'm just thinking back to the "tags replacing docs" thing, and documenting the specific mechanism you use to devstack something seems to have crossed the line from "new user browsing the software site" to "deployer actually trying to run commands"
20:26:41 <flaper87> I think it's a valuable info now
20:26:47 <flaper87> it might not be needed anymore in the future
20:26:54 <sdague> jeblair: maybe
20:27:02 <ttx> jeblair: yeah
20:27:04 <sdague> *a lot* of people bring up devstack to test things
20:27:21 <sdague> it's actually the first experience a lot of users have with openstack
20:27:32 <ttx> jeblair: maybe "there is a way to run in devstack" is enough as far as tags are concerned
20:28:03 <sdague> ttx and then when they ask "and that way is... "
20:28:06 <sdague> where do they go?
20:28:20 <annegentle> does devstack integration indicate any test integration?
20:28:30 <ttx> sdague: if they don't find it mainline, they look for a plugin?
20:28:39 <sdague> ttx: and how do they look for that?
20:28:40 <flaper87> the thing is that even when the 'as-plugin' info, they won't know exactly
20:28:47 <dhellmann> ttx: I'm not sure new users would know about plugins as a thing
20:28:47 <jeblair> annegentle: hopefully?  most of the projects with plugins should run devstack tests on them
20:28:48 <flaper87> because there are plugins outside repos anyway
20:28:54 <ttx> sdague: devstack:as-plugin doesn't exactly point to a repo either
20:28:55 <flaper87> I mean, devstack plugins in their own repos
20:29:03 <sdague> ttx: yes it does, it's the repo that's tagged
20:29:07 <annegentle> jeblair: ok
20:29:11 <dhellmann> sdague: if I was looking, frankly I would look at the devstack docs, so I wonder if there should just be a registry there
20:29:35 <ttx> sdague: is it ?
20:29:38 <sdague> ttx: yes
20:29:41 <annegentle> dhellmann: sdague: you could also look at the tag list and say, "Oh, I should work on devstack integration"
20:29:46 <sdague> sorry if that wasn't clear
20:29:53 <dhellmann> I'm not sure it's any more of a burden to keep the docs up to date than the governance list
20:29:53 * ttx reads deeper
20:29:54 <flaper87> sdague: how would that tag work for  https://github.com/openstack/devstack-plugin-zmq ?
20:30:00 * flaper87 confused now
20:30:00 <sdague> I'm so knee deep in this, I forget what people don't know
20:30:15 <dhellmann> annegentle: yeah, that's why I think it's useful to have an integration:devstack tag
20:30:39 <sdague> like openstack/trove => integration:devstack-plugin
20:30:44 <dhellmann> sdague: we just approved a patch that moved tags from repos to deliverables
20:31:08 <ttx> sdague: ok, I thought they might live in a specific repo, but if they are always bundled with the code... that works
20:31:23 <flaper87> how would that tag work for  https://github.com/openstack/devstack-plugin-zmq ?
20:31:24 <sdague> ttx: they can also live off in other repos
20:31:27 <dhellmann> sdague: is that always true? I thought the oslo.messaging stuff ended up in its own repository?
20:31:29 <lifeless> so is each neutron aas plugined separately?
20:31:38 <dhellmann> flaper87: right, that
20:31:39 <sdague> lifeless: yes, they will be
20:31:49 <ttx> sdague: then the tag applies to the devstack plugin ? or the code that has devstack integration ?
20:31:51 <lifeless> so this tag is going to be repo then, not deliverable
20:31:53 <flaper87> oslo.messaging has several drivers and plugins for each
20:32:00 <flaper87> these plugins live outside the repo
20:32:08 <ttx> lifeless: there are no such things anymore
20:32:08 <flaper87> and there's also an in-repo plugin, IIRC
20:32:12 <lifeless> ttx: and yet
20:32:38 <sdague> so, for stuff that lives outside the repo, I don't know. I was thinking about this in terms of "I want to use designate, does it come up"?
20:32:59 <ttx> lifeless: hence my question, I think the "has devstack integration" tag should apply to the thing that has devstack integration, which may be multiple repos
20:33:14 <ttx> not to the thing that contains devstack plugin code
20:33:16 <dhellmann> I understand that we need a registry of where those plugins are, but I'm starting to doubt that the governance project list is that registry.
20:33:34 <flaper87> I'd say, lets just say it has support for devstack for now and forget about the plugin bit until we find a good solution for that
20:33:41 <dhellmann> I like integration:devstack for the deliverable, and then more details in the deliverable docs or the devstack docs (or both)
20:33:44 <ttx> flaper87: ++
20:33:50 <dhellmann> flaper87: ++
20:33:50 <ttx> sounds like a good first step anyway
20:33:55 <lifeless> ttx: but neutron having devstack integration doesn't mean that all the aas's are enabled
20:33:58 <lifeless> for instance
20:34:11 <lifeless> so I guess I'm wondering if thats going to mislead
20:34:15 <sdague> ok, I'm fine just tagging the devstack in tree bits
20:34:23 <dhellmann> lifeless: right, figuring out how to express that is more than a tag
20:34:23 <sdague> that's a step 1
20:34:27 <ttx> lifeless: they should, otherwise publishing them as a single "thing" may be confusing anyway
20:34:35 <dhellmann> sdague: no, I think we want a tag that says "has some devstack integration" and does not distinguish here
20:34:43 <flaper87> dhellmann: ++
20:34:46 <sdague> ok, well I don't want that
20:34:55 <sdague> because of support issues
20:34:57 <lifeless> ttx: should doesn't make it actually happen though
20:35:13 <lifeless> so its seeming to me that either we need to bring back per repo tags
20:35:30 <ttx> lifeless: we could say the tag doesn't apply if only part of the deliverable gets devstack-integrated
20:35:32 <dhellmann> sdague: can that not be solved by documentation within devstack itself?
20:35:32 <lifeless> or find some other way of communicating what (I think) sdague wants to communicate
20:35:47 <dhellmann> sdague: i.e., list what is in tree, and describe how to find the out-of-tree stuff
20:36:20 <dhellmann> without making an exhaustive list ("look for a directory named foo" or "look at the contributor docs for the project")
20:36:27 <sdague> dhellmann: that then implies that it is the role of the devstack team to categorize the universe, vs. the project registry to be a place for information about that to be stored
20:36:44 <dhellmann> sdague: no, you only have to list the things you support in your tree, which you could do automatically
20:36:51 <flaper87> sdague: just tell people what's in-tree
20:36:55 <fungi> hrm, that means maybe we should remove the vulnerability:managed tag from, e.g., the neutron deliverable. it was applied to the openstack/neutron repo previously but not the other repos which just got glommed on today
20:36:59 <lifeless> sdague: is it possible to write an oracle that takes git tree in and returns 'has devstack plugin:TRUE|FALSE' ?
20:37:04 <jeblair> yeah, i also don't think that only tagging things in devstack is a good idea -- it could increase pressure (and of all the things we have discussed, that's the thing that could be _most_ served by a devstack-maintained list)
20:37:04 <flaper87> each project should do its best to let others know where to find the devstack plugin
20:37:05 <dhellmann> and then give general guidance for how to find the other stuff by directing them to ask the project team
20:37:29 <flaper87> if I need a plugin for X, I'd probably look in devstack -> project repo -> wherever the project repo tells me to go
20:37:32 <ttx> fungi: maybe the -*aas should be split if they are so different
20:37:35 <fungi> sort of sad i missed the implication of the deliverables discussion now
20:37:37 <sdague> lifeless: I could probably
20:37:45 <flaper87> that's something that the 'is-plugin' bit doesn't fix anyway
20:37:57 <sdague> lifeless: to a 95% accuracy at least
20:37:58 <lifeless> sdague: so I'm wondering if something could take teh repo list in, scan all the repos, and provide data back to governance (or wherever) automatically
20:38:06 <sdague> sure
20:38:07 <ttx> fungi: technically they were once in openstack/neutron and got split though
20:38:08 <fungi> well, thinking in terms of "tag only applies to a deliverable if all repos within the deliverable are covered" suggestion
20:38:21 <flaper87> lifeless: there are plugins outside repos that wouldn't be listed
20:38:21 <jeblair> ttx, fungi: i think the model is good; we probably need to reconcile whether we fix this by supporting more repos or saying that "neutron" isn't supported because it's so complex
20:38:26 <flaper87> unless they use submodules
20:38:32 <fungi> but similar concerns as qa will have with devstack support i think
20:38:37 <flaper87> or some sort of agreed listing model
20:38:44 <annegentle> jeblair: yeah that's the concern, complexity drowning
20:38:47 <sdague> right, qa will not support vpnaas
20:38:52 <lifeless> flaper87: would they be able to move to being in repos?
20:38:55 <sdague> but does support neutron
20:39:02 <sdague> if that is not an expressible thing
20:39:06 <sdague> that's kind of problematic
20:39:18 <flaper87> lifeless: in some cases, maybe. In other cases, it's unlike (vendor specific plugins)
20:39:20 <ttx> sdague: it is if we split neutron-*aas from the neutron deliverable
20:39:33 <sdague> I guess I also missed this issue on the deliverable side
20:39:34 <ttx> sdague: since it looks like it's a different "thing"
20:39:35 <jeblair> i think our side-track is getting side-tracked
20:39:53 <ttx> yep
20:39:54 <flaper87> jeblair: lol
20:40:00 <sdague> jeblair: sure, but I think this is part of the confusion about what kind of information shows up here
20:40:03 <ttx> OK, I suggest we give it some thought and comment on the review
20:40:04 <flaper87> ok, I think this need more work/discussion
20:40:08 <annegentle> agreed
20:40:10 <flaper87> I'll comment on the review with my thoughts
20:40:14 <flaper87> lets move on
20:40:16 <lifeless> flaper87: vendor specific plugin wouldn't be in vendor specific codebase?
20:40:21 <sdague> because things like upgrade modes get impacted as well
20:40:23 <ttx> no point is running for 10 more minutes in circles
20:40:27 * zaneb was bout to comment but will take it to the review
20:40:28 <fungi> well, applicability of previously per-repo tags is coming into question, so seems on-topic to the devstack tag discussion
20:40:48 <fungi> but agreed probably better in review
20:40:58 <ttx> #topic Add and apply guidelines for project and service names
20:41:00 <sdague> yeh, we can collect there, figure out what questions to ask for next week
20:41:06 <ttx> #link https://review.openstack.org/201160
20:41:07 <flaper87> lifeless: yes but they are still plugins that I might want to use and therefore I'd like to find easily. An automated tool would ignore those plugins. For example: https://github.com/openstack/devstack-plugin-zmq
20:41:08 <ttx> #link https://review.openstack.org/201670
20:41:13 <ttx> annegentle: where are we now with this one ?
20:41:14 * flaper87 stays on topic
20:41:25 <annegentle> I'll have to rebase after the alphabetization
20:41:39 <annegentle> but I updated today with the key management v key manager update
20:41:58 <annegentle> docs team is informed.
20:42:04 <annegentle> that's about it
20:42:13 <lifeless> flaper87: that looks like it would be discovered actually
20:42:31 <dhellmann> annegentle: I'm still a little worried that the zaqar description is too terse, but we can iterate on that separately
20:42:40 <flaper87> lifeless: ah ok, lets talk about it offline (or in 2 days :P)
20:42:50 <lifeless> flaper87:kk
20:42:50 <dhellmann> annegentle: specifically, differentiating zaqar and cue
20:42:51 <annegentle> dhellmann: yeah I get it.
20:42:58 <flaper87> dhellmann: yeah, I was worried about that as well but I didn't comment because that would require changing cue as well
20:43:03 <flaper87> and probably other projects
20:43:04 <annegentle> dhellmann: ayup
20:43:06 <dhellmann> unfortunately, I don't have a constructive suggestion right now :-/
20:43:20 <flaper87> I  was thinking to propose a follow up patch with a better descriptio
20:43:22 <flaper87> description
20:43:27 <annegentle> flaper87: do the rules generally work except for messaging queues?
20:43:29 <flaper87> one for each project so we can track the change
20:43:36 <annegentle> flaper87: sure
20:44:16 <annegentle> any other naming concerns?
20:44:23 <flaper87> annegentle: If we all imagine there's 'Service' at the end, I believe it does. Otherwise, it's a bit terse for every project.
20:44:24 <sdague> 'Governance'
20:44:38 <flaper87> my main worry right now is that Message and Message broker will cause confusion
20:44:38 <sdague> just because http://governance.openstack.org/
20:44:40 <ttx> sdague: yeah that one is pretty bad
20:44:45 <annegentle> flaper87: yeah the idea is to add service everywhere.
20:44:49 <dhellmann> sdague: yeah
20:44:53 <sdague> which, you know, is in no way related
20:45:14 <dhellmann> sdague: maybe we can get the congress team to review the minor projects.yaml changes?
20:45:21 <jeblair> yeah, actually, i'm pretty sure the TC is reposnsible for implementing governance as a service
20:45:24 <annegentle> Delta faucets, Delta airlines
20:45:48 <dhellmann> annegentle: note that you needed 2 words to differentiate those companies :-)
20:45:49 <lifeless> Gaas
20:45:52 <annegentle> :)
20:46:59 <ttx> so.. let's accumulate reviews and patchset on that one ?
20:47:08 <annegentle> ttx: yep, I'll rebase and keep asking people to take a look
20:47:17 <ttx> #topic Add a release model for all projects
20:47:22 <ttx> #link https://review.openstack.org/201724
20:47:26 <ttx> We are still gathering information on this one
20:47:31 <ttx> dhellmann: Starting to wonder if smaller incremental patches would not lead to faster improvements there
20:47:39 <ttx> not sure we have anything TC to discuss about it
20:47:47 <dhellmann> ttx: yeah, I'll split that up next week
20:47:51 <ttx> cool
20:47:55 <ttx> #topic Diversity script improvements
20:48:01 <ttx> We have two improvements around the diversity script
20:48:03 <ttx> #link https://review.openstack.org/204372
20:48:05 <ttx> #link https://review.openstack.org/204770
20:48:08 <ttx> I propose to approve those "code" reviews once they get two rollcall+1 votes
20:48:19 <ttx> since they are not governance either
20:48:30 <flaper87> ++
20:48:41 <ttx> and not spend meeting time on them
20:48:55 <ttx> #topic Workgroup reports
20:48:59 <ttx> * Project team guide
20:49:04 <ttx> So we have almost everything we need to publish in
20:49:09 <ttx> Only missing the open development chapter
20:49:10 <flaper87> I swear I'll get my part done
20:49:17 <flaper87> I'll do it on my flight tomorrow
20:49:23 <flaper87> and plublish it
20:49:31 <ttx> flaper87: sounds good -- post what you have
20:49:32 * flaper87 is so ashamed
20:49:38 <ttx> jeblair: will you be working on the publication jobs ? Maybe you have already and I missed them
20:49:45 <jeblair> ttx: i will
20:49:52 <ttx> jeblair: thx!
20:49:54 <ttx> * Next-tags
20:49:55 <jeblair> ttx: i'm currently hiding behind flaper87.  ;)
20:50:00 <ttx> Team will gradually post new tags over the coming weeks.
20:50:05 <ttx> The devstack tags proposed by sdague are an early manifestation of that
20:50:09 * flaper87 starts jumping
20:50:12 <ttx> sdague is just faster than us slackers
20:50:24 <ttx> * Communications
20:50:30 <ttx> annegentle, flaper87: maybe we should include this TC in the next blog post ?
20:50:36 <flaper87> yeah
20:50:43 <ttx> i.e. the conclusion of the stackforge thing
20:50:48 <flaper87> and do a single post
20:50:53 <flaper87> the stackforge thing is important
20:50:54 <annegentle> sure, next week ok?
20:51:10 <ttx> well, next week we might have more to post :)
20:51:27 <dhellmann> flaper87: the stackforge thing might be worth a separate post entirely
20:51:29 <ttx> release early, release often!
20:51:40 <annegentle> yeah, I'm thinking stackforge is a separate post, not a highlights one
20:51:46 <ttx> dhellmann: not sure
20:51:54 <annegentle> I can think of questions about it that someone could answer for the post
20:51:56 <ttx> annegentle: the change is a technical one, not a governance one
20:52:03 <flaper87> we can make a longer post this time that gives enough information about stackforge
20:52:19 <ttx> I'm not sure we need to make a separate post... we just rename repos
20:52:35 * dhellmann shrugs
20:52:41 <annegentle> How will I be notified of the move? What's the timeline for renames? What if no one is maintainer, what happens?
20:52:44 <ttx> i don't want people to start making up their own idea of what "moving under openstack namespace" means
20:53:05 <annegentle> (I have a no-one-is-maintainer repo in there)
20:53:17 <edleafe> I tried explaining this to people. They are confused about it
20:53:23 <jeblair> annegentle: i expect the infra team to come up with a plan that addresses that
20:53:37 <annegentle> jeblair: I think that a blog post should be part of that comm plan
20:53:39 <edleafe> I tried explaining this to people. They are confused about it
20:53:43 <dhellmann> annegentle: ++
20:53:48 <edleafe> ugh
20:53:54 <annegentle> edleafe: heh
20:54:03 <ttx> annegentle: I guess as long as the post clearly says it's just a repo rename, it's not "moving all of Stackforge into OpenStack" that's good
20:54:07 <edleafe> typing in two windows == bad
20:54:13 <dhellmann> ttx: ++
20:54:26 <ttx> I have enough big-tent haters sending me things
20:54:32 <lifeless> ttx: orly?
20:54:35 <dhellmann> we have a nice shiny yaml file to point to as the list of official projects
20:54:54 <ttx> lifeless: it's more of a "hit me at conference about how much the whole idea sucks" kind of thing
20:54:57 <zaneb> I really don't understand big-tent haters
20:55:17 <lifeless> ttx: totes
20:55:20 <annegentle> so, do you think we need a highlights post this week or is next ok?
20:55:29 <ttx> zaneb: it's mostly that they don't get it, but misinformed people / press will make headlines out of small things
20:55:51 <zaneb> yeah, I know
20:56:07 <zaneb> but how hard can it be to just ignore the parts you don't care about?
20:56:13 <sdague> it's a less informed version of the same pov that wanted a starter kit. If openstack is 100 projects, people feel intimidated about where to start
20:56:29 <sdague> hopefully compute starter kit helps offset that
20:56:34 <ttx> yep, fear of getting lost
20:56:40 <edleafe> zaneb: some felt that incubation meant better quality
20:56:52 <edleafe> zaneb: and we know that wasn't always true
20:57:01 <dhellmann> edleafe: +
20:57:03 <dhellmann> +
20:57:10 <ttx> so whatever we write, must clearly state that we still have official projects on one side and stackforge on th other, just the line doesn't use git repo prefixes anymore
20:57:20 <zaneb> edleafe: yeah, that's fair, and that's why we're putting these tags in place to make sure people can still get that info
20:57:23 <ttx> #topic Open discussion
20:57:28 <jeblair> ttx: ++
20:57:30 <flaper87> ttx: ++
20:57:39 <lifeless> ttx: lets not say 'official + stackforge' - thats just confusing :)
20:57:45 <lifeless> ttx: but yes, there are two sets
20:57:48 <sdague> ttx: is there a date scheduled for TC / Board joint meeting in Tokyo yet?
20:57:59 <sdague> because... travel planning
20:58:06 <ttx> sdague: Monday i'm told, no confirmation
20:58:17 <sdague> ok, monday is an acceptable answer
20:58:18 <ttx> The Debian packaging team proposal was updated, we'll review it next week
20:58:25 <ttx> #link https://review.openstack.org/185187
20:58:35 <ttx> We are at about the middle of the cycle at this point, so I'd like to take a step back for 2 minutes
20:58:43 <ttx> Is there any major problem we should be collectively working on fixing and that we aren't ?
20:59:06 <ttx> I'm still deep in the big tent aftermath
20:59:14 <ttx> I fear I'm losing the bigger picture
20:59:31 <sdague> the dynamic policy bits are kind of gummed up
20:59:51 <sdague> I feel like we need to come together as a community around what's going on there in Tokyo
21:00:02 <sdague> because it's pretty cross project cutting
21:00:05 <ttx> I think we have a few projects losing it (culture, not getting anything done, deadlocked...) and me and my team will focus on exploring them over the coming months
21:00:12 <flaper87> I honestly don't have an answer OTOH but I'll put thoughts on this
21:00:23 <annegentle> it's a great question, necessary to ask.
21:00:56 <ttx> so please, this week, take some time stepp�ng back and see if we are working on what we should be working on
21:01:00 <annegentle> sounds good
21:01:02 <ttx> I'm very happy with the project team gudie
21:01:04 <flaper87> +1
21:01:08 <ttx> but that's not the only thing
21:01:12 <dhellmann> sdague: I just started a list of cross-project topics for the summit: https://etherpad.openstack.org/p/mitaka-cross-project-session-planning
21:01:12 <sdague> honestly, I was thinking as we go into the cross project day in Tokyo, we should instead treat it as a TC priorities day, and be a little top down about the top things we think need some extra eyes
21:01:19 <sdague> dhellmann: ok, great
21:01:38 <edleafe> sdague: +1
21:01:45 <thingee> #link https://etherpad.openstack.org/p/mitaka-cross-project-session-planning
21:01:47 <dhellmann> we should do the spreadsheet thing again for submissions, but this is good for notes for now
21:01:47 <ttx> sdague: yeah, we should work ahead of that day and come up with the full agenda at this point
21:02:01 <ttx> or that
21:02:05 <ttx> anyway, time is up
21:02:12 <flaper87> o/
21:02:30 <ttx> #endmeeting