<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 16, 2013 at 8:49 PM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Sean Dague wrote:<br>
> The Linux kernel process works for a couple of reasons...<br>
><br>
> 1) the subsystem maintainers have known each other for a solid decade<br>
> (i.e. 3x the lifespan of the OpenStack project), over a history of 10<br>
> years, of people doing the right things, you build trust in their judgment.<br>
><br>
> *no one* in the Linux tree was given trust first, under the hope that it<br>
> would work out. They had to earn it, hard, by doing community work, and<br>
> not just playing in their corner of the world.<br>
><br>
> 2) This<br>
> <a href="http://www.wired.com/wiredenterprise/2012/06/torvalds-nvidia-linux/" target="_blank">http://www.wired.com/wiredenterprise/2012/06/torvalds-nvidia-linux/</a> is<br>
> completely acceptable behavior. So when someone has bad code, they are<br>
> flamed to within an inch of their life, repeatedly, until they never<br>
> ever do that again. This is actually a time saving measure in code<br>
> review. It's a lot faster to just call people idiots then to help them<br>
> with line by line improvements in their code, 10, 20, 30, or 40<br>
> iterations in gerrit.<br>
><br>
> We, as a community have decided, I think rightly, that #2 really isn't<br>
> in our culture. But you can't start cherry picking parts of the Linux<br>
> kernel community without considering how all the parts work together.<br>
> The good and the bad are part of why the whole system works.<br>
<br>
</div>This is an extremely important point in that discussion.<br>
<br>
The Linux kernel model is built on a pyramidal model where Linus, in a<br>
PTL+Release Manager role, has the final ability to refuse whole sections<br>
of the code just because he doesn't like it.<br>
<br>
Over two decades, Linus built a solid trust relationship with most<br>
subsystem maintainers, so that he doesn't have to review every single<br>
patch for sanity. In those areas he has a set of people who consistently<br>
proved they would apply the same standards as he does. But for other<br>
less-trusted areas the pyramidal model is still working.<br>
<br>
I don't see how we could apply that to OpenStack as the trust<br>
relationships are far from being that advanced (think: not old enough),<br>
and I don't think we want to replicate the personified, pyramidal merge<br>
model to handle the less-trusted relationships in the mean time.<br>
<br></blockquote><div><br></div><div>The other thing to note is that it isn't all sunshine and roses in linux kernel development either. IMO the bar for trusted subsystem maintainers is much much higher in linux kernel development than for core reviewer status for openstack projects. Also patches can take a long time to get review attention on linux-kernel with long gaps between feedback depending on how busy the maintainer is. With gerrit I think we're actually very good at keeping track of patches and they are much less likely to get completely lost. We certainly have much better stats on how responsive we are to proposed patches.<br>
<br></div><div>Chris<br></div></div></div></div>