# How To Contribute¶

## Clone and Provision Environment¶

1. Make sure you have a GitHub account

2. Clone the cilium repository into your GOPATH.

mkdir -p $GOPATH/src/github.com/cilium cd$GOPATH/src/github.com/cilium
git clone https://github.com/cilium/cilium.git
cd cilium

3. Set up your Development Setup.

4. Check the GitHub issues for good tasks to get started.

## Submitting a pull request¶

Contributions must be submitted in the form of pull requests against the github repository at: https://github.com/cilium/cilium.

1. Fork the Cilium repository to your own personal GitHub space or request access to a Cilium developer account on Slack
2. Push your changes to the topic branch in your fork of the repository.
3. Submit a pull request on https://github.com/cilium/cilium.

Before hitting the submit button, please make sure that the following requirements have been met:

1. Each commit compiles and is functional on its own to allow for bisecting of commits.

2. All code is covered by unit and/or runtime tests where feasible.

3. All changes have been tested and checked for regressions by running the existing testsuite against your changes. See the End-To-End Testing Framework section for additional details.

4. All commits contain a well written commit description including a title, description and a Fixes: #XXX line if the commit addresses a particular GitHub issue. Note that the GitHub issue will be automatically closed when the commit is merged.

apipanic: Log stack at debug level

Previously, it was difficult to debug issues when the API panicked
because only a single line like the following was printed:

level=warning msg="Cilium API handler panicked" client=@ method=GET
panic_message="write unix /var/run/cilium/cilium.sock->@: write: broken
pipe"

This patch logs the stack at this point at debug level so that it can at
least be determined in developer environments.

Fixes: #4191

Signed-off-by: Joe Stringer <joe@cilium.io>

5. If any of the commits fixes a particular commit already in the tree, that commit is referenced in the commit message of the bugfix. This ensures that whoever performs a backport will pull in all required fixes:

daemon: use endpoint RLock in HandleEndpoint

Fixes: a804c7c7dd9a ("daemon: wait for endpoint to be in ready state if specified via EndpointChangeRequest")

Signed-off-by: André Martins <andre@cilium.io>

6. If you change CLI arguments of any binaries in this repo, the CI will reject your PR if you don’t also update the command reference docs. To do so, make sure to run the postcheck make target.

$make postcheck$ git add Documentation/cmdref


### Triage issues for Triage team¶

Dedicated expectation time for each member of Triage team: 15/30 minutes per day. Works best if done first thing in the working day.

1. Committers belonging to the Triage team should make sure that:

1. Add the label kind/community-report;
2. If feasible, try to reproduce the issue described;
3. Assign a member that is responsible for that code section to that GitHub issue;
4. If it is a relevant bug to the rest of the committers, bring the issue up in the weekly meeting. For example:
• The issue may impact an upcoming release; or
• The resolution is unclear and assistance is needed to make progress; or
• The issue needs additional attention from core contributors to confirm the resolution is the right path.
1. If there is someone already assigned to that GitHub issue and that committer hasn’t provided an answer to that user for a while, ping that committer directly on Slack;
2. If the issue cannot be solved, bring the issue up in the weekly meeting.

### Backporting PR for Backport team¶

Dedicated expectation time for each member of Backport team: 60 minutes per week depending on releases that need to be performed at the moment.

Even if the next release is not imminently planned, it is still important to perform backports to keep the process smooth and to catch potential regressions in stable branches as soon as possible. If backports are delayed, this can also delay releases which is important to avoid especially if there are security-sensitive bug fixes that require an immediate release.

In addition, when a backport PR is open, the person opening it is responsible to drive it to completion, even if it stretches after the assigned week of backporting hat. If this is not feasible (e.g. PTO), you are responsible to initiate handover of the PR to the next week’s backporters.

If you can’t backport a PR due technical constraints feel free to contact the original author of that PR directly so they can backport the PR themselves.

Follow the Backporting process guide to know how to perform this task.

#### Coordination¶

In general, coordinating in the #launchpad Slack channel with the other hat owner for the week is encouraged. It can reduce your workload and it will avoid backporting conflicts such as opening a PR with the same backports. Such discussions will typically revolve around which branches to tackle and which day of the week.

Starting backport round for v1.7 and v1.8 now
cc @other-hat-wearer


The other hat owner can then handle v1.9 and v1.10 backports the next day, for example.

If there are many backports to be done, then splitting up the rounds can be beneficial. Typically, backporters opt to start a round in the beginning of the week and then another near the end of the week.

By the start / end of the week, if there are other backport PRs that haven’t been merged, then please coordinate with the previous / next backporter to check what the status is and establish who will work on getting the backports into the tree (for instance by investigating CI failures and addressing review feedback). There’s leeway to negotiate depending on who has time available.

## Developer’s Certificate of Origin¶

To improve tracking of who did what, we’ve introduced a “sign-off” procedure.

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

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

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.


then you just add a line saying:

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


Use your real name (sorry, no pseudonyms or anonymous contributions.)