<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 April 2015 at 03:07, Ian Wienand <span dir="ltr"><<a href="mailto:iwienand@redhat.com" target="_blank">iwienand@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
IMO requiring two cores to approve *every* change is too much.  What<br>
we should do is move the responsibility downwards.  Currently, as a<br>
contributor I am only 1/3 responsible for my change making it through.<br>
I write it, test it, clean it up and contribute it; then require the<br>
extra 2/3 to come from the "hierarchy".  If you only need one core,<br>
then core and myself share the responsibility for the change.  In my<br>
mind, this better recognises the skill of the contributor -- we are<br>
essentially saying "we trust you".<br></blockquote><div><br></div><div><br></div><div>I frankly disagree. There are a number of fixes that have come in that look good, particularly to somebody not intimately familiar with a particular area of code, that turn out to have all sorts of nasty side effects that were only spotted by the second (or in some cases third, forth) core to come along.</div><div><br></div><div>If you compare the velocity of openstack to many opensource projects, it is *huge*. We really are making very rapid progress, in so many areas, every single cycle. I'm starting to worry that we are pushing velocity above vision, code quality, and many other things. I think we want to reduce the expectation that your feature (or even contentious bug fix) is likely to get merged in days - the project is sufficiently big that that is in fact unlikely. </div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div></div>