Alessandro, please fix your email program so that it does not send HTML email to the list, and correctly quotes text you are replying to with '> '. Your reply comes out looking like this which makes it impossible to see who wrote what:
On Wed, Oct 16, 2013 at 10:42:45AM +0000, Alessandro Pilotti wrote: > > On Oct 16, 2013, at 13:19 , Thierry Carrez > <thie...@openstack.org<mailto:thie...@openstack.org>> > wrote: > > Sean Dague wrote: > The Linux kernel process works for a couple of reasons... > > 1) the subsystem maintainers have known each other for a solid decade > (i.e. 3x the lifespan of the OpenStack project), over a history of 10 > years, of people doing the right things, you build trust in their judgment. > > *no one* in the Linux tree was given trust first, under the hope that it > would work out. They had to earn it, hard, by doing community work, and > not just playing in their corner of the world. > > 2) This > http://www.wired.com/wiredenterprise/2012/06/torvalds-nvidia-linux/ is > completely acceptable behavior. So when someone has bad code, they are > flamed to within an inch of their life, repeatedly, until they never > ever do that again. This is actually a time saving measure in code > review. It's a lot faster to just call people idiots then to help them > with line by line improvements in their code, 10, 20, 30, or 40 > iterations in gerrit. > > We, as a community have decided, I think rightly, that #2 really isn't > in our culture. But you can't start cherry picking parts of the Linux > kernel community without considering how all the parts work together. > The good and the bad are part of why the whole system works. > > This is an extremely important point in that discussion. > > The Linux kernel model is built on a pyramidal model where Linus, in a > PTL+Release Manager role, has the final ability to refuse whole sections > of the code just because he doesn't like it. > > Over two decades, Linus built a solid trust relationship with most > subsystem maintainers, so that he doesn't have to review every single > patch for sanity. In those areas he has a set of people who consistently > proved they would apply the same standards as he does. But for other > less-trusted areas the pyramidal model is still working. > > I don't see how we could apply that to OpenStack as the trust > relationships are far from being that advanced (think: not old enough), > and I don't think we want to replicate the personified, pyramidal merge > model to handle the less-trusted relationships in the mean time. > > > 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. > As an example, well, the Hyper-V linux kernel LIS modules fit pretty well :-) > > You don't really want to develop the hyper-V driver in a private > subsystem branch all cycle, then at the very end have it rejected from > release by an empowered Russell or Thierry just because we think it's > not tested enough or we don't like the color it's been painted. This is > how the Linux kernel model works with untrusted subsystems -- by > subjecting your work to a final BDFL right to kill it at release time. > > The other two alternatives are to accept the delays and work within Nova > (slowly building the trust that will give you more autonomy), or ship it > as a separate add-on that does not come with nova-core's signature on it. > > > 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). > https://wiki.openstack.org/wiki/Governance/NewProjects > > -- > Thierry Carrez (ttx) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev