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.

Hindsight

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

---

Summary

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

Enhancements

• 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

Pre-Branching

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
  1. new optional package
  2. show-stopping bugs/issues to resolve first
• 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

• ​http://dev.haiku-os.org/wiki/R1/ReleaseRoadMap
• stub out wiki pages (​http://dev.haiku-os.org/wiki/R1/Alpha3/)
  1. FeatureProposals (unused in R1/A2)
  2. StatusAndCoordination (possibly break down to Tasks, Timeline)
  3. MergeTracking (hopefully not needed)
  4. RebuildingOptionalPackages
  5. QualityAssurance
  6. ReleaseNotes
     • provide link to ReleaseAddendum
     • possibly link to ImprovementsSinceRelease , ReportedIssues
  7. ReleaseAddendum
  8. ReportedIssues
  9. ImprovementsSinceRelease
  10. InThePress

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

Before Tagging

This is near the end of the release cycle. Enforce a "pencils down" date -- only show-stopping issues may be resolved The attention shifts from producing code to finalizing details

Before Tagging: Tasks

1. disable serial debugging
2. remove the sleeps in the Bootscript
3. build feature-final images for testing -- the only thing to be different is the reported SVN revision in AboutSystem, Kernel, etc.
4. ensure all points of QA are completed
5. ensure all documents and related pages are ready to be rolled out

Immediately before tagging:

1. build/jam/ReleaseBuildProfiles

   # Uncomment in official release branch.
   HAIKU_DEFINES += HAIKU_OFFICIAL_RELEASE ;
   TARGET_DEFINES += HAIKU_OFFICIAL_RELEASE ;
   

Upon Tagging

1. Trac Administration
   1. create new default 'version'
   2. close current milestone
2. Internal Testing
   1. build the final-for-distribution images
   2. test the final-for-distribution images -- not all points, but more of to ensure the images are built properly & function as expected.
   3. harvest public keys from svn.haiku-os.org
   4. sudo bash ; export allkeys=`find /home -type f -name "authorized_key*"` ; for key in $allkeys; do cat $key >> allkeys.pub ; done
3. Create tar.xz sources for Haiku & Buildtools
   1. tar --exclude=.svn -cJf <archive>.tar.xz directory/
4. Copy all sources to ​http://haiku-files.org/files/releases/r1alpha2/sources/
   1. simply allow the .OptionalPackageDescriptions & InstallSourceArchive to point to ​http://haiku-files.org/files/sources
5. Place release files on baron for rsync mirrors

---

Stuff to organize more

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

Mirrors

Automatic rsync mirrors

TBD -- how to add new rsync mirrors?

Manual upload/push mirrors

TBD -- maybe we can ditch the non-rsync mirrors?

Installing files for rsync

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

baron.haiku-os.org
/srv/rsync/haiku-mirror-seed/releases/

Flipping the switch

1. update ​http://dev.haiku-os.org/wiki/R1/ReleaseRoadMap to display Release date & revision
2. Documents & articles rolled out.

Graphics

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

Website Pages

• 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.

Installing Drupal's front page graphic

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