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>

docs/develop/index.rst

@@ -39,6 +39,7 @@ Table of contents
    :caption: Contents:
 
    /build/index
+   /release/index
    /apps/haikudepot/server
    /midi/index
    /net/NetworkStackOverview

docs/develop/release/index.rst

@@ -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

docs/develop/release/milestones.rst

@@ -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!