docs/develop: Introduce release engineering documentation
* This has been floating around on trac forever. We should formalize these steps to help future Haiku releases to be successful. Change-Id: I5881e27a23e66a18539d04c5977593a827f8fcef Reviewed-on: https://review.haiku-os.org/c/haiku/+/5441 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit is contained in:
Alexander von Gluck IV
waddlesplash
parent
c8641d3a23
commit
fd482d0a57
@ -39,6 +39,7 @@ Table of contents
|
||||
:caption: Contents:
|
||||
|
||||
/build/index
|
||||
/release/index
|
||||
/apps/haikudepot/server
|
||||
/midi/index
|
||||
/net/NetworkStackOverview
|
||||
|
||||
42
docs/develop/release/index.rst
Normal file
42
docs/develop/release/index.rst
Normal file
@ -0,0 +1,42 @@
|
||||
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.
|
||||
|
||||
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.
|
||||
* 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
|
||||
* Timeline proposals are proposed via the haiku-development mailing list
|
||||
|
||||
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.
|
||||
|
||||
* Final date for enhancements in (RELEASE)
|
||||
* Branch buildtools for (RELEASE)
|
||||
* Branch haiku for (RELEASE)
|
||||
* Setup CI/CD pipelines for (RELEASE)
|
||||
* Generate first test candidates (TC0, TC1, etc), encourage extreme testing.
|
||||
* Begin accepting bugfixes in branches via code review
|
||||
* Final translations synchronization
|
||||
* Generate first release candidates (RC0, RC1, etc), encourage testing.
|
||||
* Profit
|
||||
|
||||
* R1/Beta 2's timeline from branch to release was roughly 35 days
|
||||
* R1/Beta 3's timeline from branch to release was roughly 50 days.
|
||||
|
||||
Release dates can slide, it's ok.
|
||||
We just try to slide pragmatically (+1 week because of X,Y,Z)
|
||||
|
||||
.. toctree::
|
||||
|
||||
milestones
|
||||
75
docs/develop/release/milestones.rst
Normal file
75
docs/develop/release/milestones.rst
Normal file
@ -0,0 +1,75 @@
|
||||
Critical Milestones
|
||||
===================
|
||||
|
||||
Community Concensus
|
||||
-------------------
|
||||
|
||||
* Determine a release is needed
|
||||
* Gain support in the community
|
||||
* Raise release proposal on mailing list (haiku-development)
|
||||
* Elect Release Coordinator
|
||||
* Plan timeline (which should be made up of milestones below)
|
||||
* Allow one week RFC time for comments
|
||||
|
||||
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
|
||||
* Final ICU upgrades, webkit upgrades, etc.
|
||||
* Plan for release logo used in installer (always fun, lots of bikeshed)
|
||||
* Be working on release notes!
|
||||
|
||||
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!
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
**Time:** ~ 2 weekes
|
||||
|
||||
* Agressively market Test Candidate builds for *(RELEASE)*
|
||||
* Bugs opened on trac under *new* version. Squash bugs
|
||||
* **Release Coordinator** should be downright obnoxious about people testing TC images!
|
||||
|
||||
Finalization
|
||||
------------
|
||||
|
||||
**Time:** ~ 1 week
|
||||
|
||||
* Everything going well? Produce Release Candidate images
|
||||
* RC images all want to be *(RELEASE)*
|
||||
* Any RC image can be renamed *(RELEASE)*
|
||||
* Ensure release notes are almost done.
|
||||
* MOAR Testing!
|
||||
|
||||
Distribution
|
||||
------------
|
||||
|
||||
**Time:** ~ 1 week
|
||||
|
||||
* You now have the release images in hand! (RCX is secretly the release)
|
||||
* Keep it to yourself and don't tell people
|
||||
* 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
|
||||
* Give mirrors time to... mirror via rsync
|
||||
* 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!
|
||||
Loading…
Reference in New Issue
Block a user