On Jun 4, 2018, at 2:10 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
>> Those rules were added because we wanted to avoid the appearance of one 
>> company implementing features that would only be beneficial to it. This 
>> arose from concerns in the early days when Rackspace was the dominant 
>> contributor: many of the other companies involved in OpenStack were worried 
>> that they would be investing their workers in a project that would only 
>> benefit Rackspace. As far as I know, there were never specific cases where 
>> Rackspace or any other company tried to push features in that no one else 
>> supported..
>> 
>> So even if now it doesn't seem that there is a problem, and we could remove 
>> these restrictions without ill effect, it just seems prudent to keep them. 
>> If a project is so small that the majority of its contributors/cores are 
>> from one company, maybe it should be an internal project for that company, 
>> and not a community project.
>> 
>> -- Ed Leafe
> 
> Where was the rule added, though? I am aware of some individual teams
> with the rule, but AFAIK it was never a global rule. It's certainly not
> in any of the projects for which I am currently a core reviewer.

If you're looking for a reference to a particular bit of governance, I can't 
help you there. But being one of the Nova cores who worked for Rackspace back 
then, I was part of many such discussions, and can tell you that Rackspace was 
very conscious of not wanting to appear to be dictating the direction, and that 
this agreement not to approve code committed by other Rackers was an important 
part of that.


-- Ed Leafe





Attachment: signature.asc
Description: Message signed with OpenPGP

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to