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?
Chris
__________________________________________________________________________
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
