openstack team mailing list archive

[Todd Willey <todd@xxxxxxxxxxxx>]

On Mon, Mar 28, 2011 at 7:42 PM, Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: Todd Willey
>> Sent: 28 March 2011 21:11
>> To: Jay Pipes
>> Cc: openstack@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Openstack] Feature Freeze status
>>
>> [Snip]
>>
>> Clearly blueprints are about process and not about code.  Merge
>> proposals are a hybrid of code and process.  Blueprints are about
>> managing expectations, whereas merge proposals are about managing
>> code.  I think if you are working on a self-contained change you don't
>> need to manage the expectations of people working on other parts of
>> the system because you're not going to interfere, and their
>> expectations about how they should write code can go unchanged.  You
>> do, however, need to have a process required to get your changes
>> accepted into the code, and need to outline your reasoning and
>> implementation goals.
>
> I think that this paragraph is a great exposition of why I (and others) disagree with you.  Blueprints are not about managing expectations.  Blueprints are about telling other people what you're working on.  This is important, because I don't think that anyone is in a position to judge whether they are "working on a self-contained change" or whether they're "not going to interfere" _unless_ they are telling people what they are working on.
>

Blueprints are great for the reason you and Rick have stated.  They
let all types of people who are interested in monitoring the
development and planning their own development and implementation plan
more effectively.  I think of unplanned features as an extra gift on
top of all of this that we should accept gratefully.  I'm not saying
we can know before propose-time if a feature is isolated.  But, if at
the end it turns out it is in fact isolated, then I see no reason we
shouldn't welcome it with a minimum of drama.

> For example, there have been many occasions when we (Citrix) have said "oh, we don't need to work on that, because Rackspace have it covered" or "we'd best mention this to Rackspace, because they're working on something else that is _bound_ to conflict".  There have also been times when we've said "it sure would have been great to know about that in advance, and save ourselves half-a-dozen trunk merges".
>
> Blueprints are important because they save other people wasting their time.  That's either because they get to avoid duplicating your effort, or because they want to work in the same code and get to schedule around you so that the merge conflicts aren't insane.  Maybe, if you're really lucky, they might actually have some good ideas and can make suggestions to you.
>

I understand that working without blueprints is more often the more
painful way to do things.  I'm not saying it's good, I'm only saying
that there are cases where it is _acceptable_.  Breaking things,
making major design decisions without discussion, and ignoring our
platform goals should get things rejected.  Always.

We can also still offer feedback and suggestions in a MP, so I think
the window of time that people have to be really lucky is non-zero
even in the absence of a BP.  With core review days and targeting
specific reviewers by name we should continue to move this out of the
realm of luck and into a process designed to get the right people
providing that meaningful feedback.

> Blueprints should be regarded in the same way as docstrings.  Sure, you can write the code faster without docstrings, and the code will work just as well, but it will take everyone else twice as long to figure out what it was you are trying to do.  Blueprints are the same, just at a different phase in the process.  You can definitely write the code without writing the blueprint first, but everyone else would sure appreciate it if you put half-an-hour into the blueprint.  That way, we'll know what it is you're trying to do.
>

I, too, appreciate people taking their time to write blueprints.  I
also appreciate people who take time to write code, even if it doesn't
come with a blueprint.  People who take their creative energy to
contribute to something I love earn enough favor that my default state
is to try and accept their contribution without imposing additional
barriers to entry.  Maybe a patch comes in that it isn't reasonable to
merge, but we never know unless we actually look at it with the
mindset of trying to accept it.  I still expect that people give
blueprint-level details in merge proposals so that we can follow the
code with an understanding of what you're trying to accomplish,
otherwise we'd do right to mark it "Needs Information" and get the
clarity we need.

> Thanks,
>
> Ewan.
>

I get that blueprints are useful, all I'm advocating is that we don't
beat people over the head with it.

-todd[1]