Open Stack

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
networking, the one for people working on block drivers, the one for
people working on graphics, etc. There are also more "experimental"
ones, like the -mm tree used to be. As I understand it, each of these
have their own lieutenant, and every once in a while, it all gets merged
into Linus' main tree.

This way, the patch acceptance load is distributed across a number of
lieutenants.

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

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

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