Open Stack

2011/4/1 FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp>:
> On Thu, 31 Mar 2011 10:02:34 +0200
> Soren Hansen <soren at openstack.org> wrote:
>> 2011/3/31 FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp>:
>> > Sounds like the importance of blueprints is overrated. If you look at
>> > Linux kernel development (more than ten times developers and
>> > development speed, I guess),
>> The Linux kernel development process uses a number of other approaches
>> to deal with its volume. There a number of different staging trees.
>> There are topic-based ones, like the one for people working on
> 'topic-based' is one of ways to manage a git tree so it's unrelated
> with this top

Um, no. I realise git has a concept of topic branches, but this is not
what I'm referring to at all. David Miller, for instance, maintains
git.kernel.org/.../davem/net-2.6.git which is where all the
interesting networking related stuff goes on. Every once in a while,
this gets merged into Linus' linux-2.6 tree.

> I expect OpenStack will need to do the similar with developers increased. You don't?

Quite probably. When the time comes. Different scales of development
community warrant different approaches.

>> > you see that lots of developers can work well without something like
>> > blueprints.
>> Just so we're clear: Linux has merge windows as well. New features
>> simply do not get to go into mainline outside of these merge windows.
> Yeah, but you can propose new features (patches) any time.

Sure. You can do that in OpenStack, too. People just still expect to
get stuff discussed/reviewed/merged outside of this window. That's
what we're talking about. I don't believe our core development team is
large enough to support splitting our efforts like this. When we're
past feature freeze, we all need to focus on QA'ing what we've got
already. There are plenty of bugs to fix.

>> It's not uncommon for changes to take several kernel releases from being
>> proposed until they're actually accepted into the tree. Also, noone
>> promises that your stuff will get reviewed. Ever. We do. If you propose
>> stuff in time, we promise it will at least be reviewed once before
>> feature freeze.
> Hmm, that 'promise' works (and will work in the future)?

If we want it to, it can. If noone does reviews and just everyone
keeps working on their own snazzy, new features, it won't. That's
really the core of this problem.

> I already saw
> the shortage of reviewing (and I even saw that a half-baked feature
> without enough reviewed was merged and reverted).

Yes! EXACTLY! Because people who ought to be reviewing aren't.

> I bet that we'll face more serious shortage of reviewing with
> developers increasing. In genera, developers prefer to write own code
> rather than reviewing. We can't change the nature.

Then people ought to grow up. Seriously. They should grow up and stop
saying that they're going to review stuff, or they should start
actually reviewing stuff.

> I think that there is no such 'promise' for reviewing in a large
> OSS. If your code can't get enough reviewers, your code might be not
> useful enough for the project. It's sorta evolutionary theory. The
> better code has the better chance to be merged quickly. The features
> are prioritized fairly.

I think we have quite different definitions of "fair".

We're on a mission: "to produce the ubiquitous Open Source Cloud
Computing platform that will meet the needs of public and private
clouds regardless of size, by being simple to implement and massively
scalable."

We can't pretend to meet everyone's needs if we only accept patches
that are fun to review or that we wrote ourselves.

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/