Open Stack

Sorry guys about this, my OS X Mail client had no issues
in doing the proper indentation, so I never noticed it. Darn. 

I made a test with Daniel with a private email before spamming 
here for nothing. Hope it worked out here as well.

Thanks for the heads up.


On Oct 16, 2013, at 13:47 , "Daniel P. Berrange" <berrange at redhat.com>
 wrote:

> 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 :|
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev