[openstack-dev] The Evolution of core developer to maintainer?

Chris Friesen chris.friesen at windriver.com
Thu Apr 2 06:42:39 UTC 2015

On 04/01/2015 06:07 PM, Ian Wienand wrote:
> On 04/02/2015 09:02 AM, Jeremy Stanley wrote:
>> but since parties who don't understand our mostly non-hierarchical
>> community can see those sets of access controls, they cling to them
>> as a sign of importance and hierarchy of the people listed within.

> Once code is submitted, there *is* a hierarchy.  The only way
> something gets merged in OpenStack is by Brownian motion of this
> hierarchy.  These special "cores" float around and as a contributor
> you just hope that two of them meet up and decide your change is
> ready.  You have zero insight into when this might happen, if at all.
> The efficiency is appalling but somehow we get there in the end.

This agrees with my experience as a new OpenStack contributor.  The process 
seemed very opaque, there was very little in the way of timely feedback, and it 
was frustrating not knowing if something was going to be reviewed in a day or a 
month (or two).  A year later I'm starting to see the relationships but it's 
still not as clear as it could be.

> IMO requiring two cores to approve *every* change is too much.  What
> we should do is move the responsibility downwards.  Currently, as a
> contributor I am only 1/3 responsible for my change making it through.
> I write it, test it, clean it up and contribute it; then require the
> extra 2/3 to come from the "hierarchy".  If you only need one core,
> then core and myself share the responsibility for the change.  In my
> mind, this better recognises the skill of the contributor -- we are
> essentially saying "we trust you".

Interesting idea.

Makes me wonder about the history...where did the "two cores to approve" model 
come from originally?  Were there bad experiences previously with just one 
approver, or did it start out with two approvers?


More information about the OpenStack-dev mailing list