openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Thu, Mar 31, 2011 at 12:44 AM, Todd Willey <todd@xxxxxxxxxxxx> wrote:
> On Wed, Mar 30, 2011 at 6:41 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
>> 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.
>
> I don't think the methods used to submit code have anything to do with
> what the motivations of the contributors are.

Sorry, you lost me on this one. We're not talking about the methods of
submitting code. We're talking about the methods of discussing said
code with the community, where the community is larger than the few
folks who look at the merge proposal.

>> 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:
>
> Not sure how valid this is since applying the apache license doesn't
> make you a part of the apache foundation.

Not sure how valid the Apache open development method is to the open
source world? Well, we are clearly on different sides of the chasm
when it comes to what we consider the open source world and what
things are valid to consider as "standard practices" (your words) in
the open source world.

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

If the patch is over a thousand lines long, adds a new feature that
wasn't discussed, all we're saying is that we are more likely to
review proposals that have a blueprint attached and have been
discussed on the ML. That's all. Nothing preventing a contributor from
proposing the branch for merging. I'll review it and ask questions,
but I'm not going to give it as much weight as if it had been
discussed on the mailing list and had some sort of spec associated
with it so people can track what it does.

It's about prioritizing, that's all. I understand you and others don't
think blueprints should play a role in prioritizing for *some*
patches. That's totally fine. But blueprints and open discussion on
the ML are just one of the many tools we have at our disposal to
determine, during the Hell Week of feature freeze, which branches of
the dozens proposed, to review first. That's the only thing I'm
saying...

>> 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.
>
> If you think the less than 200 repositories the ASF manages speak more
> clearly about openness and standard practices than the nearly 2
> million on github, then I think we are going to continue talking past
> each other.

Ah, and here is the rub. Yep, I 100% emphatically believe that the 200
repositories the ASF manages speak more clearly about openness and
standard practices than the nearly 2 million on github, The reason is
because the ASF actually *have* standard practices, and even standard
practices specifically about openness! :)

2 million repositories doesn't mean anything. Most are just "forks"
(uhm, branches...) that are dead-ends and won't go anywhere. Is that
totally cool and groovy? Yep. But they don't mean anything when it
comes to openness and standard practices. All it means is GitHub is an
easy place for coders to publish their work. Nothin wrong with that,
and GitHub is great at that. But the number of random branches of code
on GitHub doesn't say anything about standard practices. It just means
that GitHub has been spectacularly successful at attracting open
source developers to use Git and to put their code online.

I view GitHub as a place for developers to push code to and let a
thousand flowers bloom. But I don't view ASF software in the same way.
ASF software is stable, consistent, and mature. And I'm pretty sure
the sysadmins and operations people that deploy OpenStack aren't
really interested in the blooming of code gardens. I think they are
more interested in seeing a stable, consistent direction in the
project.

Bottom line is, while you've dismisseD this thread as pointless, the
thread has brought up some grumblings from a number of folks on both
sides of the proverbial coin. There is a happy medium in between
somewhere, where we can balance the needs of non-contributors and
deployers with the just-as-important needs of contributors. A balance
between process and agility.

I look forward to discussing all of this at the summit with you and others.

-jay

> My feelings remain:
> * Isolated patches are okay, and reviews will weed the dangerous ones out
> * Two patches (esp. when marked as exceptions) do not signal a change
> in practices
> * Let's all be nice to our user-contributors
>
> -todd[1]
>
>> -jay
>>
>