|Version 5 (modified by 9 years ago) ( diff ),|
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
- no way to monitor QA
- not enough testing of "final" images
Release Phase : Mindset
- realize that there will be issues in the release
- the release phase is for polishing the code -- not for anything to potentially destablize it
- 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
- Policy increases as the deadline approaches
- Main focus on testing & fixing small issues
- Will lessen the need for a Changset Reviewer
- Introduce "cool down" phase
- build the final release images several days before the release date.
- 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
- detailed checklists for testing images
- QA manager/coordinator
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
- post on mailing list & website
- explain new procedures in release cycle
- stricter commit policy
- formalization of QA
- other new tasks
- proposal/vote stage
- new optional package
- 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
- stub out wiki pages (http://dev.haiku-os.org/wiki/R1/Alpha3/)
- FeatureProposals (unused in R1/A2)
- StatusAndCoordination (possibly break down to Tasks, Timeline)
- MergeTracking (hopefully not needed)
- provide link to ReleaseAddendum
- possibly link to ImprovementsSinceRelease , ReportedIssues
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
- where to send it for review
- need to allow project members to review/edit it as needed.
- most information can be done beforehand -- fill in the exact dates & revision later
- organize translators
- where to send it for review
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
- disable serial debugging
- remove the sleeps in the Bootscript
- build feature-final images for testing -- the only thing to be different is the reported SVN revision in AboutSystem, Kernel, etc.
- ensure all points of QA are completed
- ensure all documents and related pages are ready to be rolled out
Immediately before tagging:
# Uncomment in official release branch. HAIKU_DEFINES += HAIKU_OFFICIAL_RELEASE ; TARGET_DEFINES += HAIKU_OFFICIAL_RELEASE ;
- Trac Administration
- create new default 'version'
- close current milestone
- Internal Testing
- build the final-for-distribution images
- test the final-for-distribution images -- not all points, but more of to ensure the images are built properly & function as expected.
- 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 <archive>.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
- Place release files on baron for rsync mirrors
Stuff to organize more
- each image type (anyboot, vmware, ...) needs to be tested for:
- booting from medium
- booting on hardware
- installation from all mediums
- testing of all optional packages for missing dependencies
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
- update http://dev.haiku-os.org/wiki/R1/ReleaseRoadMap to display Release date & revision
- Documents & articles rolled out.
- HAIKU logo with ladybugs & stamp
- Installer logo
- Desktop logo (though, do not enable it)
- Frontpage download graphic
- CD/DVD graphic
- Official Article
- 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