20:01:35 #startmeeting tc 20:01:36 Meeting started Tue Sep 6 20:01:35 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:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:39 The meeting name has been set to 'tc' 20:01:42 o/ 20:01:43 o/ 20:01:50 Hello everyone! Our agenda for today: 20:01:54 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:10 (remember everyone can use #info #idea and #link to make for a more readable summary) 20:02:18 #topic Add 'library convergence' to Requirements mission 20:02:25 #link https://review.openstack.org/363502 20:02:41 This is a follow-up patch to address one of my comments on the Requirements team mission 20:02:49 just reached majority approval 20:02:58 any objection to merging it now ? 20:03:35 I'll take that as a no 20:03:56 go for it ttx 20:03:57 approved 20:04:02 #topic Mention where the metric rules are defined/used 20:04:06 #link https://review.openstack.org/342225 20:04:16 This is a clarification of how those tags is actually applied 20:04:24 Looks like a good incremental improvement to me 20:04:30 flaper87: anything you wanted to mention ? 20:04:47 nope, I'll address the typos 20:04:54 if folks have questions, I'm happy to answer them 20:05:03 I noticed amrith's comment but dhellmann replied to him 20:05:06 since this is a formal-vote item, do you want to do the typos as a separate patch? 20:05:06 so, I think I'm good 20:05:14 yup, sounds good to me 20:05:23 yes typo, patches are fasttracked too 20:05:33 unless you wanted to do the more substantial rewrite annegentle proposed 20:05:33 yeah I think that follow up's fine 20:05:36 k 20:05:42 plural possessive ftw 20:05:44 ./ 20:06:01 I think "proposed" is valid, so amrith -1 is probably shallow 20:06:04 flaper87: how does the tool handle repos with a single review in 6 months? 20:06:08 * mtreinish is just curious 20:06:19 none of my concerns are of the ilk that require a hold up. my -1 is as ttx said, shallow 20:06:40 mtreinish: mmh, good question. I should double check that. can't remember OTOH 20:06:48 mtreinish: we still use common sense when applying tag changes, fwiw 20:06:54 mtreinish: iirc, it considers the project as not active 20:06:59 which is why we end up reviewing the proposed changes 20:07:01 but yeah 20:07:08 common sense is still the rule 20:07:14 ttx: sure, its just we are encoding that it's what the script does in there right? 20:07:40 ttx, dhellmann, flaper87 just the observation is that the tool currently doesn't deal with patch proposal, rather with 'reviews during the period'. 20:07:52 the distinciton is subtle but one that exists ... 20:07:59 amrith : we're measuring the activity of the reviewer, right? 20:08:07 mtreinish: patch just says we measure activity based on rules of the script. Not that we blindly apply script's output as law 20:08:18 dhellmann: +1 20:08:37 yes, dhellmann .. in that case you should consider reviews proposed during the period, not patches proposed during the period. 20:08:39 amrith : there is no requirement that a core-reviewer submit patches 20:09:00 mtreinish: the line was more generic and annegentle correctly pointed out that we may want to have some of the current rules explained in plain English 20:09:11 amrith : I'm not understanding whatever you're trying to say 20:09:15 dhellmann, if a review lasts longer than the six months 20:09:20 it was not 'proposed' within the period 20:09:26 it was 'reviewed' within the period 20:09:28 amrith : a "review" is when I click -1, etc. 20:09:32 that was the distinciton I was looking at 20:09:33 we count those events 20:09:45 those are point-in-time, and don't span releases 20:09:46 we don't count the proposed patches 20:09:48 "patches currently proposed for review" 20:09:51 but the reviews made to those patches 20:09:59 not patches created in a given timeframe 20:10:07 "have reviewed at least 2% of the proposed..." 20:10:38 I think the word order is confusing some people here 20:10:48 reviews need to be on patches that are open 20:10:53 they can have been opened at any time 20:10:53 the verbiage is "of the proposed 20:10:53 patches", change it to "of the proposed reviews" and I think it will say what you are saying here ... 20:11:01 the reviews need to happen in the period being measured 20:11:18 if annegentle's text is clearer, I'll update the patch 20:11:23 amrith : you are using the term 'review' to mean what I think this is meaning when it says 'patch' 20:11:53 dhellmann, in that case we're saying the same thing. I withdraw my -1 20:12:06 I'm not sure mine addressed the proposed, vs. not proposed in the window of reviews 20:12:16 flaper87 : "review comment" might be clearer 20:12:24 but yeah 20:12:39 main thing is to write it like we're talking about it 20:12:52 dhellmann: would that still count as typo ? 20:12:54 :P 20:12:59 * flaper87 can do a ninja fix during the meeting 20:13:13 ok, let's try that and move on 20:13:22 we'll be back to this one on open discussion 20:13:27 sounds good 20:13:28 ok 20:13:35 #topic Write down OpenStack principles (initial discussion) 20:13:45 timeboxing to 15min 20:13:51 #link https://review.openstack.org/357260 20:13:59 So... this one is an effort to document a few principles we historically follow in how we write OpenStack 20:14:10 Credits for the original draft goes to mordred 20:14:23 although I removed most of the swearing so you wouldn't be able to tell 20:14:27 ha 20:14:38 Once we are happy with the draft, we should start a larger discussion on the ML before approving it 20:14:40 there's no swearing in OpenStack 20:14:48 But I'd like to see some consensus on the TC before we move to that 20:15:06 How do we revise to be more welcoming? 20:15:20 I've not seen objections from TC members, but from the larger community, so far there is some discussion around the wording of the "One OpenStack" principle 20:15:21 I mean, I know I said somethign like that on the review, but hadn't offered a true revision. 20:15:41 annegentle: yes, I'll come back to that 20:15:47 ttx ok thanks 20:15:51 On "One OpenStack" there are definitely some developers who would prefer to see OpenStack as a loose collection of independent projects 20:16:03 I'll just point out that this was discussed and decided before (in 2011) by the ancestor to the TC, the PPB 20:16:14 can I just ask whoever is doing the style reviews if we could get some consenseus on language before we have a lot more on things like case used in headings 20:16:18 ttx: my only issue with it was already pointed out among the sea of comments there. Which is a definition of the 'OpenStack Way' 20:16:20 So this is nothing new, we are just copying it over. That doesn't mean we couldn't change it in the future, but that's not the goal of this change 20:16:42 mtreinish: yes, that is a bit fuzzy and could use other wording 20:16:51 The other one which seems to trigger reactions is the last one, "Participation is voluntary" 20:16:54 but other than that I was happy with most of what was there (for what I could parse amongst all the inline comments) 20:16:59 which is seen as overly negative and could probably be rewritten in a more positive way 20:17:09 The rest of the principles seem to be mostly acceptable so far, some wording tweaks might be necessary 20:17:21 like mentioning "the OpenStack Way" without defining it 20:17:45 should probably just say "those principles" 20:17:46 ttx: please don't read my comments on the proposed doc as disagreeing with previous TC rules. I simply found the phrasing inconsistent and unclear. I didnt' advocate for a particular "side" 20:18:01 ttx: well I have know what that is, (especially if it was an mordred draft originally) but I think definiing it would be useful 20:18:21 I think we also mention it in the big tent resolution 20:19:06 So I'll probably propose a new revision and start a thread on the ML to expose it to more eyes 20:19:24 ++ 20:19:26 I don't think there are strong objections to any of those, but the wording matters 20:19:27 ttx : agree 20:19:39 ttx: ++ 20:19:45 ++ 20:19:48 like notmyname says, they can be read in a lot of different ways and could use extra precision 20:20:20 I certainly don't see any need to rush that. I see it more like missing documentation than a new thing though 20:20:40 ttx I wondered if a set of positive statements "If we have these attributes, then these other results happen" along the lines of "we know we are doing these things when..." will help 20:20:41 I do like the amount of input from folk with different perspectives. we assume a bit too much tribal knowledge sometimes 20:20:57 ttx I do see it as helping us to articulate what is not known by all 20:20:59 dtroyer: +1 20:21:06 dtroyer exactly 20:21:09 dtroyer: yeah 20:21:12 dtroyer: especially those that have been around forever assume that what they think is what others think 20:21:29 I'm guilty of that and I thank mordred for starting the effort to document those 20:22:12 annegentle: ++ postiive statements 20:22:58 ok, so I'll do a new revision, let it bake a few days and if it holds the water start a thread on the ML to see how it floats 20:23:33 ttx: lol 20:23:36 sounds good to me 20:23:47 Currently assuming there are no objection to any of the principles from the TC, but that we need to refine the wording 20:24:26 In particular the "my way or the highway" tone of the last one is, I think, missing the mark 20:24:38 yes, that needs some work 20:24:54 ttx I only did a first read, and I would like to do a deeper read again... I feel it is missing some vision. 20:24:59 ttx like why are we openstack at all? 20:25:24 ttx sounds a bit philosophical I know, but it felt like it was missing vision and purpose 20:25:45 annegentle: this is not a new thing we don't have, it's a write-up of rules we've been operating under 20:25:55 annegentle: I'd say the vision work is separate 20:26:26 annegentle: vision != principles != mission 20:26:37 yeah, I'd firs try to write down the things we've been operating on, see how sound they are and see if they still apply 20:26:45 we can let this evolve from there 20:26:48 Positive statements are great, but the occasional "we don't do it this way" can also be enlightening to someone coming in new 20:26:50 document the world before you change the world :) 20:27:08 jroll: yes! 20:27:10 we can even trim it a bit and discuss some of those points separately if we find them controversial but let's first get some further feedback 20:27:45 Also like all things we do, the form of this one won't be eternal 20:27:51 it will evolve over time 20:27:59 ttx I sense there's still tension between "are we building blocks for different types of clouds" or "a community that builds software for all clouds" (Hence the storage focused cloud vs. a compute focused cloud could give you a different set of project selections.) 20:28:49 flaper87 you might be onto something, can the rules be collected in separate patches (they probably shouldn't be though if we really are getting agreement to the agreements we already operate within) 20:28:50 annegentle: I'd say this is a "mission" question -- and we have "interoperability" in the Openstack mission now 20:28:58 annegentle : do you think that tension goes beyond the question about whether we're talking about monolithic deployments vs. governance? 20:29:01 mmh, but I don't think that belongs to the principles 20:29:09 unless I'm misreading you, annegentle 20:29:14 dhellmann hmmmm thinking 20:29:40 I'm trying to get at the question of "be governed or hit the road" 20:29:54 one minute to timebox 20:30:14 With governance comes accountability, so are we holding the contributors accountable? Yes. The deployers? Not so much. 20:30:35 ok, let's continue the discussion on the review and the future ML thread 20:30:37 but isn't this about the contributors? 20:30:39 k 20:30:39 So I'll re-read and try to offer revisions with those thoughts top-of-mind ttx 20:30:44 dhellmann yep it is. 20:31:15 but please don't try to pile up too much on this doc. It's n,t a code of conduct nor a mission statement nor a vision description 20:31:22 Just a set of principles beyond the "4 opens" 20:31:29 ++ttx 20:31:45 It's not the answer to all the questions 20:31:50 ok, moving on 20:31:53 yeah good point 20:31:56 #topic Add networking-cisco back into the Big Tent 20:32:03 #link https://review.openstack.org/363709 20:32:09 Some history 20:32:14 networking-cisco was officially removed from the Neutron stadium back in April 20:32:29 That was following a decision by the Neutron team in February to "not vouch for projects that are purely interfaces to proprietary technologies" 20:32:45 So the networking-cisco folks would like to be recognized as a separate official project team 20:33:01 First of all, like flaper87 and dtroyer said, I don't think we should fast-track that application on the grounds that it was originally part of the Neutron stadium. 20:33:19 We should consider if teams belong in OpenStack separately from decisions made in the past by a specific project team 20:33:35 Looking at the proposal I have two concerns, which I mentioned in the review 20:33:47 The first is the timing -- post-FF is a pretty bad timing to add any project team. The release contents is set, the Design Summit tracks are assigned, elections are being organized 20:34:10 This should really have been proposed earlier, shortly after it was removed in April 20:34:20 So at this stage I'd rather reconsider this one at the start of Ocata 20:34:35 Then there is my second concern, which is around the "level and open collaboration playing field" requirement 20:34:35 ++ 20:34:37 ++ 20:34:38 ttx: also wouldn't this fall under the same thing as poppy, where it only works with a proprietary backend? Or because it's a neutron plugin does that make it different? 20:34:50 To me a project team whose deliverables purely interface with proprietary technologies violates that requirement 20:34:54 mtreinish: that's the second concern :) 20:34:59 It's a bit unfortunate that the dissolution of neutron is leading to this being a question at all. Having different teams handle drivers in different ways is going to lead to a lot of confusion. 20:35:00 ttx: also I'm fine with deferring to O :) 20:35:00 mtreinish: yes, prettmuch 20:35:16 do we know the original neutron requirements, are they written down? 20:35:18 Or in other words, should we provide open collaboration resources to a project that is clearly tilted in favor of one single organization contributors 20:35:22 dhellmann: ++ 20:35:23 agreed on timing, btw 20:35:25 mtreinish: being part of neutron does not confer magical vendor openness powers. it is not different, IMO. 20:35:50 dougwig: I agree with that. I was just playing devil's advocate with the second question 20:36:03 the bad timing is my fault, I only realised we had been removed from the big tent too when I dug into why I couldn't publish to docs.openstack.org any more 20:36:24 So yes, I'd like to defer this one until RC1 at least, and probably the new TC elections 20:36:31 because in the past we were discussing a service with a proprietary backend, but this isn't a service 20:36:31 We have several teams struggling with how to handle vendor-specific contributions like drivers, and they're coming to different conclusions. It would be useful to see what sort of commonality there might be. 20:36:43 dhellmann yeah I'd like this written down 20:36:47 But I wouldn't mind a quick read of the current TC on the "level playing field" requirement 20:36:50 dhellmann and agreed to 20:37:13 the projects that have proprietary components are all still useful on their own in some way without the proprietary bits 20:37:21 it's a bit of an existential question on drivers in general. was the code "more free and open" when it was under neutron's governance than it is when governed separately? 20:37:37 annegentle: yes, neutron subproject acceptance policy is written down 20:37:41 i just think it's organizational bizarre and awkward 20:37:46 organizationally* 20:37:50 fungi : as a part of a larger whole, maybe? 20:37:50 How is this different than the VMWare or Hyper-V drivers for Nova? 20:38:23 edleafe: it's not a separate team. If they were, they would fall under the same argument 20:38:30 edleafe: It might not be but the governance rules are 20:38:34 edleafe: they are part of Nova, and subject to everything Nova is subject to as a whole, with at least one exception of testing in our environment 20:38:36 i.e. the "Nova team" is a level playing field 20:38:38 #link http://docs.openstack.org/developer/neutron/stadium/sub_projects.html 20:38:43 I mean, Nova's requirement is not (was not) the same as the big tent 20:38:46 but it represents the consensus in neutron team at the moment 20:38:48 it's unfortunate 20:38:56 I was thinking more in terms of Neutron kicking them out 20:38:57 edleafe: the nova core team agreed to maintain those drivers. 20:39:11 it's possibel that the neutron stadium was masking vendor-specific teams under a larger non-vendor-specific team 20:39:36 dougwig: Hyper-v was kicked out because no one was supporting it 20:39:37 so once those subteams are cut loose, they're suddenly exposed as vendor-specific 20:39:39 In other words, if we were to accept networking-cisco, we'd have an "OpenStack project team" that is clearly a "Cisco project team" since Cisco contributors have access to more data than other contributors 20:39:47 fungi: isn't that what led to its undoing? 20:39:50 fungi : likely. do we see that in the other teams with vendor-specific drivers? 20:39:52 fungi I'm pretty sure it was doing exactly like. But then I think you have a similar thing in cinder and nova with some of their driver teams as well. 20:39:52 fungi: of course it was 20:39:53 They wer eonly let back in when there were resources from Microsoft and others 20:39:57 naturally, for any vendor driver ... 20:40:21 ttx: yes, that's right, I don't think I could vote to accept this as a standalone team :-( 20:40:24 i'd ask this another way ... do vendor drivers belong "in" OpenStack? 20:40:28 dtroyer: i'm mostly curious because neutron's stadium governance model is at least suprtficially to infra's council model 20:40:37 IOW, Nova will not support it if the vendor support disappears 20:40:40 so... honestly the bigger concern is that, correct me if I'm wrong, in neutron drivers can actually change the API in substantial ways 20:40:40 * fungi really can't type today 20:40:53 russellb : I would like to have them all in-tree, or at least in repos accepted by the parent project team. 20:41:00 dhellmann: agreed 20:41:01 in regards to openness, all our code and libraries are apache 2.0 opensource, and though we right now have mostly developers from Cisco, we are unbias to code contributions from anywhere 20:41:02 dhellmann: ++ 20:41:10 Is it important that it is a single vendor, or that the back end is not open, or only if both apply? 20:41:11 sdague: some have in the past, though it's frowned upon these days 20:41:23 persia : the closed backend is more important, imho 20:41:27 russellb: do we know where this driver falls on that line? 20:41:44 in terms of hacking the API? i don't. sambetts, does networking-cisco add custom REST APIs? 20:41:46 persia : i have to have access to gear to test, and I have to have access to new project feature information that might not be public to develop 20:41:48 sambetts: but contributors from Cisco happen to have access to the code of the black box you're interfacing with... which gives them a clear advantage 20:41:51 lack of an open backend means nobody can test changes to the driver adequately unless they buy/license the target backend 20:41:59 sdague: not sure that's the biggest concern, tbh. 20:42:21 sambetts: unless you end up providing every potential contributor with the appliances source code and test hardware 20:42:55 sambetts: the end result will be that only Cisco will contribute to that team, and that team will forever be single-vendor 20:43:07 ttx sambetts how is this different from most of the cinder drivers? Is the difference the fact that this is *out of tree* from an already accepted project? 20:43:08 I don't see the point of putting that under OpenStack governance 20:43:10 rather than rejecting this, I would prefer that we work with the neutron team to reverse the dissolution decision 20:43:13 i think the more valuable conversation here is trying to figure out if we can make driver handling more consistent in openstack 20:43:27 russellb: dhellmann ++ 20:43:29 cburgess : yes 20:43:32 yes 20:43:43 dhellmann: that's not likely to happen. 20:43:45 because this is going to come up 25 times 20:43:46 also that makes for some rather slow turn-around on adding new contributors if they do. for example i may want to propose some mass changes for a particular bug across many projects. i wouldn't be able to locally test my changes for that particular repo without some significant turn-around time to get the required hardware 20:43:47 just for neutron 20:43:51 So, let's use the delay to have a larger discussion about vendor drivers in OpenStack 20:43:57 and try to present a coherent front 20:44:05 sounds good to me 20:44:08 dhellmann: I think that ship sailed when neutron decided to make driver testing optional 20:44:09 dougwig : does neutron have a stable driver API? 20:44:21 stable-ish 20:44:26 we have documented open APIs for our hardware, and I don't see why someone unrelated to Cisco who has a peice of our hardware couldn't contribute a feature they want 20:44:28 has been getting much better lately 20:44:52 I think this is about consistency in treatment of driver teams -- the conversation about backports comes to mind as well. 20:45:03 sambetts : could I do the same for an unreleased piece of hardware? 20:45:16 dhellmann: even simple requirements bumps can break things. and with 30+ drivers, and drive-by vendor contributors, it was a lot of work even to kick out the stuff that had gone idle. that solution doesn't scale. 20:45:35 sambetts: they would still have a harder time than a Cisco developer with access to the black box code, and factory-cost hardware 20:45:41 dhellmann: we wouldn't consider putting in there 20:46:00 dougwig : is the neutron team accepting any of these drivers, or are they all being pushed out? what's the dividing line? 20:46:06 and we strive to provide third party CI for all hardware backends we support 20:46:09 We need to move on 20:46:30 everything is split, except for the "default" stuff, which was honestly too embedded to be split out (my take on how it went down) 20:46:34 dhellmann: the ref implementation (ovs & lb) are all that remain. the plugin interfaces are being maintained as stable interfaces. 20:46:36 nobody motivated enough to extract that stuff 20:46:37 My take is, we need to delay this until Ocata is started and the var is open to new project teams again (and the next TC is elected) 20:46:42 bar* 20:46:50 sambetts: on the requirements change point, avoiding involvement in community processes which are hard to implement because your backend is proprietary doesn't make for a compelling argument for why it should be an official community project 20:46:53 ttx I think you put too much on this whole access to the black box. I'm a cisco employee and I can't just go download the source for how one of our devices works. It doesn't work that way. 20:46:58 ttx: I agree with waiting. 20:47:03 And we should take the time until then to reflect back on vendor drivers everywhere and present a more coherent front 20:47:17 ttx: +1, especially to the latter point 20:47:30 ++ 20:47:33 * flaper87 nods 20:47:35 cburgess: i find that (and all proprietary software) unfortunate 20:47:47 ok, next topic 20:47:49 cburgess: it really is not about individual contributors as much as it is about simply being open and accessible and available 20:47:58 #topic Add ocata goal "support python 3.5" 20:48:06 #link https://review.openstack.org/349069 20:48:18 Last week we explored three ideas -- making unit tests an optional part of the goal, rewrite it with full-stack-testing as an objective, or find some other goal entirely 20:48:31 notmyname said dropping unit tests would not really make the goal easier for Swift, so there seems to be little point in doing that 20:48:48 sdague said he would explore a py35 full-stack-testing goal variant but was worried about lack of activity drivers, since most py35-pushing folks are not involved with devstack/gate 20:49:01 ... and no alternate goal was proposed 20:49:11 So this is a bit stalled 20:49:15 ttx: well, it was feature freeze week :) 20:49:19 + holiday 20:49:23 ttx: haypo has agreed to lead a team of helpers. I'll be on the team. We can recruit others. 20:49:28 this goal still seems to obvious to me ... i'm not sure what to say 20:49:36 where helpers != "we're going to write your patches for you" 20:49:37 sdague: yes, fair. Happy to put it back on agenda next week. Not much time left today anyway 20:49:39 s/to/so/ 20:50:04 russellb: I think the end goal is good for sure 20:50:16 ok 20:50:28 I guess the question is if it's just implementation path, do we figure out how to fuzz that and agree on the end goal 20:50:48 I think it would be a mistake to say we can only have goals where we have a set of people "driving" the work. The point is to get project teams to integrate these things with their existing work. 20:50:49 i think it's good enough to just say "yes, we agree this end goal is important, and we should try" 20:51:17 dhellmann: I think that assumes that it's complete rote 20:51:29 I'm not convinced we're at the completely rote stage here 20:51:31 personally I'd rather have goals that can be clearly "completed", as opposed to say "advance the state of py35" and have everyone evaluate what "some progress" means 20:51:33 russellb: projects work on a goal and report progress? 20:52:05 sdague : we have seen over and over that having a central team try to do work across all repos does not scale. 20:52:10 sdague: I wonder if you might get more folks hacking on nova/devstack/gate than you think, if only because so many projects full stack testing depends on nova working 20:52:12 but I also agree this one as proposed is a bit assymetric for that 20:52:29 jroll : right 20:52:35 jroll: that's fine 20:52:53 dhellmann: it's more than just an isolated thing in each project. We've had projects declare they're py3 compat on the ML but it's just unit tests. No one is driving getting a dsvm job running or any of the cross project work 20:52:55 my instinct is that it won't just happen, but I'm happy to be proved wrong 20:53:09 ttx: I do think it is worth us saying this is a high community priority, as a lot of the decision makers in corporate sponsors watch these thingsā€¦ this is one way to influence how resources get allcated 20:53:12 mtreinish : that is the entire point of this goal, to make all of that happen 20:53:12 OK, I propose to put it back on agenda next week (hopefully first item) and have people more ready to discuss it then 20:53:38 ttx: sounds good. We don't have much time left anyway 20:53:47 please be ready to say something more specific than "this won't work" 20:53:54 dhellmann: ok, but which project team owns the sunk shared cost? Like getting the first job running is going to be 10x the cost of the second project joining in. 20:53:54 dhellmann: ++ 20:53:57 dhellmann: except nothing in the goal has people stepping up to do that work. Like d-g is an infra thing and devstack is an qa thing, but who owns getting things running with py3 20:54:20 there is a lot of effort in getting things running in the gate on all projects, and it's not owned by a particular silo 20:54:25 sdague : do we need to pick someone up front? 20:54:28 mtreinish: a bit of everyone, that's the idea with the goals 20:54:30 mtreinish: ++ 20:54:42 if we know who will do the work, what's the point in inspiring people to work on a thing 20:54:51 "tiger team"! 20:54:56 ttx: is that the point? 20:55:04 I thought the point was getting the thing done in a timely manner? 20:55:21 sdague: well, that's one of the points. 20:55:22 if the point is to recruit new folks to a task, that's fine 20:55:30 If we have a goal, we also need to move it forward 20:55:31 one of the points at least 20:55:35 mtreinish: there shouldn't be anything required from d-g to run openstack under python3 20:55:38 mtreinish: fwiw 20:55:39 but it is actually orthoginal to timely manner 20:55:49 clarkb: well flipping a devstack switch probably 20:55:56 clarkb: or in project-config 20:56:06 ok, need some time for open discussion, so we'll continue this one next week (or on the review in the mean time) 20:56:12 #topic Open discussion 20:56:17 ./ 20:56:21 clarkb: but it's a minimal change in code. It's more about tracking things and making it work. Which was kinda my point 20:56:24 patch updated 20:56:25 I announced the first PTG date/location (Atlanta, Feb 20-24, 2017) in a ML thread 20:56:26 ya project-config might need to be edited to flip an env var, just pointing out python3 vs 2 isn't really something we care about when cloning git repos and collecting logs 20:56:30 #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/102981.html 20:56:32 ttx: w00h0000 20:56:38 On the Design Summit side, it will soon be time to plan the cross-project workshop track 20:56:48 Traditionally we had 7 time slots and used 3 parallel rooms 20:56:57 For this one, as sdague suggested we'll likely scale it back a little to preserve space for the "normal" sessions 20:57:06 i.e. use only 6 time slots instead of 7 (we can still use 3 rooms, or more if needed) 20:57:27 happy to help with that, btw! 20:57:43 does 6 time slots sound good ? 20:57:48 #info PTG date/location (Atlanta, Feb 20-24, 2017) 20:58:00 annegentle: +1 20:58:09 ttx: honestly, I think we should see if we even have 6 x 3 sessions worth having 20:58:20 I feel like we got very mixed at the bottom of the list last time 20:58:22 i guess the minimal registration cost mentioned in the faq will have a specific number associated with it soon? 20:58:27 (ptg) 20:58:28 ttx: how does that effect scheduling. like how many sessions are there in a day? 20:58:31 ttx, I've put my questions into https://etherpad.openstack.org/p/gMPYW40Fmq and referenced it in https://review.openstack.org/#/c/342225/8/reference/tags/team_diverse-affiliation.rst; not sure if there's time to discuss here and now. 20:58:38 can be 6x (2 to 4 based on parallelization needs) 20:59:18 mtreinish: not sure I understand your question, but we can take it offline 20:59:25 flaper87: your patch is up ? 20:59:30 ttx: yup 20:59:33 amrith you have a good point on change set nomenclature vs review 20:59:33 vs patch set 20:59:45 Please rereview https://review.openstack.org/#/c/342225/ 21:00:00 annegentle: the gerrit wording is change and change set 21:00:00 If it gets to majority I'll just approve it, otherwise it will be back next week 21:00:17 anteaya ah, good to know 21:00:19 annegentle: patch review CR and others are socialization terms 21:00:25 ttx, to be clear, my question isn't a -1, rather a request to clarify. 21:00:28 and ... we are out of time 21:00:33 wah 21:00:34 :) kidding 21:00:37 ttx: what's the diff between 6 session vs 7? Does that mean we have 1 non cross project session on the tues? I'm not sure I see what diff it makes 21:00:44 bye folks! 21:00:47 thanks everyone 21:00:53 thanks :D 21:00:53 #endmeeting