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" <[email protected]> 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 >> <[email protected]<mailto:[email protected]>> >> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
