openstack team mailing list archive

[Todd Willey <todd@xxxxxxxxxxxx>]

On Tue, Mar 29, 2011 at 8:54 AM, Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: Todd Willey [mailto:todd@xxxxxxxxxxxx]
>> Sent: 29 March 2011 04:08
>> To: Ewan Mellor
>> Cc: Jay Pipes; openstack@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Openstack] Feature Freeze status
>>
>> 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.
>
> I don't agree.  Unplanned features aren't an extra gift -- they're extra work for everyone.
>
> Thierry is trying to stabilize a release and get it out on time.  He can't do that if people come along saying "here's an extra gift that you now need to give time to review".  We're already short on resources, and Thierry needs to prioritize based on the capacity that we collectively have.  For example, Citrix has bumped a number of features to Diablo, because it was clear that we wouldn't get everything reviewed and merged and stabilized in time unless we deferred low priority work.  Unplanned features just put all that in jeopardy.
>
> If someone comes along with a random branch as a "gift", then it's not unreasonable for us to say "Thank you for that, we'll take it in the next unstable period in a couple of months.  In the meantime, please write a brief blueprint so that we don't forget about it."
>

Well then lets recruit more -core members, keep tweaking the review
process, and work with the release windows.  I would say those things
are more a cause of the problem than someone sharing code.

What is the point of timed releases if we punt stuff without
blueprints regardless of landing during an open window?  Code that
comes in before freezes should be reviewed for the release it was in
the window for.

> A blueprint doesn't have to be burdensome.  Big features need a long time at the planning stage, but for other things there's no reason why the blueprint should take more than half-an-hour.  I don't think it's unreasonable to ask anybody to spend half-an-hour writing down what their new shiny thing is, how it works, and how to test it.
>

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.

-todd[1]

> Cheers,
>
> Ewan.
>
>