Process

Revision as of 13:20, 21 October 2011

Mer process

We have:

• A large amount of git repositories, with branches "master" (Trunk) and potentially release branches (Mer_1.0, Mer_2.0)
• Each of these repositories checks out to be a .spec package, with tarball included, including _meta (OBS meta information) and _attribute (attributes)
• "Core" git repository, which contains .xml files and other OBS configuration along with pointers to specific git repositories and commit IDs representing current state of Mer Core

We want to:

• Make sure that every Mer release is release-able through continuous integration and QA
• Provide a easy contribution model with fast feedback on changes
• Have a distributed model of performing these QA checks, so we can easily scale operations and include donated hardware

Contribution model (abstracted)

1. Clone git repository for package

2. Do changes to package

3. Commit with signed-off-by in commit message

4. Submit patch to review site

5. Receive reviews and correct problems, until approved and merged to git repository

Reviewer model (abstracted)

1. Read automatic reviews of code change on review site

2. Perform own review and comment on review site

Maintainer model (abstracted)

1. Read manual and automatic reviews

2. Optionally do own review

3. Approve/decline contribution on site

4. Code change gets merged (manually or automatically)

Automation: When a proposed change comes in

After 48 hours of reviews, if there has been reviews enough, automation will mark change as verified

Packaging checks

Check if the proposed change is acceptable according to packaging guidelines, report back as code reviews

Single-build test

Test if the proposed change builds on it's own, report back as code reviews

Dependency-build test

Test if the proposed change will break other packages in the Core by compiling the package and everything that depends on it (directly and indirectly), report back as code reviews

ABI checks

Test if the changed package causes any kind of breakage in ABI, utilizing http://forge.ispras.ru/projects/abi-compliance-checker

Image creation test

Test if the repository result of the dependency-build test will create a image succesfully, based on the core reference kickstart files, report back as code reviews

Vendor verification

Notify to vendor community that a change is needed to be checked, provide results of dependency-build test

Vendor automation

Upgradeability check

Take packages from dependency-build test and attempt an upgrade, report back as code reviews