Aren/haiku
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs/develop/release: add the info from the ReleaseCookbook Trac wiki page

Browse Source 
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 <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This commit is contained in:
PulkoMandy 2022-07-15 22:11:57 +02:00 committed by Adrien Destugues
parent 46fdf97dea
commit 264f77da03
2 changed files with 102 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/develop/release/index.rst
View File

@ -1,25 +1,40 @@
Release engineering 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 Important first steps
--------------------- ---------------------
* Review blockers for the next release in [Trac](https://dev.haiku-os.org) * 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 * Active members of the `contributors group <https://review.haiku-os.org/admin/groups/23fa29f291e2dd5d41452202147d038f020fc8db,members>`_ should reach concensus on the need for a stable release
* Over time this may change to a time-based stable release schedule. * 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 * Community nomination of a Release Coordinator
* Should be someone from the contributors group * Should be someone from the contributors group
* Should have visibility of most aspects of Haiku * Should have visibility of most aspects of Haiku
* Should have good coordination and communication skills * 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 * 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 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) * Final date for enhancements in (RELEASE)
* Branch buildtools for (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. Release dates can slide, it's ok.
We just try to slide pragmatically (+1 week because of X,Y,Z) We just try to slide pragmatically (+1 week because of X,Y,Z)
.. toctree::
milestones

96
docs/develop/release/milestones.rst
View File

@ -1,41 +1,59 @@
Critical Milestones Critical Milestones
=================== ===================
This page documents the steps needed during a release.
Community Concensus Community Concensus
------------------- -------------------
* Determine a release is needed * Determine a release is needed
* Gain support in the community * 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) * Raise release proposal on mailing list (haiku-development)
* Elect Release Coordinator * Select Release Coordinator
* Plan timeline (which should be made up of milestones below) * Plan timeline (which should be made up of milestones below)
* Allow one week RFC time for comments * 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 Scramle. Enhancement Deadline
----------------------------- -----------------------------
**Time:** ~ 1 week **Time:** ~ 1 week
* Roughly one week for people to finish up their enhancements for *(RELEASE)* * 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. * Final ICU upgrades, webkit upgrades, etc.
* Plan for release logo used in installer (always fun, lots of bikeshed) * 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 <https://dev.haiku-os.org/wiki/R1/ReleaseRoadMap>`_ for the release
* Start writing or updating the release notes and press release
Branch Branch
------ ------
**Time:** ~ 1 week **Time:** ~ 1 week
* **Sysadmin** Branch *(RELEASE)*, haiku, buildtools * Update the version constants in master (example: hrev52295)
* **Sysadmin** Add *(RELEASE)* to CI/CD (Concourse) * Branch haiku and buildtools (git push origin master:r1beta1)
* **Sysadmin** generate toolchain container for *(RELEASE)* * Update the version constants in the branch (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=b5c9e6620ee731bd33d8cb3ef6ac01749122b6b3>`_)
* **Sysadmin** begin Test Candidate builds for target architectures (x86_gcc2h, x86_64) * Update copyright years in the `bootloader menu <https://git.haiku-os.org/haiku/tree/src/system/boot/platform/generic/text_menu.cpp#n212>`_
* **Sysadmin** Test Candidate (TC) builds should be clearly labeled and made available * Tag the buildtools & point the branch to them (TODO)
* **Sysadmin** and **Release Coordinator** work in unison to merge bugfix patches to stable branches * Disable serial debug output in bootloader and kernel config file (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=81fb2084b01e87c15bdde507e024e2938af71272>`_)
* **Sysadmin** focuses on merging build fixes, etc * Turn KDEBUG_LEVEL down to 1, for performance reasons (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=6db6c0b275f684d0b25d49e87d5183e40c7cd4ec>`_)
* **Release Coordinator** focuses on reviewing bug fixes * Update Haiku's main package repos to use the branch's repo (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=ebd3fb55d9549247be65c4b62e3653f9bc1a7841>`_)
* Communication is key! * 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 <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=3d0db15a6f2963f011554f421611ee9c9b31c6f5>`_)
* 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 Testing
------- -------
@ -43,19 +61,22 @@ Testing
**Time:** ~ 2 weekes **Time:** ~ 2 weekes
* Agressively market Test Candidate builds for *(RELEASE)* * 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! * **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 Finalization
------------ ------------
**Time:** ~ 1 week **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)* * RC images all want to be *(RELEASE)*
* Any RC image can be renamed *(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! * MOAR Testing!
* When you have decided that an RC is actually the release, tag it in git
Distribution Distribution
------------ ------------
@ -67,9 +88,54 @@ Distribution
* Generate Torrents, seed. Get a few other people to seed. * Generate Torrents, seed. Get a few other people to seed.
* Place onto wasabi s3 under releases in final layout (be consistent!) * Place onto wasabi s3 under releases in final layout (be consistent!)
* Move to releases onto IPFS, pin and use pinning services * 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 * 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. * Update website references.
* Double check listed mirrors have release * Double check listed mirrors have release
* Comment out any mirrors which don't have it (a few missing is fine) * Comment out any mirrors which don't have it (a few missing is fine)
* Put release notes on proper place on website * Put release notes on proper place on website
* Release! * 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