Views
Release Engineering/Process
Contents |
Release Process
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.
The preview repository holds a snapshot of the Trunk and is used for the weekly preview and final image preparation. The preview repository is generated on Friday from the Trunk and is frozen until the next snapshot is taken on Tuesday for the final release. Parties working with code that depends on MeeGo, but is not included in it, can use the Friday preview to check the compatibility and fix critical issues for the weekly release.
Iteration cycle schedule
Preview images created and delivered to QA on Friday are non-official images. They serve to test major changes introduced into the Trunk and to provide a preview of the weekly image. Release Engineers have the discretion to accept, reject or queue submitted changes after the preview has been finalized. Feedback may be given to ensure the usability of the upcoming weekly releases for the users of MeeGo.
In principal, 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 preview release
- ...
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/Release. 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 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.
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
