Matt Riedemann <mriede...@gmail.com> 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 complete. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
