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)
  * python3 worked well,  used time because we had it.  Don't usually have it.

What experiments need tweaking:

   20121002: KES  - still too much manual effort in keeping blueprints up  to date,  need more systemic use of templates to facilitate automation.
,  need more systemic use of templates to facilitate automation.
       - no concensus to improve this.  When its 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.  Mandatory isn't really applied.
   Auto sucking in to generate initial cut of release notes?

What do we want to do differently in 13.04:
Concerns:
  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.com/launchpad-critical-bugs - possibly some progress;
   foundations+r is better for searching..
   
We now have mechanism (images marked ready), so lets retire use of manifest WIKI page.
 There is a separate UDS session about release manifest streamlining (linked as a dependency of this blueprint).
https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-release-manifest-streamlining

 Queue accepts - lack of auditing was an issue.  Logging still being worked oun in background process SteveK.  IRC channel for coordination.  Duplication happened on reviews.  People didn't say on ubuntu-release channel.

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 that important things that ended up resulted in multiple  respins the weekend before release got addressed later than the should  have.

    Telling people no and blanket exceptions?   Communicate schedule and that "really mean it".  Compromise is 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 - using the "release tracking mechanism".   Coherent mechanism if we want to get rid of section.    Communicating issues in #ubuntu-release would be better.  

Do we even want to have weekly meetings?
Likely not,  try by doing on weekly emails.

Need differences between what is in the manifest for release vs. daily builds.   Need to reflect this on the iso tracker UI.  

Discussion of test rebuilds --> other session.   Want to be schedule at any time.

ACTIONS:
[stgraber] add support for ISO tracker to continue QAing dailies for images that are not included in a currently-tested milestone
[vorlon] convert the release notes common-infrastructure include to use it only for the common bugs, and push features to the individual product pages
[kate.stewart] release scripts for pulling release notes blurbs from blueprints and concatenating them
[pgraner] get PS representation on #ubuntu-release on an ongoing basis
[adconrad] update template for weekly reports to drop the section on "bugs being worked on"
[adconrad] socialize the change to use the release targeting bug list as The One Way to track bugs that are important to the team
[stgraber] autopublishing of the chinese images and cloud images to isotracker