Views
Release Engineering/Software update process
(→MeeGo 1.1 Update Release Plan) |
(→MeeGo 1.1 Update Release Plan) |
||
| Line 84: | Line 84: | ||
|- | |- | ||
|3 | |3 | ||
| - | |2011.02. | + | |2011.02.28 |
| + | |http://repo.meego.com/MeeGo/updates/1.1/ | ||
| + | |http://meego.com/downloads/releases/updates/meego-v1.1.3-core-update http://meego.com/downloads/releases/updates/meego-v1.1.3-netbook-update | ||
| + | |- | ||
| + | |4 | ||
| + | |2011.04.08 | ||
|http://repo.meego.com/MeeGo/updates/1.1/ | |http://repo.meego.com/MeeGo/updates/1.1/ | ||
| | | | ||
Revision as of 07:08, 2 March 2011
Contents |
Overview
- Target for monthly service pack update
- Incremental software update between service packs should be available
- Monthly service pack update is a full update. It aggregates all previous service packs and incremental updates
- Schedule budgeting for monthly update cadence:
- Week 0 – CCB (change control board) team setup and triage process to create draft update bug list
- Week 1 – final update bug list approved. Development starts from day 1.
- Week 2 ~Week 3 –bug fixes and testing. End of week 3 - code freeze, final repo release to QA.
- Week 4 – Release engineering, package signing, deployment testing. Release update by end of the week 4.
Work Flow
How the code reaches the update
How a bug becomes an update release blocker
Software update content is managed by bugzilla. Only the fixes for bugs with flag MeeGo_Update_Release_Blocker = Approved can be accepted into an update. If you want to include one bug fix into an update, you should first propose it with MeeGo_Update_Release_Blocker = Proposed. Then CCB will review and decide whether it’s a real update release blocker or not by setting MeeGo_Update_Release_Blocker to Approved or Rejected. Generally, the approved update release bugs must be fixed and verified in MeeGo Trunk firstly. For detailed criteria, please see http://wiki.meego.com/Quality/How_To_Report_Bugs#MeeGo_update_bug_fix_acceptance_criteria.
Maintainers to handle requests submitted to update projects
- MeeGo OBS projects for 1.1 software update are:
- MeeGo:1.1:Core:Update:Testing
- MeeGo:1.1:Netbook:Update:Testing
- MeeGo:1.1:IVI:Update:Testing
- MeeGo:1.1:Core:Update
- MeeGo:1.1:Netbook:Update
- MeeGo:1.1:IVI:Update
- All requests should be submitted to *:Update:Testing projects, and from a branched home project.
- The changelog should specify a valid bug number for current update release. A valid bug means it must have proper values in following fields:
- MeeGo_Update_Release_Blocker = Approved
- MeeGo Release = Release version to which item is targeting
- Update Release = Monthly update release version to which item is targeting
- Status = RESOLVED
- The request should also follow any other common MeeGo requirments for a request.
Compile packages
- Packages should compile correctly in *:Testing repositories for all target architectures.
- Packages should not break compilation of other dependant packages.
Create testing repo
With some packages accepted, the release engineer will create a testing repo for internal release. The release is of form of repo with all updated packages. Such a repo is very unique in that
- It has metadata of update info containing all information of available patches. The objective of patches is to provide a maintenance point of view over the updated packages (as multiple packages could be involved in one issue).
- The update repo is incremental. It means end user can update from any formal MeeGo state. For example we have reached update release 2. Users can update to this state from MeeGo 1.1 release or update release 1 without any broken.
The testing repo should be smoke-tested by responsible release engineer before it is released for QA and other users’ testing. The testing repo will be uploaded to http://repo.meego.com/MeeGo/builds/1.1/. The release engineer will post announcement of the repo updates on “meego-releases” mailing list. If the end users run into any issues about the update, please file a bug on bugzilla. QA will do testing and give quality report for the build.
Create final repo
For each milestone, after all testing repo has been tested, the release engineer will push all changes in *:Update:Testing projects to *:Update projects, and create the final release repo from *:Update projects.
Release acceptance criteria
- Each internal release repo should be passed to QA to verify functionality of the build
- The final release repo should have no regressions, based on QA reports
- If build has no regressions, release is made
- If build contains regressions, based on QA reports Release Manager makes a decision
- release with documented limitations
- introduce some changes and re-iterate release procedure