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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
