The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Process
(→Contribution model (abstracted)) |
|||
| Line 40: | Line 40: | ||
4. Code change gets merged (manually or automatically) | 4. Code change gets merged (manually or automatically) | ||
| + | |||
| + | == Automation: When a proposed change comes in == | ||
| + | |||
| + | === 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 | ||
| + | |||
| + | ==== 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 | ||
Revision as of 11:52, 21 October 2011
Contents |
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
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
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
