Matt Riedemann <>  wrote:

>The specs thing was mentioned last week in IRC when talking about blueprints 
>in launchpad and I just want to reiterate the specs are
>more about high level designs and reviewing those designs in Gerrit which was 
>/ is a major drawback in the 'whiteboard' in launchpad for 
>working on blueprints - old blueprints that had a design (if they had a design 
>at all) were usually linked from a wiki page.

>Anyway, specs are design documents per release. Blueprints in launchpad, at 
>least for nova, are the project management tracking tool for 
>that release. Not all blueprints require a spec, but all specs require a 
>blueprint since specs are generally for API changes or other major 
>design changes or features. Just FYI.

Matt is saying exactly what I've been saying in OpenContrail/Tungsten Fabric 
TSC meetings for a year. Launchpad Blueprints are very valuable for identifying 
what's likely to be in a given release, unambiguously indicating when the team 
has determined that something is going to miss a release (and therefore get 
bumped out to the future) and capturing the history of what was in a release. 
But they're lousy for reviewing and collaborating on technical details of what 
the thing actually is and how it is planned to work.

On the other hand, spec documents in Gerrit are pretty good for iteratively 
refining a design document and ultimately agreeing to a finalized version, but 
not really all that good at reflecting status and progress to people who are 
not down in the weeds of discussing the implementation details of the feature.

If Storyboard can find a way to improve on one or both of these activities, 
that's great. But abandoning Launchpad series and milestones functionality 
without a good replacement isn't a good idea for projects that are using them 
effectively. And for projects that aren't using them, I have to ask whether 
it's because they have a better way of communicating release plans to their 
user/operator communities or if it's because they simply aren't communicating 
release plans.

Generally somebody somewhere is paying for almost all development, so most 
likely somebody wants to know if and when it is/will-be/was done. The simpler 
and more consistent the tooling for communicating that, the less time everyone 
has to spend answering questions from the people who just want to know if 
whatever thing they're waiting on is in progress, on the backlog, or already 

OpenStack Development Mailing List (not for usage questions)

Reply via email to