Kubuntu/ReleaseManagement: Difference between revisions
basic outline |
|||
| (10 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
The purpose of this document is to outline the duties and responsibilities of the Kubuntu Release Manager. | 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. The Kubuntu Council has been [https://lists.launchpad.net/kubuntu-council/msg00155.html asked] to facilitate this.}} | |||
== | == Stay in Touch == | ||
First off, make sure to participate in the modes of communication for the [http://wiki.ubuntu.com/ReleaseTeam 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 | ||
: [irc://chat.freenode.org/ubuntu-release #ubuntu-release on freenode] | |||
;mailing list | |||
: [https://lists.ubuntu.com/mailman/listinfo/ubuntu-release [email protected]] | |||
== Be Organized == | |||
Be aware of the [https://wiki.ubuntu.com/ReleaseSchedule release schedule], paying close attention to the older LTS releases. They get approximately five [https://wiki.ubuntu.com/PointReleaseProcess point releases], the cycle of which often overlaps parts of current release development cycles. Make sure to keep your team members aware 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 [https://wiki.ubuntu.com/CommunityMilestoneProcess 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 [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 == | |||
Based on the results of development and QA, at each given deadline, the release manager will need to make decisions about whether or not to allow or disallow the release of a particular package or milestone image. Depending on the nature of the object in question, it may be necessary to liaise with other team leaders or admins to discuss the options and confirm a particular suggestion. Most notably, during milestone testing, this means getting on the [http://iso.qa.ubuntu.com Testing Tracker] and marking milestone images as ready or not. | |||
Latest revision as of 08:26, 11 February 2017
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. The Kubuntu Council has been asked to facilitate this. |
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 aware 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.
Make Decisions
Based on the results of development and QA, at each given deadline, the release manager will need to make decisions about whether or not to allow or disallow the release of a particular package or milestone image. Depending on the nature of the object in question, it may be necessary to liaise with other team leaders or admins to discuss the options and confirm a particular suggestion. Most notably, during milestone testing, this means getting on the Testing Tracker and marking milestone images as ready or not.