Open Stack

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.

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.

I think we outlined the cost of not filing blueprints... Could you
outline the cost of filing them ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack