Login to OSM portal

Go to OSM portal: https://osm.etsi.org/
Login using your username and password

Note:

If you are contributing on behalf of your company, you should login with your ETSI Online Account (EOL).
- If your company is not yet an OSM Member or Participant, you can check here how to join OSM as an organization
- If your company has already joined OSM but you do not have an EOL account yet, you can request an EOL account

If you are an individual contributor, you can create your OSM account online.

If you need any help, contact us at OSMsupport@etsi.org

Report a bug on Bugzilla

Go to the OSM Portal
Click on Bugzilla menu on the portal menu bar.
Click on "new" on Bugzilla menu bar.
Choose the product, e.g. "OSM".
Complete the bug form. If you know, choose the component, e.g. UI, SO, RO, Documentation/Wiki, etc.
Enter the bug summary, description, attachement, etc.
Click on the "Submit Bug" button to confirm.
A bug id is generated (e.g. Bug 6 -Small Error)

Clone your project

Clone a git repository, for example:

 git clone https://osm.etsi.org/gerrit/osm/RO.git

Enter your username
Enter you password
It is recommended to install the Gerrit commit-msg hook for the cloned repository in order to automatically insert a Change-Id tag in commit messages. You can install it by entering the following command for RO repository
```
 curl -Lo RO/.git/hooks/commit-msg http://osm.etsi.org/gerrit/tools/hooks/commit-msg 
```
You then need to make the hook executable
```
 chmod u+x RO/.git/hooks/commit-msg 
```
More information about the Gerrit commit-msg hook can be found here https://git.eclipse.org/r/Documentation/cmd-hook-commit-msg.html

Note:

You can find all the project repository URLs on Gitweb or on Gerrit
- On Gitweb
  1. Click on Gitweb menu on the portal menu bar.
  2. Select a product to see the available cloning URLs
- On Gerrit
  1. Click on Gerrit menu on the portal menu bar.
  2. Click on "Projects" menu on the Gerrit menu bar.
  3. Click on "List" menu.
  4. Select a product to see the available cloning URLs.

Configure your Git environment

Configure your git username globally:

 git config --global user.name <username>

Configure your git email address:

 git config --global user.email <email>

Check your git configuration:
```
 git config --list 
```

Note: Your email address will be visible on commits to Git. 
If you'd like to keep your email address private, you can mask your email as follows:
if your email is <name@company.com> you can set user.email to <hidden@company.com>
This allows other users to identify you as a contributor (with your user name) and
Git Stats to keep track of your company's contributions (with the email domain)

In case you are using git in the same computer for other open source projects, you can restrict your git variables to the local folder:

git config --local user.name <username>
git config --local user.email <email>

Commit changes to your local project

Go to the "RO" folder
```
cd osm/RO
```
Make some changes on the source (e.g. add a line to the "example-file")
Stage the change.
```
 git add example-file 
```
Commit the change to your local repository. You can add a bug id in your commit message to link the bug to your contribution
```
 git commit -s -m "Bug 2 fixed!!"  
```
You can see your commit message and update it, if needed, using the following command:
```
git commit --amend 
```

Developer's Certificate of Origin

The "-s" parameter enables to Sign the contribution. It adds the following line at the end of your commit message:

   Signed-off-by: Random J Developer <random@developer.example.org>

The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: signing a contribution means that you can certify the below:

        Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) 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

        (b) 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

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

        (d) 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.

Push your contribution to Gerrit

Push your contribution to Gerrit using git push

1. To avoid merge conflicts, it is recommended to do a pull with rebase before pushing your contribution in order to merge latest changes made by other users.

git pull --rebase

Note: you can force git to use always the --rebase option with:

git config --local pull.rebase true

2. Push your commits to Gerrit for Code Review using the following command:

git push origin HEAD:refs/for/master
#use 'v1.0' instead of 'master' for contributing to v1.0 branch

Note: you can also configure git to push always to the desired branch.

git config --local remote.origin.push HEAD:refs/for/master
git config --local remote.origin.push HEAD:refs/for/v1.0

3. Enter your username.

4. Enter your password.

5. You can review your contribution on Gerrit web interface

Notes:

The following actions are execution automatically after pushing any contribution to Gerrit:
- Gerrit reports the new contribution state to the corresponding bug in Bugzilla
- Gerrit notifies Jenkins to build the new contribution.

Push your contribution to Gerrit using git review

Instead of using "git push", you could use "git review". Follow this guide (Using git-review to push and review changes) to install and configure git-review. You will also have to set the SSH URL for your remote and copy the commit-msg hook.

To avoid merge conflicts, it is recommended to do a pull with rebase before pushing your contribution.

git pull --rebase

Then, send your contribution to gerrit:

git review -c

Gerrit Notifications

Gerrit sends email notifications to:

Owner of the change
Reviewers of the change
Project watchers

Each user can configure his own watched projects and branches in the "settings/watched project" menu. Email notifications can be sent for New Changes, New Patch Sets, All Comments, Submitted Changes and Abandoned Changes.

Link: https://osm.etsi.org/gerrit/#/settings/projects (you can navigate there from the Gerrit console by clicking on the arrow by your login on the top right corner)

Continuous Integration

Jenkins builds, tests the new contribution, and reports the result on its web interface.
Jenkins votes on the contribution using “Code-Verif” (-1, +1) on Gerrit.

Code Review

Other contributors and MDG Committers can comment the new contribution and vote using “Code-Review” (-1, 0, +1) on Gerrit.
The MDG Leader can comment the new contribution and votes using “Code-Review” (-2, -1, 0, +1, +2) on Gerrit.

Amending a contribution in Gerrit

Before amending, make sure that you have the commit-msg hook installed in your local repo. For instance, if your user is "user" and the repo is the "devops" repo, the command to install the commit-msg hook would be:

$ scp -p -P 29418 user@osm.etsi.org:hooks/commit-msg devops/.git/hooks/

In that way, all patches will use the same Change Id, thus guaranteeing that they will be associated to the same change.

Amending a change in Gerrit using git

Note: steps 1 to 4 are not required if the local change to be modified is in the tip of the branch.

1. Get the last code from the repository. Note: use the appropriate branch instead of master

git checkout master
git pull origin master

2. Create a new branch to work on the code. You can use the review number and patchset as name.

git checkout -b <review-number>-<patchset>

3. Pull the patch on the created branch. (To find the command to execute you can open the corresponding change page on Gerrit UI, click on download menu, then copy the "pull" command.)

git pull <url> <ref>

4. Make a rebase of your branch against master. Note: use the appropriate branch instead of master if your change was applied on a different branch.

git rebase master

In case of conflicts, follow instructions here to resolve them.

5. Fix the code.

6. Add all updated files to the index.

git add <file>

Note: You can use git-status to make sure that conflicts are solved

git status

7. Amend your commit. NOTE: Don't use the -m flag to specify a commit message, since it will override the previous message and regenerate the Change-Id. Instead, use the text editor to change the commit message if needed, and keep the Change-Id line intact.

git commit --amend

8. Submit your change back to the repository

git push origin HEAD:refs/for/master

Amending a change in Gerrit using git-review

1. Follow the instructions in this link to install and configure git-review.

2. Download the change with git-review

$ git review -d 1280
Downloading refs/changes/80/1280/1 from gerrit
Switched to branch "review/garciadeblas/1280"

This will download the change, put it in a branch called review/AUTHOR/change (if the change has no tag, the sequence number will be used instead), and switch to that branch.

3. After that, you can amend the downloaded change to improve it. Finally, push it again:

$ git add                         # add the changes
$ git commit --amend              # do not touch the Change-Id. The Change-Id is the way for gerrit to keep track what belongs to what development stream as a new patch set.
$ git commit --amend --author     # if you want to mark the changes as yours.
$ git review -c -R                # The -R is important, since it tells git-review to not rebase your change against master.

NOTE: Don't use the -m flag to specify a commit message, since it will override the previous message and regenerate the Change-Id. Instead, use the text editor to change the commit message if needed, and keep the Change-Id line intact.

4. Delete the branch once you have finished:

$ git branch -D review/garciadeblas/1280

Merging the contribution

The MDG Leader can "Submit" the change only if +1 "Code-Verif" (from Jenkins) and at least one +2 "Code-Review".
Gerrit reports the result of the code review to the corresponding bug in Bugzilla

Your feedback is most welcome!
You can send us your comments and questions to OSM_TECH@list.etsi.org
Or join the OpenSourceMANO Slack Workplace
See hereafter some best practices to report issues on OSM

Workflow with OSM tools

Contents