Brainstorming how future releases can be improved.
Brainstorm how the future release management processes can be improved. This is initially to be used to catch ideas as they emerge during the Quantal cycle, and will be restructured based closer to UDS-R. Areas of interest: frequency of milestones, what we want to accomplish with them, rolling releases, infrastructure needs to support improvements.
Blueprint information
- Status:
- Complete
- Approver:
- Ubuntu Release Team
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Steve Langasek
Whiteboard
Initial ideas for topics, in light of the fact that there will be no Canonical appointed release manager any more.
- Do we need a dedicated RM as a project role rather than a C one?
- Which milestones are we going to release?
- Assign engineers to milestones
- Does the RT need to track release tracking bugs or can this be left up to individual teams?
- Who liaises with flavours?
- Is there still a need for weekly release meetings?
- Is someone in charge of the release notes?
- Do our freezes still work for us? Review their dates.
- Can freezes be done on an opt-in basis by flavors as desired
