Open Stack

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.

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.

-- 
Thierry Carrez (ttx)