Contents

Process

We center Mer contribution around our Gerrit instance and git, http://review.merproject.org/ . Every single package is in git and the Core (+ ports) is described in xml files inside a git repository. It is possible to monitor gerrit events with 'gerrit stream-events'

Step X: Checking if it builds on it's own

3. Locally, check out git (GERRIT/project/packagename) and merge the proposed change from branch. The change ref can be found with 'ssh -p 29418 username@review.merproject.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs.

6. Wait for the end of the package build for each architecture. For a 'succeeded' build, code review with +1 "Looks good to me, but someone else must approve", for failed, code review with -1 "I would prefer that you didn't submit this" along with URL to build log. For 'excluded', report which architecture in comment with 0, no score.

3. Locally, check out git (GERRIT/project/packagename) and merge proposed change from branch. The change ref can be found with 'ssh -p 29418 username@review.merproject.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs.

6. Wait for it to finish building. If there are 'failed' packages, review to gerrit -1 "I would prefer that you didn't submit this", along with which packages it broke and URLs to their build logs, else +1 "Looks good to me, but someone else must approve"

7. If successful, pass on (method unknown so far) repository+changeset id to Core vendors for them to test as part of images, else delete repository.