Open Stack

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 <thierry at openstack.org<mailto:thierry at 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 :|