[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-commits
Subject:    [haiku-commits] haiku: hrev56308 - docs/develop/release
From:       Adrien Destugues <pulkomandy () pulkomandy ! tk>
Date:       2022-07-24 14:11:58
Message-ID: 20220724141158.938223FAC5 () turing ! freelists ! org
[Download RAW message or body]

hrev56308 adds 1 changeset to branch 'master'
old head: 46fdf97dea86cc469ea1653ac287489ffbe29b75
new head: 264f77da0353f78611c4bc95607ad246cbbe252a
overview: https://git.haiku-os.org/haiku/log/?qt=range&q=264f77da0353+%5E46fdf97dea86

----------------------------------------------------------------------------

264f77da0353: 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 <no-reply+buildbot@haiku-os.org>
  Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

                                   [ PulkoMandy <pulkomandy@pulkomandy.tk> ]

----------------------------------------------------------------------------

Revision:    hrev56308
Commit:      264f77da0353f78611c4bc95607ad246cbbe252a
URL:         https://git.haiku-os.org/haiku/commit/?id=264f77da0353
Author:      PulkoMandy <pulkomandy@pulkomandy.tk>
Date:        Fri Jul 15 20:11:57 2022 UTC
Committer:   Adrien Destugues <pulkomandy@pulkomandy.tk>
Commit-Date: Sun Jul 24 14:11:55 2022 UTC

----------------------------------------------------------------------------

2 files changed, 102 insertions(+), 24 deletions(-)
docs/develop/release/index.rst      | 30 +++++++----
docs/develop/release/milestones.rst | 96 +++++++++++++++++++++++++++------

----------------------------------------------------------------------------

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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic