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
===================
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 <https://dev.haiku-os.org>`_
* 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
* 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

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

@ -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 <https://dev.haiku-os.org/wiki/R1/ReleaseRoadMap>`_ 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 <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=b5c9e6620ee731bd33d8cb3ef6ac01749122b6b3>`_)
* Update copyright years in the `bootloader menu <https://git.haiku-os.org/haiku/tree/src/system/boot/platform/generic/text_menu.cpp#n212>`_
* Tag the buildtools & point the branch to them (TODO)
* Disable serial debug output in bootloader and kernel config file (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=81fb2084b01e87c15bdde507e024e2938af71272>`_)
* Turn KDEBUG_LEVEL down to 1, for performance reasons (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=6db6c0b275f684d0b25d49e87d5183e40c7cd4ec>`_)
* Update Haiku's main package repos to use the branch's repo (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=ebd3fb55d9549247be65c4b62e3653f9bc1a7841>`_)
* 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
-------
@ -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