20:01:38 <ttx> #startmeeting tc
20:01:38 <openstack> Meeting started Tue Sep 30 20:01:38 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:42 <openstack> The meeting name has been set to 'tc'
20:01:48 <ttx> Our agenda for today:
20:01:55 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:05 <ttx> This is the last meeting for the Juno membership, unless we decide to meet during election season
20:02:13 <ttx> (We'll discuss that in Open Discussion at the end of this meeting.)
20:02:25 <mordred> o/
20:02:27 <ttx> #topic Recommendation to Adopt DCO as CLA
20:02:35 <ttx> jeblair is proxied by mordred
20:02:42 <ttx> #link https://review.openstack.org/120260
20:02:47 <mordred> jeblair is in favor of this
20:02:54 <ttx> Last time I looked it was still missing a few votes
20:03:01 * devananda reads
20:03:13 <annegentle> sorry I'm late
20:03:19 <mordred> oops. I forgot to actually vote before
20:03:21 <sdague> ttx: it has 7 votes
20:03:58 <ttx> ok, I'll let a few more minutes anc collect it at the end of the meeting
20:04:14 <zaro> jesusaurus: for python 3 support: https://review.openstack.org/#/c/118703/
20:04:18 <ttx> any comment on that before we move to next topic ?
20:04:22 <jesusaurus> zaro: thanks
20:04:33 <markmc> ttx, yeah, we want this on the agenda for joint meeting in Paris, I assume
20:05:10 <ttx> #action ttx to propose the DCO resolution as part of the agenda for joint TC/Board meeting in Paris
20:05:15 <sdague> +1
20:05:18 <markmc> thanks
20:05:20 <ttx> #topic Add a docs environment to the testing interface
20:05:27 <ttx> #link https://review.openstack.org/119875
20:05:34 <ttx> Feels like jeblair has a pretty valid objection there
20:05:57 <ttx> mordred: let's see if you can impersonate both +1 and -1 here
20:06:03 <annegentle> so I do understand jeblair's concern
20:06:12 <annegentle> oh yes let's let mordred represent :)
20:06:45 <dhellmann> any steps we want to automate through the tox.ini can be automated directly inside of sphinx, too
20:06:55 <dhellmann> doc8 could be a sphinx extension
20:07:10 <ttx> Feels like we don't have a winner here
20:07:11 <sdague> dhellmann: I suppose, we have a lot of entry points for people
20:07:31 <dhellmann> sdague: yeah, as a usability thing I like having docs, but we could also let infra keep building docs using the venv entry point
20:07:36 * mordred working up impersonation
20:08:00 <dhellmann> sdague: my point is, we can have both of the things we want if we do them carefully
20:08:30 <mordred> dhellmann: ++
20:08:44 <ttx> mordred: so this neds more work ?
20:08:46 <ttx> needs*
20:08:47 <mordred> I think dhellman just said what jeblair was trying to get at
20:08:49 <mordred> I think so
20:09:01 <dhellmann> I'll leave a comment on the patch
20:09:05 <ttx> ok, maybe we can skip this, then
20:09:09 <mordred> the concern is that we make setup.py build_sphinx not actually able to do its job
20:09:10 <ttx> and worflow-1 it
20:09:13 <mordred> ++
20:09:21 <sdague> yeh, I left my comments
20:09:23 <ttx> moving to next topic ?
20:09:31 <sdague> ttx: go for it
20:10:17 <ttx> just approved the dco resolution
20:10:21 <ttx> (10 yes)
20:10:27 <ttx> #topic Remove support for specific public cloud implementations from our code
20:10:30 <zehicle_at_dell> o/
20:10:38 <ttx> #link https://review.openstack.org/122968
20:10:41 <mordred> I need to rewrite this, sorry
20:10:49 <ttx> Right... at the very least, would need to stop mentioning Rackspace explicitely, if only so that the same rule can apply to others in the future.
20:10:51 <mordred> I apologize for my tone and wording
20:10:55 <sdague> I agree with jaypipes and markmc, concept ok, wording harsh
20:11:11 <mordred> yah. I was pissed of that python*clients were not working for simple tasks
20:11:17 <mordred> s/of/off/
20:11:24 <mordred> but I'll fix that
20:11:31 <ttx> when mordred is pissed, he posts a governance patch. When he is happy, he does a blogpost
20:11:35 <mordred> :)
20:11:36 <sdague> heh
20:11:45 <zaneb> mordred: can we have some specifics about which projects are affected?
20:11:46 <mordred> unless we feel the underlying idea needs discussion?
20:12:04 <sdague> on a saturday afternoon non the less
20:12:05 <dhellmann> are we asking projects to remove the code, or suggesting that is' ok?
20:12:09 <zaneb> mordred: I feel like the Heat ones at least need to be looked at case-by-case
20:12:17 <zaneb> it's not clear if there are others also
20:12:20 <mordred> zaneb: I agree - I think you made excellent points
20:12:26 <ttx> mordred: there is lack of consensus on whether we should force, ask, or advise removal of implementation -specific code
20:12:38 <mordred> the patches that set that off were docs entries describing HP and Rackspace API extensions
20:12:54 <mordred> I feel that those should just flat be disallowed - and the equivilent code as well
20:12:59 <annegentle> mordred: I did approve the extension removal from the docs, as it reduces our scope
20:13:16 <mordred> such as python-*client support for rax_auth, as an example
20:13:18 <mordred> but that may just be me
20:13:24 <annegentle> mordred: but the original vision was a shared extension place that anyone could come and get extensions from and re-use in their own implementation
20:13:29 <annegentle> so it's a little tricky
20:13:37 <sdague> so, honestly, I think advise remove is appropriate
20:13:39 <mordred> well, the shared extensions ARE in bounds
20:13:41 <annegentle> how do we enable the original vision (make cool extensions that eventually become core)
20:13:47 <mordred> like floating-ip
20:13:57 <mordred> when the extension is named EXT-HP it's clearly not a shared extension
20:14:08 <sdague> annegentle: so, realistically, I think the extension story is going to change from the original vision
20:14:09 <mordred> it's an HP product thing
20:14:16 <annegentle> mordred: right, I'm well aware of that
20:14:22 <sdague> but that's longer term evolution
20:14:28 <annegentle> mordred: just also making sure the original vision is understood by the tc
20:14:32 <sdague> because that's actually a huge interop issue
20:14:33 <mordred> annegentle: nod
20:14:50 <mordred> sdague: advise remove sounds good to me
20:15:15 <mordred> sdague: because zaneb  has some excellent points about some times when it makes life easier for heat devs themselves to carry some things
20:15:21 <ttx> mordred: ok, you can work on a new version based on that ?
20:15:25 <mordred> ttx: I will
20:15:41 <ttx> other comment on that before we move on ?
20:15:46 <mordred> but I don't like seeing things like workarounds for product decisions, tbh
20:16:10 <zaneb> iirc one time Keystone added a feature for Heat and it was called EXT-RHAT or something for a while (it was changed to EXT-OS)
20:16:29 <zaneb> so the extension name may not always be a reliable guide
20:16:52 <annegentle> true zaneb
20:17:16 <mordred> http://git.openstack.org/cgit/openstack/heat/tree/contrib/rackspace/rackspace/clients.py#n176
20:17:25 <mordred> is the type of thing that makes my blood boil
20:17:29 <mordred> the comment there
20:18:00 <mordred> because a vendor choses to not list swift in thier keystone catalog (which is a pain point for users, btw) - we have code in an openstack repo to work around it.
20:18:20 <russellb> zaneb: but that extension was not red hat specific at all, it was just an absolutely horrible name
20:18:32 <ttx> I agree that doesn't sound like the best to encourage them to stop their insanity
20:18:41 <zaneb> russellb: agreed, and I was glad it changed
20:18:57 <russellb> "name the extension after the company that employs the developer" was the scheme iirc
20:18:59 <zaneb> russellb: but the name reflected an understanding of policy that at least some people had at one time
20:19:22 <russellb> yep, no idea how wide that applies, but i do recall that specific case
20:19:34 <mordred> yup. my punative tone aside, I really am more interested in communicating what we think should be happening in a productive way moving forward
20:19:45 * mordred wears shame hat
20:20:09 <russellb> a less-ragey "don't do product/vendor specific API stuff" sounds fine :)
20:20:30 <Guest43089> less rage, mo bettah
20:20:32 <Guest43089> gah
20:20:33 <ttx> mordred: proxying jeblair changed you. You seem all reasonable
20:20:46 <mordred> ttx: I'm wearing a hat and slacks too
20:20:53 <markmcclain> haha
20:20:59 <annegentle_> pants? what?
20:21:02 <ttx> now I wonder who is proxying who.
20:21:18 <annegentle_> ha ha ha
20:21:24 <rockyg> more like channelling
20:21:24 <ttx> #topic Other governance changes
20:21:27 <zaneb> mordred: fwiw I think the client plugin specifically could be moved out of tree with probably no ill effects
20:21:46 <ttx> * Add tripleo-puppet-elements in programs.yaml (https://review.openstack.org/123826)
20:21:52 <ttx> I'd like to have the former/future TripleO PTL ack on that one
20:22:09 <mikal> ttx: you saw his email saying he's AWOL?
20:22:11 <ttx> lifeless: a comment there saying you want it would be nice, before you step down if possible.
20:22:25 <ttx> mikal: I may have missed that
20:22:30 <mordred> ttx: both? or you want SpamapS and slagle to both ack?
20:22:30 <devananda> SpamapS: ^ ?
20:22:41 <mikal> I have had an unexpected family matter turn up, and may be absent at
20:22:41 <mikal> fairly arbitrary points for a couple weeks while we deal with the
20:22:42 <mikal> fallout.
20:22:42 <mikal> I've asked Clint to wear my PTL hat between now and the 3rd when
20:22:42 <mikal> voting closes and we find out whether he or James are the new PTL.
20:22:44 <mikal> He has my real world contact details should something urgent which
20:22:46 <mikal> only I can do [there should be no such things] turn up.
20:22:56 <mikal> ^-- Subject: [openstack-dev] [TripleO] PTL leave of absence
20:23:13 <lifeless> commented
20:23:24 <ttx> lifeless: thx!
20:23:27 <russellb> nice!
20:23:27 <mordred> oh look. a lifeless
20:23:27 <ttx> will approve asap
20:23:33 <mikal> lifeless: you do absent poorly
20:23:35 <ttx> like.. now
20:24:11 <lifeless> mikal: and arbitrary points
20:24:14 <ttx> * Add python-keystoneclient-federation to the Identity program (https://review.openstack.org/123786)
20:24:18 <lifeless> mikal: s/and/at/
20:24:19 <ttx> This one is proposed by Morgan, so I'll approve it unless someone complains really soon
20:24:27 <ttx> * Add two new repos to infra program (https://review.openstack.org/124238)
20:24:32 <ttx> This one is proposed by Jim, so I'll approve it unless someone complains really soon
20:24:58 <sdague> yeh, these are seem procedural
20:25:11 <ttx> ok, that leaves plenty of time for an interesting open discussion
20:25:15 <ttx> #topic Open discussion
20:25:28 <ttx> I doubt you missed it, but we are having a big discussion on structural changes around the integrated release / incubation / ecosystem concepts
20:25:33 <ttx> Mostly kicked off by mordred's "Layer #1 and the big tent" blogpost
20:25:39 <dhellmann> are we publishing the governance repo docs anywhere yet?
20:25:43 <ttx> We have a number of discussions that were shelved as a result, as they only make sense within the current structure:
20:25:51 <ttx> - Deeper dive into Swift "differences" and which ones we should try to reduce
20:25:56 <ttx> - The Kilo plan for Zaqar
20:25:57 <russellb> lots of talking ... i think we need to move to concrete proposals
20:26:02 <russellb> to make sure we're all talking about the same things
20:26:07 <ttx> Both don't really make sense in a world where Swift/Zaqar would not be part of the layer #1
20:26:14 <ttx> So we should have that discussion first
20:26:20 <annegentle_> oh I must thank vishy and ttx for standing up for docs... I haven't been able to formulate enough thoughts on that thread to reply
20:26:31 <ttx> Other questions we need to solve during the next 30 minutes:
20:26:38 <ttx> should we meet over the next 2 weeks (TC election season) ?
20:26:43 <mikal> I personally think Swift should be in layer 1
20:26:47 <ttx> should we organize a TC dinner ?
20:26:49 <mikal> Just to make this discussion more interesting
20:27:06 <ttx> Who would like to write up the final "Technical Committee Update" ?
20:27:06 <russellb> i'd like a more formal proposal for what layer #1 even means
20:27:07 <mordred> so - I believe there is no way to actually have that discussion in 30 minutes
20:27:15 <mordred> I agree with russel
20:27:16 <russellb> mordred: ++
20:27:28 <mikal> I wrote yet another blog post on this topic yesterday, but hven't hit publish yet
20:27:29 <markmc> definitely should make sure a question on this debate is in the TC candidate election question thing
20:27:31 <anteaya> two lls in russell
20:27:35 <mordred> I've been holdin off on submitting governance changes to discuss - mainly because i don't know if we're going to take lame-duck action or not
20:27:37 <mikal> To be honest I don't think layers guide us in what to exclude or not
20:27:39 <markmc> would be good to see something like http://blogs.gnome.org/markmc/2013/10/18/a-new-openstack-technical-committee/ again
20:27:39 <zaneb> mikal: +1. if we have Layer 1 it should be Swift, Zaqar, Nova; Layer 1.5 anything needed to make those work
20:27:46 <zaneb> Layer 0: Keystone
20:27:48 <mikal> But they do help us break the ecosystem into more managable chunks
20:28:00 <mordred> so to me we need to decide if we're going to do something now or wait until next TC
20:28:07 <mordred> before any further anything makes sense
20:28:07 <anteaya> markmc: the tc questions have been published
20:28:09 <devananda> as far as wording, I would suggest s/layers/rings/
20:28:13 <russellb> it's the next TC's baby IMO
20:28:13 <markmc> anteaya, doh
20:28:21 <russellb> doesn't mean we can't start on formalizing a proposal to talk around now though
20:28:22 <markmc> anteaya, thanks, and sorry
20:28:23 <dhellmann> anteaya: where are those?
20:28:23 <ttx> next TC baby, agreed
20:28:28 <devananda> ttx: ++
20:28:30 <anteaya> markmc: i purposely didn't include questions on this topic since the discussion is so active on the ml
20:28:46 <ttx> it's actually quite great to have an election with the question already on the table.
20:28:49 <anteaya> markmc: but any candidate can say whatever they wish in their platform
20:29:01 <anteaya> dhellmann: on the wikipage I linked last week and will link again
20:29:02 <jogo> thoughts on dealing with some of the testing changes before the layer issue?
20:29:02 <mordred> zaneb: you and I have VERY different ideas about layer 1, btw
20:29:06 <mordred> :)
20:29:12 <zaneb> mordred: yes, I know :)
20:29:19 <sdague> jogo: they are realistically kind of linked
20:29:22 <devananda> while I think we could field some proposals before the summit, I question whether we will collectively be able to address them without the in person discussions that wil happen there
20:29:27 <mordred> zaneb: swift and zaqar are advanced services for people who are super cloud saavy
20:29:28 <anteaya> #link https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions
20:29:41 <anteaya> markmc: no problem
20:29:44 <zaneb> mordred: tell that to SwiftStack
20:29:45 * russellb has to go now, sorry ... last second unexpected flight to catch
20:29:46 <sdague> because whatever is in the base is by definition tightly coupled
20:29:50 <jogo> sdague: but there are definitely testing changes that can be made before any layer changes
20:29:52 <dhellmann> anteaya: thanks
20:29:56 <anteaya> dhellmann: np
20:30:01 <vishy> I move that any proposal starts with “Whereas…"
20:30:03 <jogo> and I don't think we can wait on some of the testing issues
20:30:07 <sdague> vishy: ++
20:30:17 <ttx> One thing we could want to discuss during next two weeks is the final state for Juno gap coverage plans
20:30:32 <ttx> since we didn't really close them yet
20:30:34 <dhellmann> vishy: we save those for communicating with the board
20:30:43 <sdague> ttx: so it seems like about 4 conversation topics all got put out here in the last 4 minutes
20:30:48 <devananda> sdague: I would be thrilled to see the two-project gating changes start being implemented sooner
20:30:49 <sdague> which one are we actually trying to ahve
20:30:51 <devananda> rather than later
20:30:55 <vishy> I think there has been pretty strong consensus on one of the topics
20:31:08 <vishy> which is to break up the integrated gate into functional testing scenarios
20:31:18 <vishy> and not cross gate everything on everything
20:31:20 <markmcclain> ttx: +1 for final gap plans being discussed because that is still a function of this term's TC
20:31:22 <ttx> sdague: hmm, let's have a ring0/layer1 discussion first
20:31:28 <mordred> right. the main disagrement is how much stuff to cross-gate on
20:31:32 <sdague> vishy: yeh, and I honestly think you summed up that bit pretty well
20:31:35 <zaneb> vishy: +1, and also pretty strong consensus for enlarging the tent, I think
20:31:37 <ttx> and discuss need for meeting after
20:32:06 <jogo> devananda vishy: we can take other small steps such as: not running tempest on unit test only changes
20:32:19 <mordred> jogo: we can?
20:32:22 <annegentle_> I really like the functional testing scenarios and I can see doing some info architecture around that as well
20:32:45 <jogo> mordred: that wouldn't impact any big tent debate would it? (we can politically that is)
20:32:51 <mordred> jogo: physically
20:33:02 <mordred> just for the record, I'm very uncomfortable talking about anything that reaches into mechanics of test running without jeblair present
20:33:03 <vishy> mordred: do you think the cross-gating projects need to be selected by the tc? or can the projects themselves choose when to co-gate?
20:33:14 <devananda> vishy: self-selecting, IMO
20:33:21 <mordred> I disagree
20:33:25 <devananda> :)
20:33:26 <markmc> vishy, nice distinction
20:33:40 <devananda> mordred: outside of "ring 0"?
20:33:42 <annegentle_> vishy: mordred: functional tests would dictate
20:33:55 <mordred> I think that the functional test cross-gating is a project choice
20:34:02 <sdague> I think that's the definition of ring 0 realistly
20:34:04 <mordred> if tehre is a ring0/layer1, I think that is a tc call
20:34:11 <mordred> that thing could not exist
20:34:13 <devananda> right
20:34:17 <mordred> or could be the current integrated release
20:34:20 <sdague> that the tc dictates ring 0 testing policy
20:34:22 <mordred> or could be a subset
20:34:26 <dhellmann> I'd like to see us just have groups of co-gated projects, and not treat any group as special
20:34:27 <sdague> beyond that projects pick
20:34:35 <vishy> ok so our definition of ring0 would be that these are the things that must test together?
20:34:38 <annegentle_> (and not cross-doc everything)
20:34:42 <vishy> dhellmann: ++
20:34:42 <devananda> I think the TC needs to all agree on what "ring0" is, and taht needs to all cogate. beyond that, I think tprojects need to mutually agree,a nd the TC should not have to step in
20:34:50 <mordred> I do not believe that vastly increased project autonomy is likely to help achieve any goals we have
20:34:51 <mikal> dhellmann: agreed
20:35:02 <sdague> dhellmann / mikal / vishy: so that
20:35:06 <dhellmann> mordred: I don't either, but you started this :-)
20:35:08 <mordred> so, I do not believe that letting ring 0 emerge from project choices is likely to happen
20:35:09 <sdague> that's this "nice idea"
20:35:18 <annegentle_> problem with a large expansive ring0 is the functions aren't for everyone all the time (well, nothing is really)
20:35:19 <jogo> I am interested in seeing a new testing policy for our existing definition of OpenStack, as a testing policy is easy to revert but the large tent thing not so much
20:35:23 <sdague> but as someone who's had to chase after that implementation, it's a disaster
20:35:34 <zaneb> mordred: for everything, or just ring 0? because your proposal sounds like a free-for-all for everyone outside of ring 0
20:35:39 <annegentle_> sdague: boy I feel for you.
20:35:51 <sdague> and very few people that are proposing *all in* help at all on that
20:35:52 <ttx> I like that ring0 is a static set. i like that it is usercase driven.
20:35:52 <jogo> and  I assume getting the mechanics of the large tent just right will take time
20:36:20 <devananda> vishy: yes. ring0 == must be tested together. that's one of the requirements of it IMO, but not the driving reason to put those projects together
20:36:29 <ttx> I think multiple rings would just perpetuate the badge-granting role of the TC
20:36:34 <mordred> right - and while I agree with jogo that I'd like to see some changes made in how we test, I dont know of a specific change that makes sense that doesn't involve an implicit description of a ring 0
20:36:48 <zaneb> ttx: I don't like anything static. static = give up trying to respond to change
20:36:48 <anteaya> sdague: ++
20:37:16 <ttx> zaneb: how about "essentially static" ? We are not committing to never ever change. Who knows who will be on the TC next year.
20:37:56 <zaneb> we're committing to not have a process to respond to change, AIUI
20:37:59 <jogo> mordred: if we can't improve our testing policy soon I fear it will be a big impediment for kilo Development
20:38:04 <ttx> I've seen quite a few things change over the last 4 years, trust me. And a lot where seen as definitive choices when they were made
20:38:08 <mordred> jogo: I disagree
20:38:13 <mordred> jogo: I think it's important
20:38:30 <mordred> but we did just have the smoothest freeze we've had in quite a while
20:38:38 <annegentle_> ttx: heh on "seen as definitive"
20:38:39 <anteaya> we did
20:38:43 <jogo> mordred: whats important? the large tent debate?
20:38:48 <mordred> jogo: nope
20:38:49 <ttx> zaneb: if it works, it should stay static. If it fails, we'll change again
20:38:50 <jogo> mordred: that is relative
20:39:10 <mordred> jogo: what change would you make that wouldn't implicitly define a ring0 ?
20:39:13 <jogo> mordred: in nova we use recheck on over 60% of patch revisions
20:39:28 <mordred> jogo: then you should make some functional tests in nova
20:39:40 <sdague> mordred: or in neutron
20:39:46 <mordred> or everywhere
20:39:49 <sdague> yep
20:39:52 <mordred> that's not a policy that needs any help
20:39:55 <mordred> it just needs to be done
20:39:56 <anteaya> jogo: have you isolated how much of that is build issues and how much is dev poor habits?
20:39:57 <markmcclain> sdague: expect more in kilo for neutron
20:40:03 <ttx> We have a few other questions to cover, and there is no way we can conclude this discussion, so I'll timebox it to 5 more minutes.
20:40:05 <vishy> mordred: Our problems are not around freezes
20:40:10 <vishy> they are around code contributions
20:40:14 <zaneb> mordred: for once we agree ;)
20:40:35 <jogo> mordred: not run devstack on unit test changes is one.  we have an implicit ring0 - integrated release
20:40:36 <vishy> I’m not sure if people realize how incredibly painful it is for (even experienced openstack) devs to contribute
20:40:52 <jogo> anteaya: I have isolated it. most is build issues
20:40:55 <mordred> vishy: I do - but what can we approve here in the TC today that will make a marked difference before we get together with a new TC to discuss rings and tents?
20:40:59 <vishy> I think the only reason we have any contributions at all is because people are getting paid to work on this stuff
20:41:01 <jogo> anteaya: vast majority
20:41:10 <clarkb> jogo: I don't think you can make a promise that code in a repo changing won't break integration
20:41:12 <mordred> vishy: well, I think that has always and will always be the case, tbh
20:41:14 <anteaya> jogo: great, I look forward to your numbers after the meeting
20:41:18 <clarkb> jogo: its all arbitrary and you enforce that with tests
20:41:23 <devananda> mordred: nothing. i think we have to discuss this f2f to get anywhere with it
20:41:39 <clarkb> jogo: so skipping specific tests because $specificfile changes seems risky to me
20:41:45 <mordred> btw - our unaffiliated numbers are at the highest they've ever been this cycle - so SOMEHOW we're picking up more people who aren't fulltime openstack devs
20:41:53 <jogo> clarkb: if a unit test change breaks devstack, we have much bigger issues
20:42:02 <clarkb> jogo: hackin is the perfect example fwiw
20:42:06 <vishy> i do agree that if we are going to discuss this in person, we should have some concrete proposals on the table
20:42:08 <dhellmann> devananda: are we planning a f2f tc meeting in paris? I suppose that would be up to the new tc
20:42:08 <clarkb> jogo: unittests are code, that may be consumed
20:42:22 <zaneb> vishy: the hobbyist developer is honestly not a particularly important market for OpenStack
20:42:24 <sdague> yeh, I would agree developer contribution has more friction than it should, but I don't think that's the biggest issue
20:42:27 * mordred will make his blog post into governance patches
20:42:36 <mordred> before paris
20:42:48 <mordred> and will make sure they are concrete
20:42:51 <dhellmann> zaneb: I could see that class of developer contributing to oslo
20:42:55 <annegentle_> sorry all have to head to an appt. but will catch up in minutes
20:42:58 <sdague> zaneb: it's not the hobbiest dev, it's the IT person at a college
20:43:06 <sdague> that is going to be doing this only on their own time
20:43:09 <devananda> dhellmann: i'm not yet aware of one. but I thnk that is the best thing we can do: come up with concrete proposals and discuss in paris
20:43:12 <jogo> clarkb: but shouldn't be in devstack
20:43:15 <mordred> devananda: ++
20:43:16 <dhellmann> devananda: ++
20:43:25 <ttx> yes
20:43:25 <markmcclain> devananda: ++
20:43:26 <ttx> and wine
20:43:27 <vishy> sdague, zaneb: it is also developer retention
20:43:29 <sdague> that person is basically completely scared away from openstack
20:43:33 <devananda> mordred: I also think we need to change the terms so that they dno't appear to be "in or out"
20:43:35 <clarkb> jogo: maybe not devstack but definitely tempest
20:43:36 <vishy> most former openstack dev’s will not touch it with a 10-foot pole
20:43:37 <sdague> because there are so many moving parts
20:43:38 <vishy> and that is sad
20:43:43 <clarkb> jogo: or other testing toolin
20:43:56 <sdague> vishy: yeh, agreed.
20:44:03 <jogo> clarkb: so maybe we need a little bit more 'API' contract documentation around these things
20:44:07 <devananda> mordred: dhellmann: i'm happy to work with you (or anyone) on said proposals
20:44:11 <ttx> vishy: most of it is because it's going fast and it's hard to keep up, though
20:44:16 <mordred> devananda: I'd love that
20:44:28 <dhellmann> mordred, devananda : count me in, too
20:44:28 <vishy> ttx: not from what I’ve heard. In every case they got frustrated with getting patches merged
20:44:34 <devananda> the bblog posts have been great to share different POV
20:44:37 <vishy> to be fair my sample size is like 3
20:44:39 <vishy> :)
20:44:43 <devananda> those nee to be turned into specific suggestions
20:44:49 <mordred> vishy: fwiw, I've been trying to land a patch into ansible for about 3 months
20:45:05 <devananda> mordred's blog was the closest to actionable taht I've seen, but it's not easily digestible as governance changes
20:45:09 <zaneb> vishy: remember not every project is the same in that respect, though
20:45:09 <ttx> OK, let's move on to another question
20:45:14 <zaneb> there's a wide variance
20:45:15 <vishy> mordred: ha. And I tried and failed to land one in golang. I’m not saying we are worse than other communities
20:45:19 <devananda> and some probably would need to be checked at the board meeting, too
20:45:20 <fungi> we've had patches to gerrit take 6 months or more to land
20:45:20 <mordred> vishy: :)
20:45:23 <vishy> zaneb: agreed
20:45:28 <mordred> vishy: but taht doesn't mean we can't strive to be better for sure! :)
20:45:31 <sdague> vishy: I do think some of the early openstack devs have unrealistic expectations that people should just take their code :)
20:45:33 <ttx> Shall we meet next week to close the Juno gap coverage plans ?
20:45:43 <devananda> mordred: are you preparing anything for the tc/board meeting re: big tent?
20:45:46 <mordred> ttx: I think devananda and dhellmann and I are going to work up actionable proposals
20:45:47 <markmcclain> ttx: +1
20:45:55 <ttx> or is it a bit worthless and we should rather run the gap analysis again with the new PTLs and all
20:46:00 <vishy> sdague: perhaps
20:46:01 <mordred> ttx: what do we need to do to get this on the tc/board table?
20:46:02 <mikal> ttx: if we hav work left ot be done for juno, we should meet
20:46:14 <dhellmann> devananda: how about if we chat tomorrow morning about writing those up?
20:46:31 <ttx> mordred: I think we need to have convergence on the TC before we expose it to the board, so next Board meeting will be too early for them
20:46:36 <mordred> ttx: kk
20:46:42 <devananda> dhellmann: ++ though my schedule is a bit tight tomorrow
20:47:06 <mordred> devananda, dhellmann: since I brain-vomitted the first thing, do you guys want to take a pass at carving it up then?
20:47:08 <dhellmann> devananda: I'm sure both of us are skilled enough at async communication by now :-)
20:47:12 <mordred> ++
20:47:13 <ttx> so.. meeting or not meeting next week ?
20:47:15 <dhellmann> mordred: yeah, I think that's the idea
20:47:19 <mordred> dhellmann: awesome
20:47:34 <devananda> dhellmann: yup
20:47:35 <ttx> I just fear we won't have the PTLs around, so it might be worthless
20:47:52 <devananda> ttx: without the effort that has gone into gap analysis in the past, i'm not sure what we can do
20:47:54 <anteaya> looks like markmcclain and mikal are up for a meeting next week
20:48:00 <sdague> ttx: I vote meeting next week, cancel if no agenda
20:48:05 <ttx> hmm... I'll bring it up on the -tc list and we'll decide there.
20:48:05 <dhellmann> devananda: you're west coast, right? how about if I try to put some notes together first thing my time and then sync up with you to finish?
20:48:15 <devananda> ttx: perhaps a ML thread where outgoing PTLs follow up on the things the TC identified early on?
20:48:20 <dhellmann> ttx: yeah, we should always just keep meeting
20:48:29 <ttx> devananda: good idea
20:48:33 <devananda> ttx: some trace for the next round of PTLs (where they changed) would be helpful, I think
20:48:48 <devananda> dhellmann: yup. sounds good
20:48:49 <ttx> #action ttx to raise -dev thread to pass the baton on Juno gap analysis, if needed
20:49:09 <ttx> next question, Who would like to write up the final "Technical Committee Update" blogpost ?
20:49:48 <ttx> I can do it if nobody wants it
20:49:56 <vishy> I will do it
20:50:11 <ttx> vishy: ok, we'll set you up with a openstack.org blog account
20:50:18 <ttx> if you don't have retained one from the past
20:50:27 <vishy> I don’t think i have one
20:50:34 <ttx> vishy: contact redd and he will set you up
20:50:37 <ttx> reed*
20:51:07 <anteaya> I will be asking reed for one too
20:51:17 <ttx> Next question... we'll be shooting "flight safety" style video snippets about design summit on the Sunday/monday of the summit
20:51:26 <anteaya> since if I can get one I will publish answer responses during tc election week
20:51:30 <ttx> so that they can be projected Tue-Fri
20:51:35 <mordred> nice
20:51:51 <ttx> so once we have the scenario, we'll need volunteers to do hand signs
20:52:05 <markmcclain> awesome
20:52:09 <ttx> TC / PTLs / well-known faces wanted
20:52:12 <sdague> ttx: sounds fun, count me in
20:52:13 <zaneb> mordred: not *those* hand signs
20:52:26 <ttx> they said they would be able to edit it on Monday evening so that it's ready for Tuesday
20:52:48 <anteaya> who is scripting the safety rules?
20:52:53 <ttx> just advance notification ;)
20:53:11 <ttx> anteaya: foundation staff, but if you're interested we can loop you in
20:53:22 <ttx> I mean, we can loop anyone interested.
20:53:36 * anteaya realizes she just volunteered for something
20:53:40 <anteaya> yeah, okay
20:54:05 <ttx> we haven't even started. We thought it would be too late for Paris
20:54:22 <anteaya> depends on the video crew
20:54:25 <ttx> but the prod folks just said editing on Monday night wasn't a problem
20:54:32 <ttx> so .. yeah
20:55:11 <ttx> OK, next up.. TC dinner. Anyone wants to organize (I can if nobody else does). Any preferred day ?
20:55:42 <ttx> do we even know when the parties are ?
20:55:47 <mordred> ttx: funny story - I was just about to poke you to see if you wanted to take care of finding/booking
20:55:48 <markmcclain> ttx: you're likely to know the best places :)
20:56:02 <dhellmann> https://openstacksummitnovember2014paris.sched.org/overview/type/evening+events#.VCsY275hUts
20:56:06 <ttx> markmcclain: you know for a fact that my addressbook is a bit outdated.
20:56:16 <dhellmann> we only have one for tues so far, it looks like
20:56:23 <mordred> ttx: as all of the good places I foudn seemed like haggling a private table would involve more french than I own
20:56:25 <ttx> markmcclain: we just didn't do enough scouting on that week.
20:56:43 <markmcclain> ttx: true.. more scouting was needd
20:56:45 <ttx> haggling for a private table is difficult in paris, yes
20:56:55 <AlanClark> Hey TTX, reminder that we have the joint board and TC meeting on the Sunday Nov 2 with a diner after
20:57:03 <mordred> AlanClark: ++
20:57:05 <ttx> AlanClark: +
20:57:07 <devananda> AlanClark: ++
20:57:13 <ttx> oooh ascii art
20:57:48 <AlanClark> ttx, I talked with claire yesterday and owe you some emails to sync up
20:57:56 <ttx> and finally, reminder that TC self-nomination will start this Friday. If your seat is up for renewal, you might want to self-nominate yourself
20:58:49 <ttx> jeblair, ttx, vishy, markmcclain, jaypipes, devananda and mikal can't run
20:58:50 <anteaya> read the wikipage: https://wiki.openstack.org/wiki/TC_Elections_October_2014
20:59:14 <vishy> ttx: but what if we want two seats each?
20:59:24 <anteaya> can't have 'em
20:59:27 * jaypipes gives vishy his seat
21:00:17 <ttx> vishy: you would have to find a way to bribe anteaya
21:00:27 <anteaya> my price is the moon
21:00:34 <anteaya> in a small box
21:00:47 <ttx> vishy: you know some planetlabs folks that may be able to help
21:01:01 <ttx> OK, last words ?
21:01:34 <ttx> in case it's our last Juno meeting, it was a pleasure.
21:01:36 <ttx> #endmeeting