Open Stack

On Wed, Mar 30, 2011 at 6:17 PM, Todd Willey <todd at ansolabs.com> wrote:
> On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez <thierry at openstack.org> wrote:
>> Todd Willey wrote:
>>> Not all features take a long time to plan and implement.  Some are
>>> quite tiny.  Some are conceived and implemented near the end of the
>>> release cycle.  Size, scope, and timing can change how valuable a
>>> blueprint is as the odds that a patch requires coordination tends
>>> toward zero.  The information that you point to (what their new shiny
>>> thing is, how it works, and how to test it) certainly remains valuable
>>> regardless of size, scope an timing, but that information can also
>>> live in a merge proposal.
>>
>> We have always had some tolerance so far for small unplanned features
>> that land in time. I still think those should have linked blueprints
>> (since I still fail to see the cost associated), even if that means
>> creating them retroactively.
>
> Then it is reasonable to ask people in a merge proposal discussion to
> file a blueprint, and give them guidance on how to do so.
>
>>
>> What I want to avoid is large unplanned features, which hurt project
>> external visibility and tend to generate duplicate work and last-minute
>> objections. I also want to avoid unplanned features landing *outside the
>> merge window*. This whole thread started because a set of unplanned
>> features were proposed after FeatureFreeze and required exceptions.
>
> At FFE time why don't we branch and change so proposals default to the
> next release then?  I understand that you don't want people focusing
> on features instead of bugs, but I doubt that situation will arise.
> It could, however, save us from some late proposals.  I don't want to
> have to do more work on my end in tracking branches and remembering
> dates, I'd rather just push my stuff to launchpad and have it show up
> in the list of pending proposals.
>
>>
>> I think we outlined the cost of not filing blueprints... Could you
>> outline the cost of filing them ?
>
> They aren't standard practice in the open source world.  My main
> concern is the amount of indignation that was exhibited for a practice
> that is the standard operating procedure in most open source projects.
> If we keep that attitude we're going to drive away developers, and I
> feel like we should be doing all we can to be welcoming.
>
> We're apache licensed, people don't have to share their work.  They
> can either close up or fork.  The best way to avoid that and encourage
> them to be open is to take contributions in a way that feels natural
> for developers who are making the changes and are willing to share
> their work.  if we need more information let's ask nicely, not turn a
> merge proposal into a protest.

Sorry, have to respond here. You have a view of "the open source
world" that seems to correspond only to the "hackers itching an itch"
view. While this view is valid, it's not the only "open source world"
even though it might be near and dear to some of our hearts.

You also bring up that we are licensed under the Apache license. I'll
therefore bring up this, which outlines the "the open source world"
that the Apache foundation and its contributors belong to:

http://ostatic.com/blog/guest-post-the-apache-software-foundations-open-source-approach

>From the article:

"For the Apache Software Foundation, open source is more about an open
development methodology (ODM). This is characterized by six main
traits and, regardless of the strength of the technology and vision,
all Apache TLPs have to prove themselves in these key areas:

•    a deep level of user engagement: if you don't have users then
there is no point having a project.
•    transparency: being open about what the community is undertaking
and the way decisions are made.
•    collaboration: the ability of working within a diverse group of
people, something that the Internet has obviously made easier.
•    agility: once work begins and there is a serious engagement with
users, ideas and plans may need to change.
•    sustainability: having the capacity to keep developing an
application solution over the necessary period of time.
•    tools: wikis, bug- and version-trackers and email lists to
support the development of the community and keep track of
intellectual property rights

The roots of ODM at Apache date back to the original development on
the Apache HTTP server. Originally a webserver project at the National
Center for Supercomputer Applications (NCSA), the project was left in
a corner to gather dust when key developer Rob McCool left NCSA in
mid-1994. A group of eight concerned users then decided to work
together informally on developing and maintaining the project, sharing
incremental updates or ‘patches’.

For this group, transparency: making decisions and documenting them in
public, became a requisite part of maintaining the project and of
building a sustainable development community around it. To this day,
openness and transparency are central tenets at the heart of the ASF
and the development and direction of all its projects."

That last paragraph is what we're talking about in this thread. Open
and transparent communication and decision-making in a public forum.

Ewan and others have described why the process of creating blueprints,
discussing those blueprints at summits and the ML, and using those
blueprints as the basis for release goals contributes to the success
of an *open*, *transparent* project. That's all we're trying to say.

I really don't see what the big deal is about creating a blueprint and
discussing it on the ML. For you to say that it's not standard
practice in the open source world to spec something up and is not
true. You can ask anyone who contributes to an Apache project.

-jay