20:01:07 <ttx> #startmeeting tc
20:01:08 <openstack> Meeting started Tue Mar 21 20:01:07 2017 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:13 <openstack> The meeting name has been set to 'tc'
20:01:15 <ttx> Hi everyone!
20:01:16 * edleafe acts nonchalant
20:01:21 <ttx> Our agenda for today is at:
20:01:25 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:33 <ttx> (friendly reminder: you can all use #info #idea and #link to help build a more readable summary)
20:01:37 <thingee> ttx: I'm here
20:01:43 <jroll> \o
20:01:54 <ttx> cool! I was misinformed
20:02:02 <ttx> #topic Add naming poll info for R release
20:02:07 <ttx> #link https://review.openstack.org/445733
20:02:15 <ttx> I don't see any objection to this one, will approve now
20:02:18 <EmilienM> ship it
20:02:18 * rockyg kicks some dirt, looks up and whistles a tune
20:02:26 <flaper87> o/
20:02:37 <ttx> I think we can volunteer mordred in his absnece to drive the next steps ?
20:02:40 <sdague> yep
20:02:43 * cdent waves from the kitchen
20:02:47 * mugsie lurks
20:02:49 <ttx> #action mordred to drive the R naming process
20:02:55 * flaper87 likes volunteering mordred for stuff
20:02:58 <ttx> On a related topic, we need to renew part of the TC, voting on the week of April 17
20:03:03 <fungi> always a good bet to volunteer mordred in his absence
20:03:06 <ttx> Which means nominations/campaigning early April
20:03:12 <ttx> #action ttx to contact election officials to organize April TC elections
20:03:36 <ttx> In particular they may build in a campaigning week as that was requested by people after last election
20:04:01 <ttx> #topic Add Golang CTI
20:04:07 <ttx> #link https://review.openstack.org/410355
20:04:11 <ttx> dtroyer: o/
20:04:19 <ttx> care to introduce it ?
20:04:23 <dtroyer> Yes
20:05:03 <dtroyer> This is the common test interface for projects containing golang components, assuming mixed language projects may exist.
20:05:23 <ttx> Looks like there are still a bunch of typos + late suggestions from sdague on target renaming
20:05:34 <dtroyer> There are a few things not completed yet, listed in the commit and inside the doc
20:05:45 <ttx> Beyond that I'm fine with it as a first version. CTIs are living documents anyway
20:05:45 <sdague> yeh, on the target renaming the only thing I really think we want to consider is hardcoding of test types in here
20:05:45 <dims> ttx : dtroyer : this is a living document right? wanted to ask before but slipped.
20:05:53 <dtroyer> Modulo sdague's comments I have a PS ready for the rest of those
20:05:54 <dims> :)
20:05:54 <sdague> we evolved that on the python side over time
20:05:55 <ttx> dims: yes
20:06:04 <sdague> and seems weird to be that specific
20:06:11 <dtroyer> dims: I believe so
20:06:23 <flaper87> dims: dtroyer it's a living doc
20:06:26 <dims> ++
20:06:27 <sdague> make test, and make test-* would just seem to open up flexibility
20:06:41 <fungi> seems fine to me
20:06:43 <dtroyer> I called out both unit and functioanl testing targets because they are both specifically listed in the language requirements doc
20:06:44 <flaper87> mod nits, I think it looks good
20:07:11 <fungi> worth noting, whatever project's jobs come first will probably de facto define those anyway
20:07:32 <fungi> as we'll mostly want to just reuse common job templates
20:07:36 <sdague> dtroyer: yeh, we should probably roll that back there, because I honestly think we should be more flexible to adjusting that stuff as we go.
20:07:39 <dtroyer> whether the 'test' target is specific or just calls some subset of the 'test-*' targets is just something we need to decide
20:07:52 <mugsie> I do like the suggestions sdague made for the makefile targets, but overall it looks good
20:08:13 <mugsie> dtroyer: do we? as long at the "make test" call does something cnsistantly, do we really care?
20:08:19 <dtroyer> sdague: so just specify 'test' as the default testing and other test targets prefixed with 'test-*'?
20:08:20 <sdague> right, agreed
20:08:26 <sdague> mugsie: ++
20:08:48 <ttx> dtroyer: want to quick-rev it ? Or need more time ?
20:08:55 <dtroyer> I can quickly do that...
20:09:12 * flaper87 has his voting pen ready
20:09:17 <johnthetubaguy> and the plan is to merge what we have and work on the TODOs in a follow up patch?
20:09:34 <EmilienM> johnthetubaguy: that's how I understand it too
20:09:35 <fungi> if that's the plan, i'm still good with it
20:09:39 <ttx> johnthetubaguy: yes
20:09:50 <johnthetubaguy> cool, makes sense, just wanted to check
20:09:51 <ttx> Python CTI wasn't built in a day
20:09:53 <fungi> "living document" and all
20:10:15 <dtroyer> johnthetubaguy: yes
20:10:15 <johnthetubaguy> yep, my preference is totally to iterate on it
20:10:28 <fungi> go cti sprung from odin's forehead, fully formed, right?
20:10:44 <dims> next PS, let's merge then iterate :)
20:10:45 <ttx> Not Odin's, just Doug Graves's
20:10:50 <flaper87> ttx: it took like 6 years :P
20:11:09 * fungi mixed up odin and zeus anyway
20:11:28 <fungi> not the right time of day to be bringing mythological references into the discussion
20:11:44 * dtroyer looks around suspicously for that Eric guy
20:11:53 <ttx> OK, maybe let's cover another topic real quick while Odin^WDean revs the patch
20:11:57 <dtroyer> new PS up
20:12:04 <ttx> jinx
20:12:13 <ttx> ok, let's review it now then
20:12:26 <sdague> +1
20:13:20 <fungi> in-meeting review is the best kind of review
20:13:41 <ttx> alright, lgtm
20:13:59 <EmilienM> 7 votes, we have quorum
20:14:00 <ttx> and...
20:14:04 <ttx> approved
20:14:16 <EmilienM> dtroyer: nice work, thanks :)
20:14:19 <ttx> dtroyer: thanks for pushing this!
20:14:21 <dtroyer> thanks everyone
20:14:27 <ttx> #topic Add a "docs:install-guide-verified" tag
20:14:49 <ttx> is asettle around?
20:14:56 <annegentle> darn, I don't see her
20:15:07 <ttx> #link https://review.openstack.org/445536
20:15:09 <EmilienM> it's 10.14pm in London I don't think so
20:15:13 <johnthetubaguy> its sure late over here
20:15:13 <ttx> annegentle: oh. Ho!
20:15:15 <ttx> hi
20:15:24 <annegentle> hiho
20:15:41 <ttx> not 10.14. Merely 8.14pm
20:15:44 <johnthetubaguy> well, 8.15pm, but thats worse in some ways
20:15:50 <annegentle> heh, yeah
20:15:50 <fungi> EmilienM: ever been to london? that's early ;)
20:15:54 <EmilienM> err, sorry I was confused
20:15:54 <ttx> This looks pretty close
20:16:06 <EmilienM> fungi: ahah, I've never been :)
20:16:15 * ttx looks up late revisions
20:16:24 <flaper87> fungi: rofl
20:16:29 <ttx> thingee has a -1
20:16:43 <thingee> just on the fixing of distro packages
20:16:56 <annegentle> thingee yeah there's some dependence there?
20:17:22 <mugsie> but, seen as the guide is package based, there is not much choice, is there?
20:17:29 <johnthetubaguy> thing is the install guide requires the use of the distro packages right?
20:17:40 <mugsie> johnthetubaguy: yeah
20:17:42 <dtroyer> maybe I missed this in the early going, what are the consequences if the testing is not completed in a timely manner?
20:17:54 <dtroyer> is that a tag-per-release?
20:17:55 <sdague> thingee: just commented on that
20:17:58 <ttx> johnthetubaguy: could it "support" some components not using distro packages ?
20:18:16 <sdague> I think using the ops midcycle as representative of the whole community is a biased sample
20:18:23 <johnthetubaguy> it does feel like this would be per release, in some ways, or reviewed
20:18:23 <fungi> is it a priority review and testing list for the docs team?
20:18:30 <mugsie> the way it is currently laid out, I dont think it could ttx
20:18:32 <ttx> dtroyer: tags are not pre-release. But things like the project-navigator use a snapshot of tags from release time
20:18:38 <thingee> the last time I spoke with the docs team on other projects getting their install guides in, it was agreed that we'd allow other forms of installations besides packages because of the reason given in comment
20:18:44 <ttx> per-release* I mean
20:18:50 <thingee> I don't think the tag really helps anything otherwise.
20:18:54 <johnthetubaguy> ttx: its possible, just would be very strange
20:18:57 <flaper87> the doc says it;'ll be reviewed per-release
20:19:01 <annegentle> thingee as in, "is this installable" yeah
20:19:04 <thingee> well it helps the projects that can get attention from distros
20:19:15 <ttx> flaper87: yes, a few weeks befroe so tha tthe tag is current when the release it out
20:19:17 <annegentle> thingee but things are installable without distros
20:19:26 <thingee> annegentle: from previous ops midcycles it has been expressed that packages are not the most common way people deploy openstack
20:19:27 <mugsie> thingee: the issues can be wiht the docs themselves as well
20:19:29 <flaper87> ttx: right, which I honestly think is fine
20:19:32 <annegentle> thingee yeah
20:19:32 <ttx> yep
20:19:37 <thingee> and I don't believe the docs team should be dictating this
20:19:58 <mugsie> thingee: how do people deploy?
20:19:58 <fungi> is the docs team overseeing the install guide testing?
20:19:59 <sdague> thingee: the ops midcycles are the top 1% of the operators
20:20:05 <ttx> Sounds like a nice cross-community discussion to have
20:20:11 <sdague> and are doing much more custom stuff
20:20:18 <ttx> docs+devs+ops
20:20:28 <johnthetubaguy> sdague: +1
20:20:30 <annegentle> thingee right, okay, so then is there a way for the docs team to get approved install instructions from each project at a certain point in time? I think there still is.
20:20:30 <sdague> I think it's fine to have a tag which is "we've verified the install guide"
20:20:33 <fungi> following the docs ml, in the past install guide testing has been coordinated there at any rate
20:20:34 <flaper87> ttx: +1
20:20:38 <sdague> which assumes using packages
20:20:49 <sdague> because that's how install guides are, and work best for most people
20:21:06 <mugsie> thingee: there is also deployment guides now as well
20:21:12 <EmilienM> I agree that it would be a nice topic to propose at forumtopics.openstack.org
20:21:46 <annegentle> EmilienM +1
20:21:49 <thingee> I agree with with sdague it should be just verified. I still believe it shouldn't just be off of packages though.
20:21:53 <sdague> except, is it going to be any more informative there. We have to be really careful of sample bias in conversations like that.
20:21:56 <ttx> sdague: I think "we ahve verifies the install guide is fine", however would be great not to bake install-using-packages in the tag, so that the install doc can evolve
20:22:02 <thingee> you might as well request a tag "accepted by distros" then
20:22:22 <sdague> ttx: given there are currently no install guides that do it a different way, it seems fine to me, and evolve it later
20:22:26 <fungi> i can understand the concern that distro-package-based installation instructions, at least where commercial distros are concerned, is a bit of a gimme to those companies
20:22:34 <annegentle> This was a good first point for discussion, I think it's good to write down what happens now and evolve.
20:22:44 <annegentle> fungi yep :)
20:22:48 <sdague> fungi: well, it's been that way for the last 4+ years in openstack
20:22:50 <dtroyer> the problem with a "we verified it" tag is the time.  in 6 months with a new rreelase does that tag apply to the current one or the previously verified one?
20:23:09 <fungi> sdague: totally aware, i've felt that way for 4+ years ;)
20:23:12 <thingee> sdague: not sure that's true. mugsie can you comment on designate's deployment guide, since you can't have the right to the word of install guide?
20:23:22 <annegentle> dtroyer the docs team currently doesn't cut a stable branch for openstack-manuals until the install guide is verified, is that what you mean?
20:23:31 <mugsie> thingee: the docs team has a deployment guide section
20:23:36 <annegentle> dtroyer and the stable branch is for the trailing-by-a-few-weeks release
20:23:37 <sdague> fungi: well, you can write a new guide if you don't like the current one :)
20:23:46 <annegentle> sdague everyone else does ;)
20:23:58 <ttx> thingee: how about we approve the current version, and you submit a change to decouple it from package-based installs ? So far the install guide is all package-based so not much hurt in merging the first version as-is ?
20:23:59 <mugsie> #link https://docs.openstack.org/project-deploy-guide/ocata/
20:24:02 <annegentle> thingee yeah, the deployment guide is new this release
20:24:03 <dtroyer> annegentle: I just left an example in a comment, but if Ocata is verified, when Pike rolls around, the status of the Ocata verification does not change, but if Pike is not verified what happens?
20:24:20 <annegentle> dtroyer no team gets the tag for Pike until verification
20:24:43 <fungi> sdague: yeah, i'm not arguing that the current install guides are bad, just that if they're only covering commercial distros then there's not a lot of gain in us regulating them and as a community eating the testing coordination
20:24:52 <thingee> I'm fine with everyone else approving it. I'm not going to approve it and kind of tired of fighting this.
20:24:55 <johnthetubaguy> there is no "for pike" right, you would have to either loose the tag or keep the tag "from" that point in time where it is no longer verified
20:24:55 <dtroyer> so there is a tag per release?
20:24:56 <ttx> dtroyer: I suspect they would remove the tag before release
20:25:09 <johnthetubaguy> yeah, what ttx said
20:25:13 <annegentle> thingee it's better to not approve and say what you think the better fight is?
20:25:22 <annegentle> thingee I'm not entirely clear of the alternative
20:25:28 <sdague> fungi: debian is in the current install guides
20:25:33 <ttx> dtroyer: no it's a tag updated once before every release
20:25:42 <dtroyer> ttx: but the Ocata status has not changed.  Or do we not let users have install guides for the relases they are actually deploying?  (based on annegentle no-branch comment)
20:25:48 <ttx> a bit like we update the diversity tags regularly
20:26:01 <annegentle> ttx oh I mirespresented that then.
20:26:05 <sdague> ttx: that does seem weird thought, I think we need branch tagging
20:26:08 <fungi> sdague: debian is always hanging by a thread in the install guides due to lack of commercial backing
20:26:10 <mugsie> sdague: ++
20:26:14 * dtroyer has not actually used these guides so really doesn't know this bit
20:26:25 <fungi> sdague: or popularity, depending on what word you prefer ;)
20:26:25 <ttx> sdague: we do tag governance repo around elections. We could tag around releases
20:26:27 <thingee> annegentle: my recommendation to you and asettle is to update the patch to be consistent with what has been discussed with previous guides. Don't lean on distro packages.
20:26:35 <annegentle> ttx the stable/ocata does not exist yet for openstack-manuals
20:26:42 <annegentle> ttx due to install guide issues
20:26:42 <sdague> ttx: right, but if horizon was not verified in queens
20:26:47 <annegentle> thingee ok thanks
20:26:52 <sdague> then there is no history that is was in pike
20:27:03 <thingee> annegentle: it's not going to help adoption of the smaller projects otherwise.
20:27:13 <ttx> sdague: except if we tag around release time
20:27:21 <ttx> to capture the picture "then"
20:27:35 <sdague> ttx: ok, I think we disagree on needing the historical bits
20:27:41 <sdague> but we probably won't resolve here
20:27:46 <annegentle> thingee yeah, do you think that wider is better than narrower? In other words, right now the goal with the install guide is "be able to launch a VM" -- of course that can change but also it indicates nova-centric
20:27:53 <dtroyer> yeah, I think we do need history somehow…
20:28:02 <ttx> sdague: I mean we use the word "tag" too much, and that we agree
20:28:17 <annegentle> dtroyer sdague okay, the idea being, these projects had install guides at these releases?
20:28:22 <ttx> We have history if we tag the governance repository around releases
20:28:27 <jroll> "Any projects that maintain project-specific Installation Guides must have this tag for their guide to be linked from docs.openstack.org." - this makes me sad, with the requirement of "work alongside the docs team to test the instructions". the reason we have out of tree install guides is because the docs team didn't have time to do this :/
20:28:34 <flaper87> ttx: was going to propose that
20:28:46 * jroll adds comment to gerrit, but wanted to point it out here
20:28:49 <thingee> jroll: +1
20:28:54 <fungi> jroll: i agree, it has a baked-in bottlenect
20:28:57 <fungi> bottleneck
20:29:03 <johnthetubaguy> jroll: hmm, I missed that bit
20:29:03 <ttx> OK, sounds like this one needs a bit more baking
20:29:06 <annegentle> jroll thingee sure, good to note
20:29:13 <ttx> I propose we continue to iterate on the review
20:29:27 <flaper87> ttx: ++
20:29:37 <annegentle> thanks all
20:29:44 <ttx> #agreed continue to iterate on review
20:29:47 <annegentle> I can try to summarize with info?
20:29:51 <dtroyer> thanks annegentle
20:29:53 <ttx> annegentle: please
20:30:01 <fungi> bottleneck of the docs team deciding when this governance tag can be applied seems fine, but needs more self-service
20:30:30 <annegentle> #info Questions on timing of application of the tag: when is it applied, and what history can we include for past releases?
20:31:18 <annegentle> #info Concerns about distro dependence mean that as-yet-unpackaged projects felt like they couldn't be included; however those project can be included
20:31:46 <annegentle> #info Need for re-assurance that frameworks and tooling are in place for self-service docs written by projets
20:32:12 <ttx> nice summary, thx!
20:32:18 <johnthetubaguy> well, its the publishing restrictions that seem problematic I think
20:32:19 <johnthetubaguy> but that captures it I think
20:32:20 <annegentle> #help Propose a forum discussion for data on whether many people need distro packages for install instructions
20:32:37 <ttx> the "install guide" session
20:32:41 <fungi> annegentle is a master of summary
20:32:44 <annegentle> johnthetubaguy we can talk more about that in the review yeah
20:32:57 <ttx> annegentle: care to add the session to https://etherpad.openstack.org/p/BOS-TC-brainstorming ?
20:33:05 <ttx> that way we won't forget
20:33:11 * ttx moves to next topic
20:33:19 <ttx> #topic Add tag assert:never-breaks-compat
20:33:25 <ttx> #link https://review.openstack.org/446561
20:33:35 <ttx> mordred is not around but we should still complain about his change
20:33:43 <ttx> As stated in my comment, I'd like to make sure this is realistic, and desirable
20:33:55 <sdague> honestly, I'd rather table for mordred to be around
20:33:55 <ttx> (since tags should drive desirable behavior i think)
20:34:09 <ttx> he told me he would take our feedback in
20:34:16 <sdague> I'm not quite sure I understand the purpose of this, and would like him to express it
20:34:24 <ttx> ah, ok, fair
20:34:40 <ttx> I encouraged him to reorder his patches so that the shade stuff can be approved without this one
20:34:45 <ttx> which will likely take more time
20:35:09 <dims> i like the steps in "If a breaking change is accidentally released,"
20:35:10 <flaper87> sdague: mmh, I guess if it's not clear enough from the tag definition then it's probably a bad sign of the patch itself?
20:35:36 <dims> dunno if we have that already somewhere else
20:35:48 <ttx> sdague: probably something missing in the rationale section yes
20:36:00 * ttx moves on
20:36:20 <ttx> #info will be discussed when mordred will be around, sdague would like to hear him speak about it
20:36:27 <ttx> #topic Open discussion
20:36:31 <ttx> * FYI on Unified Limits
20:36:37 <ttx> sdague: floor is yours
20:36:41 <sdague> thanks
20:36:42 <EmilienM> ttx: I have one for later
20:36:43 <ttx> #link https://review.openstack.org/#/c/440815/
20:36:46 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114230.html
20:36:55 <ttx> I have several!
20:36:58 <sdague> so there is a spec, and a called out email thread (which also went to ops list)
20:37:18 <sdague> we've got agreement in a subset of folks over a new approach to limits that would store them in keystone
20:37:38 <sdague> as part of the path to a real hierarchical quota solution
20:38:15 <sdague> but, it would be really good to get more folks engaged there to make sure making a big shift like this isn't going to freak people out later
20:38:43 <sdague> we are dangerously close to having a plan here that I think will work
20:38:58 <sdague> which emerged out of the PTG
20:39:15 <sdague> so... tell your friends, dig in if this is something you have thoughts on
20:39:33 * johnthetubaguy loves sdague's plan
20:39:40 <dims> sdague : a PTL mailing list would have been handy?
20:39:55 <bauzas> \o
20:39:55 <ttx> sdague: do you want to expose the plan to more users at the Forum, or will it be too late for that ?
20:40:09 <sdague> ttx: the intent is to be working on implementation by then
20:40:14 <ttx> ack
20:40:30 <sdague> my timeline is that we're going to give it this week, and next for feedback, then make the go no go on the concept
20:40:50 <sdague> and I need to write up the detailed interface adds for keystone still
20:40:54 <ttx> ok
20:40:58 <thingee> sdague: setup a cross-project meeting?
20:41:00 <sdague> but the keystone team is pretty good with this so far
20:41:16 <sdague> thingee: maybe?.... honestly, during Pike it's basically 100% keystone work
20:41:43 <ttx> sdague: anything more on that ?
20:41:55 <thingee> sdague: could've argued that with the servce catalog tng?
20:42:00 <sdague> thingee: plan is here - https://review.openstack.org/#/c/440815/4/specs/keystone/backlog/unified-limits.rst@193
20:42:07 <sdague> ttx: nope
20:42:18 <ttx> * Moving "Split out tempest plugins" to Queens potential goals
20:42:22 <ttx> #link  https://review.openstack.org/369749
20:42:31 <ttx> Rather than abandoning this one I'll bootstrap the Queens goal directory and then move this one to a Queens potential goal
20:42:35 <ttx> unless someone objects...
20:42:57 <ttx> #action ttx to set up Queens goal directory and move https://review.openstack.org/369749 to it
20:43:03 <sdague> seems fine, would be good to have mtreinish around for conversation around it as there still seems to be some friction
20:43:28 <fungi> dims: with my ptl hat on, i don't know that a ptl-only ml is a great way to reach teams which are so out of the loop that their members ignore the more general discussion lists
20:43:30 <EmilienM> ttx: to we want all sessions from https://etherpad.openstack.org/p/BOS-TC-brainstorming recorded into http://forumtopics.openstack.org/ ?
20:43:31 <ttx> will be a change on the governance repo anyway, so we'll rediscuss it
20:43:40 <ttx> * Forum topics
20:43:45 <jroll> fungi: ++
20:43:54 <ttx> EmilienM: yes we are now at the stage where we should formally propose the results of the brainstorming
20:43:59 <ttx> The website is up at:
20:44:03 <ttx> #link http://forumtopics.openstack.org/
20:44:05 <dims> fungi : problem is many folks complain later on (ex placement service)
20:44:05 <EmilienM> ttx: I'll do it
20:44:07 * fungi relies on other team members to point discussions out to him
20:44:11 <ttx> Looking at the TC brainstorming, we should convert that in a series of proposals, before the deadline on April 2
20:44:15 <ttx> #link https://etherpad.openstack.org/p/BOS-TC-brainstorming
20:44:23 <EmilienM> #action EmilienM to grab sessions from https://etherpad.openstack.org/p/BOS-TC-brainstorming and propose them to http://forumtopics.openstack.org/
20:44:25 <ttx> Anything that you think wouldn't make a good proposal ?
20:44:31 <ttx> Or should be merged before being proposed ?
20:44:45 <sdague> ttx: what is the forum going to look like logistically?
20:44:46 <jroll> I know nobody here runs that cheddar install, but as a note, it sends the launchpad auth over plain text :(
20:45:07 <fungi> i think i know who runs that cheddar install
20:45:15 <ttx> the "TC vision" one looks a bit fuzzy
20:45:29 <fungi> jroll: you'll be happy to know that your actual auth happens between you and launchpad and is over https
20:45:32 <ttx> sdague: fishbowl setup, like cross-project sessiosn at old design summit
20:45:34 <sdague> because I'm still a little confused on what kind of track / day structure is being attempted to be created, and I don't think I'm the only one confused
20:45:53 <jroll> fungi: yeah, just the oauth token, idk how risky that is
20:46:03 <fungi> jroll: but i agree, it's not great that cheddar asks for authorization over plain http
20:46:13 <ttx> thingee: we have... 3 parallel rooms over 4 days ?
20:46:19 <jroll> sdague: +1
20:46:24 <fungi> jroll: not terrible, but also not great, if that counts as an answer
20:46:36 <ttx> sdague: I thought I sent an email about that
20:46:38 <jroll> fungi: :)
20:46:40 * ttx checks
20:46:42 <sdague> ttx: you might have
20:46:48 <bauzas> should we propose project-specific sessions into forumtopics.o.o ?
20:46:53 * thingee checks too
20:46:54 <sdague> but it definitely doesn't feel like it sunk in
20:47:03 <ttx> can't force people to read
20:47:05 <sdague> and given that the answer isn't "just like last time"
20:47:13 <sdague> it needs to be pretty heavily over communicated
20:47:34 <EmilienM> sdague: ++
20:47:48 <ttx> thingee and fifieldt are the contacts on the Foundation staff side. EmilienM and dhellmann on the TC side
20:48:42 <fungi> from an infra team perspective, i got the impression we fit more as users/operators in the feedback spectrum and so should show up for sessions but not necessarily have coordinated things to propose there
20:48:58 <ttx> sdague: http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html
20:49:12 <thingee> ttx: verified three rooms
20:49:37 <ttx> thingee: let's plan another thread around Forum specifically
20:50:05 <ttx> like repeat the deadline, the submission site, and the structure (4 days / 3 rooms / fishbowl)
20:50:29 <sdague> and probably examples of sessions that were run during past summits that would be appropriate
20:50:34 <jroll> ttx: "cross-community discussions" doesn't necessarily mean "cross-project", right?
20:50:48 <jroll> and will these be 40 minute sessions, as usual?
20:51:00 <sdague> I think right now there is a bunch of self censoring because no one is sure if their stuff is appropriate
20:51:07 <ttx> jroll: the idea is to have discussions we can't have anywhere else because a part of our community is missing
20:51:23 <ttx> sdague: EmilienM's original email gave examples
20:51:32 <jroll> ttx: I think that answers my question, thanks
20:51:51 <sdague> ttx: non of those were sessions that were proposed in past events right? Those were new whole cloth ideas.
20:51:52 <ttx> jroll: we can have double-slot sessions where needed, so 40 or 90min I would say
20:52:02 <jroll> perfect
20:52:04 <ttx> but then I'm not on the selection committee :)
20:52:18 <ttx> sdague: hmm, sounded like old sessions
20:52:28 <ttx> with actualized names maybe
20:52:39 <ttx> EmilienM: is it what you wanted to cover ?
20:52:47 <sdague> ok, I missed barcelona, so maybe they were there
20:53:12 <EmilienM> ttx: yes, I'll work on https://etherpad.openstack.org/p/BOS-TC-brainstorming this week and put something into cheddar
20:53:25 <ttx> sdague: some session ideas were brand-new because the old format did not leave any room for them. Like Appdev-feedback oriented sessions
20:53:36 <EmilienM> ttx: I'll probably ask for reviews from TC team
20:53:53 <ttx> EmilienM: the "TC vision" entry looks a bit fuzzy to me. You migt want to confirm before copying it over
20:54:03 <EmilienM> ttx: noted.
20:54:04 <ttx> * Vision exercise feedback
20:54:08 <ttx> Two weeks ago after the Board+TC+UC meeting we started working on a TC vision
20:54:12 <ttx> Anyone wants to say anything on that ?
20:54:34 <johnthetubaguy> dims and I are working on getting a draft together to bring lots of etherpads into one
20:54:46 <jroll> is there a rough timeline for the "rest of us" seeing the output of that?
20:54:47 <mriedem> that's this thing right? http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
20:54:54 <ttx> mriedem: no
20:54:58 <sdague> jroll: first week of April
20:55:04 <jroll> cool, thanks sdague
20:55:16 <sdague> that's the target for getting things into sharable state, so pretty soon
20:55:23 <ttx> mriedem: on the day after that one we did go through an exercise to produce a draft of a vision for the TC itself
20:55:26 <sdague> and with enough time for people to ponder pre Boston
20:55:35 <jroll> yep :)
20:56:08 <ttx> mriedem: the article is about the Board+TC+UC meeting where we tackled strategic questions
20:56:27 <fungi> the concern is that it's supposed to present a unified voice of the current tc, so distributing it in an incom,plete state risks implying opinions we don't all agree on
20:56:28 <sdague> mriedem: it was similar, but this is a bit different.
20:56:53 <jroll> fungi: yeah, I totally get it. just curious / excited to see it
20:57:00 <fungi> jroll: me too! ;)
20:57:05 <ttx> Goal is to have something to present before Bosto, definitely
20:57:07 * zaneb too :)
20:57:08 <jroll> ha
20:57:27 <ttx> * Next week meeting
20:57:34 <ttx> I'll be traveling around meeting time next week, so I may not be around for the meeting
20:57:37 <dims> so, this is a vision for the TC itself, not a technical direction for openstack :)
20:57:41 <sdague> it is probably worth a write up of the process when the whole thing gets out there as well so we have a reference like the superuser article to explain how we got here
20:57:43 <ttx> I may be having dinner with flaper87 instead
20:57:46 <dims> zaneb : jroll : ^
20:57:50 <ttx> Any volunteer to chair the meeting ? I'll work on agenda and all
20:57:51 <jroll> dims: indeed
20:57:56 <sdague> dims: well, a bunch of it bleeds through :)
20:57:56 <ttx> and might end up being present
20:57:58 <fungi> dims: well, seems to me like a vision for the tc _and_ technical community we lead/represent
20:57:58 * thingee disappears as mai tai appears and plane is landing
20:58:14 <ttx> thingee: good timing
20:58:15 <fungi> dims: but not a vision for openstack the software
20:58:15 <dims> fungi : sdague : tempering expectations :)
20:58:28 <zaneb> dims: aware of that, but it's blocking the next thing, which is to have a technical vision of openstack
20:58:30 <fungi> yeah, there is certainly overlap
20:58:39 <flaper87> ttx: \o/
20:58:39 <dims> ++ zaneb
20:59:13 <EmilienM> ttx: I can try
20:59:19 <ttx> volunteer for sharing next week meeting in case I'm too stuffed of currywurst to chair ?
20:59:23 <ttx> EmilienM: thanks!
20:59:31 <fungi> flaper87 and EmilienM can fight over it
20:59:35 <EmilienM> only if you're helping me :D
20:59:36 <dims> here's a plug for zaneb's effort https://review.openstack.org/#/c/447031/
20:59:51 <ttx> well flaper87 mighy have currywurst overdose as well
21:00:10 <flaper87> fungi: I'll pass this time, I want currywurst
21:00:12 <flaper87> :D
21:00:15 <ttx> and we are out of time
21:00:19 <ttx> Thanks everyone
21:00:28 <ttx> #endmeeting