The purpose of this document is to outline the duties and responsibilities of the Kubuntu Release Manager.
|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.|
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.
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.
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.
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.
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.