Quality/TestSuite/MCTS/MCTS Release Process

Latest revision as of 05:09, 13 May 2011

Overview

The MCTS release consists of the MCTS codebase, related API coverage analysis documents in Gitorious and documentation in MeeGo Wiki. For each release, a release note is composed, which indicates the changes in the release and known issues.

The MCTS codebase consists of packages. For each package, there is a named maintainer who is responsible to ensure that the quality criteria is met for the package for a release. Typically, one maintainer is responsible for multiple packages. The maintainer must also ensure that the package is mergeable to the MCTS master tree at release time. The maintainer is also responsible to ensure that the API coverage analysis documentation is updated and available for the release, as well as the related documentation at MeeGo Wiki.

The package maintainer manages his/hers set of packages in a separate clones. Before release, the maintainer issues a merge request to MCTS code main git-tree. In addition, the package maintainer is responsible to manage a set of related API coverage analysis documents in Gitorious using separate clones. At release time, the maintainer issues merge requests MCTS coverage main git-tree.

The MCTS maintainer is responsible to create an MCTS release. To achieve this, the MCTS maintainer merges the pending merge requests at release time, pushes the merged codebase to MCTS main git-tree, does the same for coverage analysis documents, tags both git-trees and finalises the release page in MCTS Wiki.

Release dates

The release dates are preagreed so that the packet maintainers have sufficient time to prepare for the release. The MCTS release page contains information about the planned and past releases, including proposed and actual release dates, proposed and actual release content as well as known issues and notes of a release.

The merge window for a release is closed at 12:00 UTC on the indicated release date. After closing, the final merge and release note changes are completed.

The releases happen roughly biweekly and the next release date and initial content proposal appears shortly when ongoing release is completed. Should there be need to change the release date, please propose a new date to all packet maintainers and the MCTS maintainer.

Release content

The content of the MCTS release shall be planned as detailed as possible. The content of the next release is described in MCTS Releases page. The packet maintainers add their plans to the page promptly after next release appears to the MCTS Releases page. Should there be deviations against the plan, the changes need to be updated to the planned release.

Quality criteria

The test code needs to be developed according to MeeGo Core Test Suites Development Guidelines.

+ Merge requests can be applied without conflict
+ The tests.xml files exist and validate against newest schema
+ The MCTS release page is updated to reflect the content of the merge request
+ The latest release commit is reachable from merge request commit
+ The source package can be build and generate a rpm package
+ The rpm package can be installed to a target platform
+ The test asset be run with testrunner-lite
+ The release content can be inserted to MeeGo OBS
+ The test asset should update changelog and version number when it has checkin

Status

Please note that the MCTS release process is evolving and not all details are complete. Feel free to suggest any improvements to the process.