Views
Release Engineering/Process
From MeeGo wiki
< Release Engineering(Difference between revisions)
(→Iteration cycle schedule) |
(→Step 1: Review by Release Engineers) |
||
| (38 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | + | == The iterative development model - weekly cycles == | |
| - | + | ||
| - | + | ||
Between releases in the active development cycle, work for MeeGo will run in weekly iterations, producing nightly builds and weekly releases from the Trunk. The resulting build from each iteration is used to track development progress. The diagram below shows the timing for the weekly cycle - unless otherwise noted in the diagram, all times are GMT. | Between releases in the active development cycle, work for MeeGo will run in weekly iterations, producing nightly builds and weekly releases from the Trunk. The resulting build from each iteration is used to track development progress. The diagram below shows the timing for the weekly cycle - unless otherwise noted in the diagram, all times are GMT. | ||
| - | + | == Development Builds == | |
Daily is the repository where the trunk output with the latest changes lands. This is the bleeding edge of development. This repository can be added to images but should be disabled by default. <br> | Daily is the repository where the trunk output with the latest changes lands. This is the bleeding edge of development. This repository can be added to images but should be disabled by default. <br> | ||
| - | |||
| - | + | == Iteration cycle schedule == | |
| - | + | MeeGo images created and delivered to [[Quality|QA]] and are non-official images. They serve to test major changes introduced into the Trunk testing. Release Engineers have the discretion to accept, reject, or queue submitted changes after the image has been finalized. Feedback may be given on the daily releases to increase the usability of the MeeGo weekly releases.<br> | |
| - | In | + | In principle, changes can still go in for the final weekly release, if the changes meet the following criteria: |
* The change is not a major API change | * The change is not a major API change | ||
* The change is not a base system or tool-chain change | * The change is not a base system or tool-chain change | ||
| - | * The change addresses a showstopper found by [[Quality | + | * The change addresses a showstopper found by [[Quality|QA]] in the image release |
* ... | * ... | ||
| - | <p>[[File: | + | <p>[[File:WeeklyReleaseCycle.png|frame|left|'''Timing for Weekly Iteration Cycle (all times GMT unless otherwise noted)''']]</p> |
<br style="clear: both" /> | <br style="clear: both" /> | ||
| Line 25: | Line 22: | ||
Integrating new code to Trunk or a release must not break the MeeGo reference images. The reference images represent product categories, SDK, and other configurations that need to be in place for MeeGo to function, development to continue, and products to use MeeGo. MeeGo will provide facilities to help developers test against the different references. <br> | Integrating new code to Trunk or a release must not break the MeeGo reference images. The reference images represent product categories, SDK, and other configurations that need to be in place for MeeGo to function, development to continue, and products to use MeeGo. MeeGo will provide facilities to help developers test against the different references. <br> | ||
| - | The first level of integration is called Staging, where developers work with the packages in OBS development projects. The package maintainer pushes the project towards the MeeGo Trunk | + | The first level of integration is called Staging, where developers work with the packages in OBS development projects. The package maintainer pushes the project towards the MeeGo Trunk:Testing projects. MeeGo will provide an automated testing facility where test cases can be contributed. This will provide results from the different MeeGo references, since in many cases it is not feasible to obtain all the different reference devices. <br> |
| - | When test results are of a sufficient standard the package maintainer pushes his/her code towards Trunk. These contributions are reviewed by the MeeGo Distribution/Platform maintainers and tested against the current Trunk. If they pass, QA packages are promoted to the Trunk. | + | When test results are of a sufficient standard, the package maintainer pushes his/her code towards the MeeGo Trunk:Testing project. These contributions are reviewed by the MeeGo Distribution/Platform maintainers and tested against the current Trunk. If they pass, QA packages are promoted to the Trunk. |
<p>[[File:MeeGoIntegrationFlow.JPG]]</p> | <p>[[File:MeeGoIntegrationFlow.JPG]]</p> | ||
| + | |||
| + | === Package quality expectation in devel:* projects === | ||
| + | |||
| + | * Package follows [[Packaging/Guidelines|packaging guidelines]] | ||
| + | * Package is compilable against [[Release_Engineering/Repo_List|target project]] | ||
| + | * Package is tested on relevant hardware platform | ||
| + | * '''If package introduces intrusive changes, maintainer should inform Release Engineering team by sending mail to meego-releases@meego.com mailing list | ||
| + | ''' | ||
| + | |||
| + | === Package quality expectations for submissions into *:Testing projects === | ||
| + | |||
| + | ==== Step 1: Review by Release Engineers ==== | ||
| + | |||
| + | * Package follows [[Packaging/Guidelines|packaging guidelines]] | ||
| + | * A new package must have a Feature in bugzilla corresponding to it. | ||
| + | ** If none exist, file a feature request through bugzilla with a description of why this package is needed in MeeGo. | ||
| + | ** This feature request must then be approved in the product management forum and set to state ACCEPTED. | ||
| + | * Package upgrades must have a Feature or Bug # corresponding to it. | ||
| + | ** If none exists, file new Bug or Feature and describe why this change is needed in MeeGo | ||
| + | ** For minor upgrades to pkgs that mostly include bug fixes, a Bug will suffice instead of a Feature. For major upgrades that include new features or major API changes, a Feature # is required. | ||
| + | * Package bug-fixes must have a Bug # corresponding to it. | ||
| + | ** If none exists, file new Bug and describe why this change is needed in MeeGo. | ||
| + | ** '''Note:''' If your package bug-fixes doesn't touch actual code, or is merely a cosmetic (configuration) change, no Bug number is required. | ||
| + | * Package is submitted from corresponding devel:* project by one of project maintainers. | ||
| + | * Package has clear change description and references to bugs and/or features (see [[Packaging/Guidelines#External_References|packaging guidelines on format]]) | ||
| + | * Bug or Feature referenced must have proper values in following fields: | ||
| + | ** Status = RESOLVED | ||
| + | ** Version = MeeGo release to which item is targeting | ||
| + | ** Target Build = MeeGo weekly build to which item is targeting | ||
| + | |||
| + | ==== Step 2: Compilation and Images ==== | ||
| + | |||
| + | * Packages should compile correctly in *:Testing repositories for all target architectures | ||
| + | * Packages should not break compilation of other dependant packages | ||
| + | * Packages should not break creation of all needed reference images | ||
| + | |||
| + | Note: Processing of requests containing packages that delve lower in the dependency hierarchy may be postponed (usually done during the weekends). This is due to the fact that processing the said package(s) will trigger a lot of rebuilds and the builders are comparatively idle during the weekends. [[Release_Engineering/lower_level_pkgs|Here]] is a sample list of 'special' packages. | ||
| + | |||
| + | ==== Step 3: Developer Submission Check-list ==== | ||
| + | |||
| + | * Here is a helpful check-list that developer's can go through before a submission. It covers all of the above in an easy-to-follow manner. It also includes a FAQ and common problems developers go through, when submitting, that can cause their request to be rejected. | ||
| + | |||
| + | [[Release_Engineering/Submission_Checklist|Developer Submission Checklist]] | ||
| + | |||
| + | === Acceptance criteria for Trunk === | ||
| + | |||
| + | * Release Engineers are responsible for smoke-testing medium and big changes on relevant hardware. | ||
| + | * Based on QA test results, accumulated changes to be promoted to Trunk (or Release), if those changes are not causing any regressions compared to Trunk (or Release) | ||
| + | |||
| + | === Release acceptance criteria === | ||
| + | |||
| + | * All required images should be built and smoke-tested by responsible release | ||
| + | * All required images should have no regressions, based on QA reports | ||
| + | ** If build has no regressions, release is made | ||
| + | ** If build contains regressions, Release Manager makes a decision based on QA reports | ||
| + | *** release with documented limitations | ||
| + | *** introduce some changes and re-iterate release procedure | ||
== Making a product out of MeeGo Release == | == Making a product out of MeeGo Release == | ||
| Line 38: | Line 92: | ||
<p>[[File:MeeGoReleaseCollaboration.JPG]]</p> | <p>[[File:MeeGoReleaseCollaboration.JPG]]</p> | ||
| + | |||
| + | [[Category:Release engineering]] | ||
Latest revision as of 18:12, 26 April 2011
Contents
|
The iterative development model - weekly cycles
Between releases in the active development cycle, work for MeeGo will run in weekly iterations, producing nightly builds and weekly releases from the Trunk. The resulting build from each iteration is used to track development progress. The diagram below shows the timing for the weekly cycle - unless otherwise noted in the diagram, all times are GMT.
Development Builds
Daily is the repository where the trunk output with the latest changes lands. This is the bleeding edge of development. This repository can be added to images but should be disabled by default.
Iteration cycle schedule
MeeGo images created and delivered to QA and are non-official images. They serve to test major changes introduced into the Trunk testing. Release Engineers have the discretion to accept, reject, or queue submitted changes after the image has been finalized. Feedback may be given on the daily releases to increase the usability of the MeeGo weekly releases.
In principle, changes can still go in for the final weekly release, if the changes meet the following criteria:
- The change is not a major API change
- The change is not a base system or tool-chain change
- The change addresses a showstopper found by QA in the image release
- ...
Timing for Weekly Iteration Cycle (all times GMT unless otherwise noted)
How the code reaches the Trunk/Release
Integrating new code to Trunk or a release must not break the MeeGo reference images. The reference images represent product categories, SDK, and other configurations that need to be in place for MeeGo to function, development to continue, and products to use MeeGo. MeeGo will provide facilities to help developers test against the different references.
The first level of integration is called Staging, where developers work with the packages in OBS development projects. The package maintainer pushes the project towards the MeeGo Trunk:Testing projects. MeeGo will provide an automated testing facility where test cases can be contributed. This will provide results from the different MeeGo references, since in many cases it is not feasible to obtain all the different reference devices.
When test results are of a sufficient standard, the package maintainer pushes his/her code towards the MeeGo Trunk:Testing project. These contributions are reviewed by the MeeGo Distribution/Platform maintainers and tested against the current Trunk. If they pass, QA packages are promoted to the Trunk.
Package quality expectation in devel:* projects
- Package follows packaging guidelines
- Package is compilable against target project
- Package is tested on relevant hardware platform
- If package introduces intrusive changes, maintainer should inform Release Engineering team by sending mail to meego-releases@meego.com mailing list
Package quality expectations for submissions into *:Testing projects
Step 1: Review by Release Engineers
- Package follows packaging guidelines
- A new package must have a Feature in bugzilla corresponding to it.
- If none exist, file a feature request through bugzilla with a description of why this package is needed in MeeGo.
- This feature request must then be approved in the product management forum and set to state ACCEPTED.
- Package upgrades must have a Feature or Bug # corresponding to it.
- If none exists, file new Bug or Feature and describe why this change is needed in MeeGo
- For minor upgrades to pkgs that mostly include bug fixes, a Bug will suffice instead of a Feature. For major upgrades that include new features or major API changes, a Feature # is required.
- Package bug-fixes must have a Bug # corresponding to it.
- If none exists, file new Bug and describe why this change is needed in MeeGo.
- Note: If your package bug-fixes doesn't touch actual code, or is merely a cosmetic (configuration) change, no Bug number is required.
- Package is submitted from corresponding devel:* project by one of project maintainers.
- Package has clear change description and references to bugs and/or features (see packaging guidelines on format)
- Bug or Feature referenced must have proper values in following fields:
- Status = RESOLVED
- Version = MeeGo release to which item is targeting
- Target Build = MeeGo weekly build to which item is targeting
Step 2: Compilation and Images
- Packages should compile correctly in *:Testing repositories for all target architectures
- Packages should not break compilation of other dependant packages
- Packages should not break creation of all needed reference images
Note: Processing of requests containing packages that delve lower in the dependency hierarchy may be postponed (usually done during the weekends). This is due to the fact that processing the said package(s) will trigger a lot of rebuilds and the builders are comparatively idle during the weekends. Here is a sample list of 'special' packages.
Step 3: Developer Submission Check-list
- Here is a helpful check-list that developer's can go through before a submission. It covers all of the above in an easy-to-follow manner. It also includes a FAQ and common problems developers go through, when submitting, that can cause their request to be rejected.
Developer Submission Checklist
Acceptance criteria for Trunk
- Release Engineers are responsible for smoke-testing medium and big changes on relevant hardware.
- Based on QA test results, accumulated changes to be promoted to Trunk (or Release), if those changes are not causing any regressions compared to Trunk (or Release)
Release acceptance criteria
- All required images should be built and smoke-tested by responsible release
- All required images should have no regressions, based on QA reports
- If build has no regressions, release is made
- If build contains regressions, Release Manager makes a decision based on QA reports
- release with documented limitations
- introduce some changes and re-iterate release procedure
Making a product out of MeeGo Release
MeeGo supports a wide range of different categories of products and the release process tries to accommodate the different requirements of each product category. The Release process takes into account the following three aspects of successful product creation:
- Fast time-to-market by supporting QA in contributed reference HW for all contributions
- Fast development cycles by providing facilities to do upstream development within MeeGo and enabling easy synchronization to weekly releases via the release preview practice
- Fully open toolset for any HW or SW vendor to use for efficient SW creation
