Contribution in detail

This page describes how to contribute a patch to a Mer package and how to resubmit corrected patches. It is the user facing part of the Mer change control process

Nov 2015: we've migrated from gerrit to gitlab and will follow a more github-like 'merge request' approach. The guide below is a WIP and mainly useful as an editing baseline. Talk to lbt or Stskeeps in #mer for more details.

Preparation

You'll need git and osc setup and a Mer account to use the Mer git repos. You also need to be able to perform a trial build on the Mer Community OBS.

Configure osc

The first time you try to access one of those using osc ( for example osc -A https://api.merproject.org ls ) osc will ask for a username and a password, and it will save them in the config file, which is very well commented to describe various advanced options.

This will now be scheduled for a CI build and test; then it will be
manually reviewed and hopefully, accepted.

If you are fixing a bug/request in BugZilla, include a comment to BugZilla with a link to the review URL and mark the bug as fixed.

Re-submit if original change was rejected

If your changes is rejected for some reason (a frequent occurence) then you should address the issues and resubmit.

Summary

For Mer this is done by:

Address the issue

Finding the Change-Id

amending the commit

adding a Change-Id: line

resending the change

Address review issues

The gerrit tool is used to permit reviews of your code. If the change is rejected then the tool should have a comment explaining what needs to be done to resolve the issue. Make these changes and re-test your code.

Your package should follow best practice - eg use PkgConfigBR where possible

Pay attention to rpmlintian (though we have not fully tuned it for Mer yet)

Feedback

The people reviewing your code (and yes, they are people, not sadistic monsters who enjoy laughing at your contributions ... apart from Sage) will try to give you concise and honest feedback.

Usually they'll address all the issues they see in the code so (provided no new problems are introduced) a second submission correcting the points raised should be accepted. Sometimes a second review will reveal issues missed the first time around - annoying but it happens.

Over time you will become more familiar with the review process and eventually you may start to comment on contributions yourself.