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