Release Engineering/Process

Contents 1 Release Process 1.1 The iterative development model - weekly cycles 1.2 Development Builds 1.3 Iteration cycle schedule 2 How the code reaches the Trunk/Release 2.1 Acceptance Criteria for devel:* 2.2 Acceptance criteria for *:Testing 2.2.1 Step 1: Review by Release Engineers 2.2.2 Step 2: Compilation and Images 2.3 Acceptance criteria for Trunk 2.4 Release acceptance criteria 3 Making a product out of MeeGo Release

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 the 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.

Acceptance Criteria for devel:*

• Package is compilable against target project
• Package is following packaging guidelines

Acceptance criteria for *:Testing

Step 1: Review by Release Engineers

• Package is following packaging guidelines
• Package is submitted from corresponding devel:* project by one of project maintainers
• Package has clear description and references to bugs and/or features
• Bug or Feature 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 packages
• Packages should not break creation of all needed reference images

Acceptance criteria for Trunk

• 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

Release acceptance criteria

• TODO

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:

1. Fast time-to-market by supporting QA in contributed reference HW for all contributions
2. Fast development cycles by providing facilities to do upstream development within MeeGo and enabling easy synchronization to weekly releases via the release preview practice
3. Fully open toolset for any HW or SW vendor to use for efficient SW creation