15:00:16 <bswartz> #startmeeting manila
15:00:17 <openstack> Meeting started Thu Apr  9 15:00:16 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:20 <openstack> The meeting name has been set to 'manila'
15:00:35 <bswartz> hello all
15:00:35 <lpabon> hi
15:00:38 <toabctl> hi
15:00:38 <cknight> Hi
15:00:40 <vponomaryov> hi
15:00:40 <geguileo> Hi
15:00:40 <tbarron> hi
15:00:41 <ganso_> hi
15:00:45 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:00:46 <csaba> hi
15:01:15 <bswartz> #topic Kilo-RC1 status (bugs)
15:01:35 <bswartz> so first of all, I'm happy that we've found and closed so many bugs since K-3
15:01:40 <bswartz> #link https://launchpad.net/manila/+milestone/kilo-rc1
15:02:01 <bswartz> however I think it's past time for a RC1, and we've got a few left to close
15:02:14 <markstur_> hi
15:02:14 <bswartz> so I'm going to cover them now
15:03:00 <bswartz> I'm looking retarget bugs out of Kilo soon
15:03:38 <bswartz> so please be responsive to reviewer feedback if you're a submitter, and if you're a reviewer, please focus on the 5 remaining bugs
15:03:49 <bswartz> Failed to allow-access for native_glusterfs
15:03:52 <bswartz> https://bugs.launchpad.net/bugs/1417352
15:03:54 <openstack> Launchpad bug 1417352 in Manila "Failed to allow-access for native_glusterfs" [Medium,In progress] - Assigned to Csaba Henk (chenk)
15:03:56 <bswartz> https://review.openstack.org/#/c/171302/
15:04:10 <bswartz> this one had some serious issues discovered on code review
15:04:18 <bswartz> at least one problem still remains
15:04:33 <csaba> bswartz: yes I see my bad left in there by mistake
15:04:49 <csaba> (probably forgot to save the edited file)
15:04:56 <csaba> I'll correct in a minute
15:05:20 <bswartz> unit tests should have caught the issues before it got to code review -- so a reminder to everyone: cover your exception code paths with unit tests!
15:05:39 <bswartz> and of course, run the unit tests before pushing upstream
15:05:43 <bswartz> it only takes like 2 minutes
15:06:03 <csaba> bswartz: don't want to nitpick but this one would not be caught by a test :)
15:06:48 <vponomaryov> arguably
15:07:10 <mkoderer> csaba: what kind of test do we need to discover it?
15:07:37 <mkoderer> 3rd party vendor tests?
15:07:44 <csaba> "%(message)" % {"message":"foo"} is syntactically OK... hacking could detect probably
15:07:50 <vponomaryov> csaba: simple substitution verification is enough
15:07:53 <bswartz> the tests need to exercise the exception code path and validate that the correct exception is thrown
15:08:15 <bswartz> it's true that this bug would only result in a bad message getting logged, which typically isn't validated by unit tests
15:08:24 <xyang1> I think you'll have to write test to check the output of every message to detect this one
15:08:31 <csaba> vponomaryov: why is it not done?
15:08:33 <bswartz> I like the idea of a hacking check
15:08:43 <xyang1> I don't think that is covered by anyone
15:09:07 <vponomaryov> csaba: ? why is it not done by your tests?
15:09:11 <mkoderer> adding a hacking rule sound good
15:09:17 <bswartz> anyways, I think that bugfix will be okay -- it's just a case study for why unit tests are valuable
15:09:38 <bswartz> can I go to the next one?
15:09:52 <bswartz> share server can not be deleted if hung in transitional state
15:09:52 <csaba> vponomaryov: AFAIK we don't test message text, it's a job for hacking IMHO, which would work regardless of unit test coverage
15:09:56 <bswartz> https://bugs.launchpad.net/bugs/1434563
15:09:58 <openstack> Launchpad bug 1434563 in Manila "share server can not be deleted if hung in transitional state" [Medium,In progress] - Assigned to Igor Malinovskiy (imalinovskiy)
15:10:02 <bswartz> https://review.openstack.org/#/c/170528/
15:10:32 <bswartz> valeriy have you read u_glide's responses?
15:10:35 <xyang1> I agree that this should be a hacking check, no one has unit test for every message
15:10:52 <bswartz> this one seems almost ready
15:10:55 <vponomaryov> bswartz: not yet
15:10:58 <bswartz> okay
15:11:05 <bswartz> I think it's just waiting on you
15:11:11 <bswartz> no need to discuss here
15:11:15 <vponomaryov> ok
15:11:16 <u_glide1> ok
15:11:18 <bswartz> NetApp cDOT driver is too strict in delete workflows
15:11:22 <bswartz> https://bugs.launchpad.net/bugs/1438893
15:11:23 <openstack> Launchpad bug 1438893 in Manila "NetApp cDOT driver is too strict in delete workflows" [Medium,In progress] - Assigned to Clinton Knight (clintonk)
15:11:25 <bswartz> https://review.openstack.org/#/c/171789/
15:11:31 <bswartz> this one was recently pushed up
15:11:53 <bswartz> reviewers please take a look at it
15:12:00 <cknight> I have a couple questions from Valeriy that I just started looking at.  Further reviews are welcome.  More details are in the Launchpad bug.
15:12:30 <bswartz> Response 404 NotFound for listing share types request
15:12:33 <bswartz> https://bugs.launchpad.net/bugs/1441602
15:12:34 <openstack> Launchpad bug 1441602 in Manila "Response 404 NotFound for listing share types request" [Medium,In progress] - Assigned to Valeriy Ponomaryov (vponomaryov)
15:12:46 <bswartz> so I'd like to talk about this one
15:12:58 <bswartz> there is an issue which cases tempest to fail transiently
15:13:04 <vponomaryov> I reproduced it on lab and found out that it not only returns bad response but also hurts DB records
15:13:09 <bswartz> we've needed to do too many rechecks in the last week or 2
15:13:30 <bswartz> vponomaryov is investigating and trying to fix
15:13:36 <bswartz> if anyone wants to help, that would be very welcome
15:13:52 <vponomaryov> so, even if we do not fit Kilo with it, it will be backport fix definitely
15:14:14 <vponomaryov> because it leads to data loss
15:14:19 <cknight> vponomaryov: we should hold RC1 for a DB corruption issue
15:14:20 <bswartz> vponomaryov recently pushed 4 identical patchsets to try and test a fix with a large number of job runs -- in case anyone wondered about those
15:14:55 <bswartz> yes I think this is an RC blocker, so I'd like to ask everyone who can to help out
15:15:02 <vponomaryov> DB affected with deletion of all private share types
15:15:36 <bswartz> vponomaryov: do you know for sure which commit introduced the issue?
15:15:38 <vponomaryov> when concurrent requests for type-list and list of some type access projects are performed in parallel
15:15:58 <tbarron> xyang1: +1 -- indeed, in Cinder we've had pushback on reviews where we did asserts matching message content (on the grounds the test becomes too fragile)
15:15:59 <vponomaryov> bswartz: appearance of share type access functionality
15:16:07 <vponomaryov> bswartz: I believe Cinder has this bug too
15:16:15 <vponomaryov> bswartz: it is not tested there at all
15:16:25 <vponomaryov> bswartz: by tempest, as we had for some time
15:16:36 <vponomaryov> bswartz: before addon of tests
15:16:40 <bswartz> okay so it's not a problem caused by the new tests -- the problem already existed and the new tests just revealed it?
15:17:16 <vponomaryov> yes
15:17:20 <xyang1> tbarron: I got questions on one patch because I added a unit test for a message:).  But usually I try to unit test message for exceptions
15:17:22 <bswartz> If we're sure of that then we have to hold up the RC
15:18:02 <vponomaryov> bswartz: would be great to have it till monday
15:18:10 <vponomaryov> "hold up"
15:18:25 <bswartz> for a data corruption bug we'll hold the RC as long as we need to
15:18:45 <bswartz> the risk is that the later the RC is cut, the less testing we can expect before the actual release
15:18:57 <xyang1> bswartz: how long can we hold it up?
15:18:58 <bswartz> because there are always some who don't start testing until there is an RC
15:19:25 <bswartz> xyang1: technically, April 30
15:19:43 <xyang1> bswartz: ok, GA date
15:19:43 <bswartz> however that would be terrible
15:20:05 <xyang1> bswartz, right, we want to cut it early so that people will do more testing
15:20:05 <bswartz> from my perspective the sooner we get RC1 the better
15:20:52 <bswartz> okay we don't need to hash this one out any more
15:20:59 <bswartz> #topic XML API removal
15:21:02 <vponomaryov> bswartz: here is DB error that leads to data loss - #link http://paste.openstack.org/show/201360/
15:21:43 <toabctl> vponomaryov: would be nice to collect theses infos in the bug report
15:22:16 <bswartz> yeah, let's compile as much as we can in the LP bug, so if others want to help they can come up to speed on what's been discovered so far
15:22:28 <bswartz> Remove Limited XML API Support from Manila
15:22:33 <bswartz> https://bugs.launchpad.net/bugs/1440782
15:22:34 <openstack> Launchpad bug 1440782 in Manila "Remove Limited XML API Support from Manila" [Low,In progress] - Assigned to Igor Malinovskiy (imalinovskiy)
15:22:36 <bswartz> https://review.openstack.org/#/c/170904/
15:22:58 <bswartz> so many of you know that XML hasn't worked in the REST API for a very long time
15:23:11 <bswartz> we've wanted to remove it, but we never got around to it until recently
15:23:28 <bswartz> I think u_glide's patch is pretty low risk, and it's better to get it in Kilo rather than Liberty
15:23:42 <bswartz> but I wanted to ask the rest of you if you have any concerns about a change like this
15:24:38 <vponomaryov> +1 for removal in Kilo
15:24:49 <toabctl> +1 from my side as well
15:24:50 <bswartz> u_glide: are you addressing the few reamining issue with this to make it mergeable?
15:24:55 <cknight> bswartz: I'm OK with it.  It's a sizable change, but given our test coverage, I think the risk is low.
15:25:05 <xyang1> bswartz: I've added my comments in the patch that this seems to be a very big change at this stage, but if most people are okay, I'm fine
15:25:16 <bswartz> okay
15:25:23 <mkoderer> There wasn't any tempest tests for xml?... +1 for removal
15:25:29 <lpabon> i think since rc1 has not been released yet, it would be ok.
15:25:29 <u_glide1> bswartz: yes, I will upload new patch in next 15 minutes
15:25:38 <bswartz> okay this seems clear then
15:25:41 <vponomaryov> mkoderer: they were, long-long time ago
15:25:47 <bswartz> we'll keep it in
15:25:47 <vponomaryov> mkoderer: in far-far galaxy =)
15:25:53 <mkoderer> vponomaryov: :)
15:26:06 <xyang1> u_glide1 will fix any bugs if this patch resulted in any:)
15:26:07 <bswartz> but keep reviewing to make sure it's good before merging
15:26:14 <bswartz> +1
15:26:21 <bswartz> lol
15:26:55 <bswartz> okay that's it for Kilo-related stuff
15:27:33 <bswartz> I think we'll be okay with everything except for https://bugs.launchpad.net/bugs/1441602
15:27:34 <openstack> Launchpad bug 1441602 in Manila "Response 404 NotFound for listing share types request" [Medium,In progress] - Assigned to Valeriy Ponomaryov (vponomaryov)
15:27:57 <bswartz> so vponomaryov please share information as you learn it and don't hesitate to ask for help if you need it
15:28:33 <bswartz> on to liberty stuff
15:28:39 <bswartz> #topic Specs repo
15:29:01 <bswartz> so many other openstack projects have been experimenting with specs repos for the last 2 releases
15:29:29 <bswartz> I think that people generally like them, but they are not without problems
15:29:52 <bswartz> It's because of the problems that I've held off on introducing them for Manila
15:30:04 <bswartz> but more people have been asking so I'd like to open up the discussion
15:30:50 <bswartz> the main value of specs repos is that they create a formalized way to give feedback on design proposals, and they create a template to follow that forces people to consider things they might otherwise ignore when proposing a new feature
15:30:50 <mkoderer> bswartz: I personally like to have more details for a feature
15:31:20 <mkoderer> so the manila bp that I saw wasn't giving me all the information I would need
15:31:28 <mkoderer> have specs reviews would solve that
15:31:37 <bswartz> also they create a formal record of what designs were approved, and a process for those approvals
15:31:48 <markstur_> it would be good to have it for when we need it for big features but most patches wouldn't use it
15:31:52 <bswartz> I have 2 concerns
15:32:02 <xyang1> bswartz: I think it is good for Manila to use the same process that other projects are using
15:32:08 <csaba> bswartz: would this supersede lp bps or would these be used together?
15:32:32 <mkoderer> csaba: lp bps and specs are usually used together
15:32:37 <mkoderer> but it's not a must
15:32:50 <bswartz> the first is that a spec only allows you to discuss a feature at the hypothetical level -- it's common for unexpected issues to come up during implementation that may require changes to the design
15:33:02 <xyang1> csaba: you have a have a bp for a new feature, but spec is not required for every bp item
15:33:18 <bswartz> and also some people have a hard time reading a spec and understanding what it means -- whereas a code submission is unambiguous -- you can download and run it
15:33:23 <xyang1> csaba: so you can't have a spec without a bp
15:33:40 <csaba> mkoderer, xyang1: thanks
15:34:02 <mkoderer> bswartz: reading a spec is much easier for ops people for instance
15:34:15 <cknight> mkoderer: +1
15:34:21 <bswartz> the other issue with specs is that they get out of date quickly -- it's common for other teams to approve specs, and then implement something different from the spec, and to never go back and fix the spec to match the implementation
15:34:32 <mkoderer> bswartz: so yes.. code is easier to read for developers.. but if you want to get feedback from "customers" specs are really helpful
15:34:43 <markstur_> other concern is that often design specs are not read and the design gets clobbered later anyway
15:34:56 <markstur_> So it is a tool to get agreement on design, but a faulty one.
15:35:12 <markstur_> Still worthwhile for big feature collab
15:35:30 <bswartz> so IF we do decide as a team to start using a spec repo, we will need to create a policy on when/if approved specs should be updated to match the implementation
15:35:39 <toabctl> mkoderer: that's true if the specs are up-to-date. if the information is wrong, it's sometimes even worse than no information.
15:36:15 <mkoderer> toabctl: yeah.. I agree.. outdated specs are an issue..
15:36:48 <xyang1> Yes, spec should be updated after the code is merged
15:36:53 <bswartz> there is a related problem for people trying to use a specs repo as a source-of-truth which is that specs are a bunch of standalone documents, which can be hard to read and understand as a whole
15:37:11 <vponomaryov> toabctl: +1
15:37:19 <bswartz> I would argue that a well written architecture guide would be more valuable to and end user than a bunch of specs
15:37:33 <bswartz> or a deployer
15:37:39 <toabctl> bswartz: +1
15:37:47 <u_glide1> bswartz: +1
15:37:57 <markstur_> specs are better used to agree on a design for future work than as doc for existing work
15:38:07 <bswartz> so we have to understand what problem we're trying to solve by introducing specs
15:38:08 <mkoderer> bswartz: but the guide will be written after implementation?
15:38:27 <bswartz> mkoderer: unfortunately that's the only choice
15:38:32 <lpabon> chicken egg problem
15:38:50 <bswartz> it would be weird to edit the architecture document before there is working code
15:39:30 <toabctl> ideally there's a spec to discuss, then an implementation and then (or in parallel) documentation which should make the spec for OPS obsolete
15:39:31 <lpabon> it depends how much content is necessary to understand what the new feature/bp is going to do
15:40:08 <xyang1> bswartz: there's a risk that we will be stuck in spec:)
15:40:14 <lpabon> i have found one of the best times to propose new features is at a design summit or a hackathon, for a Q&A session
15:40:14 <markstur_> toabctl, +1
15:40:15 <toabctl> :)
15:40:53 <mkoderer> toabctl: +1
15:41:11 <bswartz> my feeling is that if we do specs, we either have to keep them up to date forever, or there has to be an understand that their immediately obsolete when they're agreed to, in which case we'd need to diligent about updating the architecture guide after a feature merges
15:41:24 <mkoderer> so if we link a spec to the documentation later on everyhing shouel be fine
15:41:30 <bswartz> understanding(
15:41:43 <markstur_> up-to-date-forever: -1
15:42:02 <xyang1> bswartz: we should allow code to be submitted and reviewed before a spec is approved, otherwise, we could be stuck:)
15:42:02 <toabctl> mkoderer: +1
15:42:17 <bswartz> specs are still good for hashing out ideas in a international-multi-timezone community like we have
15:42:31 <markstur_> xyang1, +1  If reviewers don't need a spec.  Great.
15:42:45 <bswartz> xyang1: oh I'm not in favor of blocking implementation until the spec is agreed to at all
15:42:47 <lpabon> +1 for luis ;-)
15:43:00 <bswartz> I love the idea of spec and code in parallel
15:43:01 <mkoderer> xyang1: so other teams do not accept code without a spec
15:43:18 <markstur_> Sometimes a feature deserves a spec rat hole because it is controversial.
15:43:19 <mkoderer> xyang1: but for me this is too much
15:44:09 <mkoderer> so do we agree that specs are helpful? :)
15:44:17 <bswartz> developers just have to understand that they're risking wasting their time implementing something before the spec is agreed to because the spec could get -2'd or the significantly changed after discussion
15:44:41 <mkoderer> bswartz: I mean that a usual risk for every commit
15:44:48 <bswartz> but I think it's extremely valuable to propose a new feature and have a working prototype to demonstrate the idea
15:44:48 <cknight> bswartz: +1, but if a spec is needed for a new feature, the final code shouldn't merge if it doesn't match the spec.
15:45:10 <xyang1> cknight: that will not work:)
15:45:17 <xyang1> cknight: it is the other way around
15:45:28 <xyang1> your spec has to match your final code
15:45:51 <vponomaryov> do we really have issue that will be fixed with appearance of specs repo?
15:45:51 <bswartz> yeah I agree with xyang1: the code review is the decider of how the feature turns out
15:45:52 <xyang1> I've found out from my own experience there is no way to completely match an approved spec
15:45:52 <lpabon> test -- can you guys see this?
15:46:04 <cknight> xyang1: OK, either way.  :-)
15:46:08 <xyang1> people keep come up with new ideas
15:46:11 <markstur_> lpabon, test passed
15:46:16 <lpabon> cook, thanks
15:46:17 <mkoderer> lpabon: yes
15:46:19 <lpabon> cool
15:47:02 <lpabon> my $0.02 is that specs are.... ok.. and most of the time they talk about something that the code never does
15:47:19 <markstur_> So reviewer can -1 to say 'fix your spec' before merge -- but after that expect the spec to age and get obsolete
15:47:19 <lpabon> specially in open source projects
15:47:26 <bswartz> vponomaryov: the issue is that large new features are hard to discuss without some kind of document -- in the last we've used wikis
15:47:31 <bswartz> in the past*
15:47:42 <xyang1> markstur_: I don't think that is efficient
15:47:54 <xyang1> people will come up with new ideas after you fix the spec
15:47:58 <xyang1> it is never ending
15:48:06 <xyang1> we have to allow the code to be merged first
15:48:11 <vponomaryov> big +1 for neverending =)
15:48:14 <xyang1> and update spec as soon as possible
15:48:37 <bswartz> yeah -- I feel strongly that unless we commit to updating the specs forever, people have to accept that they're instantly obsolete and the code becomes the source of truth
15:48:53 <vponomaryov> wiki page has history as well
15:48:54 <lpabon> bswartz, i do not think that is going to work in a community based environment
15:49:10 <mkoderer> vponomaryov: a wiki page does not have a "review" process
15:49:44 <bswartz> wikis actually do have a "discussion" function but I don't think it works too well
15:49:49 <lpabon> a spec should be enough of the architecture to understand how to read the code (commented code that is)
15:50:15 <xyang1> I don't think wiki is good, it is too easy for anyone to make changes
15:50:34 <cknight> bswartz: +1.  If the code can merge first, there is much less incentive to update the spec later.  Of course the spec becomes obsolete, but if there was never a point in time the spec matched the code, the spec has little value after the initial discussion.
15:50:36 <vponomaryov> xyang1: do not truct people ? =)
15:50:46 <vponomaryov> s/truct/trust/
15:51:06 <cknight> vponomaryov: trust but verify :-)
15:51:13 <bswartz> cknight: I think the value is mostly that initial discussion -- after that happens the spec loses its value rapidly
15:51:14 <mkoderer> vponomaryov: we have code review because we never trust people :)
15:51:18 <xyang1> vponomaryov:  if it is people in this group, that is fine, but it could be modified by anyone in the world:)
15:51:37 <xyang1> vponomaryov: I had some trouble keep correcting one particular wiki:)
15:51:54 <vponomaryov> xyang1: same about gerrit
15:52:02 <vponomaryov> xyang1: anyone can add patch-sets
15:52:08 <xyang1> vponomaryov: there is a review process
15:52:09 <lpabon> bswartz, that is why i think bringing up new features to design summits, irc meetings, or hackathons are the best method... and not necessarily a long spec
15:52:10 <bswartz> I wrote several "specs" about the manila driver modes and network plugins 6 months ago -- they're all very wrong now
15:52:24 <xyang1> at least we can see before it is changed:)
15:52:33 <markstur_> bswartz, go fix'em
15:53:01 <vponomaryov> markstur_: fix them tomorrow, and every day =)
15:53:02 <xyang1> lpabon: problem is things usually change after the design summit:)
15:53:16 <markstur_> Seems like we'll never agree to have perfect specs
15:53:22 <bswartz> markstur_: I should, but it probably makes more sense to write the current truth into an architecture document rather than a bunch of disconnected specs
15:53:28 <lpabon> xyang1, The developer is just bringing up an idea.. which gets discussed with others
15:53:36 <markstur_> I don't see why we cant try them for additional reviewer info
15:54:08 <xyang1> lpabon: right, but it could be a complete re-design, the benefit of spec is it keeps a history
15:54:08 <bswartz> okay well we clearly have a bunch of different opinions on this topic, which is good
15:55:00 <lpabon> xyang1, a complete re-design is a great thing..because it is the community working together, and not a single person (or company) working in a cave then coming out with a spec
15:55:05 <vponomaryov> bswartz next topic?
15:55:24 <markstur_> bswartz, +1 on docs instead of specs for implemented things
15:55:26 <bswartz> well I think we need to figure out how to decide this one
15:55:28 <vponomaryov> lpabon: in a cave - =)
15:55:29 <bswartz> perhaps a vote next week?
15:55:33 <lpabon> vponomaryov, :-)
15:55:38 <mkoderer> bswartz: +1
15:55:45 <cknight> bswartz: +1
15:55:57 <bswartz> it probably deserves an ML post too
15:55:59 <ganso_> bswartz: +1
15:56:00 <bswartz> I'll write that up
15:56:10 <bswartz> in the last few minutes, 1 more topic
15:56:16 <bswartz> #topic Core team members from the same company
15:56:17 <lpabon> anyways, my message is -- make it a community effort by bringing ideas up as early as possible
15:56:42 <bswartz> we now have a core team including 2 mirantis developers, 2 netapp developers, and 1 emc developer
15:57:03 <bswartz> some have raised concerns about the concentration of power in 2 companies
15:57:20 <bswartz> there is a diversity concern too -- but we can solve that by continuing to grow the core team
15:57:21 <xyang1> lpabon: "as early as possible" may not happen:).  ideas will keep coming till GA
15:57:23 <lpabon> (and i worked for two of them in my previous life)
15:58:01 <bswartz> I'd like to propose, that in the interest of fairness, we create a rule that the two +2s before a +A on any patch cannot come from a single company
15:58:11 <vponomaryov> bswartz: contentration of power in two companies because other not active?
15:58:15 <lpabon> +1mil
15:58:20 <cknight> bswartz: +1, I've been adhering to this already.  But I think there should be some leeway for things like emergency gate fixes.
15:58:20 <mkoderer> bswartz: having some more cores from distributors would be quite helpful
15:58:32 <mkoderer> bswartz: at the end someone need to package Manila and give support :)
15:58:46 <bswartz> cknight: that leeway already exists -- any of us and break the rules and +2A anything, but we REALLY avoid that
15:58:56 <markstur_> cknight, +1
15:59:01 <bswartz> in fact I don't think I've needed to use that power in more than 6 months
15:59:05 <cknight> bswartz: ok, thanks
15:59:52 <bswartz> vponomaryov: it's true that developers have to be doing the hard work of doing reviews to be considered for the core team
16:00:04 <xyang1> so I think it is good to have diversity, but we also should not make a hard rule saying no more cores from the 3 companies
16:00:07 <bswartz> and up until recently, the set of people doing that was small
16:00:11 <vponomaryov> bswartz: so it is problem not of these two companies
16:00:21 <vponomaryov> bswartz: that are "active"
16:00:30 <bswartz> but I'm happy to see many new people doing reviews, so we can continue to grow the core team
16:00:55 <bswartz> vponomaryov: the concern is that netapp could propose something nobody likes and shove it thorugh with a +2 from both me and cknight
16:01:04 <bswartz> or mirantis could do the same
16:01:16 <bswartz> the diversity concern is entirely different and we don't have time to get into that today
16:01:40 <bswartz> it's important to me that we strive for diversity and fairness
16:02:00 <xyang1> bswartz: sure.  I think it is good to require another core from a different company to +2 as much as possible
16:02:14 <esker> bswartz: are you looking to implement this measure based on some prior actual problem?  Or the possible future occurrence of such?
16:02:18 <mkwiek> \leave
16:02:18 <bswartz> this rule will be unofficial unfortunately, because I don't think we have an official set of bylaws anywhere
16:02:51 <bswartz> okay we're over our time
16:02:52 <bswartz> thanks all
16:02:56 <bswartz> #endmeeting