From 264f77da0353f78611c4bc95607ad246cbbe252a Mon Sep 17 00:00:00 2001 From: PulkoMandy Date: Fri, 15 Jul 2022 22:11:57 +0200 Subject: [PATCH] docs/develop/release: add the info from the ReleaseCookbook Trac wiki page The corresponding Trac wiki page can be deleted once this is merged. Some of this information is a little out of date, help is welcome on updating it. Change-Id: I9157b140bcb5de3fed3c95d994745b5a1cbee1f6 Reviewed-on: https://review.haiku-os.org/c/haiku/+/5477 Tested-by: Commit checker robot Reviewed-by: Adrien Destugues --- docs/develop/release/index.rst | 30 ++++++--- docs/develop/release/milestones.rst | 96 ++++++++++++++++++++++++----- 2 files changed, 102 insertions(+), 24 deletions(-) diff --git a/docs/develop/release/index.rst b/docs/develop/release/index.rst index 6ff108226c..29f32f0322 100644 --- a/docs/develop/release/index.rst +++ b/docs/develop/release/index.rst @@ -1,25 +1,40 @@ Release engineering =================== -To forge a successful stable release of the Haiku operating system, several important tasks must be accomplished. These steps are time tested as a best roadmap to draft a successful release of Haiku. +To forge a successful stable release of the Haiku operating system, several important tasks must be +accomplished. These steps are time tested as a best roadmap to draft a successful release of Haiku. + +.. toctree:: + + milestones Important first steps --------------------- -* Review blockers for the next release in [Trac](https://dev.haiku-os.org) -* A minimum of 25% of the individuals in the [contributors group](https://review.haiku-os.org/admin/groups/23fa29f291e2dd5d41452202147d038f020fc8db,members) should reach concensus of the need for a stable release - * Over time this may change to a time-based stable release schedule. +* Review blockers for the next release in `Trac `_ +* Active members of the `contributors group `_ should reach concensus on the need for a stable release + * We try to have a release every year, but blocker tickets can prevent this from happening + * It's difficult to commit to strictly time-based releases because the available time of unpaid developers is unpredictable * Community nomination of a Release Coordinator * Should be someone from the contributors group * Should have visibility of most aspects of Haiku * Should have good coordination and communication skills - * Generally occurs via the mailing list haiku-development + * Generally occurs via the haiku-development mailing list * Timeline proposals are proposed via the haiku-development mailing list +General Rules +------------- + +* Don't rush the release. Better delay it a bit and take the time to make sure everything is ok. +* Make sure the final image is really well tested. +* Start planning early. Getting the release ready takes time. Waiting until a new release is urgent is a bad idea. +* There will be another release. Maybe some big changes are too risky to integrate now, and should wait until the next release. + Forming a timeline ------------------ -An important aspect of drafting a release is forming a timeline. The Release Coordinator's role is to drive Haiku towards this release date. +An important aspect of drafting a release is forming a timeline. The Release Coordinator's role is +to drive Haiku towards this release date. * Final date for enhancements in (RELEASE) * Branch buildtools for (RELEASE) @@ -37,6 +52,3 @@ An important aspect of drafting a release is forming a timeline. The Release Co Release dates can slide, it's ok. We just try to slide pragmatically (+1 week because of X,Y,Z) -.. toctree:: - - milestones diff --git a/docs/develop/release/milestones.rst b/docs/develop/release/milestones.rst index 5d01b53151..298c746374 100644 --- a/docs/develop/release/milestones.rst +++ b/docs/develop/release/milestones.rst @@ -1,41 +1,59 @@ Critical Milestones =================== +This page documents the steps needed during a release. + Community Concensus ------------------- * Determine a release is needed * Gain support in the community + * Review the list of Trac tickets in the milestone. There should be no blockers and ideally no critical tickets + * Decide if some of the tickets can be lowered in priority or moved to the next release * Raise release proposal on mailing list (haiku-development) - * Elect Release Coordinator + * Select Release Coordinator * Plan timeline (which should be made up of milestones below) * Allow one week RFC time for comments +Each of the steps below should be announced on the mailing list to remind everyone where we're at. + Scramle. Enhancement Deadline ----------------------------- **Time:** ~ 1 week * Roughly one week for people to finish up their enhancements for *(RELEASE)* -* Should be announced on the mailing lists +* Avoid merging changes that break the API, so 3rd-party applications are ready to build with the API matching the release +* Decide if any haikuports packages should be added or removed from the release image * Final ICU upgrades, webkit upgrades, etc. * Plan for release logo used in installer (always fun, lots of bikeshed) -* Be working on release notes! + * Prepare this in advance if possible, if you want to change the logo, this is the worst time to do it. +* Set up the `Trac wiki pages `_ for the release + * Start writing or updating the release notes and press release Branch ------ **Time:** ~ 1 week -* **Sysadmin** Branch *(RELEASE)*, haiku, buildtools -* **Sysadmin** Add *(RELEASE)* to CI/CD (Concourse) -* **Sysadmin** generate toolchain container for *(RELEASE)* -* **Sysadmin** begin Test Candidate builds for target architectures (x86_gcc2h, x86_64) -* **Sysadmin** Test Candidate (TC) builds should be clearly labeled and made available -* **Sysadmin** and **Release Coordinator** work in unison to merge bugfix patches to stable branches - * **Sysadmin** focuses on merging build fixes, etc - * **Release Coordinator** focuses on reviewing bug fixes - * Communication is key! +* Update the version constants in master (example: hrev52295) +* Branch haiku and buildtools (git push origin master:r1beta1) + * Update the version constants in the branch (`example `_) + * Update copyright years in the `bootloader menu `_ + * Tag the buildtools & point the branch to them (TODO) + * Disable serial debug output in bootloader and kernel config file (`example `_) + * Turn KDEBUG_LEVEL down to 1, for performance reasons (`example `_) + * Update Haiku's main package repos to use the branch's repo (`example `_) +* Sysadmin tasks + * Symlink the release branch repository directory to master's (so that a hard branch can be done later) and update the package repos to point to it (`example `_) + * Synchronize userguide and locale catalogs in the branch during the release stabilization phase + * Add *(RELEASE)* to CI/CD (Concourse) + * generate toolchain container for *(RELEASE)* + * begin Test Candidate builds for target architectures (x86_gcc2h, x86_64) + * Test Candidate (TC) builds should be clearly labeled and made available +* Merge important bug fixes from master on a case-by-case basis. Ideally the release coordinator should review most of the changes and decide if they go in + * Use Gerrit "cherry-pick" function to propose a change for inclusion in the release branch + * Only merge bug fixes and build fixes, no new features at this point (they can stay in master) Testing ------- @@ -43,19 +61,22 @@ Testing **Time:** ~ 2 weekes * Agressively market Test Candidate builds for *(RELEASE)* -* Bugs opened on trac under *new* version. Squash bugs +* Bugs should be opened on Trac under the *new* version (make sure it is available in Trac admin pages). * **Release Coordinator** should be downright obnoxious about people testing TC images! +* Have people test on as much hardware as possible to find issues with drivers Finalization ------------ **Time:** ~ 1 week -* Everything going well? Produce Release Candidate images +* If everything is going well, produce Release Candidate images +* Make the branch officia (hrev36768) * RC images all want to be *(RELEASE)* * Any RC image can be renamed *(RELEASE)* -* Ensure release notes are almost done. +* Ensure release notes and press release are almost done. * MOAR Testing! +* When you have decided that an RC is actually the release, tag it in git Distribution ------------ @@ -67,9 +88,54 @@ Distribution * Generate Torrents, seed. Get a few other people to seed. * Place onto wasabi s3 under releases in final layout (be consistent!) * Move to releases onto IPFS, pin and use pinning services +* Prepare release-files-directory:: + + [release-name] + |--md5sums.txt (of compressed and uncompressed release-image-files) + |--release_notes_[release-name].txt + |--[release-image-files] (both as .zip and .tar.xz) + |--[release-image-files].torrent (of just the .zip's) + |--[release-name]/sources/ (all source archives should be .tar.xz) + |--haiku-[release-name]-src-[YYYY-MM-DD] + |--haiku-[release-name]-buildtools-src-[YYYY-MM-DD] + |--[all optional packages] + +* rsync release-files-directory to http://haiku-files.org/files/releases/[release-name] +* rsync release-files-directory to baron:/srv/rsync/haiku-mirror-seed/releases/[release-name]/ (the 3rd-party rsync mirrors will automatically mirror the files) * Give mirrors time to... mirror via rsync +* Tell Distrowatch: http://distrowatch.com/table.php?distribution=haiku (?) +* Update the freshmeat/freecode page: http://freecode.com/projects/haiku (mmu_man) * Update website references. * Double check listed mirrors have release * Comment out any mirrors which don't have it (a few missing is fine) * Put release notes on proper place on website * Release! + +After the release +----------------- + +* Close the current milestone on Trac, move tickets to the next milestone +* Set a release date on the next milestone (a date long in the future, just to have it show first in the milestone list) +* Make the new "version" in Trac be the default for newly creatred tickets +* Update the Roadmap wiki page again with the final release date +* Prepare graphics for the download page: stamp, ladybugs, cd/dvd graphics + +Website Pages to update: + +* Official Article +* http://www.haiku-os.org/get-haiku +* http://www.haiku-os.org/get-haiku/release-notes +* http://www.haiku-os.org/get-haiku/installation-guide +* http://www.haiku-os.org/get-haiku/burn-cd +* http://www.haiku-os.org/guides/making_haiku_usb_stick +* http://www.haiku-os.org/slideshows/haiku-tour +* http://www.haiku-os.org/docs/userguide/en/contents.html -- sync with branch or tag. + +Updating download logo for website front page: + +.. code-block:: bash + + sudo bash + cd /srv/www/drupal/haiku-os.org/themes/shijin/haiku-images + mv bg-download-box.png GET-HAIKU-download-box-r1a1.png + cp GET-HAIKU-download-box-r1a2.png bg-download-box.png