Like everything we do in Kubuntu, release management should be done by a team. I think we should create a team like Xubuntu have in Launchpad and get the Manifest updated so that it will stay correct. In addition, Xubuntu have some nice docs which explain the various functions in clear language. If we expand the team to include testers and promo people, which I think we should, "Release Manager" is just the point person who steps up for each cycle, and everyone else on the team pitches in when necessary.
Join the Kubuntu Release team on Launchpad.
New Ubuntu community hub for ISO testing: https://community.ubuntu.com/t/ubuntu-17-10-community-iso-testing/458
Throughout each cycle, the Kubuntu Release Manager ensures that a number of tasks are done by freeze dates. The Ubuntu release schedule is always listed as https://wiki.ubuntu.com/ReleaseName/ReleaseSchedule.
Current cycle is at Artful Release Schedule.
There are two alphas, and two betas, a Release Candidate (RC) as well as the Final Release. These are scheduled roughly 2.5, 3.5, 4.5, and 5 months into the cycle, and a week before release for the RC. Only the final beta is mandatory for flavors like Kubuntu, but the more we participate, the more testing coverage we have.
For each milestone and release, there may be a call for testers, a news story to be published on Kubuntu.org and social media at release, and Release Notes prepared in the Ubuntu wiki. This is a recent sample: https://wiki.ubuntu.com/ZestyZapus/Alpha2/Kubuntu. To efficiently create it, open a previous version for editing after logging in, copy it, and paste into a new page with the new name (always ReleaseCodename/Release/Kubuntu). An up-to-date list of bugs should be included in the Release Notes and any workarounds available.
The release images are usually released on a Tuesday, and due Thursday. "Due" means that the images should be fully tested and reported on the QATracker. For more about how to use it, see https://wiki.ubuntu.com/Testing/QATracker. After the mandatory tests have been done, in advance of milestones and releases, the RM marks the images ready (login to the qa site, scroll to the bottom of the page to Administration, and set the Status). If necessary, the RM can spin a new ISO during the testing period.
A "Call for Testing" story on Kubuntu.org and respread on social media will enlarge our group of testers, and we should be diligent in thanking new testers, helping them report their findings on QA, and inviting them to join the official team at some point.
In addition to the current release, for past LTS releases, there will be point releases which need some attention by the team. One can see the milestones (planned dates for point releases) at https://launchpad.net/ubuntu in the section Active series and milestones.
For point releases, one can add notes at the top of the original Release Notes. In addition, a news story should be prepared for publication on Kubuntu.org. Testing is also reported on the QATracker.
When we update Frameworks, Plasma and perhaps some important applications in the archive, they are backported to the previous release and possibly previous LTS, after testing. The RM will help with calls for testing, and the backport should be announced on the website, mail lists and social media.
- post to the Kubuntu-devel and Kubuntu-user lists
- post to Kubuntu social media
In preparation for a release, new artwork should be prepared, and uploaded to the website, twitter, etc.
The Plasma team would like us to keep this updated as well: Plasma in Kubuntu.
Also crucial are the IRC channels: #ubuntu-release on Freenode and #kubuntu-devel of course. The #ubuntu-devel channel may also be useful. For major releases, the channel topic should be updated.
There is more information on the wiki: https://community.kde.org/Kubuntu/ReleaseManagement