[openstack-dev] [kolla] discussion about core reviewer limitations by company
Joshua Harlow
harlowja at fastmail.com
Mon Feb 22 04:02:41 UTC 2016
Gary Kotton wrote:
> I think that IBM has a very interesting policy in that two IBM cores
> should not approve a patch posted by one of their colleagues (that is
> what Chris RIP used to tell me). It would be nice if the community would
> follow this policy.
> Thanks
> Gary
Sounds similar to a representative government vs. a democratic one. I'm
not sure though if it's needed or applicable (the aspiration of it
sounds nice, but meh), as long as people are good and use their heads
and we believe that people will do the right thing (and handle the cases
where this is violated in a polite and considerate manner) then meh,
more power to everyone...
My 2 cents
>
> From: "Armando M." <armamig at gmail.com <mailto:armamig at gmail.com>>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Sunday, February 21, 2016 at 6:40 PM
> To: OpenStack List <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer
> limitations by company
>
>
>
> On 20 February 2016 at 14:06, Kevin Benton <kevin at benton.pub
> <mailto:kevin at benton.pub>> wrote:
>
> I don't think neutron has a limit. There are 4 from redhat and 3
> from hp and mirantis right now.
> https://review.openstack.org/#/admin/groups/38,members
>
>
> By the way, technically speaking some of those also only limit
> themselves the right to merge to their area of expertise.
>
> On Feb 20, 2016 13:02, "Steven Dake (stdake)" <stdake at cisco.com
> <mailto:stdake at cisco.com>> wrote:
>
> Neutron, the largest project in OpenStack by active committers
> and reviewers as measured by the governance repository teamstats
> tool, has a limit of 2 core reviewers per company. They do that
> for a reason. I expect Kolla will grow over time (we are about
> 1/4 their size in terms of contributors and reviewers). I
> believe other projects follow a similar pattern besides Neutron
> that already have good diversity (and intend to keep it in place).
>
> Regards
> -steve
>
>
> From: Gal Sagie <gal.sagie at gmail.com <mailto:gal.sagie at gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Saturday, February 20, 2016 at 10:38 AM
> To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla] discussion about core
> reviewer limitations by company
>
> I think setting these limits is wrong, some companies have
> more overall representation then others.
> The core reviewer job should be on a personal basis and not
> on a company basis, i think the PTL of each project needs
> to make sure the diversity and the community voice is heard
> in each project and the correct path is taken even if
> many (or even if all) of the cores are from the same company.
> If you really want to set limits then i would go with
> something like 2 cores from the same company cannot +2 the
> same patch, but
> again i am against such things personally..
>
> Disclaimer: i am not personally involved in Kolla or know
> how things are running there.
>
> On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake)
> <stdake at cisco.com <mailto:stdake at cisco.com>> wrote:
>
> Hey folks,
>
> Mirantis has been developing a big footprint in the core
> review team, and Red Hat already has a big footprint in
> the core review team. These are all good things, but I
> want to avoid in the future a situation in which one
> company has a majority of core reviewers. Since core
> reviewers set policy for the project, the project could
> be harmed if one company has such a majority. This is
> one reason why project diversity is so important and has
> its own special snowflake tag in the governance repository.
>
> I'd like your thoughts on how to best handle this
> situation, before I trigger a vote we can all agree on.
>
> I was thinking of something simple like:
> "1 company may not have more then 33% of core reviewers.
> At the conclusion of PTL elections, the current cycle's
> 6 months of reviews completed will be used as a metric
> to select the core reviewers from that particular
> company if the core review team has shrunk as a result
> of removal of core reviewers during the cycle."
>
> Thoughts, comments, questions, concerns, etc?
>
> Regards,
> -steve
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Best Regards ,
>
> The G.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list