openstack team mailing list archive
Mailing list archive
Re: Feature Freeze status
On Thu, 31 Mar 2011 00:44:07 -0400
Todd Willey <todd@xxxxxxxxxxxx> wrote:
> I haven't disagreed with those points. I'm not advocating the removal
> of blueprints or changing the way we select release goals. I only
> don't want to be so strict that we push back against our users instead
> of being their allies. Openness and transparency don't exist in a
> project just because it uses blueprints, and a lack of using
> blueprints does not correlate to being closed or opaque. When it
> comes to high level goals, specs are pretty much required to achieve
> openness (I get that, really I do). But when it comes to individual
> patches and one-off contributions, openness and transparency are
> served by merge proposals and reviews.
Been heavily involved in Linux kernel development, I would tend to
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), you see that lots of developers can work
well without something like blueprints.
I think that eliminating barriers to contribute code is much more
important for success. If you ask people to do something before
involvement (sign CLA, create a launchpad account, writing a blueprint
for a tiny feature), you have less change to see that they would be
I don't think that blueprints are helpful for some problems discussed
in this thread (e.g. prioritizing new features). I think that we need
more strong lead for them. I like to see maintainer per subsystem (not
per project) to coordinate developers on a daily basis.
I don't think that openness and transparency are not related with
blueprints. You can simply discuss, make a decision, etc on public
Duplicating work isn't necessarily bad. Likely developers solve the
same issue differently so we can understand different approaches
better and have the good code in the end.