Skip to content
This repository has been archived by the owner on Jul 11, 2023. It is now read-only.

Latest commit

 

History

History
272 lines (178 loc) · 11.4 KB

CONTRIBUTING.md

File metadata and controls

272 lines (178 loc) · 11.4 KB
Raw

Contributing Guidelines

The OSM project accepts contributions via GitHub pull requests. This document outlines the requirements for contributing to this project.

Table of Contents

Design Document

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.

Pull Request Workflow

The following sections describe how to contribute code by opening a pull request.

1. Fork the Open Service Mesh repository

  1. Visit https://github.com/openservicemesh/osm.
  2. Click the Fork button.

2. Clone the new fork to your workstation

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

3. Git branch

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

4. Commit

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.

5. Push

Push your branch to your remote fork:

git push -f <remote name> <branch name>

6. Open a pull request

  1. Visit your fork at https://github.com/$GITHUB_USERNAME/osm.
  2. Open a pull request from your feature branch using the Compare & Pull Request button.
  3. 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.

Get code reviewed

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.

Merging pull requests

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 a merge 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 merged PRs to remove messages from follow-up commits.

Commit Style Guideline

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

Sign Your Work

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.

Documentation

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.

Roadmap

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.

Issues

If a bug is found, need clarification, or want to propose a feature, submit an issue using GitHub issues.

Milestones

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.

Semantic Versioning

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.

Attribution

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.