Feedback on Quantal Release and Improvements
Feedback session on what went well and what needs to be tweaked from our experiences in quantal. Goal is to keep the experiments that did work, and adjust those parts that were still causing problems.
What experiments worked:
* marking images as 'ready' in the tracker worked well, but this needs to supersede the manifest check-off
* pre-publishing needs to ignore the ready flag
* virtual release sprint (i.e., doing the release remotely)
* release notes - had to add some markers so not everything was included in the server page (keeping include for bugs but not features)
What experiments need tweaking:
* 20121002: KES - still too much manual effort in keeping blueprints up to date, need more systematic use of templates to facilitate automation.
* no consensus to automate changes to blueprint states. When it's within % of completion, send email to ask?
* Gardening implementation state of blueprints, to get in correct state to get in release notes.
* Define release notes at start of cycle, not at end. The fact that release notes are "mandatory" isn't honored.
What do we want to do differently in 13.04:
* 20121002: KES - ability to search blueprints is not effective. How can we get this improved?
* this is in the launchpad critical queue and being driven down now (says cjwatson) webnumbr.
* foundations+r is better for searching
* We now have a streamlined mechanism for denoting images are ready to publish (marked on the tracker), so let's retire use of manifest wiki page.
* There is a separate UDS session about release manifest streamlining (linked as a dependency of this blueprint).
* Queue accepts - lack of auditing was an issue. Logging still being worked out in background process StevenK. In the meantime, IRC channel will continue to be used for coordination. Duplication happened on reviews, when people didn't say on #ubuntu-release that they were doing them.
* 20121025 - kitterman - It seemed to me that we spent a lot of time reviewing UIFe/FFe requests around late-landing features that weren't really critical and resulted in multiple respins the weekend before release for bugs that got addressed later than they should have.
* Telling people no and blanket exceptions? Communicate schedule and that "we really mean it". The other half of the compromise of a later freeze is a harder "no".
* 20121028 - KES - weekly team summaries consistently not making it by day before deadline. Arriving just before meeting, so not much time to review/cross check between teams. Do we want to continue weekly mail outs before release meeting in Raring?
* bugs being worked on - use the "release tracking mechanism" instead and get rid of this section in the weekly mails. If there are issues where a team is blocked on another team, it's better to proactively communicate those issues in #ubuntu-release instead of waiting for a weekly mail.
* Do we even want to have weekly meetings?
* Likely not, try to just use weekly emails.
* Need to be able to distinguish between daily builds vs. what is in the manifest for release, and for this to be reflected on the iso tracker UI.
[stgraber] add support for ISO tracker to continue QAing dailies for images that are not included in a currently-tested milestone: DONE
[stgraber] make pre-publishing ignore the ready flag: DONE
[vorlon] convert the release notes common-
[kate.stewart] release scripts for pulling release notes blurbs from blueprints and concatenating them: POSTPONED
[pgraner] get PS representation on #ubuntu-release on an ongoing basis: TODO
[kate.stewart] update template for weekly reports (https:/
[adconrad] socialize the change to use the release targeting bug list as The One Way to track bugs that are important to the team: TODO
[pgraner] inform the community that the weekly meetings are dropped and point them at the replacement process of weekly reports by mail only + bug targeting: TODO
[stgraber] autopublishing of the chinese images and cloud images to isotracker: DONE
* Blueprints in grey have been implemented.