<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<div>On Oct 16, 2013, at 13:19 , Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Sean Dague wrote:<br>
<blockquote type="cite">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/">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>
</blockquote>
<br>
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>Younger projects at the bottom of the pyramid, especially kernel modules that we could consider equivant to drivers, IMO cannot be based on such a long trust relationship due to their age.</div>
<div>As an example, well, the Hyper-V linux kernel LIS modules fit pretty well :-)</div>
<br>
<blockquote type="cite">You don't really want to develop the hyper-V driver in a private<br>
subsystem branch all cycle, then at the very end have it rejected from<br>
release by an empowered Russell or Thierry just because we think it's<br>
not tested enough or we don't like the color it's been painted. This is<br>
how the Linux kernel model works with untrusted subsystems -- by<br>
subjecting your work to a final BDFL right to kill it at release time.<br>
<br>
The other two alternatives are to accept the delays and work within Nova<br>
(slowly building the trust that will give you more autonomy), or ship it<br>
as a separate add-on that does not come with nova-core's signature on it.<br>
<br>
</blockquote>
<div><br>
</div>
<div>I never asked for a nova signature on it. My only requirerement is that the project would be part of OpenStack and not an external project, even if this means passing 2 releases in incubation on stackforge as long as it can become part of the OpenStack
core group of projects afterwards (if it meets the required OpenStack criteria of course). <a href="https://wiki.openstack.org/wiki/Governance/NewProjects">https://wiki.openstack.org/wiki/Governance/NewProjects</a></div>
<br>
<blockquote type="cite">-- <br>
Thierry Carrez (ttx)<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</body>
</html>