Feedback on Natty Release and Improvements for Oneiric

Registered by Kate Stewart

This meeting is to brainstorm on the current release process, what worked and what didn't, and ways they can be improved for Oneiric.

Some of the open questions up for discussion:
- There are more projects now interacting that need to have inter-dependencies clarified. (development, stable releases, linaro, launchpad) Interlock pages working? Improvements?
- There are many process pages for managing a release is scattered over many different WIKI pages, and the role as to who needs to do which tasks is not always clear ( does it make sense to create a unified summary page with roles a bit clearer? ).
- How to get better feedback/bugs earlier in the release cycle? High/Critical bugs persisting through cycle.
- What images do we really need to create with each release? What will be tested? Image contacts work?

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
Essential
Drafter:
Kate Stewart
Direction:
Approved
Assignee:
Ubuntu Release Team
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Work items for oneiric-alpha-1:
[kate.stewart] Discuss new day for the release meeting - DONE
[gerry.carr] Review P/Q/R schedules for interaction with marketing plans - TODO
[kate.stewart] Update Oneiric schedule with feedback from UDS - DONE
[kate.stewart] Create Oneiric Interlock page - include LTS events, QA, SRU, CERT, community events (KDE 3.0, etc). - TODO

Work items for oneiric-alpha-2:
[allison] Summarize community case for rebalance of Q/R (Gnome, KDE, other problems?) - TODO
[kate.stewart] Look implicationsinto rebalance of Q/R closer to 26 weeks each. - TODO
[product managers] sign off on images for oneiric manifest, after testing arranged for each image. -TODO
[kate.stewart] Determine focus points for each subsequent milestones, and arrange for contributors to pre-seed tech overview with "interesting things" - TODO

---------

General Recommendations:
 - Consider blogging general updates from the release team level
 - preferably something which can be 'scripted'
- Be better at recording 'interesting things' in the tech overview
- Be better at "filling the void" for example "Ubuntu is switching to Wayland" (describe what we aren't doing)

http://summit.ubuntu.com/uds-o/meeting/foundations-o-releaseprocess/
#ubuntu-uds-petofi at Freenode

Feedback from 11.04
  - what worked?
  - what needs improvement?
     - communication beyond developers.... blog post - thematic, what's coming up?
       - summary of weekly reports. looking for the meta viewpoint.
         between announcements?
    - interesting things to tech overview for release notes - good selection of interesting things from milestone builds. (nudge for technologies in advance of them first landing and give date needed by...) -- include "IMPACT" of the new. Address the void (python multiarch, etc.)
  - what needs to have eye kept on?
    -ARM testing - more access to hardware +++ for community.

Oneiric Release Schedule
  - https://wiki.ubuntu.com/OneiricReleaseSchedule
  - any issues/concerns with schedule? (beyond freeze dates)

Beta 2 approach vs. Release Candidate?
  - effective?
  - improvements? better communication of beta 2. position release candidate.

 What are the images we'll be releasing as part of Oneiric?
  - consolidation? https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts
  - communication and expectation setting?
    - send out call by alpha 2 - plans....
     - community signed up by beta, at least one beta before community release.
     - untested dailies after beta removed (arm)

 Release Interlock chart
  - https://wiki.ubuntu.com/NattyReleaseInterlock -> ??
  - what improvements? Interlocking with other teams processes?
  - set up with with Stable Kernel? QA? Server? Launchpad updates? Linaro?
     - add dedicated SRU testing
     - system and target testing.
     - add upstream events column (eucalyptus, upstream milestones, etc.)

Kubuntu - changing lead.

Platform specific patches not testing by someone with hardware.
    - Qt and touch screen support on arm - needs investigation.
   - accepting without understanding how long it takes to build

(?)

Work Items