Skip to content

Latest commit

 

History

History
95 lines (64 loc) · 3.51 KB

CONTRIBUTING.md

File metadata and controls

95 lines (64 loc) · 3.51 KB
Raw

Contributing to Apache Traffic Server

All contributions to the ATS project should be done via a Github Pull Request (aka PR). If you are having an issue, but no code available yet, you should file a Github Issue instead, which later will be linked to a new PR.

In general, all changes that are to be committed should have a Github PR. There are some reasonable exceptions to this, but we should stick to the Github workflow as agreed upon.

New Issues process replacing old Jira

  1. If there is an issue/feature, an existing Jira Ticket, and no code, then create a Github Issue. Copy the relevant information into the Github Issue and request the Jira Ticket to be closed. Hopefully this use case won't happen very often.

  2. If there is an issue/feature and no code, then create a Github Issue. When there is code later, create a Github Pull Request and reference the Github Issue.

  3. If there is an issue/feature and code, then create a Github Pull Request. If there is an existing Jira Ticket or Github Issue refer to the Ticket or Issue in the PR. Creating a Github Issue is not required for a Github Pull Request.

Making a good PR or Issue

Since Github PRs and Issues are now our primary way of tracking both code changes and outstanding issues, it's important that we all play nicely. Here are a few simple rules to follow:

  1. Always branch off the master branch, unless you are requesting a subsequent backport PR.

  2. Make the subject line short (< 50 characters), but reasonably descriptive.

  3. When filing a PR, without a previous Issue describing the problem, please write something explaining the problem as part of the Description.

  4. When filing an Issue, you should of course describe the problem, as well as any details such as platform, versions of software etc. used.

  5. Make sure you set the appropriate Milestone, Labels, Assignees and Reviewers.

  6. If the PR is a backport, or intended to be backported, please make sure to add the Backport label.

  7. If the PR is a Work-In-Progress, and not ready to commit, mark it with the WIP label.

  8. Make sure you run clang-format before making the PR. This is easiest done with e.g. "make clang-format", which works on macOS and Linux.

  9. Make sure you run autopep8 before making the PR. This is easiest done with e.g. "make autopep8".

  10. When making backports, make sure you mark the PR for the appropriate Github branch (e.g. 6.2.x).

  11. If you are making backports to an LTS branch, remember that the job of merging such a PR is the duty of the release manager.

Merging a PR

Only committers can merge a PR (obviously), and any committer is allowed to merge any PR after review. A few requirements before merging must be met:

  • Never, ever, merge a PR which did not pass all the Jenkins build jobs!

  • Make sure all attributes on the PR and issue is satisfied, such as Milestone and Labels.

  • Only merge a PR that have at least one review approval, and no pending requested changes.

  • Make sure the PR is for the master branch, only the RM should merge backport requested for her or his release branch.

  • If there is also an open Issue associated with the PR, make sure to close the Issue as well.

Miscellaneous

Once your Github branch has been merged, it is safe to delete it from your private repository.