20:01:23 #startmeeting tc 20:01:24 Meeting started Tue Jan 10 20:01:23 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:27 The meeting name has been set to 'tc' 20:01:30 Hi everyone! 20:01:34 Our agenda for today is at: 20:01:38 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:38 * edleafe slinks to the side of the room 20:01:44 o/ 20:01:45 #topic Add extra-atc nominations for Trove 20:01:50 #link https://review.openstack.org/414764 20:01:57 The latest rev looks good to me 20:02:14 If you pile up approvals we can merge it now 20:02:27 +1 20:02:28 * amrith is happy to answer questions about that if required 20:02:48 Sounds like it has majority support and no more objections now 20:02:56 * ttx approved and moves on 20:02:56 ship it! 20:03:04 that was easy! 20:03:14 flaper87: yt? 20:03:24 amrith : thanks for being a mentor 20:03:37 #topic Reference doc for new language additions 20:03:41 thx dims 20:03:43 #link https://review.openstack.org/398875 20:03:55 Was counting on flaper87 to present this 20:04:02 looks good enough to me for an initial version of the requirements 20:04:10 we can discuss the merits of subsequent improvements as separate changes 20:04:19 o/ 20:04:23 here he is 20:04:28 sorry, couple of mins late 20:04:28 flaper87: floor is yours 20:04:32 o/ 20:04:38 yeah, so, I've updated the patch and addressed the latest comments 20:04:53 I've submitted another patch to fix the last comments from yday 20:04:56 saw a subsequent patch already, which is good -- shall be a living document anyway 20:04:57 (or was that today?) 20:05:05 yeah 20:05:35 I just noticed Graham's last comment and I can address that 20:05:47 flaper87: excellent work on this first draft 20:05:55 cool, i wanted to see the in-meeting discussion covering the most recent inline comments before adding my rc vote 20:06:00 but sounds like something we can fix in subsequent patches, unless I missed something 20:06:03 comments, remaining objections ? 20:06:09 fungi +1 20:06:14 +1 to living document + patches 20:06:36 i still feel like it's a bit proscriptive/rigorous, but i guess it could be a lot worse so happy with this as a starting point 20:06:36 EmilienM: danke 20:07:03 o/ (sorry I'm late - in an all-day offsite, but am lurking) 20:07:03 flaper87: yeah, FWIW (this was part of the very first patch) I intentionally started with a higher bar 20:07:06 flaper87 please enlighten us with regards to mugsie's comments 20:07:06 i like to also consider it as compliment/counterpoint to dtroyer's cti patch for go 20:07:11 re Graham's comment, I think the working from earlier regarding ensuring the user/operators consistency of experience is what is important here... 20:07:40 yeah, I think there might be a missunderstanding with my wording 20:07:49 I read it as we need to provide equivalents, that doesn't mean everyone needs to use them 20:07:57 the crux of that section is guaranteeing the ocmpatibility from an ops perspective 20:08:02 (but they probably need a good reason not to) 20:08:05 either by the support of already existing language features 20:08:10 My point about the requirements was that we may need more than just these 2 libs to get the operator consitancy 20:08:12 or by implementing the required libs 20:08:20 fungi: I see this as the prereq/enabler for the CTI doc 20:08:29 mugsie_: if we need more, we might need to add them there 20:08:31 dtroyer: so you see this as compatible (at least in spirit) with your end of the effort? 20:08:52 seemed that way to me, but wanted to be sure it's not at odds 20:08:53 The goal is to not break ops or other compatibility by introducing a new language 20:08:55 fungi: I wrote the golang cti doc with this in mind, and think it is already pretty close 20:09:27 awesome 20:09:33 sounds like it's at a stage where it's simpler to propose improvements as separate changes 20:09:44 ttx ++ 20:09:49 ++ttx 20:09:52 mugsie_: would you agree with this not being a blocker ? 20:10:15 Not a blocker - we can amend it 20:10:31 mugsie_: awesome, thanks. I appreciate your input on this 20:10:35 It's not the concept, just how it is stated right now 20:10:40 ok cool 20:10:41 Here 20:10:52 look! a stevemar 20:10:56 Here-ish, mostly lurking. 20:10:59 oh no stevemar_droid turned into a droid! 20:11:01 ttx: a droid stevemar 20:11:10 we haven't added a second general-purpose language (nodejs aside i don't consider js a general-purpose language) before, so i fully expect this will still need a lot of fine-tuning to meet reality 20:11:12 this is not the droid we are looking for 20:11:22 :) 20:11:28 fungi: it will need for sure 20:11:50 Alright, we have enough votes... Any last minute objection ? 20:12:21 * fungi just wants to see the "tc hates go" crowd eat their hats 20:12:33 fungi: ++ 20:12:36 LOL +1 fungi 20:12:42 I just want to get the constructive effort started 20:12:50 fungi: heh, we can still hate go and approve this :) 20:13:01 mtreinish: :) 20:13:06 yeah, I'm happy to work with ppl interested in go in this process 20:13:18 flaper87: that work is underway... 20:13:21 OK, last minute to object before I approve 20:13:23 I'm not saying I'm going to code in go but I'd like to walk through this process 20:13:25 flaper87, I'm sure dtroyer will help 20:13:25 dtroyer: yup 20:13:43 dtroyer: by all means, feel free to ping me and keep me in the loop 20:14:14 ok, it's in 20:14:21 w000h000 20:14:22 thanks for driving this flaper87 20:14:25 Nice 20:14:26 go go go 20:14:28 my pleasure 20:14:32 flaper87: thx again :) 20:14:35 Thanks flaper87 20:14:44 flaper87 burning up karma :) 20:14:49 #topic Driver teams: establish new "driver team" concept (or not) 20:14:58 stevemar posted the results of the survey question we asked driver maintainers: 20:15:02 #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html 20:15:09 Let's use the voice-turn system to avoid speaking over one another. 20:15:10 nice work on that stevemar 20:15:16 unsurprisingly, everyone wants everything ;) 20:15:17 I can summarize my position first 20:15:28 At this stage pretty much everyone agrees that we need to fix driver visibility on openstack website properties 20:15:35 And that it is the main and urgent issue to solve 20:15:45 There is still much disagreement on whether we /also/ need to change governance to consider driver teams as official OpenStack teams 20:15:54 On one side people wanting to be inclusive and welcoming of all forms of contributing to OpenStack success 20:16:04 On the other side people seeing it as unnecessary, potentially diluting openness values and difficult to reverse 20:16:15 I feel like the continuing debate between the two distracts us from starting (and fully focusing on) fixing the main and urgent issue 20:16:17 * fungi raises hand to retort at some point 20:16:21 o/ 20:16:23 o/ 20:16:25 Once we fix that main and urgent issue, we'll be in a much better position to assess whether we still need a governance change or not 20:16:31 So I'd like to add a third option. We have: 20:16:35 1/ Add driver teams now: https://review.openstack.org/403829 20:16:45 2/ Clearly exclude driver teams (unless developed as a level playing field) now: https://review.openstack.org/403836 20:16:49 I'd add: 20:16:57 3/ Fix driver visibility first, table the governance choice until that's done, and see what's still needed then 20:17:03 In the indicative vote last week neither (1) nor (2) had a clear majority, so I feel like making a call now either way would be a bad decision 20:17:13 Discussing it again next week would just delay starting to work on fixing the main issue 20:17:18 which is why at this point I support (3) 20:17:22 20:17:28 fungi: your turn 20:17:37 next flaper87, dtroyer 20:18:27 just wanted to interject that i'm happy to liaise with the marketplace devs on improvements on that end 20:18:42 there were some indications in the survey results of improvement people wanted to see 20:18:58 we should probably try to gather more 20:19:13 ok, flaper87 ? 20:19:19 yup, writing 20:19:40 remember to raise your hand if you want voice 20:20:00 * ttx pipes some interlude music while flaper87 types 20:20:06 So, as I've stated elsewhere, I believe including the drivers team is important. Drivers *are* an important part of our community. While I think we should fix the discoverability, I also think we can work on these 2 things in parallel. Therefore, I'd prefer us to take option 1 20:20:17 o/ 20:20:20 if people happen to not like that, then I guess I can live by #3 20:20:23 o/ 20:20:33 o/ 20:20:35 * flaper87 done 20:20:42 ok, dtroyer now 20:20:48 * dims just listens 20:20:57 next sdague stevemar thingee 20:20:57 The survey stevemar sent highlighted something for me, namely that the visibility and horizontal team access is what appears to be the highest priority. It also highlighted how everything that appears on an OpenStack site reflects on the project, independant of actual status. 20:20:59 * edleafe sits on his hands 20:21:18 I think it is very important for us to include the measure of confidence and quality for those things that appear, namely that regualt CI comparable with offical projects is performed for everything that we endorse, even unofficially, by posting it to an openstack.org site. 20:21:54 I would now prefer to persue #3, followed by #1 if we do not feel we can enforce our quality requirements without a governance action. 20:21:58 * dtroyer done 20:22:03 sdague 20:22:14 next stevemar, thingee 20:22:34 I think I'm largely with dtroyer on this. #3 seems very reasonable way to address the major current friction points 20:23:03 I would like to figure out if we can manage to do discovery with some kind of quality assurance without inventing new governance, because that gives more flexibility 20:23:36 especially because otherwise it seems like TC is going to be evaluating lots of driver team applications 20:23:46 for now 20:23:53 stevemar: you're on 20:23:58 next thingee 20:23:59 o/ 20:24:03 Even if we have a consistent place to list the drivers, there are many questions about what to include and the criteria for inclusion 20:24:26 And that seems like the same questions we'll have about what makes them official 20:24:37 I like sdagues last point though 20:24:41 * stevemar_droid done 20:24:50 thingee now 20:24:53 next dhellmann 20:25:00 flaper87 as I mentioned in the review, I found your position vague of it not being enough to fix discoverability. Can you please elaborate why it's not enough. 20:25:24 * fungi has a response for stevemar_droid's question when the floor is available 20:25:26 flaper87: feel free to interject 20:25:31 o/ 20:25:39 thingee: sure, so, I believe that doesn't answer the question of whether we believe drivers are important or not 20:25:54 discoverability is a critical thing but it doesn't solve the issue of including drivers 20:26:11 why? it's making them visible. Highlighting them in a way of being compatible. 20:26:12 Based on stevemar_droid's summary, there's a feeling that drivers should be included in openstack 20:26:26 I personally feel they should be part of the openstack community, officially 20:26:37 again I view your position purely from a development perspective. These developers are motivated because of a paycheck from a company that is happy they have that compatibility stamp 20:26:38 done 20:26:56 dhellmann: your turn 20:27:04 I’m disappointed that the discussion about this issue detoured from the concern about community membership and devolved into concerns about companies somehow taking advantage of the community and orthogonal issues like discoverability that could be solved independently. 20:27:06 next dims 20:27:08 thingee: I prefer not to think about "these developers" that way, fwiw. They are still contributing 20:27:11 I’m especially disappointed that we’re keeping a rule that enables project teams to exclude contributors from participating fully in the community by stripping them of ATC status. 20:27:15 I don’t like the image that projects of our community. 20:27:18 err next fungi then dims 20:27:24 But I want to thank the project teams that recognize the importance of drivers and have constructive relationships with their driver authors for setting a good example. 20:27:26 done 20:27:53 * flaper87 agrees with dhellmann 20:28:38 fungi: ? 20:28:44 then dims 20:28:46 just wanted to respond to stevemar_droid's concern about identifying supported drivers: that should be up to individual project teams. just as definitions of what a "deiver" is differ from project to project, so should standards for support 20:29:27 we (openstack as a whole) just need to make sure we provide a place where they can be registered and maintained with support information in a consistent and discoverable manner 20:30:04 s/deiver/driver/ 20:30:10 fungi something like whether or not we require CI should be consistent though, I think? 20:30:35 it hasn't been in the past 20:30:51 fungi: well it's a per project thing now 20:30:58 some projects require it, others don't 20:31:06 dims: your turn, then ttx 20:31:09 neutron and cinder and ironic and manila have had distinctly differing opinions on what is needed for driver support 20:31:29 who is going to gate-keep the discoverability aspects? (which drivers pass a minimum bar for being included in docs etc, when to nuke things when things go south)? is that the foundation staff? i second dhellmann 's sentiment as well 20:31:31 stevemar https://etherpad.openstack.org/p/driverlog-validation 20:31:59 3/ is obviously an easy choice, but prefer 1/ and 3/ 20:32:00 done 20:32:01 dims currently it's the docs team rule. that needs to be addressed as I've repeated numerously 20:32:29 the market place is driven by a community repo that has a yaml file today. 20:32:46 thingee : understood 20:33:02 back to you ttx 20:33:11 So the reason why I proposed #3 is that we passed 7-6 votes in the past and that never stood the test of time. If we can't get a stronger majority to support one option, it's probably a bad idea to choose at that precise moment 20:33:37 and I don't want us to discuss this question every week for the next two months 20:34:09 but not answering is not that much better, I admit 20:34:40 Deciding to not make a decision counts as making a decision, right? :) 20:34:50 What do you propose to make progress ? Another indicative vote with the 3 options in ? 20:35:37 If we go with 3, I'd like there to be a commitment to review this once the discoverability issue is fixed 20:35:39 (as time passes I don't see the lines changing, I actually see the lines strengthening) 20:35:56 (And I still sit firmly on the fence) 20:36:12 I would like to hear a proposal from the folks who object to driver teams that solves the community membership issue. 20:36:13 * dims notes that /3 does not really need a vote from us. it can be implemented right away 20:36:20 flaper87: oh, definitely. That is what #3 is about 20:36:21 the resolution option with no special driver team provisions is basically equivalent to not making a decision, as it's the current status quo 20:36:36 dims it does need a vote. it means we table this conversation and wait for results 20:36:41 (if you develop drivers in a level and open fashion, you can apply as a normal project team) 20:36:57 ttx: can we break down other bits that might be individually solvable like the discoverability, such as handling ATC status? 20:37:09 so, do we have volunteers to work on the discoverability issue ? 20:37:15 flaper87 me 20:37:16 ++ dtroyer 20:37:18 dhellmann: I guess the POV of that group is taht there is no community membership issue to be solved ? 20:37:18 thingee : talking about what's visible to folks outside of TC 20:37:57 thingee: so, are you against #1 entirely or just against #1 before the discoverability issue is fixed ? 20:37:57 dtroyer: by default ATC status would be handled through extra-atc mechanism 20:38:00 atc status is generally solvable already if project teams want to list driver devs as "extra atcs" in governance. though it merits repeating that being an atc just means you get to vote in elections. it's not "free passes to conferences" 20:38:12 ttx: I don't understand that. These folks are part of the electorate today. When the status expires because their repo is no longer "official" they may not be. Am I really the only one who considers that an issue? 20:38:29 dhellmann: no, I do 20:38:41 fungi : I have serious doubts that teams that already can't work with driver authors are going to go that route. 20:38:46 hence my strong preference for #1 and addressing this issue right away 20:38:47 dhellmann: well, that is in part oslved by the deletions list in governance. if they continue not contributing to official projects for a year they cease being atcs 20:38:49 dhellmann: no. but driver teams as first-class status doesn't make sense to me at all and is not the right solution 20:39:03 it's odd to me, to think that a project team would spend the time to mark a driver as supported, and to give those folks extra ATCs, but not allow those drivers in tree 20:39:05 dtroyer +1 20:39:25 the time spent to vet those drivers as supported is most of the effort to keep them in tree 20:39:31 s/most/much 20:39:32 jroll so to clear something up, some won't today. That's a whole other issue though 20:39:41 jroll: yeah, that's what I was thinking. Although there is the longer term maint. commitment 20:40:02 fungi : yes, that's right. We're telling them their contributions don't count unless they work on "common" aspects of the parent project. I don't think that's a reasonable position for us to take, as a community. We expect too many contributors to spend too much time on things. I don't think it's realistic. 20:40:05 right, so I'm not sure that those things will help 20:40:36 Our issue with drivers in tree is we don't have the licenses/equipment to fully validate and maintain them. 20:40:37 jroll I think for some projects it's because no one wants to step up to begin with to setup the validation to say what is compatible 20:40:55 jroll it's my belief once we help projects with a system that this will continue to be a solution to be taken over 20:41:21 dhellmann: if you take the position of who has control over the driver development, it makes some sense though. Would those driver teams really defer to the TC ? Do we want them to ? 20:41:30 this comes from my perspective of spending time on this issue since the summit in tokyo 20:41:44 thingee: I guess my point is: for ironic, I'm not willing to call something supported unless they have CI running. which means they can be in tree. so this changes nothing for ironic drivers. 20:41:44 ttx: I don't care about their motivation. I care about giving them a choice. They have no choice today. 20:41:48 stevemar_droid: did we get a sense from the survey about how many folks that were only working on drivers were concerned about ATC status? 20:41:50 s/point/perspective/ maybe 20:41:50 hmm, too many parallel discussions, we'll return back to voicing 20:41:58 dhellmann: ++ 20:41:59 * jroll shuts up 20:42:11 dhellmann: ttx fwiw, I also care about us having a clear stand on this 20:42:20 dhellmann: it is a good point 20:42:20 sdague +1 20:42:25 sdague : i asked that question before. but then i think that we should do the right thing ... 20:42:40 sdagues not really 20:42:42 stevemar_droid: sdague: my take on the survey was that very few driver maintainers chimed in. it was mostly (ex-)ptls 20:42:44 jroll no it's fine to discuss this. so I think the next step is highlighting these vendors in the market place. I'm not even sure if you recommend to driver maintainers to take advantage of docs.o.o 20:43:19 stevemar_droid: sdague: and while i consider being able to vote in elections very important, any idea if the people who expressed an interest in atc merely saw it as a way to get other unrelated perks (like conference registration discounts, which have already gone away)? 20:43:39 ok, one question at a time, first that one from fungi 20:43:45 thingee: I do, for the drivers in tree. the ones out of tree can't use docs.o.o, no matter what they do, which makes me sad. 20:43:49 sorry ttx 20:44:05 jroll right so option 3 is to fix those out-of-tree drivers to be included in docs 20:44:14 next I have one for dhellmann 20:44:26 fungi, I suspect that was the initial reasoning for it. We already have low turn out rate for some elections I believe? 20:44:41 my question was mostly rhetorical. i doubt we have statistics to support any answer 20:44:52 but thanks stevemar_droid 20:45:02 * dhellmann awaits the question from ttx 20:45:06 fungi, sorry 20:45:40 dhellmann: my question would be -- what do you propose we do now ? Try to pass the driver teams proposal using a weak majority ? 20:46:05 I proposed #3 because it's been a few weeks now and the split doesn't fix itself, only gets worse 20:46:20 o/ (for when voicing comes around) 20:46:42 I'm happy to defer to any strong majority on this topic, but we don't have one 20:47:04 and I don't see the lines moving. So... what now? 20:47:10 ttx: I would like to see a real proposal that addresses the membership issue from someone who opposes it. Because if there isn't another way to do that, then I want people to reconsider the motivation for making the rule change and reconsider their positions in light of that, which seems to not have been on anyone's mind during this discussion. 20:47:49 to be clear, the membership issue being, people currently voting that won't be able to vote in the near future 20:47:57 yes 20:48:01 (due to a decision outside of their reach about team membership) 20:48:09 yes 20:48:15 which IIUC we alrady have a mechanism, if non-ideal, to handle that 20:48:40 I have no expectation of the neutron team exercising that option, so I don't consider it a serious solution. 20:48:48 dhellmann: +1 20:48:53 Note: doesn't have to be the neutron team 20:48:56 (the ironic team likely wouldn't either) 20:49:00 a related example is the fuel team retiring repos which had contributors that weren't contributing to other repos (even other parts of fuel) 20:49:06 can be the TC itself 20:49:09 is that the only option for networking-* comtributors to get extra-ATC status? 20:49:13 but the voting question doesn't seem to be in the top #3 list of concerns by existing driver teams 20:49:15 ttx: that's what I though 20:49:16 t 20:49:49 The docs thing keeps coming up, it would be interesting to fix that as a concrete issue 20:49:49 yes, nobody ever said 'I want to be able to continue to vote' 20:49:53 how would the TC decide which drivers should get extra-atc? all? ones that 'work'? 20:49:55 sdague : I honestly didn't ask them. I think our governance is broken right now, because a team can kick out members of the community who have been active contributors. 20:50:17 mtreinish: sdague was checking the patch and noticed your votes are missing. Is that because you're on the fence or just wanted to have this discussion first ? (I know ttx is on the fence) 20:50:18 dhellmann: and we can recover them if we want 20:50:26 dhellmann: to take jroll's point, ironic may remove drivers from the orinic project (for legitimate reasons) which will strip their ability to vote in ironic ptl or tc elections (assuming they don't contribute to any other repos). should we be trying to "solve" that? 20:50:36 * flaper87 was not around last week and can't remember the voting from the logs 20:50:43 s/orinic/ironic/ 20:50:43 jroll: we currently have expectations of other projects as official, I think we would have similar there…ie, quality (CI) and so on 20:50:44 jroll as fungi said earlier, whatever the team sets as the validation. as I've pointed to this etherpad earlier there's a clear trend https://etherpad.openstack.org/p/driverlog-validation 20:50:49 flaper87: which patch? 20:50:54 there were 2 20:50:56 fungi : ironic has a set of policies for driver authors to follow to stay in. The authors get to choose. Neutron has not provided a similar mechanism. 20:51:02 mtreinish: https://review.openstack.org/#/c/403829/ (sorry) 20:51:09 honestly, I'd like to throw out steve's survey. there were four emails in that thread, from two people that are driver maintainers. the rest were (ex-)ptl/tc members or cinder cores 20:51:20 dtroyer: sounds like a driver team :) 20:51:34 jroll: I was hoping for more non-core responses there. 20:51:41 smcginnis: me too :( 20:51:47 flaper87: yeh, I zeroed out my vote yesterday, because this doesn't feel like concensus 20:51:47 flaper87: oh I was -1 on that in the irc vote 20:52:22 and fix the docs situation does feel like a common first step which can be done 20:52:38 smcginnis: lack of responses from driver authors on a thread to the mailing list where official openstack development is coordinated strikes me as a sort of result 20:52:39 thingee: and if we expect project teams won't validate out of tree drivers, as doug and I mentioned, then nobody will get extra-atc, is my point 20:52:53 jroll, that sounds fine to me. I wish there were more people replying. 20:52:56 fungi: this was a private thread fwiw 20:52:57 dhellmann agreed sort of. I see armax attempting to set validation points for plugins https://review.openstack.org/#/c/391594/1 20:53:01 dhellmann: so the answer to your question seems to be: "it's not that much of a problem, but the TC can use teh extra-atc mechanism to propose and add ATC status to drivers that fall in the cracks" 20:53:07 o/ 20:53:10 sdague: regarding docs: If somebody writes up a rule on what that means, I'm fine (note I'm a docs member but don't speak for the team). 20:53:16 jroll: yeah, more projecting to the followup thread to the -dev ml about the private thread 20:53:19 I think I had sdague in the queue with a question 20:53:23 fungi: nod 20:53:23 dhellmann in terms for the system to be policed, I don't see neutron taking that up until A system is in place 20:53:29 ttx: well, I just jumped out there with it 20:53:42 Tired, long day 20:53:43 basically, it seems like the discoverability and docs question as the primary concerns 20:54:08 fixing them moves the ball forward, lets the dust settle, and we can then ask the next question about what is needed 20:54:10 jroll if I work on a random repo outside of openstack, should I get extra-atc status? 20:54:21 if I read what you typed correctly 20:54:38 thingee: if an extra-atc change is proposed, the TC will evaluate it 20:54:41 thingee: and the other question: Should that random repo publish to docs.o.o? 20:54:50 (if the repo is too random, probably will say no) 20:55:05 ttx: do we have an extra-atcs list that is not attached to a project team? 20:55:09 AJaeger: if the TC says it can, probably yes 20:55:26 thingee: I'm not talking about random repos, I'm talking about the out of tree drivers that might apply for official status like we're talking about here 20:55:27 we should be welcoming people with open arms given where we are on the maturity curve ... 20:55:30 We have TC repos, I don't see why we couldn't have TC's extra-atcs 20:55:34 AJaeger for cases like neutron, if there is a system in place that validates that a driver out of tree is compatible and working by whatever means in tempest, yes they should have a right to be docs.o.o 20:55:39 ttx: ok 20:55:45 ttx: at that point, wouldn't it be better for the repo to be just part of openstack? 20:55:54 jroll see my last message to AJaeger 20:56:06 jroll, dhellmann, if maintainers don't bother to show up to meetings or reply to ml or surveys, then what are the odds they are voting? 20:56:10 time check, 10 mins (or less) 20:56:15 jroll however, you made the choice to not validate out of tree drivers. which I don't understand why 20:56:34 flaper87: well that would mean compromising on what "an openstack project" is 20:56:40 stevemar_droid : I would still rather give them the choice. 20:56:41 thingee: if the project team is going to spend the effort to do that, they would make the driver repo part of the project team 20:56:50 flaper87: with extra-atcs we can recognize that driver work is essentail to thee success of openstack 20:56:56 without making it openstack proper 20:56:56 dhellmann, true 20:57:19 jroll to put it simply, I wouldn't do both out of tree and in-tree drivers. I would pick one or the other. 20:57:24 anyway, just to recap. I really think we should do #1 since that gives drivers a choice 20:57:31 ttx : how far away is extra-atcs and driver-team in that case? 20:57:41 I can live by #3 if we set a checkpoint date to revisit #1 20:57:56 thingee: you can't "not do" out of tree drivers, people can just write them. unless you block it in code which just leads to forks. 20:58:14 dims: it's different in my opinion. In one case you say that a driver team is an openstack team, even if it does not openly collaborate 20:58:22 jroll I mean to say recognize one or the other 20:58:28 on the other you say people working on drivers should have a voice in elections 20:58:38 but, to be really honest, going with #3 would be a bit disappointing but it's better than #2 20:58:47 Doesn't extra-acts have a stigma around it? We've only used it once in Keystone. Seems like we're using it as a convenience 20:58:51 ttx : ack 20:58:52 thingee: if a project team spends the effort to validate out-of-tree drivers, they should just accept those drivers under the project 20:59:00 thingee: maybe we should s/tree/project/ in these discussions 20:59:10 as in, a project can be many repos 20:59:11 To solve the problem of giving people ATC properly 20:59:18 OK, I propose we pause this discussion for a couple of weeks, start the discovery work, let the water calm down 20:59:20 To support dhellmann's point: if there is a mechanism by which members of the polity can have franchise removed due to changes beyond their control, those members are unlikely to expect to seek redress of any other concern within the same goernance mechanisms that enable them to be disenfranchised. This can affect more than just voting, and the disenfranchised folk may have a poor relation with their host project (or they would be less 20:59:20 likely to lose franchise). 20:59:25 (no open discussion today :-/) 20:59:29 jroll or base with a driver repo :) 20:59:44 take cinder for example. it recognizes only in-tree. that's what's in docs.o.o and that's what it's in the market place. Neutron it would be out of tree, but they would only recognize out of tree drivers that meet the validation they set. thus what will be in docs and market place. 20:59:50 jgriffith: that too :) 20:59:54 We don't wait until discovery work is complete to revisit it, just a couple meetings without discussing it 20:59:59 chiming in late, but i think we need to do #3 regardless and i want to figure out how to fix the data side of that. it’s definitely a question i hear ALL the time (usually in the form of “which products work with project y?”) 21:00:00 see where that puts us 21:00:20 thingee: in my world, neutron would either allow those in the stadium, or we would have driver teams. the former isn't happening. 21:00:21 EmilienM: you had something ? 21:00:26 jbryce : for sure 21:00:31 but i think the core issue does need to get resolved because, just from a practical perspective, most of openstack is not super useful without drivers 21:00:32 ttx: no but maybe some folks had something 21:00:38 jbryce: #3 is basically # giving priority to the discoverability issue, though. 21:00:49 jroll I don't understand why the stadium matters. Projects have this solved without having a "stadium" 21:00:53 nothing we can't do if we go with #1 21:00:55 ok, time is up 21:01:04 and the ambiguity is something that i hear is confusing for companies who are trying to integrate with us 21:01:25 for me it mostly comes down to this question: are we in a position where we need to encourage people/companies to write drivers, or do they already have plenty of incentive to do so? 21:01:33 Thanks everyone, even if little progress here 21:01:40 (noting i don't know the answer_ 21:01:40 #endmeeting