Kubuntu/ReleaseManagement: Difference between revisions
(→Be Organized: dates) |
(→Herd Cats: freeze exceptions) |
||
| Line 26: | Line 26: | ||
The crux of release management is making sure the work gets done. This doesn't mean doing all the work, but ensuring that all of the team members have all the information, resources, and tools to do the work they've volunteered for. Essentially it means staying in touch with all the teams to be sure everything is progressing well enough to be sure that a quality release comes out on time. Invariably, this is the part of release management that is the meat of the work. | The crux of release management is making sure the work gets done. This doesn't mean doing all the work, but ensuring that all of the team members have all the information, resources, and tools to do the work they've volunteered for. Essentially it means staying in touch with all the teams to be sure everything is progressing well enough to be sure that a quality release comes out on time. Invariably, this is the part of release management that is the meat of the work. | ||
Most of this should be fairly obvious. However, as release-critical bugs or new features come to light, some additional work may need to happen to individually track those specific things. This is not to mention [https://wiki.ubuntu.com/StableReleaseUpdates Stable Release Updates (SRUs)] which track high priority changes to published releases. | Most of this should be fairly obvious. However, as release-critical bugs or new features come to light, some additional work may need to happen to individually track those specific things. This is not to mention [https://wiki.ubuntu.com/StableReleaseUpdates Stable Release Updates (SRUs)] which track high priority changes to published releases and [https://wiki.ubuntu.com/FreezeExceptionProcess Freeze Exceptions] which request permission for a change after the respective deadline. | ||
== Make Decisions == | == Make Decisions == | ||
Revision as of 04:48, 14 November 2016
The purpose of this document is to outline the duties and responsibilities of the Kubuntu Release Manager.
| TODO |
|---|
| At time of writing, this is written from the perspective of a Lubuntu Release Manager. This is to say that some additional items may be missing. It will be enhanced through discussions with previous Kubuntu Release Managers. |
Stay in Touch
First off, make sure to participate in the modes of communication for the Release Team. This will keep you up to date on what's going on. In particular, IRC is the primary mode of communication for keeping up to date with day to day business. Especially during milestones, it is essential to be here for announcements of respins or systemwide bugs.
- IRC channel
- #ubuntu-release on freenode
- mailing list
- [email protected]
Be Organized
Be aware of the release schedule, paying close attention to the older LTS releases. They get approximately five point releases, the cycle of which often overlaps parts of current release development cycles. Make sure to keep your team members available of important dates.
Help Out the Community
As a general rule the "canonical" Ubuntu releases (i.e. Desktop, Server, etc.) as opposed to the actual flavors do not participate in the milestone process until the last beta. Canonical will provide infrastucture to allow for 2 alphas and one other beta milestone, as well as someone to flip the switches on the appropriate servers.
However, it is up to flavors to coordinate amongst itself. The Community Milestone Process details how this is done. Essentially, one person signs up as point of contact for that particular milestone. They are responsible for coordinating with the other flavors and sending out the final release announcement.
Herd Cats
The crux of release management is making sure the work gets done. This doesn't mean doing all the work, but ensuring that all of the team members have all the information, resources, and tools to do the work they've volunteered for. Essentially it means staying in touch with all the teams to be sure everything is progressing well enough to be sure that a quality release comes out on time. Invariably, this is the part of release management that is the meat of the work.
Most of this should be fairly obvious. However, as release-critical bugs or new features come to light, some additional work may need to happen to individually track those specific things. This is not to mention Stable Release Updates (SRUs) which track high priority changes to published releases and Freeze Exceptions which request permission for a change after the respective deadline.