The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)

Contribution

From Mer Wiki
(Difference between revisions)
Jump to: navigation, search
m (Fixed Merge request workflow documentation link link)
 
(25 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 +
== How can I contribute? ==
 +
 +
The Mer project welcomes new contributors! Everybody is invited to help and make a difference. We need more people in every aspect of the project; Documentation, bug fixing, testing and development.
 +
 +
  ''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 an example list of Wiki pages that need to be accurate and one could help by executing them and reporting back any discrepancy or issue they encounter:
 +
** https://wiki.merproject.org/wiki/Nemo/Installing
 +
** https://wiki.merproject.org/wiki/Trying_it_out
 +
** https://wiki.merproject.org/wiki/Platform_SDK
 +
** https://wiki.merproject.org/wiki/Contribution_in_detail
 +
** https://wiki.merproject.org/wiki/Building_against_Mer_in_COBS
 +
** Any other page you use to accomplish something, and you discover is out of date or inaccurate. report a bug against the '''Wiki''' component in bugzilla ,once fixed, hope on #mer@freenode to get some review from the community before closing the bug.
 +
* There are also wiki pages used for brainstorming and collaborating, for example [[https://wiki.merproject.org/wiki/Website_Ideas Website Ideas]] where you can add your take, suggestions and so forth. Once you've done so hop on #mer@freenode to let the rest of community know if it needs discussion or mail the mailing list for that.
 +
* High level testing: As a user, you are encouraged to use and [[https://wiki.merproject.org/wiki/Main_Page#End_Users 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.
 +
* You are encouraged as well to test Mer releases and report bugs accordingly. You can find some insight into testing [[https://wiki.merproject.org/wiki/Quality/Test_processes here]].
 +
 +
If you like code, packaging, and are interested in contributing to 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 [[http://en.wikipedia.org/wiki/Continuous_integration 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 are interested in both, you're more than welcome to contribute to both, as many times, they harmonically coincide.
 +
 
== Contributing to packages ==
 
== Contributing to packages ==
 +
 +
NOTE: If this sections feels a bit brief there's also a page which walks through [[Contribution in detail|the change submission process in greater detail.]].
 +
 +
=== Our repositories ===
 +
 +
You can view our repositories at [http://git.merproject.org/ Mer gitlab]
  
 
=== Signed-off-by ===
 
=== Signed-off-by ===
Line 10: Line 44:
  
 
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 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 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.
 
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."
+
 
 +
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."
 
</pre>
 
</pre>
  
Line 20: Line 61:
  
 
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.
 
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 [http://code.google.com/p/gerrit/ 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 [http://monster.tspre.org:8080/ 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 [http://monster.tspre.org:8080/#settings,ssh-keys the Gerrit SSH keys page]
 
  
 
=== Making changes ===
 
=== Making changes ===
  
−
With the following command, pick out a package you'd like to contribute to - in the following denoted as REPO.
+
We use the forking workflow 'Merge Request' approach to accepting changes to packages. This is [https://git.merproject.org/help/user/project/merge_requests/authorization_for_merge_requests.md documented here] and the standard [https://git.merproject.org/help/workflow/workflow.md feature branch workflow].
−
<pre>
+
−
ssh -p 29418 USERNAME@monster.tspre.org gerrit ls-projects
+
−
</pre>
+
−
 
+
−
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:
+
−
 
+
−
<pre>
+
−
git clone ssh://USERNAME@monster.tspre.org:29418/REPO
+
−
</pre>
+
−
 
+
−
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:
+
−
 
+
−
<pre>
+
−
git push origin HEAD:refs/for/master
+
−
</pre>
+
  
−
This will now give you a review URL that you should follow for reviews.
+
When committing, remember to add '-s' option - this adds a Signed-off-by line and is required for Mer contribution and we will not accept patches without.
  
−
== Reviewing ==
+
=== Responding to reviews ===
  
−
You can help reviewing patches for Mer packages on the [http://monster.tspre.org:8080/ the Mer Gerrit]. Click "All" -> "Open" to see what patches are currently proposed.
+
You can help reviewing changes for Mer packages on the [https://git.merproject.org/groups/mer-core/merge_requests Mer Core MR page ].

Latest revision as of 08:18, 27 May 2017

Contents

[edit] How can I contribute?

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

 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 an example list of Wiki pages that need to be accurate and one could help by executing them and reporting back any discrepancy or issue they encounter:
  • There are also wiki pages used for brainstorming and collaborating, for example [Website Ideas] where you can add your take, suggestions and so forth. Once you've done so hop on #mer@freenode to let the rest of community know if it needs discussion or mail the mailing list for that.
  • 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.
  • You are encouraged as well to test Mer releases and report bugs accordingly. You can find some insight into testing [here].

If you like code, packaging, and are interested in contributing to 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 are interested in both, you're more than welcome to contribute to both, as many times, they harmonically coincide.

[edit] Contributing to packages

NOTE: If this sections feels a bit brief there's also a page which walks through the change submission process in greater detail..

[edit] Our repositories

You can view our repositories at Mer gitlab

[edit] 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.

[edit] Making changes

We use the forking workflow 'Merge Request' approach to accepting changes to packages. This is documented here and the standard feature branch workflow.

When committing, remember to add '-s' option - this adds a Signed-off-by line and is required for Mer contribution and we will not accept patches without.

[edit] Responding to reviews

You can help reviewing changes for Mer packages on the Mer Core MR page .

Retrieved from "https://wiki.merproject.org/wiki/index.php?title=Contribution&oldid=7791"
Personal tools