The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Process
From Mer Wiki
(Difference between revisions)
(New page: == 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 o...) |
|||
| Line 1: | Line 1: | ||
| − | |||
== Mer process == | == Mer process == | ||
| Line 17: | Line 16: | ||
1. Clone git repository | 1. Clone git repository | ||
| + | |||
2. Do changes to package | 2. Do changes to package | ||
| + | |||
3. Commit with signed-off-by in commit message | 3. Commit with signed-off-by in commit message | ||
| + | |||
4. Submit patch to review site | 4. Submit patch to review site | ||
| + | |||
5. Receive reviews and correct problems, until approved and merged to git repository | 5. Receive reviews and correct problems, until approved and merged to git repository | ||
| Line 25: | Line 28: | ||
1. Read automatic reviews of code change on review site | 1. Read automatic reviews of code change on review site | ||
| + | |||
2. Perform own review and comment on review site | 2. Perform own review and comment on review site | ||
| Line 30: | Line 34: | ||
1. Read manual and automatic reviews | 1. Read manual and automatic reviews | ||
| + | |||
2. Optionally do own review | 2. Optionally do own review | ||
| − | 3. Approve/decline on site | + | |
| − | 4. Code change gets merged | + | 3. Approve/decline contribution on site |
| + | |||
| + | 4. Code change gets merged (manually or automatically) | ||
Revision as of 13:56, 20 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
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)
