20:01:23 <ttx> #startmeeting tc
20:01:24 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:27 <openstack> The meeting name has been set to 'tc'
20:01:30 <ttx> Hi everyone!
20:01:34 <ttx> Our agenda for today is at:
20:01:38 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:38 * edleafe slinks to the side of the room
20:01:44 <mrhillsman> o/
20:01:45 <ttx> #topic Add extra-atc nominations for Trove
20:01:50 <ttx> #link https://review.openstack.org/414764
20:01:57 <ttx> The latest rev looks good to me
20:02:14 <ttx> If you pile up approvals we can merge it now
20:02:27 <dims> +1
20:02:28 * amrith is happy to answer questions about that if required
20:02:48 <ttx> Sounds like it has majority support and no more objections now
20:02:56 * ttx approved and moves on
20:02:56 <EmilienM> ship it!
20:03:04 <amrith> that was easy!
20:03:14 <ttx> flaper87: yt?
20:03:24 <dims> amrith : thanks for being a mentor
20:03:37 <ttx> #topic Reference doc for new language additions
20:03:41 <amrith> thx dims
20:03:43 <ttx> #link https://review.openstack.org/398875
20:03:55 <ttx> Was counting on flaper87 to present this
20:04:02 <ttx> looks good enough to me for an initial version of the requirements
20:04:10 <ttx> we can discuss the merits of subsequent improvements as separate changes
20:04:19 <flaper87> o/
20:04:23 <ttx> here he is
20:04:28 <flaper87> sorry, couple of mins late
20:04:28 <ttx> flaper87: floor is yours
20:04:32 <sigmavirus> o/
20:04:38 <flaper87> yeah, so, I've updated the patch and addressed the latest comments
20:04:53 <flaper87> I've submitted another patch to fix the last comments from yday
20:04:56 <ttx> saw a subsequent patch already, which is good -- shall be a living document anyway
20:04:57 <flaper87> (or was that today?)
20:05:05 <flaper87> yeah
20:05:35 <flaper87> I just noticed Graham's last comment and I can address that
20:05:47 <EmilienM> flaper87: excellent work on this first draft
20:05:55 <fungi> cool, i wanted to see the in-meeting discussion covering the most recent inline comments before adding my rc vote
20:06:00 <flaper87> but sounds like something we can fix in subsequent patches, unless I missed something
20:06:03 <ttx> comments, remaining objections ?
20:06:09 <thingee> fungi +1
20:06:14 <dims> +1 to living document + patches
20:06:36 <fungi> 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 <flaper87> EmilienM: danke
20:07:03 <mordred> o/ (sorry I'm late - in an all-day offsite, but am lurking)
20:07:03 <flaper87> flaper87: yeah, FWIW (this was part of the very first patch) I intentionally started with a higher bar
20:07:06 <thingee> flaper87 please enlighten us with regards to mugsie's comments
20:07:06 <fungi> i like to also consider it as compliment/counterpoint to dtroyer's cti patch for go
20:07:11 <dtroyer> 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 <flaper87> yeah, I think there might be a missunderstanding with my wording
20:07:49 <ttx> I read it as we need to provide equivalents, that doesn't mean everyone needs to use them
20:07:57 <flaper87> the crux of that section is guaranteeing the ocmpatibility from an ops perspective
20:08:02 <ttx> (but they probably need a good reason not to)
20:08:05 <flaper87> either by the support of already existing language features
20:08:10 <mugsie_> My point about the requirements was that we may need more than just these 2 libs to get the operator consitancy
20:08:12 <flaper87> or by implementing the required libs
20:08:20 <dtroyer> fungi: I see this as the prereq/enabler for the CTI doc
20:08:29 <flaper87> mugsie_: if we need more, we might need to add them there
20:08:31 <fungi> dtroyer: so you see this as compatible (at least in spirit) with your end of the effort?
20:08:52 <fungi> seemed that way to me, but wanted to be sure it's not at odds
20:08:53 <flaper87> The goal is to not break ops or other compatibility by introducing a new language
20:08:55 <dtroyer> fungi: I wrote the golang cti doc with this in mind, and think it is already pretty close
20:09:27 <fungi> awesome
20:09:33 <ttx> sounds like it's at a stage where it's simpler to propose improvements as separate changes
20:09:44 <dtroyer> ttx ++
20:09:49 <dims> ++ttx
20:09:52 <flaper87> mugsie_: would you agree with this not being a blocker ?
20:10:15 <mugsie_> Not a blocker - we can amend it
20:10:31 <flaper87> mugsie_: awesome, thanks. I appreciate your input on this
20:10:35 <mugsie_> It's not the concept, just how it is stated right now
20:10:40 <ttx> ok cool
20:10:41 <stevemar_droid> Here
20:10:52 <ttx> look! a stevemar
20:10:56 <stevemar_droid> Here-ish, mostly lurking.
20:10:59 <thingee> oh no stevemar_droid turned into a droid!
20:11:01 <flaper87> ttx: a droid stevemar
20:11:10 <fungi> 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 <ttx> this is not the droid we are looking for
20:11:22 <stevemar_droid> :)
20:11:28 <flaper87> fungi: it will need for sure
20:11:50 <ttx> 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 <flaper87> fungi: ++
20:12:36 <dims> LOL +1 fungi
20:12:42 <ttx> I just want to get the constructive effort started
20:12:50 <mtreinish> fungi: heh, we can still hate go and approve this :)
20:13:01 <smcginnis> mtreinish: :)
20:13:06 <flaper87> yeah, I'm happy to work with ppl interested in go in this process
20:13:18 <dtroyer> flaper87: that work is underway...
20:13:21 <ttx> OK, last minute to object before I approve
20:13:23 <flaper87> I'm not saying I'm going to code in go but I'd like to walk through this process
20:13:25 <stevemar_droid> flaper87, I'm sure dtroyer will help
20:13:25 <flaper87> dtroyer: yup
20:13:43 <flaper87> dtroyer: by all means, feel free to ping me and keep me in the loop
20:14:14 <ttx> ok, it's in
20:14:21 <flaper87> w000h000
20:14:22 <ttx> thanks for driving this flaper87
20:14:25 <stevemar_droid> Nice
20:14:26 <flaper87> go go go
20:14:28 <flaper87> my pleasure
20:14:32 <EmilienM> flaper87: thx again :)
20:14:35 <dtroyer> Thanks flaper87
20:14:44 <dims> flaper87 burning up karma :)
20:14:49 <ttx> #topic Driver teams: establish new "driver team" concept (or not)
20:14:58 <ttx> stevemar posted the results of the survey question we asked driver maintainers:
20:15:02 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html
20:15:09 <ttx> Let's use the voice-turn system to avoid speaking over one another.
20:15:10 <dims> nice work on that stevemar
20:15:16 <fungi> unsurprisingly, everyone wants everything ;)
20:15:17 <ttx> I can summarize my position first
20:15:28 <ttx> At this stage pretty much everyone agrees that we need to fix driver visibility on openstack website properties
20:15:35 <ttx> And that it is the main and urgent issue to solve
20:15:45 <ttx> There is still much disagreement on whether we /also/ need to change governance to consider driver teams as official OpenStack teams
20:15:54 <ttx> On one side people wanting to be inclusive and welcoming of all forms of contributing to OpenStack success
20:16:04 <ttx> On the other side people seeing it as unnecessary, potentially diluting openness values and difficult to reverse
20:16:15 <ttx> 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 <flaper87> o/
20:16:23 <dtroyer> o/
20:16:25 <ttx> 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 <ttx> So I'd like to add a third option. We have:
20:16:35 <ttx> 1/ Add driver teams now: https://review.openstack.org/403829
20:16:45 <ttx> 2/ Clearly exclude driver teams (unless developed as a level playing field) now: https://review.openstack.org/403836
20:16:49 <ttx> I'd add:
20:16:57 <ttx> 3/ Fix driver visibility first, table the governance choice until that's done, and see what's still needed then
20:17:03 <ttx> 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 <ttx> Discussing it again next week would just delay starting to work on fixing the main issue
20:17:18 <ttx> which is why at this point I support (3)
20:17:22 <ttx> </endposition>
20:17:28 <ttx> fungi: your turn
20:17:37 <ttx> next flaper87, dtroyer
20:18:27 <fungi> just wanted to interject that i'm happy to liaise with the marketplace devs on improvements on that end
20:18:42 <fungi> there were some indications in the survey results of improvement people wanted to see
20:18:58 <fungi> we should probably try to gather more
20:19:13 <ttx> ok, flaper87 ?
20:19:19 <flaper87> yup, writing
20:19:40 <ttx> remember to raise your hand if you want voice
20:20:00 * ttx pipes some interlude music while flaper87 types
20:20:06 <flaper87> 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 <sdague> o/
20:20:20 <flaper87> if people happen to not like that, then I guess I can live by #3
20:20:23 <stevemar_droid> o/
20:20:33 <thingee> o/
20:20:35 * flaper87 done
20:20:42 <ttx> ok, dtroyer now
20:20:48 * dims just listens
20:20:57 <ttx> next sdague stevemar thingee
20:20:57 <dtroyer> 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 <dtroyer> 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 <dtroyer> 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 <ttx> sdague
20:22:14 <ttx> next stevemar, thingee
20:22:34 <sdague> I think I'm largely with dtroyer on this. #3 seems very reasonable way to address the major current friction points
20:23:03 <sdague> 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 <sdague> especially because otherwise it seems like TC is going to be evaluating lots of driver team applications
20:23:46 <sdague> </end> for now
20:23:53 <ttx> stevemar: you're on
20:23:58 <ttx> next thingee
20:23:59 <dhellmann> o/
20:24:03 <stevemar_droid> 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 <stevemar_droid> And that seems like the same questions we'll have about what makes them official
20:24:37 <stevemar_droid> I like sdagues last point though
20:24:41 * stevemar_droid done
20:24:50 <ttx> thingee now
20:24:53 <ttx> next dhellmann
20:25:00 <thingee> 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 <ttx> flaper87: feel free to interject
20:25:31 <dims> o/
20:25:39 <flaper87> thingee: sure, so, I believe that doesn't answer the question of whether we believe drivers are important or not
20:25:54 <flaper87> discoverability is a critical thing but it doesn't solve the issue of including drivers
20:26:11 <thingee> why? it's making them visible. Highlighting them in a way of being compatible.
20:26:12 <flaper87> Based on stevemar_droid's summary, there's a feeling that drivers should be included in openstack
20:26:26 <flaper87> I personally feel they should be part of the openstack community, officially
20:26:37 <thingee> 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 <thingee> done
20:26:56 <ttx> dhellmann: your turn
20:27:04 <dhellmann> 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 <ttx> next dims
20:27:08 <flaper87> thingee: I prefer not to think about "these developers" that way, fwiw. They are still contributing
20:27:11 <dhellmann> 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 <dhellmann> I don’t like the image that projects of our community.
20:27:18 <ttx> err next fungi then dims
20:27:24 <dhellmann> 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 <dhellmann> done
20:27:53 * flaper87 agrees with dhellmann
20:28:38 <ttx> fungi: ?
20:28:44 <ttx> then dims
20:28:46 <fungi> 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 <fungi> 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 <fungi> s/deiver/driver/
20:30:10 <stevemar_droid> fungi something like whether or not we require CI should be consistent though, I think?
20:30:35 <fungi> it hasn't been in the past
20:30:51 <mtreinish> fungi: well it's a per project thing now
20:30:58 <mtreinish> some projects require it, others don't
20:31:06 <ttx> dims: your turn, then ttx
20:31:09 <fungi> neutron and cinder and ironic and manila have had distinctly differing opinions on what is needed for driver support
20:31:29 <dims> 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 <thingee> stevemar https://etherpad.openstack.org/p/driverlog-validation
20:31:59 <dims> 3/ is obviously an easy choice, but prefer 1/ and 3/
20:32:00 <dims> done
20:32:01 <thingee> dims currently it's the docs team rule. that needs to be addressed as I've repeated numerously
20:32:29 <thingee> the market place is driven by a community repo that has a yaml file today.
20:32:46 <dims> thingee : understood
20:33:02 <dims> back to you ttx
20:33:11 <ttx> 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 <ttx> and I don't want us to discuss this question every week for the next two months
20:34:09 <ttx> but not answering is not that much better, I admit
20:34:40 <stevemar_droid> Deciding to not make a decision counts as making a decision, right? :)
20:34:50 <ttx> What do you propose to make progress ? Another indicative vote with the 3 options in ?
20:35:37 <flaper87> 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 <ttx> (as time passes I don't see the lines changing, I actually see the lines strengthening)
20:35:56 <ttx> (And I still sit firmly on the fence)
20:36:12 <dhellmann> 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 <ttx> flaper87: oh, definitely. That is what #3 is about
20:36:21 <fungi> 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 <thingee> dims it does need a vote. it means we table this conversation and wait for results
20:36:41 <fungi> (if you develop drivers in a level and open fashion, you can apply as a normal project team)
20:36:57 <dtroyer> ttx: can we break down other bits that might be individually solvable like the discoverability, such as handling ATC status?
20:37:09 <flaper87> so, do we have volunteers to work on the discoverability issue ?
20:37:15 <thingee> flaper87 me
20:37:16 <stevemar_droid> ++ dtroyer
20:37:18 <ttx> dhellmann: I guess the POV of that group is taht there is no community membership issue to be solved ?
20:37:18 <dims> thingee : talking about what's visible to folks outside of TC
20:37:57 <flaper87> thingee: so, are you against #1 entirely or just against #1 before the discoverability issue is fixed ?
20:37:57 <ttx> dtroyer: by default ATC status would be handled through extra-atc mechanism
20:38:00 <fungi> 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 <dhellmann> 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 <flaper87> dhellmann: no, I do
20:38:41 <dhellmann> fungi : I have serious doubts that teams that already can't work with driver authors are going to go that route.
20:38:46 <flaper87> hence my strong preference for #1 and addressing this issue right away
20:38:47 <fungi> 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 <dtroyer> 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 <jroll> 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 <thingee> dtroyer +1
20:39:25 <jroll> the time spent to vet those drivers as supported is most of the effort to keep them in tree
20:39:31 <jroll> s/most/much
20:39:32 <thingee> jroll so to clear something up, some won't today. That's a whole other issue though
20:39:41 <mtreinish> jroll: yeah, that's what I was thinking. Although there is the longer term maint. commitment
20:40:02 <dhellmann> 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 <jroll> right, so I'm not sure that those things will help
20:40:36 <johnsom> Our issue with drivers in tree is we don't have the licenses/equipment to fully validate and maintain them.
20:40:37 <thingee> 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 <thingee> 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 <ttx> 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 <thingee> this comes from my perspective of spending time on this issue since the summit in tokyo
20:41:44 <jroll> 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 <dhellmann> ttx: I don't care about their motivation. I care about giving them a choice. They have no choice today.
20:41:48 <sdague> 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 <jroll> s/point/perspective/ maybe
20:41:50 <ttx> hmm, too many parallel discussions, we'll return back to voicing
20:41:58 <flaper87> dhellmann: ++
20:41:59 * jroll shuts up
20:42:11 <flaper87> dhellmann: ttx fwiw, I also care about us having a clear stand on this
20:42:20 <ttx> dhellmann: it is a good point
20:42:20 <jgriffith> sdague +1
20:42:25 <dims> sdague : i asked that question before. but then i think that we should do the right thing ...
20:42:40 <stevemar_droid> sdagues not really
20:42:42 <jroll> stevemar_droid: sdague: my take on the survey was that very few driver maintainers chimed in. it was mostly (ex-)ptls
20:42:44 <thingee> 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 <fungi> 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 <ttx> ok, one question at a time, first that one from fungi
20:43:45 <jroll> 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 <jroll> sorry ttx
20:44:05 <thingee> jroll right so option 3 is to fix those out-of-tree drivers to be included in docs
20:44:14 <ttx> next I have one for dhellmann
20:44:26 <stevemar_droid> 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 <fungi> my question was mostly rhetorical. i doubt we have statistics to support any answer
20:44:52 <fungi> but thanks stevemar_droid
20:45:02 * dhellmann awaits the question from ttx
20:45:06 <stevemar_droid> fungi, sorry
20:45:40 <ttx> 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 <ttx> I proposed #3 because it's been a few weeks now and the split doesn't fix itself, only gets worse
20:46:20 <sdague> o/ (for when voicing comes around)
20:46:42 <ttx> I'm happy to defer to any strong majority on this topic, but we don't have one
20:47:04 <ttx> and I don't see the lines moving. So...  what now?
20:47:10 <dhellmann> 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 <ttx> to be clear, the membership issue being, people currently voting that won't be able to vote in the near future
20:47:57 <dhellmann> yes
20:48:01 <ttx> (due to a decision outside of their reach about team membership)
20:48:09 <dhellmann> yes
20:48:15 <dtroyer> which IIUC we alrady have a mechanism, if non-ideal, to handle that
20:48:40 <dhellmann> I have no expectation of the neutron team exercising that option, so I don't consider it a serious solution.
20:48:48 <jroll> dhellmann: +1
20:48:53 <ttx> Note: doesn't have to be the neutron team
20:48:56 <jroll> (the ironic team likely wouldn't either)
20:49:00 <fungi> 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 <ttx> can be the TC itself
20:49:09 <dtroyer> is that the only option for networking-* comtributors to get extra-ATC status?
20:49:13 <sdague> but the voting question doesn't seem to be in the top #3 list of concerns by existing driver teams
20:49:15 <dtroyer> ttx: that's what I though
20:49:16 <dtroyer> t
20:49:49 <sdague> The docs thing keeps coming up, it would be interesting to fix that as a concrete issue
20:49:49 <ttx> yes, nobody ever said 'I want to be able to continue to vote'
20:49:53 <jroll> how would the TC decide which drivers should get extra-atc? all? ones that 'work'?
20:49:55 <dhellmann> 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 <flaper87> 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 <ttx> dhellmann: and we can recover them if we want
20:50:26 <fungi> 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 <fungi> s/orinic/ironic/
20:50:43 <dtroyer> 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 <thingee> 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 <mtreinish> flaper87: which patch?
20:50:54 <mtreinish> there were 2
20:50:56 <dhellmann> 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 <flaper87> mtreinish: https://review.openstack.org/#/c/403829/ (sorry)
20:51:09 <jroll> 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 <jroll> dtroyer: sounds like a driver team :)
20:51:34 <smcginnis> jroll: I was hoping for more non-core responses there.
20:51:41 <jroll> smcginnis: me too :(
20:51:47 <sdague> flaper87: yeh, I zeroed out my vote yesterday, because this doesn't feel like concensus
20:51:47 <mtreinish> flaper87: oh I was -1 on that in the irc vote
20:52:22 <sdague> and fix the docs situation does feel like a common first step which can be done
20:52:38 <fungi> 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 <jroll> 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 <stevemar_droid> jroll, that sounds fine to me. I wish there were more people replying.
20:52:56 <jroll> fungi: this was a private thread fwiw
20:52:57 <thingee> dhellmann agreed sort of. I see armax attempting to set validation points for plugins https://review.openstack.org/#/c/391594/1
20:53:01 <ttx> 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 <persia> o/
20:53:10 <AJaeger> 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 <fungi> jroll: yeah, more projecting to the followup thread to the -dev ml about the private thread
20:53:19 <ttx> I think I had sdague in the queue with a question
20:53:23 <jroll> fungi: nod
20:53:23 <thingee> 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 <sdague> ttx: well, I just jumped out there with it
20:53:42 <ttx> Tired, long day
20:53:43 <sdague> basically, it seems like the discoverability and docs question as the primary concerns
20:54:08 <sdague> 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 <thingee> jroll if I work on a random repo outside of openstack, should I get extra-atc status?
20:54:21 <thingee> if I read what you typed correctly
20:54:38 <ttx> thingee: if an extra-atc change is proposed, the TC will evaluate it
20:54:41 <AJaeger> thingee: and the other question: Should that random repo publish to docs.o.o?
20:54:50 <ttx> (if the repo is too random, probably will say no)
20:55:05 <dhellmann> ttx: do we have an extra-atcs list that is not attached to a project team?
20:55:09 <ttx> AJaeger: if the TC says it can, probably yes
20:55:26 <jroll> 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 <dims> we should be welcoming people with open arms given where we are on the maturity curve ...
20:55:30 <ttx> We have TC repos, I don't see why we couldn't have TC's extra-atcs
20:55:34 <thingee> 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 <dhellmann> ttx: ok
20:55:45 <flaper87> ttx: at that point, wouldn't it be better for the repo to be just part of openstack?
20:55:54 <thingee> jroll see my last message to AJaeger
20:56:06 <stevemar_droid> 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 <flaper87> time check, 10 mins (or less)
20:56:15 <thingee> jroll however, you made the choice to not validate out of tree drivers. which I don't understand why
20:56:34 <ttx> flaper87: well that would mean compromising on what "an openstack project" is
20:56:40 <dhellmann> stevemar_droid : I would still rather give them the choice.
20:56:41 <jroll> 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 <ttx> flaper87: with extra-atcs we can recognize that driver work is essentail to thee success of openstack
20:56:56 <ttx> without making it openstack proper
20:56:56 <stevemar_droid> dhellmann, true
20:57:19 <thingee> 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 <flaper87> anyway, just to recap. I really think we should do #1 since that gives drivers a choice
20:57:31 <dims> ttx : how far away is extra-atcs and driver-team in that case?
20:57:41 <flaper87> I can live by #3 if we set a checkpoint date to revisit #1
20:57:56 <jroll> 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 <ttx> 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 <thingee> jroll I mean to say recognize one or the other
20:58:28 <ttx> on the other you say people working on drivers should have a voice in elections
20:58:38 <flaper87> but, to be really honest, going with #3 would be a bit disappointing but it's better than #2
20:58:47 <stevemar_droid> 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 <dims> ttx : ack
20:58:52 <jroll> 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 <jroll> thingee: maybe we should s/tree/project/ in these discussions
20:59:10 <jroll> as in, a project can be many repos
20:59:11 <stevemar_droid> To solve the problem of giving people ATC properly
20:59:18 <ttx> OK, I propose we pause this discussion for a couple of weeks, start the discovery work, let the water calm down
20:59:20 <persia> 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 <persia> likely to lose franchise).
20:59:25 <EmilienM> (no open discussion today :-/)
20:59:29 <jgriffith> jroll or base with a driver repo :)
20:59:44 <thingee> 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 <jroll> jgriffith: that too :)
20:59:54 <ttx> We don't wait until discovery work is complete to revisit it, just a couple meetings without discussing it
20:59:59 <jbryce> 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 <ttx> see where that puts us
21:00:20 <jroll> 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 <ttx> EmilienM: you had something ?
21:00:26 <dims> jbryce : for sure
21:00:31 <jbryce> 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 <EmilienM> ttx: no but maybe some folks had something
21:00:38 <flaper87> jbryce: #3 is basically # giving priority to the discoverability issue, though.
21:00:49 <thingee> jroll I don't understand why the stadium matters. Projects have this solved without having a "stadium"
21:00:53 <flaper87> nothing we can't do if we go with #1
21:00:55 <ttx> ok, time is up
21:01:04 <jbryce> and the ambiguity is something that i hear is confusing for companies who are trying to integrate with us
21:01:25 <fungi> 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 <ttx> Thanks everyone, even if little progress here
21:01:40 <fungi> (noting i don't know the answer_
21:01:40 <ttx> #endmeeting