20:01:55 <ttx> #startmeeting tc
20:01:56 <openstack> Meeting started Tue Jan  5 20:01:55 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:00 <openstack> The meeting name has been set to 'tc'
20:02:02 <ttx> Hi everyone!
20:02:04 <mriedem> o/
20:02:07 <ttx> Happy new year!
20:02:10 <prometheanfire> hi
20:02:11 <lifeless> ttx: o/
20:02:14 <ttx> Our agenda for today:
20:02:14 <russellb> happy new year, indeed
20:02:19 <markmcclain> o/
20:02:19 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:25 * dims lurks
20:02:30 <ttx> #topic Resolution about Image Uploads and Linux Kernels
20:02:36 <ttx> #link https://review.openstack.org/#/c/256438/
20:02:41 <ttx> This is getting pretty close
20:02:44 <mordred> there is a good feedback from russelb
20:02:53 <mordred> I was waiting for any additoinal feedback before revving again
20:02:55 <ttx> yeah I think we should add Russell's paragraph
20:02:55 <thingee> o/
20:02:57 <mestery> there is indeed
20:03:00 <russellb> would prefer that tweak, but happy otherwise
20:03:16 <dhellmann> ++
20:03:17 <mordred> cool. if nobody else has anyting else, I'll rev and have it ready for next week
20:03:20 <ttx> better include it and have a new vote round and see how far we end up
20:03:26 <mordred> ++
20:03:43 <lifeless> +1 on the tweak
20:03:43 <ttx> if you inline edit it we can even vote on it in this meeting
20:03:49 <mordred> oh. weird
20:03:53 <mordred> that's super fancy
20:03:56 <mestery> SUPER fancy
20:04:04 <russellb> not sure that you *have* to inline edit to be able to vote in meeting, but yes :-p
20:04:16 * dhellmann makes the mind blown gesture
20:04:32 * ttx tried that earlier today, lots fun
20:04:35 * devananda lurks as well
20:04:44 <russellb> i tried inline edit once, screwed it up.  :(
20:05:12 <ttx> mordred: if you submit a new rev while the meeting is still going, let us know and we'll revote
20:05:19 <jeblair> don't forget to save your file then save the edit then publish the edit
20:05:27 <mordred> I inlined edited
20:05:31 <ttx> and click OK then save
20:05:35 * mordred feels very hipster
20:05:45 <ttx> feels almost like github
20:06:02 <mordred> not enough emoji for that
20:06:04 <ttx> Update from Monty Taylor Show Ignore
20:06:04 * prometheanfire has trust issues
20:06:10 <ttx> hmm; tough choices
20:06:29 <russellb> +1
20:06:33 <russellb> (to the update)
20:06:44 <lifeless> is there a hotkey for review in the new gerrit ?
20:06:48 <russellb> 'a'
20:06:49 <lifeless> what 'r' used to be?
20:06:52 <lifeless> russellb: thanks
20:06:55 <russellb> np
20:06:55 <mestery> Nice work mordred
20:06:58 <mordred> \o/
20:07:13 * dhellmann looks for "a" in the words "review" or "reply"
20:07:14 <ttx> ok one more
20:07:14 <russellb> that's 6 ...
20:07:19 <russellb> dhellmann: yeah, no idea
20:07:28 <russellb> dhellmann: i have it as "append" in my head
20:07:33 <russellb> which only kind of barely makes sense
20:07:37 <ttx> and we have a winner
20:07:47 <dhellmann> russellb : "a review"? :-)
20:07:51 <ttx> approved
20:07:52 <russellb> heh, that works too
20:08:35 <jeblair> 'add review'?
20:08:45 <mordred> I've been thinking "answer"
20:08:54 <mordred> don't know why
20:08:56 <lifeless> autobots transform ?
20:08:58 <ttx> russellb, mordred: I suppose you will push that to appropriate board corners ?
20:09:04 * jeblair just hits alt-2
20:09:18 <sdague> I gave up on google key shortcuts making sense a while ago with the gmail ones
20:09:22 <mordred> ttx: I think I saw hogepodge representing defcore lurking already
20:09:24 <russellb> hogepodge is here on behalf of defcore
20:09:27 <russellb> so that's a first step :)
20:09:34 <russellb> get the feedback to that committee
20:09:34 <ttx> ok good
20:09:35 <russellb> so done!
20:09:38 <ttx> #topic Add The Four Opens
20:09:39 <hogepodge> markvoelker: is here also
20:09:45 <russellb> hogepodge: thanks for coming
20:09:48 <ttx> #link https://review.openstack.org/256439
20:09:49 <russellb> and markmcclain
20:09:50 <mordred> I have not yet done ttx's edit
20:09:53 <russellb> err markvoelker
20:09:59 <ttx> This one looks good to go, with the dependent patch from Doug
20:09:59 <mordred> but I think it's a good idea
20:10:06 * markvoelker has duly noted it
20:10:10 <ttx> The version from the project team guide was a bit refactored, but I'll propose it as a followup
20:10:15 <lifeless> ttx: well, I have a -1 on it
20:10:22 <ttx> ah hm recent one
20:10:23 <lifeless> ttx: basically the exact same thing as the edit on the prior patch
20:10:35 * purp_too catches up while lurking
20:10:44 <mordred> yah - I was trying to not re-wordsmith this
20:10:54 <mordred> it was really about moving the wiki content to the governance repo
20:10:55 <lifeless> if we're making it more official
20:10:57 <lifeless> I think we need to
20:11:03 <lifeless> because well, its more official
20:11:21 <russellb> it was already pretty official *shrug*
20:11:25 <russellb> it gets linked all the time
20:11:25 <ttx> lifeless: I think we can import the current version and push changes as subsequent edits
20:11:35 <russellb> +1 to that
20:11:42 <dhellmann> I'm comfortable with the wording as it is
20:11:49 <ttx> same reason I'll push my refactoring from the Project Team Guide as a follow-up too
20:12:07 <ttx> mordred is just importing the current one from the wiki
20:12:16 <mestery> Makes sense to me
20:12:19 <sdague> yeh, this seems fine to me
20:13:11 <ttx> I tend to agree that we could reword that paragraph, but I think we can bikeshed this one quite a bit and wouldn't like to hold the import too long
20:13:21 <sdague> honestly, there are times for being more explicit and shoe banging to get the spirit across
20:13:30 <sdague> I'm fine that this has that tone
20:13:37 <ttx> and as russellb said, the current version is still "official" until we approve this one
20:13:46 <mordred> we have had to be VERY explicit on the open core topic several times in the past
20:13:47 <ttx> so not worse
20:13:55 <mordred> including once with me yelling in a  board meeting
20:14:07 <sdague> if there was more of that previously, we wouldn't have had to spend so much time on the bring your own kernel issue
20:14:11 <mordred> it's a "give an inch and they'll take a mile" topic
20:14:32 <prometheanfire> +1
20:14:38 <lifeless> mordred: so, I'd like to see that statement from the board too then! (Amd I can't think of a better person to make that happen :))
20:14:38 <dhellmann> I also think it's fine to take this stance as a technical position, which is well within our purview
20:15:07 <mordred> russellb: perhaps we should propose something at a board meeting to get the board to also say the same thing?
20:15:15 <ttx> so I'm fine taking the majority votes we already have and merging this now, taking lifeless concern to a subsequent change
20:15:23 <russellb> it's important for us to take a stance on, actually, because it has large implications on project scope
20:15:26 <ttx> lifeless: does that work for you ?
20:15:36 <mordred> jbryce: ^^ would love some feedback at some point about how such a thing might look from the board side
20:15:39 <russellb> mordred: sure, not sure what form that would take ...
20:15:44 <lifeless> ttx: my only concern is being respectful to the boundaries between tc and board
20:15:47 <russellb> but generally +1
20:15:54 <lifeless> I *totally* agree with the thing itself.
20:16:12 <russellb> kinda funny, the red hat product has enterprise in the name :-)
20:16:16 <ttx> lifeless: I get it -- consider this version to be the import of the current situation and a base for subsequent changes
20:16:22 <lifeless> we won't turn down contributions because they might endanger any of the open core strategies other folk are building around openstack
20:16:27 <russellb> we could tweak working later though, i'm not worried
20:16:30 <mordred> lifeless: that is true
20:17:00 <mordred> lifeless: and we also don't prevent people from having those strategies
20:17:02 <ttx> I'd rather review the change separately from the import
20:17:08 <lifeless> mordred: right. Sadly.
20:17:27 <ttx> makes it clearer what changes and why
20:17:41 <lifeless> ttx: sure
20:17:46 <russellb> not really in the spirit of our licensing to prevent it, either ... i look at it as more that we don't want to artificially limit scope
20:17:55 <lifeless> ttx: my concerns are being actioned by russellb and mordred now, so I happy :)
20:17:56 <jeblair> we will not accept contributions that only exist to facilitate them
20:18:07 <ttx> ok, then I'll approve this now based on current approvals
20:18:07 <mordred> jeblair: ++
20:18:30 <ttx> approved
20:18:48 <ttx> looking forward to the discussion on watering down the language there (or not)
20:18:52 <russellb> we're efficient in this new year
20:19:01 <ttx> #topic Remove containers from Nova's mission
20:19:04 <ttx> Moar fun
20:19:06 <mordred> SOOOOOO
20:19:06 <russellb> all kinds of agreeing
20:19:07 <purp> russellb: was just noticing that. =]
20:19:09 <ttx> #link https://review.openstack.org/256440
20:19:13 <mordred> there's tons of good feedback on this one
20:19:13 <ttx> The discussion is still ongoing on this one
20:19:24 <ttx> Most seem to agree that containers are a second-class citizen in Nova, so the mission could omit them
20:19:28 <mordred> which has made me want to circle back around and try to express the intent before hacking on wording
20:19:30 <ttx> BUT most seem also to agree that support for containers should stay in Nova
20:19:34 <mordred> yah
20:19:39 <ttx> So the discussion is now around what changing the mission would actually result in.
20:19:42 <mordred> I don't think I ever wanted to suggest deleting them
20:19:50 <mordred> it's pluggable, you can do whatever
20:20:11 <russellb> just not the primary intent of the API
20:20:29 <mordred> but making it clear that nova's purpose in life is not to be a docker/kube competing container management/orchestration system, but rather a system that shines as infrastructure on which to run things like kube and swarm
20:20:32 <russellb> making it a primary target implies lots of stuff that could/should be done, so makes sense to change it to me
20:20:39 <mordred> russellb: exactly
20:20:44 <russellb> ++
20:20:53 <mordred> I do not believe what is currently written in this expresses that clearly
20:21:05 <mestery> mordred: ++ to what you're saying there
20:21:11 <russellb> nice to see all the good feedback
20:21:32 <mordred> and to the concern in the comments, I think if we do it _right_ it's a positive message to the container ecosystem, not a "openstack doesn't care about containers"
20:21:39 <ttx> mordred: agree that putting containers on the same level as VM in the current mission was a bit misleading
20:21:41 <dhellmann> on a procedural note, how do we get the nova team to sign off on the change, since they're not pushing it?
20:21:49 <ttx> dhellmann: ptl +1
20:21:54 <lifeless> dhellmann: ask them ?
20:21:59 <ttx> although in theory we can just push it
20:22:07 <sdague> well, there is a lot of nova core feedback on the change already
20:22:12 <mordred> I think getting nova ptl happy is important
20:22:14 <ttx> I'd rather have them agree with the mission they have :)
20:22:17 <mordred> ++
20:22:18 <dhellmann> sdague : enough, though?
20:22:23 <sdague> dhellmann: it's mostly negative
20:22:36 <jbryce> i think the “run a kernel/image/look like a server” delineation coming from the earlier position around defcore is really important. containers can sometimes look like a server—a unit of infrastructure—but more and more are used as the application unit vs an infrastructure unit and i think that kind of usage is what fits poorly with nova
20:22:48 <dhellmann> sdague : how many nova core +1 do we need to feel comfortable that the team has had a chance to consider the change?
20:22:51 <mordred> jbryce: ++
20:22:54 <devananda> mordred: no, I jbryce ++
20:22:59 <dhellmann> sdague , ttx: I don't think the ptl is enough
20:23:01 <russellb> dhellmann: i'd say leave that to the PTL to ensure before he signs off
20:23:02 <devananda> woops. typo
20:23:03 <bauzas> I don't really see a consensus on removing that
20:23:13 <russellb> meaning, trust the PTL to gather the team's consensus
20:23:43 <purp> russellb ++
20:23:49 <sdague> right, so what about just truncating the mission statement
20:23:57 <sdague> To implement services and associated libraries to provide massively scalable, on demand, self service access to compute resources.
20:24:03 <jbryce> treating containers in ways that look like a server makes some sense under the nova api and i think people will continue to have some use cases for that. treating a container in the way that kubernetes does for instance makes no sense in nova land to me
20:24:11 <sdague> and stop calling out the tech
20:24:13 <russellb> jbryce: agreed
20:24:24 <jbryce> sdague: i think “compute resource” is not quite specific enough, thought, and leads to some of the confusion
20:24:29 <dansmith> sdague: FWIW, I think calling out the specific layer is important
20:24:35 <dansmith> jbryce: agreed
20:24:36 <russellb> yeah, i think some more detail is useful here
20:24:44 <jbryce> sdague: a kubernetes container construct is about a differently abstracted type of compute resource
20:24:52 <dansmith> TBH, I don't really want baremetal to be in the scope as stated
20:24:53 <sdague> sure, and I don't disagree with that
20:25:04 <devananda> dansmith: calling out the specific tech is only adding confusion, esp. as the tech (and how its used) changes
20:25:05 <jbryce> hence why i (clunkily) was saying infrastructure unit of compute vs application unit of compute
20:25:21 <dansmith> devananda: well, I disagree :)
20:25:25 <jbryce> don’t know that i have the best terms myself, but when i’ve talked with people about the issue that seems to be where things start to get confusing
20:25:28 <mordred> dansmith: right. but I think _that_ is a different conversatoin tbh - I was trying to keep this specifically about "things that can run kernels" vs " things that can't"
20:25:39 <sdague> but I also think that this sentences is the wrong place to slice all that
20:25:42 <mordred> dansmith: since the bare metal conversation is on murkier lines and needs to also be sorted out
20:25:46 <devananda> dansmith: unless you think nova should be about virtualization -- and nothing else?
20:25:47 <sdague> I mean look at the mission statements from other projects
20:25:54 <sdague> "To implement services and associated libraries to provide on-demand,
20:25:54 <sdague> scalable, and technology-agnostic network abstraction."
20:26:08 <russellb> heh, yeah, that's pretty broad
20:26:15 <mestery> Indeed
20:26:18 <dansmith> mordred: yeah I just would hate someone to expect us to adopt another baremetal driver peer to ironic on the grounds that it's in here. But, agree it can be a different convo
20:26:27 <ttx> It's an aspiration, not a description
20:26:31 <mordred> dansmith: I also agree with that - that would be hella yuck
20:26:35 <mestery> Something to strive for
20:26:42 <markmcclain> mission: boil the ocean
20:26:47 <dansmith> heh
20:26:47 <ttx> the goal, not the status
20:26:50 <devananda> dansmith: I agree with your concern there too
20:27:07 <mestery> sdague: I really like your truncated mission statement from above.
20:27:21 <ttx> mordred: so it looks like you need to have another take at wording and come back another week ?
20:27:28 <mordred> oh yeah
20:27:31 <sdague> because I think that what gets done in a project  at the end of the day is based on a shared understanding in that project
20:27:46 <mordred> sdague: it is - BUT - nova is special and important tbh
20:27:53 <ttx> and then we need to revive the feedback loop from Nova people
20:27:57 <dansmith> sdague: we do have a mission statement in nova itself, so should this just say "do what nova considers to be its mission" ?
20:28:03 <mordred> in that people outside the project need to understand its boundries more so than with the other projects
20:28:09 <sdague> and in reality, I think there is a general shared understand in Nova right now that this is mostly about Virt, and some other things that can expose to look at it a bit, when they make sense.
20:28:15 <bauzas> I know that johnthetubaguy is pushing hard for describing feature classification, it would probably help the discussion
20:28:56 <dansmith> bauzas: still, johnthetubaguy has said on that review that he favors things that run a kernel, so I think he's still on board with tightening
20:28:57 <bauzas> I mean, we have some feature capabilities that need to be accepted by drivers, others that would not be fine for some features look not good for Nova mission
20:28:58 <sdague> bauzas: yeh, that's a long road to get there
20:29:02 <mordred> thing is - I tihnk this isn't just about the nova team - largely because the nova team thinks it's just about virt - but consumers want a compute api that can give vms and bare metal - so if nova is just a virt layer, we might need to grow a compute consolidation layer that  has nova and ironic backends
20:29:21 <mordred> and I think that's a very big kind of decision
20:29:26 <ttx> Also not totally sold on this change being a natural consequence of the previous position on byok
20:29:44 <mordred> dansmith: ++
20:29:49 <edleafe> ttx: +1
20:29:53 <cdent> mordred: I think that's somewhat true. I also think people want to sometimes choose a container
20:29:54 <mestery> mordred: That would be a much larger decision
20:29:54 <bauzas> dansmith: yeah, I agree with that position
20:30:00 <lifeless> mission statements are largely for not-the-team IMO
20:30:01 <cdent> not coordination thereof, just booting one
20:30:09 <lifeless> they are a coordination and communication thing
20:30:19 <ttx> It's a welcome clarification on what the priority is, not a natural consequence of byok
20:30:22 <jbryce> mordred: i agree completely
20:30:25 <bauzas> our hypervisor support matrix already provide some way to explain what a nova driver should implement
20:30:48 <mordred> cdent: I have heard people say tht they've heard people want that, but I haven't experienced many people actually wanting that - as evidenced by how historically nobody has ever cared about the lxc driver that's been there for 6 years
20:30:54 <devananda> so it seems there are two parallel ways of looking at this: is Nova only about virt (or also baremetal or containers or other tech)  vs. is Nova about "computers" or "units of compute"
20:31:31 <bauzas> that comes to a far larger scope
20:31:47 <ttx> mordred: yeah, I don't expect fat (infra-unit) containers to stay a thing for long
20:31:55 <mordred> me either
20:31:58 <purp> lifeless: Having struggled with how to explain the reasoning for a DefCore decision, I tend to agree ... but they need to be crisp enough to help the team think, too.
20:32:12 <devananda> as jbryce said earlier, the way many folks use containers does not fit well with Nova as it is today -- and I think that's perfecty fine
20:32:13 <lifeless> purp: certainly, yes.
20:32:24 <mordred> devananda: ++
20:32:38 <devananda> and I think it's worth the TC making a statement about that
20:33:24 <sdague> I guess I'm not seeing that urgency, personally. We had one confused product team at Oracle that did a thing we didn't like. We've clarified that.
20:33:37 <ttx> OK, I propose we continue the debate on the review until at least next week. I suspect mordred might push a new rev
20:33:46 <annegentle> sdague: I think that's where I am also. Project team missions are their missions.
20:34:03 <sdague> I think it's ok that we react to things that people do that we don't like by telling them so
20:34:12 <dansmith> annegentle: +1, and since the TC one currently disagrees with nova's stated one, there should be a fix
20:34:36 <sdague> not by trying to preemptively imagine all possible failures and protect against them
20:34:45 <annegentle> dansmith: patch the nova repo you mean?
20:34:52 <mordred> sdague: I agree - it's not urgent. however, I think it is important to start a conversatoin about the vm/baremetal/conatiner intent more broadly than nova-core, becuase I think more than any other team this particular topic is super far-reaching in terms of openstack as  awhole
20:34:53 <dansmith> annegentle: no, patch the TC one
20:34:53 <devananda> I'd also like to see some clarification from the nova team as to whether they view Nova as specific to virtualization technologies, since that has come up a few times in this discussion
20:35:00 <annegentle> dansmith: ah ok then yep
20:35:03 <devananda> mordred: ++
20:35:14 <dansmith> annegentle: nova has a documented mission, and if the TC one conflicts, then change the TC one (or loosen to remove the conflict)
20:35:26 <devananda> this topic has significant implications for workload scheduling across projects
20:35:29 <jbryce> sdague: i can see not requiring a new policy to be adopted, but i think discussing these and working through the issues is actually very valuable
20:35:35 <dansmith> mordred: who are you calling an awhole?
20:35:41 <devananda> that is one of, if not, my main interest in it right now
20:35:44 <mordred> dansmith: who am I not? :)
20:35:48 <dansmith> mordred: touche.
20:35:48 <annegentle> dansmith: snort
20:35:54 <ttx> alright, let's move on
20:36:06 <ttx> next topic!
20:36:06 <mordred> if the nova team thinks one thing for the future of openstack, and the tc thinks a different thing - we need to dig in to that and figure out it - so consider this mainly just an opening to the conversation
20:36:08 <purp> sdague: I'd argue it's useful to clarify now to lend more guidance/direction so that future folks don't go so far astray.
20:36:14 <annegentle> it's a valuable conversation and needs lots of talk lots of places :)
20:36:18 <mordred> annegentle: ++
20:36:24 <ttx> and a discussion we'll continue soon !
20:36:30 <ttx> #topic Cross-project spec rubberstamp: Add clouds.yaml support specification
20:36:31 <annegentle> thanks jbryce for insights also
20:36:32 <sdague> purp: I will be massively surprised if 1 paragraph in a yaml file prevents people from going astray
20:36:39 <ttx> #link https://review.openstack.org/#/c/236712
20:36:51 <ttx> annegentle posted a few questions and asked for clarification, not much answers on this one
20:37:02 <sdague> after many dozen person to person conversations did not
20:37:02 <purp> sdague: True, but it's also the transcripts of these discussions and the review comments that get used as guidance.
20:37:06 <ttx> mordred: ETOOMANYREVIEWS
20:37:13 <mordred> ttx: inorite?
20:37:16 <ttx> Maybe simpler to wait ?
20:37:49 <ttx> unless you feel you can answer live to Anne
20:37:58 <annegentle> ttx: should I follow up on any of the projects to research their current state?
20:38:14 <annegentle> or maybe mordred knows what to do with them :)
20:38:14 <mordred> annegentle: new projects should implement cli's as plugins to openstackclient
20:38:35 <annegentle> mordred: yeah, that sounds right to me
20:38:41 <mordred> annegentle: existing projects ... I'm working on making patches for all of them :)
20:38:58 <mordred> I mostly wrote this so I wouldn't have to explain why I was writing patches for everyone 100 times
20:39:10 <ttx> annegentle: so do we need another rev or are you good with that one ?
20:40:01 <annegentle> mordred: I still need a line for "what do newish projects do?"
20:40:08 <mordred> kk
20:40:10 <mordred> I'll rev
20:40:16 <annegentle> mordred: thanks
20:40:18 <ttx> alright, let's push it back
20:40:22 <ttx> #topic Cross-project spec rubberstamp: Backwards compat for libraries and clients
20:40:27 <ttx> #link https://review.openstack.org/#/c/226157
20:40:30 <mordred> yay this one isn't me!!!
20:40:36 <annegentle> heh
20:40:45 <ttx> arh nothing like a last-minute -1
20:40:52 * ttx reads
20:41:02 <lifeless> \o/
20:41:05 <lifeless> yeah
20:41:18 <lifeless> mriedem: so, the dependency mgmt spec covered the issues with capping
20:41:29 <lifeless> mriedem: I really don't want to revisit that *again*
20:41:50 <lifeless> mriedem: not when its already a spec, and nothing has changed to make capping better
20:41:51 <mriedem> i don't really have that spec in my head atm
20:42:05 <mriedem> there have been things which have made capping less painful
20:42:10 <mriedem> which i've pointed out several times before
20:42:12 <lifeless> https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
20:42:39 <ttx> lifeless: if you end up doing another rev, maybe leave the tag details to the tag definition discussion, as I suggested. But don't do a rev just for that
20:43:41 <lifeless> ttx: I think I need to, because release-constraints won't be static - it will change as libraries do point releases
20:44:04 <lifeless> ttx: I didn't add that back in after adding stable branches-stay-a-thing-in post summit discussion, and mriedem noticed (thanks!)
20:44:08 <ttx> lifeless: ok. Maybe that one was not that ready for rubberstamping after all
20:44:32 <ttx> let's push it back to the drawing board for a bit ?
20:44:33 <lifeless> ttx: well, it did previously have mriedem 's +1, so who knew :/
20:44:38 <ttx> heh
20:44:48 <ttx> it's the 2016 mriedem
20:44:50 <mriedem> well, it's a big spec, and we were hashing it over again in irc today
20:44:57 <mriedem> i've never been crazy about this honestly
20:45:02 <mriedem> but i've gotten tired of fighting it
20:45:06 <dansmith> yeah, there was a big discussion on IRC today,
20:45:14 <dansmith> which seemed to open a lot of significant concerns
20:45:25 <dansmith> from myself, the stable PTL, and the oslo PTL
20:45:28 <lifeless> mriedem: I think the point we disagree on is whether capping works
20:45:35 <dansmith> so I don't think acting like mriedem is crazy is appropriate here
20:45:45 <ttx> better now than after we approve the spec :)
20:45:47 <lifeless> dansmith: noone is acting like mriedem is crazy, are they ?
20:45:55 <mriedem> i get that capping sucks, but it's sucked for a reason many times in the past (icehouse and juno are fresh in my mind), and a lot of those reasons have been improved
20:46:00 <dansmith> lifeless: the language used above is kinda rude and not very welcoming to discussion, yeah
20:46:38 <lifeless> dansmith: thanks for letting me know, though I really can't see that. He had voted, we moved to rubber stamp, and then a problem was found (excellent!) and we're discussing it more
20:47:01 <ttx> I for one welcome the extra discussion. We need to get those things right
20:47:06 <lifeless> dansmith: I kinda feel like you're escalting in the worst possible way what I'm typing on IRC today
20:47:07 <mriedem> i've always thought this was weird from a packaging perspective
20:47:17 <dansmith> TBH, I hadn't had a chance to read this spec before the large discussion today, so I haven't commented on it,
20:47:35 <dansmith> but it seems like there are some implications or procedures that need to get worked out
20:47:35 <lifeless> anyhow, procedure wise, this is not ready for TC rubber-stamp
20:47:56 <ttx> yes
20:48:05 <lifeless> so lets let the meeting proceed, and folk interested in this can go to openstack-dev probably as the most relevant place, and we can discuss further
20:48:07 <ttx> We may have to schedule it again for cross-project discussion if necessary
20:48:20 <ttx> lifeless: agreed
20:48:22 <ttx> #topic Open discussion
20:48:29 <ttx> * "Upstream development" track at the Austin OpenStack Summit
20:48:38 <ttx> Over the holidays came the good news that we'll have an "Upstream development" track at the Austin Summit
20:48:47 <ttx> It's something I suggested a couple of months ago so that we can clearly have upstream-developer-targeted presentations
20:48:56 <ttx> without artificially using cross-project workshop space just to raise developer awareness on specific topics
20:49:00 <annegentle> ttx: remind me, which direction is that?
20:49:05 <ttx> It shall happen on the Monday in Austin, with Design Summit starting on Tuesday
20:49:05 <annegentle> ttx: ah ok
20:49:13 <ttx> Things I expect to fit in this track are:
20:49:19 <ttx> general communication about development process changes
20:49:26 <ttx> new features in a central project that need adoption in other projects
20:49:32 <ttx> present corner use cases that may need support from development
20:49:39 <ttx> developer-oriented infra talks
20:49:45 <ttx> development best practices, lightning talks on cool tricks
20:50:01 <ttx> things we abused other tracks for in the past, with varying success
20:50:14 <ttx> I'll need a couple of co-chairs for this track. I suspect everyone is interested, but I only need a few, so only raise your hand if you *really* want to be part of it :)
20:50:36 <ttx> questions on that ?
20:50:42 <russellb> i like it :)
20:50:45 <russellb> that's not a question, though.
20:50:50 <jeblair> russellb: do you like it?
20:50:50 <mestery> Very good idea (also not a question)
20:50:58 <russellb> jeblair: i do!  thanks for asking!
20:51:08 <sdague> might be worth a brain storming session on the stuff we'd like to see in there, and rounding up volunteers
20:51:12 <ttx> (NB: we still have "project updates" as a track for developers to present new features to operators/endusers)
20:51:26 <dhellmann> sdague : ++
20:51:37 <ttx> sdague: yes, before the deadline
20:51:45 <sdague> ttx: yep
20:51:53 <ttx> sdague: I'll take the action of organizing that
20:52:15 <ttx> #action ttx to set up a brainstorming about what the TC would like to see on the upstream dev track
20:52:27 <purp> n00b question: what does a co-chair do to help organize a track?
20:52:31 <ttx> sdague: I think I'd like to have a lightning talk slot on cool tricks
20:52:42 <ttx> purp:  vote on proposed talks
20:53:01 <purp> ttx ... and ... ?
20:53:02 <ttx> in this case I expect the co-chairs to reflect the consensus from the TC
20:53:13 <sdague> ttx: can we make sure those are recorded as well?
20:53:13 * purp doesn't believe anything is that simple. ;D
20:53:17 <ttx> purp: make the final selection in the summit org interface ?
20:53:37 <ttx> sdague: they should all be
20:53:44 <jbryce> sdague: recording with as well? upstream track or lightning talks?
20:53:50 <jbryce> which*
20:54:09 <edleafe> purp: trust us! :)
20:54:13 <ttx> jbryce: both I suspect... but everything would have a presentation format and benefit from our crazy AV support
20:54:15 <sdague> jbryce: upstream track
20:54:21 <purp> edleafe: you forget, I *know* you.
20:54:25 <purp> =D
20:54:31 <jbryce> upstream track will be recorded by default, lightning talks, may or may not be depending on where they end up
20:54:45 <sdague> ok, great
20:54:45 <ttx> jbryce: they would end up in a traditional presentation slot/room
20:54:47 <jbryce> unless you’re saying a lightning talk slot in the upstream track itself
20:54:53 <jbryce> ttx: ahh, then yes
20:55:03 <ttx> * N/O naming
20:55:07 <ttx> mordred: I've seen the poll results. Did you already push ordered candidate names to Lauren, or should I ?
20:55:23 <ttx> I kind of expect Newton to end up encumbered. Olimpic may also be an issue, given the IOC strongarmed enforcement of trademark. We'll see
20:55:23 <mordred> I have pushed them to lauren/foundation staff
20:55:24 <jbryce> ttx: if you want them separated out by video, let us know when you decide on a lightning talk slot because we’ll have to adjust the video set up for that
20:55:30 <annegentle> ttx: heh I was still parsing N/O
20:55:33 <jbryce> we’ve sent them to the trademark lawyers for review
20:55:38 <jbryce> waiting for feedback
20:55:53 <mordred> I kinda want newton to win so that we can get back at apple for stepping on swift
20:56:00 <jeblair> sadly NO name is NO go
20:56:15 <mordred> but that's maybe not a good official position :)
20:56:17 <edleafe> mordred: I don't think they'd be crying too much
20:56:23 <ttx> Anything else, anyone ?
20:57:50 <ttx> hmm, sounds like a no
20:58:17 <ttx> Alright then...
20:58:29 <ttx> #endmeeting