Open Stack

Octavia also has an informal rule about two cores from the same
company merging patches. I support this because it makes sure we have
a diverse perspective on the patches. Specifically it has worked well
for us as all of the cores have different cloud designs, so it catches
anything that would limit/conflict with the different OpenStack
topologies.

That said, we don't hard enforce this or police it, it is just an
informal policy to make sure we get input from the wider team.
Currently we only have one company with two cores.

That said, my issue with the current diversity calculations is they
tend to be skewed by the PTL role. People have a tendency to defer to
the PTL to review/comment/merge patches, so if the PTL shares a
company with another core the diversity numbers get skewed heavily
towards that company.

Michael

On Wed, Jun 6, 2018 at 5:06 AM,  <amrith.kumar at gmail.com> wrote:
>> -----Original Message-----
>> From: Doug Hellmann <doug at doughellmann.com>
>> Sent: Monday, June 4, 2018 5:52 PM
>> To: openstack-dev <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
>>
>> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:
>> > On 02/06/18 13:23, Doug Hellmann wrote:
>> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400:
>> > >> On 01/06/18 12:18, Doug Hellmann wrote:
>> > >
>> > > [snip]
>> > Apparently enough people see it the way you described that this is
>> > probably not something we want to actively spread to other projects at
>> > the moment.
>>
>> I am still curious to know which teams have the policy. If it is more
>> widespread than I realized, maybe it's reasonable to extend it and use it as
>> the basis for a health check after all.
>>
>
> A while back, Trove had this policy. When Rackspace, HP, and Tesora had core reviewers, (at various times, eBay, IBM and Red Hat also had cores), the agreement was that multiple cores from any one company would not merge a change unless it was an emergency. It was not formally written down (to my knowledge).
>
> It worked well, and ensured that the operators didn't get surprised by some unexpected thing that took down their service.
>
> -amrith
>
>
> __________________________________________________________________________
> 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