Views
Release Engineering/Software update process
From MeeGo wiki
< Release Engineering(Difference between revisions)
(→MeeGo 1.1 Update Release Plan) |
(→MeeGo 1.1 Update Release Plan) |
||
| (8 intermediate revisions not shown) | |||
| Line 5: | Line 5: | ||
* Monthly service pack update is a full update. It aggregates all previous service packs and incremental updates | * Monthly service pack update is a full update. It aggregates all previous service packs and incremental updates | ||
* Schedule budgeting for monthly update cadence: | * Schedule budgeting for monthly update cadence: | ||
| - | ** Week 0 – CCB (change control board) team setup and triage process to create draft update bug list | + | ** Week 0 – CCB (change control board) team setup and triage process to create draft update bug list. |
| - | ** Week 1 – | + | ** Week 1 – Final update bug list approved. Development starts from day 1. |
| - | ** Week 2 ~Week 3 | + | ** 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. | ** Week 4 – Release engineering, package signing, deployment testing. Release update by end of the week 4. | ||
| Line 19: | Line 19: | ||
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. | 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 | + | Generally, the approved update release bugs must first be fixed and verified in MeeGo Trunk. For detailed criteria, please see http://wiki.meego.com/Quality/Bug_Life_Cycle_and_Handling#MeeGo_update_bug_fix_acceptance_criteria. |
=== Maintainers to handle requests submitted to update projects === | === Maintainers to handle requests submitted to update projects === | ||
| Line 36: | Line 36: | ||
** Update Release = Monthly update release version to which item is targeting | ** Update Release = Monthly update release version to which item is targeting | ||
** Status = RESOLVED | ** Status = RESOLVED | ||
| - | * The request should also follow any other common MeeGo | + | * The request should also follow any other common MeeGo requirements for a request. |
=== Compile packages === | === Compile packages === | ||
| Line 47: | Line 47: | ||
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 | 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). | * 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 | + | * 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 breakage. |
| - | The testing repo should be smoke-tested by | + | The testing repo should be smoke-tested by the release engineer responsible 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 | + | The testing repo will be uploaded to http://repo.meego.com/MeeGo/builds/1.1/. The release engineer will post announcements 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 test it and provide a quality report for the build. |
=== Create final repo === | === Create final repo === | ||
| Line 89: | Line 89: | ||
|- | |- | ||
|4 | |4 | ||
| - | |2011.04. | + | |2011.04.11 |
|http://repo.meego.com/MeeGo/updates/1.1/ | |http://repo.meego.com/MeeGo/updates/1.1/ | ||
| - | | | + | |http://meego.com/downloads/releases/updates/meego-v1.1.4-core-update http://meego.com/downloads/releases/updates/meego-v1.1.4-netbook-update |
| + | |- | ||
| + | |5 | ||
| + | |2011.05.20 | ||
| + | |http://repo.meego.com/MeeGo/updates/1.1/ | ||
| + | |http://meego.com/downloads/releases/updates/meego-v1.1.5-core-update http://meego.com/downloads/releases/updates/meego-v1.1.5-netbook-update | ||
|- | |- | ||
|To be updated | |To be updated | ||
| Line 98: | Line 103: | ||
| | | | ||
|} | |} | ||
| + | |||
| + | [[Category:Release engineering]] | ||
Latest revision as of 02:17, 27 May 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 first be fixed and verified in MeeGo Trunk. For detailed criteria, please see http://wiki.meego.com/Quality/Bug_Life_Cycle_and_Handling#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 requirements 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 breakage.
The testing repo should be smoke-tested by the release engineer responsible 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 announcements 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 test it and provide a 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