Open Stack

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)

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/a9f887ba/attachment.html>