openstack team mailing list archive

[Todd Willey <todd@xxxxxxxxxxxx>]

On Wed, Mar 30, 2011 at 6:41 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
> On Wed, Mar 30, 2011 at 6:17 PM, Todd Willey <todd@xxxxxxxxxxxx> wrote:
>> On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> 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.
>

I don't think the methods used to submit code have anything to do with
what the motivations of the contributors are.

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

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

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

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
>