| 12 | | = Before Branching = |
| | 17 | ---- |
| | 18 | = Summary = |
| | 19 | == Release Phase : Mindset == |
| | 20 | 1. realize that there will be issues in the release |
| | 21 | 1. the release phase is for polishing the code -- not for anything to potentially destablize it |
| | 22 | 1. there will always be another release, another opportunity to introduce new bugs |
| | 23 | == Enhancements == |
| | 24 | * Increase duration of release schedule -- eg, add more days |
| | 25 | * Stricter commit policy during schedule |
| | 26 | i. Policy increases as the deadline approaches |
| | 27 | i. Main focus on testing & fixing small issues |
| | 28 | i. Will lessen the need for a Changset Reviewer |
| | 29 | * Introduce "cool down" phase |
| | 30 | i. build the final release images several days before the release date. |
| | 31 | i. allows increased testing and less chances of major issues slipping by. |
| | 32 | * At the beginning of that phase the code base would |
| | 33 | basically be ready for the release already, including all optional packages. |
| | 34 | The main focus should be on testing and fixing small annoyances. |
| | 35 | * More organized QA process |
| | 36 | i. detailed checklists for testing images |
| | 37 | i. QA manager/coordinator |
| | 38 | |
| | 39 | |
| | 40 | ---- |
| | 41 | = Detailed Breakdown = |
| | 42 | |
| | 43 | == Pre-Branching == |
| | 44 | This is an actual phase of the release schedule. |
| | 45 | It's purpose is to grab the attention of all contributors -- committers, bug reporters, translators, everyone. |
| | 46 | * strong announcement of plan to enter release cycle mode |
| | 47 | i. post on mailing list & website |
| | 48 | i. explain new procedures in release cycle |
| | 49 | * stricter commit policy |
| | 50 | * formalization of QA |
| | 51 | * other new tasks |
| | 52 | * proposal/vote stage (for new optional packages or something else?) |
| | 53 | * allows time for developers to push any remaining drastic changesets |
| | 54 | * allows optional-packages to be rebuilt |
| | 55 | * determine & publish (tentative) release cycle timeline |
| | 56 | |
| | 57 | 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 |
| | 58 | |
| | 59 | |
| | 60 | === Pre-Branching: Tasks === |
| 14 | | * & create related TracWiki pages |
| 15 | | * Feature Proposals |
| 16 | | * Status and Task Coordination |
| 17 | | * Release Notes |
| 18 | | * ( Important Addendum ) |
| 19 | | * Rebuilding Optional Package Tracker |
| 20 | | * In the Press |
| 21 | | * Reported Issues |
| 22 | | * Improvements Since Release |
| | 62 | * stub out wiki pages (http://dev.haiku-os.org/wiki/R1/Alpha3/) |
| | 63 | i. FeatureProposals (unused in R1/A2) |
| | 64 | i. StatusAndCoordination (possibly break down to Tasks, Timeline) |
| | 65 | i. MergeTracking (hopefully not needed) |
| | 66 | i. RebuildingOptionalPackages |
| | 67 | i. QualityAssurance |
| | 68 | i. ReleaseNotes |
| | 69 | i. ReleaseAddendum |
| | 70 | i. ReportedIssues |
| | 71 | i. ImprovementsSinceRelease |
| | 72 | i. InThePress |
| 34 | | == a checklist of features to test == |
| 35 | | * booting & installing CD/DVD |
| 36 | | * bash script to run each and every application, to check for non-zero exit code |
| 37 | | {{{ |
| 38 | | #!/bin/bash |
| 39 | | # not functional code |
| 40 | | for binary in $AllBinaries; do |
| 41 | | ( ${binary} --help &> /dev/null ) || ( echo ${binary} exitted $? >> non-zero.log ) |
| 42 | | done |
| 43 | | }}} |
| | 91 | == Quality Assurance == |
| | 92 | * each image type (anyboot, vmware, ...) needs to be tested for: |
| | 93 | i. booting from medium |
| | 94 | i. booting on hardware |
| | 95 | i. installation from all mediums |
| | 96 | * testing of all optional packages for missing dependencies |
