47 lines
3.9 KiB
Markdown
47 lines
3.9 KiB
Markdown
## Two weeks before release day
|
|
|
|
1. Announce internally that any last minute changes should be done as soon as possible.
|
|
1. Go through the release blocker list for this cycle and punt non-RC tasks to next cycle. Communicate this list to the Ubuntu Release Team.
|
|
1. Inform the Calamares upstream contact that we plan on doing a release in two weeks. Discuss whether any important patches should be cherry-picked, and get those uploaded as soon as possible. Ask them nicely to ping you in the next two weeks if anything important comes up.
|
|
1. Talk to the Lubuntu Documentation Team about what needs to be wrapped up for next release. Nicely remind them that the release is in two weeks.
|
|
|
|
## A week before release day
|
|
|
|
1. Update the downloads page and the homepage for the new release in a draft, so they can be published on release day.
|
|
1. Do one final check of the [ISO QA Tracker](https://iso.qa.ubuntu.com/) and send out a call for testers.
|
|
1. Start drafting a blog post for the release. Ideally in Markdown.
|
|
1. Gather known bugs (possibly automate this) to put on the blog post from:
|
|
1. [Bugs associated with the Lubuntu Packages Team](https://bugs.launchpad.net/~lubuntu-packaging);
|
|
1. Packages in the Lubuntu packageset which the Lubuntu Packages Team might not have been subscribed to, especially Lubuntu specific ones like `lubuntu-meta` and `lubuntu-artwork`;
|
|
1. Known issues from previous release notes; and
|
|
1. [Open defects report on the ISO QA tracker](http://iso.qa.ubuntu.com/qatracker/reports/defects/opened) for both the upcoming release as well as previous releases to ensure nothing has been missed.
|
|
1. Make sure that the link is correct on the Ubuntu release notes for where our announcement will be.
|
|
1. Remind the Ubuntu Release Team that our link schema has not changed.
|
|
|
|
## After ISOs have been released
|
|
|
|
1. Update the Lubuntu Manual in production (via SSH):
|
|
1. Merge `stable` -> `master`.
|
|
1. Make sure version strings and hashes are updated in the `master` branch.
|
|
1. Rename `stable` to its release number.
|
|
1. Push `master` to `stable` (and to `lts` if applicable; do NOT merge).
|
|
1. Change the version strings in `master` to reflect the new development release.
|
|
1. Publish the blog post and the downloads/homepage/links drafts.
|
|
1. Post on social media:
|
|
1. [X](https://x.com/LubuntuOfficial) and [Mastodon](https://fosstodon.org/@LubuntuOfficial).
|
|
1. [r/Lubuntu](https://www.reddit.com/r/Lubuntu) and [r/Ubuntu](https://www.reddit.com/r/Ubuntu).
|
|
1. [Facebook page](https://www.facebook.com/Lubuntu.Official.Page/) and [Facebook group](https://www.facebook.com/groups/lubuntu.official/).
|
|
1. Scan social media and see if anyone is pointing out any reproducible bugs that we can file. Be gracious and understanding of the fact that most comments are from laymen-level users.
|
|
|
|
After the codename is announced and `base-files` is uploaded:
|
|
|
|
1. File documentation about a new wallpaper and slideshow for the upcoming release.
|
|
1. Change `update.cfg` in lubuntu-meta and the branding/desktop file in calamares-settings-ubuntu.
|
|
1. Make sure `repo-list` is up-to-date and run `setup-repos` in this repo. The production values can be found elsewhere.
|
|
1. If `lintian` and `devscripts` have not been updated (NOTE: normally, Ubuntu/Debian would handle this), cherry-pick the `lintian` patch adding the new release as known if there is one, and no-change rebuild `devscripts`.
|
|
1. Lintian needs a patch because all of the Ubuntu release codenames are hardcoded in `vendors/ubuntu/main/data/changes-file/known-dists`.
|
|
1. `devscripts` needs a no-change rebuild because it gets the value grabbed by `dch -r` on build time. This is the conditional `sed` modification to `debchange.pl` in `scripts/Makefile`.
|
|
1. Evaluate our packages. What needs to be updated to the latest upstream release? What did we carry over to this release?
|
|
1. Qt 6 stack.
|
|
1. LXQt itself.
|