Open Stack

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 but as you said, the patch acceptance load is
distributed across a number of lieutenants. If there are more than
1,000 developers, you need to do that, I think. I expect OpenStack
will need to do the similar with developers increased. You don't?


> > 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.


> 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)? I already saw
the shortage of reviewing (and I even saw that a half-baked feature
without enough reviewed was merged and reverted).

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.

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 don't think that openness and transparency are not related with
> > blueprints. You can simply discuss, make a decision, etc on public
> > mailing lists.
> 
> That's merely transposing the exact same process, isn't it? If the goal
> is to have features described, whether you have to type it in one place
> or another shouldn't matter much. What does matter, though, is tracking.
> I think it's common consensus that mailing lists make *dreadful* bug
> trackers.  I'm not sure I understand why it would be much better for
> tracking "blueprints" or whatever you'd call them in that context?

Oops, I didn't mean that. I just meant that you can achieve openness
and transparency without blueprints. I read some arguments in this
thread, something like blueprints is a must for openness and
transparency.