The OSM project accepts contributions via GitHub pull requests. This document outlines the requirements for contributing to this project.
- Design Document
- Pull Request Workflow
- Documentation
- Roadmap
- Issues
- Milestones
- Semantic Versioning
- Attribution
The OSM project recommends drafting a design doc in a shareable Google doc for features that significantly alter core control plane components or change the existing behavior. It is recommended to have the design doc reviewed by the OSM project maintainers and relevant stakeholders before proceeding with an implementation. The design doc must be referenced in the Github issue corresponding to the feature being requested.
Introduction of new custom APIs, feature changes requiring significant changes to the control plane, features impacting multiple OSM components, and refactoring work for performance optimization, are some of the examples of when a design doc is necessary.
The following sections describe how to contribute code by opening a pull request.
1. Fork the Open Service Mesh repository
- Visit
https://github.com/openservicemesh/osm
. - Click the
Fork
button.
Set GITHUB_USERNAME
to match your Github username:
export GITHUB_USERNAME=<github username>
Clone and set up your fork:
git clone git@github.com:$GITHUB_USERNAME/osm.git
cd osm
git remote add upstream git@github.com:openservicemesh/osm.git
# Block accidental pushes to upstream's main branch
git remote set-url --push upstream no_push
# Verify your remote
git remote -v
Get your local main
branch up to date with upstream's main
branch:
git fetch upstream
git checkout main
git rebase upstream/main
Create a local branch from main
for your development:
# While on the main branch
git checkout -b <branch name>
# ex: git checkout -b feature
Keep your branch up to date during development:
git fetch upstream
git rebase upstream/main
# or: git pull --rebase upstream main
Make code changes on the feature
branch and commit them with your signature
git commit -s
Follow the commit style guidelines.
Make sure to squash your commits before opening a pull request. This is preferred so that your pull request can be merged as is without requesting to be squashed before merge if possible.
Push your branch to your remote fork:
git push -f <remote name> <branch name>
- Visit your fork at
https://github.com/$GITHUB_USERNAME/osm
. - Open a pull request from your
feature
branch using theCompare & Pull Request
button. - Fill the pull request template and provide enough description so that it can be reviewed.
If your pull request is not ready to be reviewed, open it as a draft.
Your pull request will be reviewed by the maintainers to ensure correctness. Reviewers might approve the pull request or suggest improvements to make before the changes can be committed.
When addressing review comments, refrain from rewriting the Git history of your branch (e.g. with git commit --amend
or git rebase
) where possible to make those changes easy to review. Instead, prefer creating new commits without --amend
and using git merge
to resolve conflicts with the upstream branch. The commit style guidelines below will not be enforced for follow-up commits. When the PR is merged, all commits in the PR will automatically be squashed into one commit added to the upstream branch.
Pull requests by default must be merged by a core maintainer.
Maintainers can add the automerge
or autorebase
label to a pull request, additional details here.
Pull requests will be merged based on the following criteria:
- Has at least two LGTM from a core maintainer.
- Commits follow the commit style guidelines.
- Does not have the
do-not-merge/hold
label. - Does not have the
wip
label. - All status checks have succeeded.
- Commits in the pull request are squashed and have a valid signature. If the commits in the PR are not squashed, maintainers must use the
squash and merge
option to squash the commits before merging. Maintainers may choose to update the commit message to meet the commit message guidelines without altering the signatures of the authors of the pull request. In certain situations, it is okay to have multiple related but independent commits in the same pull request. In such cases, a pull request may be merged as amerge commit
. - If the person who opened the pull request is a core maintainer, then only that person is expected to merge once it has the necessary LGTMs/reviews. Another maintainer can merge the pull request at their discretion if they feel the pull request must be merged urgently.
Maintainers may edit the commit message for Squash and merge
d PRs to remove messages from follow-up commits.
We follow a rough convention for commit messages borrowed from Deis. This is an example of a commit:
feat(scripts/test-cluster): add a cluster test command
Adds test experience where there was none before
and resolves #1213243.
This is a more formal template:
{type}({scope}): {subject}
<BLANK LINE>
{body}
The {scope}
can be anything specifying the place of the commit change. Use *
to denote multiple areas (i.e. scripts/*: refactored lots of stuff
).
The {subject}
needs to use imperative, present tense: change
not changed
nor changes
. The first letter should not be capitalized, and there is no dot (.
) at the end.
Just like the {subject}
, the message {body}
needs to be in the present tense and includes the motivation for the change as well as a contrast with the previous behavior. The first letter in the paragraph must be capitalized. If there is an issue number associate with the chunk of work that should be mentioned in this section as well so that it may be closed once the PR with this commit is merged.
Any line of the commit message cannot be longer than 72 characters, with the subject line limited to 50 characters. This allows the message to be easier to read on GitHub as well as in various git tools.
The allowed types for {type}
are as follows:
feat -> feature
fix -> bug fix
docs -> documentation
style -> formatting
ref -> refactoring code
test -> adding missing tests
chore -> maintenance
The sign-off is a simple line at the end of the explanation for a commit. All commits needs to be signed. Your signature certifies that you wrote the patch or otherwise have the right to contribute the material. The rules are pretty simple, if you can certify the below (from developercertificate.org):
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 to every git commit message:
Signed-off-by: Joe Smith <joe.smith@example.com>
Use your real name (sorry, no pseudonyms or anonymous contributions.)
If you set your user.name
and user.email
git configs, you can sign your commit automatically
with git commit -s
.
Note: If your git config information is set properly then viewing the git log
information for your
commit will look something like this:
Author: Joe Smith <joe.smith@example.com>
Date: Thu Feb 2 11:41:15 2018 -0800
Update README
Signed-off-by: Joe Smith <joe.smith@example.com>
Notice the Author
and Signed-off-by
lines match. If they don't your PR will be rejected by the
automated DCO check.
OSM's primary documentation is made available at https://docs.openservicemesh.io/. Any documentation content that needs to be visible on the website must be created in the osm-docs
repository. Refer to the OSM documentation guide for more details.
Documentation that is primarily intended for use with this code repo (instead of as a website) can be found in [docs/]((docs/).
Refer to the custom API reference generation guide to document custom APIs.
We use GitHub Project Boards to help give a high level overview and track what work is going on and what stage it is in. If you want an idea of our roadmap and prioritization, this is the best place to find that information.
If a bug is found, need clarification, or want to propose a feature, submit an issue using GitHub issues.
We use [GitHub Milestones] to track progress of releases. A milestone contains a set of GitHub issues we've agreed to complete for the release. A milestone will be given a semantic version and a soft due date
. We will cut a GitHub release once all issues tagged in the milestone are closed or moved to the next milestone.
This project's releases will follow semantic versioning for labeling releases to maintain backwards compatibility. Features and functionality may be added in major (x.0.0) and minor (0.x.0) releases. Bug fixes may be added in patch releases (0.0.x). We will follow semantic versioning to guarantee features, flags, functionality, public APIs will be backwards compatible as the versioning scheme suggests.
Please properly attribute any code that is copied or inspired by another project to the author(s) of the work. Read the license of the original project to understand how to properly attribute work from that project and include this in your pull request.