<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 20, 2016 at 8:27 PM, Michał Jastrzębski <span dir="ltr"><<a href="mailto:inc007@gmail.com" target="_blank">inc007@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I don't think kolla will need limit of cores per company, we are<br>
diverse and our diversity grows if anything. Mirantis did make a lot<br>
of commitment this release, and that's great, but that won't change<br>
our diversity really. Let's deal with this case-by-case, I'd hate to<br>
disqualify someone for core status because their company name.<br>
<div class=""><div class="h5"><br>
On 20 February 2016 at 16:06, Kevin Benton <kevin@benton.pub> wrote:<br>
> I don't think neutron has a limit. There are 4 from redhat and 3 from hp and<br>
> mirantis right now. <a href="https://review.openstack.org/#/admin/groups/38,members" rel="noreferrer" target="_blank">https://review.openstack.org/#/admin/groups/38,members</a><br>
><br>
> On Feb 20, 2016 13:02, "Steven Dake (stdake)" <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote:<br>
>><br>
>> Neutron, the largest project in OpenStack by active committers and<br>
>> reviewers as measured by the governance repository teamstats tool, has a<br>
>> limit of 2 core reviewers per company. They do that for a reason. I expect<br>
>> Kolla will grow over time (we are about 1/4 their size in terms of<br>
>> contributors and reviewers). I believe other projects follow a similar<br>
>> pattern besides Neutron that already have good diversity (and intend to keep<br>
>> it in place).<br>
>><br>
>> Regards<br>
>> -steve<br>
>><br>
>><br>
>> From: Gal Sagie <<a href="mailto:gal.sagie@gmail.com">gal.sagie@gmail.com</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Date: Saturday, February 20, 2016 at 10:38 AM<br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer<br>
>> limitations by company<br>
>><br>
>> I think setting these limits is wrong, some companies have more overall<br>
>> representation then others.<br>
>> The core reviewer job should be on a personal basis and not on a company<br>
>> basis, i think the PTL of each project needs<br>
>> to make sure the diversity and the community voice is heard in each<br>
>> project and the correct path is taken even if<br>
>> many (or even if all) of the cores are from the same company.<br>
>> If you really want to set limits then i would go with something like 2<br>
>> cores from the same company cannot +2 the same patch, but<br>
>> again i am against such things personally..<br>
>><br>
>> Disclaimer: i am not personally involved in Kolla or know how things are<br>
>> running there.<br>
>><br>
>> On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hey folks,<br>
>>><br>
>>> Mirantis has been developing a big footprint in the core review team, and<br>
>>> Red Hat already has a big footprint in the core review team. These are all<br>
>>> good things, but I want to avoid in the future a situation in which one<br>
>>> company has a majority of core reviewers. Since core reviewers set policy<br>
>>> for the project, the project could be harmed if one company has such a<br>
>>> majority. This is one reason why project diversity is so important and has<br>
>>> its own special snowflake tag in the governance repository.<br>
>>><br>
>>> I'd like your thoughts on how to best handle this situation, before I<br>
>>> trigger a vote we can all agree on.<br>
>>><br>
>>> I was thinking of something simple like:<br>
>>> "1 company may not have more then 33% of core reviewers. At the<br>
>>> conclusion of PTL elections, the current cycle's 6 months of reviews<br>
>>> completed will be used as a metric to select the core reviewers from that<br>
>>> particular company if the core review team has shrunk as a result of removal<br>
>>> of core reviewers during the cycle."<br>
>>><br>
>>> Thoughts, comments, questions, concerns, etc?<br>
>>><br>
>>> Regards,<br>
>>> -steve<br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Best Regards ,<br>
>><br>
>> The G.<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">This comes back to a thread I started [1] earlier. The general rule has been that we should not allow a patch proposed, reviewed, and approved by all one company. In general, I am of the opinion that trust (especially in openstack) should be given until there is a reason not to. Patches can be reverted, cores can be removed, and PTLs can end up not elected the next cycle if the project has issues relating to cores misbehaving. In the worst cases the TC could step in. </div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't think you should limit who can be core unless there is a proven track record justifying the issues. Which case, I'd look into proper corrective behaviors for the bad actors, without adding limits unless really needed. </div><div class="gmail_extra"><br></div><div class="gmail_extra">In short, trust the cores and PTLs until you have a solid reason not to. Trust builds the community better than distrust. Pre-emptive limits may discourage contribution more than encourage "healthy" contribution.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/080238.html">http://lists.openstack.org/pipermail/openstack-dev/2015-November/080238.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">--Morgan</div></div>