Version 4 (modified by mmadia, 10 years ago) ( diff )

saving in-progress thoughts. more to come today.

These are some notes pertaining to the R1 Alpha 2 release cycle.

The order is semi-random. Feel free to make additions.

For now, it's on this page & in the future it may be moved elsewhere or deleted entirely.


These are some general points of the R1/A2 release

  • rushed feeling
  • too many drastic changesets being committed
  • large overhead of reviewing changesets
  • no formal QA
    1. no way to monitor QA
    2. not enough testing of "final" images


Release Phase : Mindset

  1. realize that there will be issues in the release
  2. the release phase is for polishing the code -- not for anything to potentially destablize it
  3. there will always be another release, another opportunity to introduce new bugs


  • Increase duration of release schedule -- eg, add more days
  • Stricter commit policy during schedule
    1. Policy increases as the deadline approaches
    2. Main focus on testing & fixing small issues
    3. Will lessen the need for a Changset Reviewer
  • Introduce "cool down" phase
    1. build the final release images several days before the release date.
    2. allows increased testing and less chances of major issues slipping by.
  • At the beginning of that phase the code base would

basically be ready for the release already, including all optional packages. The main focus should be on testing and fixing small annoyances.

  • More organized QA process
    1. detailed checklists for testing images
    2. QA manager/coordinator

Detailed Breakdown


This is an actual phase of the release schedule. It's purpose is to grab the attention of all contributors -- committers, bug reporters, translators, everyone.

  • strong announcement of plan to enter release cycle mode
    1. post on mailing list & website
    2. explain new procedures in release cycle
      • stricter commit policy
      • formalization of QA
      • other new tasks
  • proposal/vote stage (for new optional packages or something else?)
  • allows time for developers to push any remaining drastic changesets
  • allows optional-packages to be rebuilt
  • determine & publish (tentative) release cycle timeline

The needs to be ample time between the decision of when to branch and the actual branching . This is especially important for R1/A3, as there have been numerous API changes and 3rd party software may need to be updated to work properly

Pre-Branching: Tasks

Upon Branching

This is the official start of the release cycle. Enforce a stricter commit policy

  • only minor changes to fix reported bugs
  • optional packages can only be fixed -- not updated simply for the sake of it
  • reduces the need of a formal "Changset Reviewer" or branch maintainer
  • reduces the chance of destablizing release

Upon Branching: Tasks

  • MergeTracking script (hopefully not needed)
  • Organize the press release
    1. where to send it for review
      • need to allow project members to review/edit it as needed.
    2. most information can be done beforehand -- fill in the exact dates & revision later
    3. organize translators

Quality Assurance

  • each image type (anyboot, vmware, ...) needs to be tested for:
    1. booting from medium
    2. booting on hardware
    3. installation from all mediums
  • testing of all optional packages for missing dependencies

Before Tagging: Tasks

This is near the end of the release cycle. The attention shifts from producing code to finalizing details

  • disable serial debugging
  • remove the sleeps in the Bootscript
  • build/jam/ReleaseBuildProfiles
    # Uncomment in official release branch.

After Tagging

  • Trac Administration
    • create new default 'version'
    • close current milestone
  • create the following wiki pages
    • InThePress
    • ReportedIssues
    • ImprovementsSinceRelease
  • Internal Testing
    • harvest public keys from
    • sudo bash ; export allkeys=`find /home -type f -name "authorized_key*"` ; for key in $allkeys; do cat $key >> ; done
  • Create tar.xz sources for Haiku & Buildtools
    • tar --exclude=.svn -cJf <archive>.tar.xz directory/
  • Copy all sources to

Stuff to organize more


Automatic rsync mirrors


Manual upload/push mirrors


Installing files for rsync

Include all image archive files, md5sums.txt, *.torrent, sources/

Flipping the switch


  • Stamp
  • HAIKU logo with ladybugs & stamp
  • Installer logo
  • Desktop logo (though, do not enable it)
  • Frontpage download graphic
  • CD/DVD graphic

Website Pages

Installing Drupal's front page graphic

sudo bash
cd /srv/www/drupal/
mv bg-download-box.png GET-HAIKU-download-box-r1a1.png
cp GET-HAIKU-download-box-r1a2.png bg-download-box.png
Note: See TracWiki for help on using the wiki.