Contribution

Revision as of 19:32, 3 August 2012

How can I contribute?

The Mer project welcomes new contributors! Everybody are invited to help and make a difference. We need more people in every aspect of the project; Development, bug fixing, documentation, testing etc.

 Every contribution counts.

If you like wikis, writing documentation, working with the community and supporting the non coding efforts part of the Mer project you can make a difference by:

• Wiki gardening: The Wiki is our main source of documentation, and as the project is making quick progress it is a rapidly moving target. Keeping the Wiki up to date to represent the current state of affairs in all aspect of the project is a challenge with extreme importance. Here's a list of Wiki pages that need to be accurate and one could help by executing them and reporting back any discrepancy or issue you encounter:
  • https://wiki.merproject.org/wiki/Platform_SDK
• High level testing: As a user, you are encouraged to use and [end user product] handset vertical and report back issues both to NemoMobile and Mer project, as per the components affected. If in doubt feel always welcome to hop on #nemomobile@freenode and ask around to know whom to contact about an issue.

If you like code, packaging, and interested in contributing at the project code development take a look here to whet your appetite:

  https://bugs.merproject.org/buglist.cgi?keywords=easyFix&resolution

Issues tagged easyFix are those that should be relatively easy to fix and will get you up and running running with the contribution model and workflow. This usually means proposing a patch to a package, having it reviewed in the [continues integration system] and eventually have it accepted and built onto the package repository.

To get more details about code contributions, read on, as the next sections elaborate just on that.

If you can, and interested in both, you're more than welcome to contribute to both, as many times, they harmonically coincide.

Contributing to packages

Our repositories

You can view our repositories at Mer gitweb

Signed-off-by

The Mer project uses the signed-off-by language and process, used by the Linux kernel, to give us a clear chain of trust for every patch received.

Linux Kernel Certificate of Origin v 1.1
"By making a contribution to this project, I certify that:

The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the
right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license 
(unless I am permitted to submit under a different license), as indicated in the file; or

The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

I understand and agree that this project and the contribution are public and that a record of the contribution
(including all personal information I submit with it, including my sign-off) is maintained indefinitely
and may be redistributed consistent with this project or the open source license(s) involved."

We have the same requirements for using the signed-off-by process as the Linux kernel has.

In short, you need to include a signed-off-by tag in every patch:

Signed-off-by: this is a developer's certification that he or she has the right to submit the patch for inclusion into the project. It is an agreement to the Developer's Certificate of Origin (above). Code without a proper signoff cannot be merged into the mainline.

Initial setup

Mer uses the Gerrit code review system and has all packages in the Core stored within git repositories.

First thing you should do is to register yourself on the Mer Gerrit and assign yourself a username, in the following referred to as USERNAME. You can use a Google account or OpenID to authenticate yourself.

You then need to generate yourself a SSH key and upload it on the Gerrit SSH keys page

Making changes

With the following command, pick out a package you'd like to contribute to - in the following denoted as REPO.

ssh -p 29418 USERNAME@review.merproject.org gerrit ls-projects

NOTE: If you receive this error 'Agent admitted failure to sign using the key. Permission denied (publickey)' use the ssh-add command.

Prominent examples are:

mer/release-tools - Release tools and fakeobs

mer/project-core - Project core description, configurations and package contents (like what git corresponds to what revision)

Then check out the git repository:

git clone ssh://USERNAME@review.merproject.org:29418/REPO

Now do your changes to the repository as if you were working with a git repository, git add/rm/commit. When committing, remember to add '-s' option - this adds a Signed-off-by line and is required for Mer contribution and Gerrit will not accept patches without.

When your change is ready for commit:

git push origin HEAD:refs/for/master

This will now give you a review URL that you should follow for reviews.

Responding to reviews

There is bound to be a lot of things wrong with your submission, so here is how you make and send an updated change for review.

First, do your modifications, git add, git rm, etc.

Then, you will need to amend your changes to your previous commit:

• First off, visit the page for your change, and copy the field called 'Change-id:', you will need this. In the following this is called CHANGEID
• Run the following command:

git commit -s --amend

Below the signed-off-by header, add the following

Change-Id: CHANGEID

Save and exit the editor. Now as before, send the change to Gerrit:

When your change is ready for commit:

git push origin HEAD:refs/for/master

This will then mean that your new patchset will be appearing at the same review page as before, in the updated form.

Reviewing

You can help reviewing patches for Mer packages on the the Mer Gerrit. Click "All" -> "Open" to see what patches are currently proposed.

Difference to previous patchset

You can use "Old Version History:" dropdown to get diff according to previous patchset.