On Wed, 2012-05-16 at 09:34 +0100, James Page wrote:
> That said there are a few concepts in the specification template that
> I think would still benefit our use of blueprints. So I'd like to
> propose bringing in some of the concepts we had in specs to the
> blueprint summary and whiteboard.
Thanks for pulling this together James, it fits nicely into our need to
automate away a lot of the mindless manual part of tracking the release.
I've gone ahead and created a WIKI page to summarize your template ,
and will be starting off a wider discussion on this beyond the server
team. We've got too many half followed ways of tracking the status of
features , and until we standardize, automation isn't going to
Thierry's points are valid about the lack of history on the whiteboard
section, but folks can subscribe to the blueprints they're interested
in and monitor, so I don't consider this a blocker. Certainly its
something we'd like to see improved in Launchpad, but lack of this
logging shouldn't stop us from trying to get this standardization and
built in quality going forward.
Getting a common set of
keywords/phrases established and folks thinking about the problem from
the viewpoint of how do we test this, how will it appear to the user,
has to be an improvement on where we are today.
A good initial target will be generating the release notes for our
features  as they get completed. A combination of standard location
to look for (ie. "Release Notes:"), accurate status (blueprint "Done"),
linkage of related features together (via
topic-quantal-server-release-notes) to ReleaseNotes/UbuntuServer -
should enable a nice bit of this automation. I'll make a point of
moving the blueprint for the release note automation into this new
blueprint format tomorrow.
I do plan on citing  though in any
discussion, since that example is how like most will need to look
ubuntu-server mailing list
More info: https://wiki.ubuntu.com/ServerTeam