Kubuntu/ReleaseManagement
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.
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.