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 i. no way to monitor QA i. not enough testing of "final" images ---- = Summary = == Release Phase : Mindset == 1. realize that there will be issues in the release 1. the release phase is for polishing the code -- not for anything to potentially destablize it 1. 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 i. Policy increases as the deadline approaches i. Main focus on testing & fixing small issues i. Will lessen the need for a Changset Reviewer * Introduce "cool down" phase i. build the final release images several days before the release date. i. 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 i. detailed checklists for testing images i. 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 i. post on mailing list & website i. 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 === * http://dev.haiku-os.org/wiki/R1/ReleaseRoadMap * stub out wiki pages (http://dev.haiku-os.org/wiki/R1/Alpha3/) i. FeatureProposals (unused in R1/A2) i. StatusAndCoordination (possibly break down to Tasks, Timeline) i. MergeTracking (hopefully not needed) i. RebuildingOptionalPackages i. QualityAssurance i. ReleaseNotes i. ReleaseAddendum i. ReportedIssues i. ImprovementsSinceRelease i. 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 i. where to send it for review * need to allow project members to review/edit it as needed. i. most information can be done beforehand -- fill in the exact dates & revision later i. organize translators == Quality Assurance == * each image type (anyboot, vmware, ...) needs to be tested for: i. booting from medium i. booting on hardware i. 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. HAIKU_DEFINES += HAIKU_OFFICIAL_RELEASE ; TARGET_DEFINES += HAIKU_OFFICIAL_RELEASE ; }}} == 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 svn.haiku-os.org * {{{ sudo bash ; export allkeys=`find /home -type f -name "authorized_key*"` ; for key in $allkeys; do cat $key >> allkeys.pub ; done }}} * Create tar.xz sources for Haiku & Buildtools * {{{ tar --exclude=.svn -cJf .tar.xz directory/ }}} * Copy all sources to http://haiku-files.org/files/releases/r1alpha2/sources/ * simply allow the .OptionalPackageDescriptions & InstallSourceArchive to point to http://haiku-files.org/files/sources ---- = Stuff to organize more = == Mirrors == === Automatic rsync mirrors === TBD === Manual upload/push mirrors === TBD === 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 == * update http://dev.haiku-os.org/wiki/R1/ReleaseRoadMap to display Release date & revision = 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 }}}