From 61da353c0a90a3973903703de038d1682cd5aa6f Mon Sep 17 00:00:00 2001 From: mayank Date: Mon, 20 Apr 2020 19:00:32 +0530 Subject: [PATCH] Adding following files for the project: - issue template - feature request template - CODE_OF_CONDUCT.md - CONTRIBUTING.md - GOVERNANCE.md - MAINTAINERS - README.md - code-standard.md - developer-setup.md Signed-off-by: mayank --- .github/ISSUE_TEMPLATE/bug_report.md | 38 +++++ .github/ISSUE_TEMPLATE/feature-request.md | 28 ++++ .github/pull_request_template.md | 16 ++ CODE_OF_CONDUCT.md | 46 ++++++ CONTRIBUTING.md | 122 +++++++++++++++ GOVERNANCE.md | 3 + MAINTAINERS | 16 ++ README.md | 2 + RELEASE.md | 38 +++++ code-standard.md | 24 +++ developer-setup.md | 178 ++++++++++++++++++++++ 11 files changed, 511 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature-request.md create mode 100644 .github/pull_request_template.md create mode 100644 CODE_OF_CONDUCT.md create mode 100644 CONTRIBUTING.md create mode 100644 GOVERNANCE.md create mode 100644 MAINTAINERS create mode 100644 RELEASE.md create mode 100644 code-standard.md create mode 100644 developer-setup.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 00000000..27b02f07 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,38 @@ +--- +name: Bug report +about: Tell us about a problem you are experiencing +labels: Bug + +--- + +**What steps did you take and what happened:** +[A clear and concise description of what the bug is, and what commands you ran.] + + +**What did you expect to happen:** + + +**The output of the following commands will help us better understand what's going on**: +(Pasting long output into a [GitHub gist](https://gist.github.com) or other [Pastebin](https://pastebin.com/) is fine.) + +* `kubectl logs deployment/velero -n velero` +* `kubectl logs deployment/maya-apiserver -n openebs` +* `velero backup describe ` or `kubectl get backup/ -n velero -o yaml` +* `velero backup logs ` +* `velero restore describe ` or `kubectl get restore/ -n velero -o yaml` +* `velero restore logs ` + + +**Anything else you would like to add:** +[Miscellaneous information that will assist in solving the issue.] + + +**Environment:** +- Velero version (use `velero version`): +- Velero features (use `velero client config get features`): +- Velero-plugin version +- OpenEBS version +- Kubernetes version (use `kubectl version`): +- Kubernetes installer & version: +- Cloud provider or hardware configuration: +- OS (e.g. from `/etc/os-release`): diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md new file mode 100644 index 00000000..4de96e00 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature-request.md @@ -0,0 +1,28 @@ +--- +name: Feature request +about: Suggest an idea for this project +labels: Enhancement + +--- + +**Describe the problem/challenge you have** +[A description of the current limitation/problem/challenge that you are experiencing.] + + +**Describe the solution you'd like** +[A clear and concise description of what you want to happen.] + + +**Anything else you would like to add:** +[Miscellaneous information that will assist in solving the issue.] + + +**Environment:** +- Velero version (use `velero version`): +- Velero features (use `velero client config get features`): +- Velero-plugin version +- OpenEBS version +- Kubernetes version (use `kubectl version`): +- Kubernetes installer & version: +- Cloud provider or hardware configuration: +- OS (e.g. from `/etc/os-release`): diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 00000000..3fc64678 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,16 @@ +## Pull Request template +Please, go through these steps before you submit a PR. + +1. This repository follows semantic versioning convention, therefore each PR title/commit message must follow convention: `(): `. + Most common types are: + * `feat` - for new features, not a new feature for build script + * `fix` - for bug fixes or improvements, not a fix for build script + * `chore` - changes not related to production code + * `docs` - changes related to documentation + * `style` - formatting, missing semi colons, linting fix etc; no significant production code changes + * `test` - adding missing tests, refactoring tests; no production code change + * `refactor` - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes + +IMPORTANT: Please review the [CONTRIBUTING.md](../CONTRIBUTING.md) file for detailed contributing guidelines. + +**PLEASE REMOVE THIS TEMPLATE BEFORE SUBMITTING** diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..e7c7c2c5 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,46 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at community@openebs.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] + +[homepage]: http://contributor-covenant.org +[version]: http://contributor-covenant.org/version/1/4/ diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..5bb251b4 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,122 @@ +# Contributing to velero-plugin + +velero-plugin is an open-source project. + +velero-plugin uses the standard GitHub pull requests process to review and accept contributions. + +You can contribute to velero-plugin by filling an issue at [openebs/velero-plugin](https://github.com/openebs/velero-plugin/issues) or submitting a pull request to this repository. + +* If you want to file an issue for bug or feature request, please see [Filing an issue](#filing-an-issue) +* If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute) and code standard(code-standard.md). +* If you would like to work on something more involved, please connect with the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community) + +## Filing an issue +### Before filing an issue + +If you are unsure whether you have found a bug, please consider asking in the [Slack](https://kubernetes.slack.com/messages/openebs) first. If +the behavior you are seeing is confirmed as a bug or issue, it can easily be re-raised in the [issue tracker](https://github.com/openebs/velero-plugin/issues). + +### Filing issue + +When filing an issue, make sure to answer these seven questions: + +1. What version of Velero are you using (`velero version`)? +2. What version of OpenEBS are you using? +3. What version of velero-plugin are you using? +4. What steps did you follow to create a backup or restore? +5. What did you expect to see? +6. What did you see instead? +7. Logs of velero/velero pod and openebs/maya-apiserver pod. + +#### For maintainers +* We are using labeling for the issue to track it more effectively. The following are valid labels for the issue. + - **Bug** - If the issue is a **bug to existing feature** + - **Enhancement** - If the issue is a **feature request** + - **Maintenance** - If the issue is not related to production code. **build, document or test related issues fall into this category** + - **Question** - If the issue is about **querying information about how the product or build works, or internal of product**. + - **Documentation** - If the issue is about **tracking the documentation work for the feature**. This label should not be applied to the issue of a bug in documentations. + - **Good First Issue** - If the issue is easy to get started with. Please make sure that the issue should be ideal for beginners to dive into the codebase. + - **Design** - If the issue **needs a design decision prior to code implementation** + - **Duplicate** - If the issue is **duplicate of another issue** + +* We are using following labels for issue work-flow: + - **Backlog** - If the issue has **not been planned for current release cycle** + - **Release blocker** - If the issue is **blocking the release** + - **Priority: high** - issue with this label **should be resolved as quickly as possible** + - **Priority: low** - issue with this label **won’t have the immediate focus of the core team** + +**If you want to introduce a new label then you need to raise a PR to update this document with the new label details.** + +## Steps to Contribute +velero-plugin is an Apache 2.0 Licensed project and all your commits should be signed with Developer Certificate of Origin. See [Sign your work](#sign-your-work). + +For setting up a development environment on your local machine, see the detailed instructions [here](developer-setup.md). + +* Find an issue to work on or create a new issue. The issues are maintained at [openebs/velero-plugin](https://github.com/openebs/velero-plugin/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/velero-plugin/labels/good%20first%20issue). +* Claim your issue by commenting your intent to work on it to avoid duplication of efforts. +* Fork the repository on GitHub. +* Create a branch from where you want to base your work (usually master). +* Commit your changes by making sure the commit messages convey the need and notes about the commit. +* Please make sure than your code is aligned with the standard mentioned at [code-standard](code-standard.md). +* Verify that your changes pass `make lint` or `make lint-docker` (docker version of `make lint`) +* Push your changes to the branch in your fork of the repository. +* Submit a pull request to the original repository. See [Pull Request checklist](#pull-request-checklist) + +## Pull Request Checklist +* Rebase to the current master branch before submitting your pull request. +* Commits should be as small as possible. Each commit should follow the checklist below: + - For code changes, add tests relevant to the fixed bug or new feature. + - Commit header (first line) should convey what changed + - Commit body should include details such as why the changes are required and how the proposed changes help + - DCO Signed, please refer [signing commit](code-standard.md/sign-your-commits) +* If your PR is about fixing an issue or new feature, make sure you add a change-log. Refer [Adding a Change log](code-standard.md/adding-a-changelog) +* PR title must follow convention: `(): `. + + For example: + ``` + feat(backup): support for backup to aws + ^--^ ^-----^ ^-----------------------^ + | | | + | | +-> PR subject, summary of the changes + | | + | +-> scope of the PR, i.e. component of the project this PR is intend to update + | + +-> type of the PR. + ``` + + Most common types are: + * `feat` - for new features, not a new feature for the build script + * `fix` - for bug fixes or improvements, not a fix for the build script + * `chore` - changes not related to production code + * `docs` - changes related to documentation + * `style` - formatting, missing semicolons, linting fix, etc; no significant production code changes + * `test` - adding missing tests, refactoring tests; no production code change + * `refactor` - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes + * `cherry-pick` - if PR is merged in the master branch and raised to release branch(like v1.9.x) + +## Code Reviews +All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) for more information on using pull requests. + +* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community) + +* If PR is fixing any issues from [github-issues](github.com/openebs/velero-plugin/issues) then you need to mention the issue number with a link in PR description. like: _fixes https://github.com/openebs/velero-plugin/issues/56_ + +* If PR is for bug-fix and release branch(like v1.9.x) is created then cherry-pick for the same PR needs to be created against the release branch. Maintainer of the Project needs to make sure that all the bug fixes after RC release are cherry-picked to release branch. + +### For maintainers +* We are using labeling for PR to track it more effectively. The following are valid labels for the PR. + - **Bug** - if PR is a **bug to existing feature** + - **Enhancement** - if PR is a **feature request** + - **Maintenance** - if PR is not related to production code. **build, document or test related PR falls into this category** + - **Documentation** - if PR is about **tracking the documentation work for the feature**. This label should not be applied to the PR fixing bug in documentations. + +* We are using the following label for PR work-flow: + - **DO NOT MERGE** - if PR is about critical changes and no scope of testing before release branch creation + - **On Hold** - if PR doesn't have sufficient changes, all the scenarios are not covered or changes are requested from contributor + - **Release blocker** - if PR is created for the issue having label **Release blocker** + - **Priority: high** - if PR is created for the issue having label **Priority: high** + - **Priority: low** - if PR is created for the issue having label **Priority: low** + +* Maintainer needs to make sure that appropriate milestone and project tracker is assigned to the PR. + +**If you want to introduce a new label then you need to raise a PR to update this document with the new label details.** diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 00000000..da567efc --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,3 @@ +This is a OpenEBS sub project and abides by the +[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md). + diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100644 index 00000000..9b4ba792 --- /dev/null +++ b/MAINTAINERS @@ -0,0 +1,16 @@ +# Official list of OpenEBS Maintainers. +# +# Names added to this file should be in the following format: +# Individual's name,@githubhandle, Company Name +# +# Please keep the below list sorted in ascending order. +# +#Maintainers +"Kiran Mova",@kmova,MayaData +"Mayank Patel",@mynktl,MayaData +"Vishnu Itta",@vishnuitta,MayaData + +#Reviewers +"Kiran Mova",@kmova,MayaData +"Mayank Patel",@mynktl,MayaData +"Vishnu Itta",@vishnuitta,MayaData diff --git a/README.md b/README.md index b911fec4..83949f02 100644 --- a/README.md +++ b/README.md @@ -6,8 +6,10 @@ To do backup/restore of OpenEBS CStor volumes through Velero utility, you need t OpenEBS velero-plugin. [![Build Status](https://travis-ci.org/openebs/velero-plugin.svg?branch=master)](https://travis-ci.org/openebs/velero-plugin) +[![Slack](https://img.shields.io/badge/chat!!!-slack-ff1493.svg?style=flat-square)](https://kubernetes.slack.com/messages/openebs) [![Go Report](https://goreportcard.com/badge/github.com/openebs/velero-plugin)](https://goreportcard.com/report/github.com/openebs/velero-plugin) [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fvelero-plugin.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fvelero-plugin?ref=badge_shield) +[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3900/badge)](https://bestpractices.coreinfrastructure.org/projects/3900) ## Table of Contents - [Compatibility matrix](#compatibility-matrix) diff --git a/RELEASE.md b/RELEASE.md new file mode 100644 index 00000000..8a38ff96 --- /dev/null +++ b/RELEASE.md @@ -0,0 +1,38 @@ +# Release Process +velero-plugin follows a monthly release cadence. The scope of the release is determined by contributor availability. The scope is published in the [Release Tracker Projects](https://github.com/openebs/openebs/projects). + +## Release Candidate Verification Checklist + +Every release has release candidate builds that are created starting from the third week into the release. These release candidate builds help to freeze the scope and maintain the quality of the release. The release candidate builds will go through: +- Platform Verification +- Regression and Feature Verification Automated tests. +- Exploratory testing by QA engineers +- Strict security scanners on the container images +- Upgrade from previous releases +- Beta testing by users on issues that they are interested in. +- Dogfooding on OpenEBS workload and e2e infrastructure clusters. + +If any issues are found during the above stages, they are fixed and a new release candidate builds are generated. + +Once all the above tests are completed, a main release tagged image is published. + +## Release Tagging + +velero-plugin is released as a container image with a versioned tag. + +Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `master`. Name of the branch should follow the naming convention of `v.1.9.x` if the release is for v1.9.0. + +Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder `changelogs/v1.9.x`, if release branch is `v1.10.x` then folder will be `changelogs/v1.10.x`. + +The format of the release tag is either "Release-Name-RC1" or "Release-Name" depending on whether the tag is a release candidate or a release. (Example: v1.9.0-RC1 is a GitHub release tag for the velero-plugin release build. v1.9.0 is the release tag that is created after the release criteria are satisfied by the velero-plugin builds.) + +Once the release is triggered, Travis build process has to be monitored. Once Travis build is passed images are pushed to docker hub and quay.io. Images can be verified by going through docker hub and quay.io. Also the images shouldn't have any high-level vulnerabilities. + +Images are published at the following location: +https://quay.io/repository/openebs/velero-plugin?tab=tags +https://hub.docker.com/r/openebs/velero-plugin/tags + +Once a release is created, update the release description with the changelog mentioned in `changelog/v1.9.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `master` with the following details: +1. update the changelog from `changelog/v1.9.x` to `velero-plugin/CHANGELOG.md` +2. If a release is not an RC tag then PR should include the changes to remove `changelog/v1.9.x` folder. +3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v1.9.x` which are already mentioned in `velero-plugin/CHANGELOG.md` as part of step number 1. diff --git a/code-standard.md b/code-standard.md new file mode 100644 index 00000000..717b2123 --- /dev/null +++ b/code-standard.md @@ -0,0 +1,24 @@ +# Code Standards + +## Sign your commits + +We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS projects. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/master/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message: + +```` + Signed-off-by: Random J Developer +```` + +Use your real name (sorry, no pseudonyms or anonymous contributions). The email id should match the email id provided in your GitHub profile. +If you set your `user.name` and `user.email` in git config, you can sign your commit automatically with `git commit -s`. + +## Verifying code style + +We are using [golangci-lint](https://github.com/golangci/golangci-lint) to verify the linting errors. Make sure that your changes pass linting check by executing `make lint` or `make lint-docker` (docker version of `make lint`) + +## Adding a changelog +If PR is about adding a new feature or bug fix then the Author of the PR is expected to add a changelog file with their pull request. This changelog file should be a new file created under the `changelogs/unreleased` folder. Name of this file must be in `pr_number-username` format and contents of the file should be the one-liner text which explains the feature or bug fix. + +```sh +velero-plugin/changelogs/unreleased <- folder + 12-github_user_name <- file +``` diff --git a/developer-setup.md b/developer-setup.md new file mode 100644 index 00000000..f17bf175 --- /dev/null +++ b/developer-setup.md @@ -0,0 +1,178 @@ + +# Development Workflow + +## Prerequisites + +* You have Go 1.14 installed on your local development machine. +* You have Docker installed on your local development machine. Docker is required for building velero-plugin container images and to push them into a Kubernetes cluster for testing. +* You have `kubectl` installed. For running integration tests, you will require an existing single node cluster with [openebs](https://blog.openebs.io/how-to-install-openebs-with-kubernetes-using-minikube-2ed488dff1c2) and [velero](https://velero.io/docs/master/basic-install/) installed. Don't worry if you don't have access to the Kubernetes cluster, raising a PR with the velero-plugin repository will run integration tests for your changes against a Minikube cluster. + +## Initial Setup + +### Fork in the cloud + +1. Visit https://github.com/openebs/velero-plugin +2. Click the `Fork` button (top right) to establish a cloud-based fork. + +### Clone fork to the local machine + +Place openebs/velero-plugin's code on your `GOPATH` using the following cloning procedure. +Create your clone: + +```sh + +mkdir -p $GOPATH/src/github.com/openebs +cd $GOPATH/src/github.com/openebs + +# Note: Here user= your github profile name +git clone https://github.com/$user/velero-plugin.git + +# Configure remote upstream +cd $GOPATH/src/github.com/openebs/velero-plugin +git remote add upstream https://github.com/openebs/velero-plugin.git + +# Never push to upstream master +git remote set-url --push upstream no_push + +# Confirm that your remotes make sense: +git remote -v +``` +> **Note:** If your `GOPATH` has more than one (`:` separated) paths in it, then you should use *one of your go path* instead of `$GOPATH` in the commands mentioned here. This statement holds throughout this document. + +### Building and Testing your changes + +* To build the velero-plugin binary +```sh + +make +``` + +* To build the docker image + +```sh + +make container REPO= +``` + +* Test your changes +Integration tests are written in ginkgo and run against a minikube cluster. The Minikube cluster should be running to execute the tests. To install the Minikube follow the doc [here](https://kubernetes.io/docs/tasks/tools/install-minikube/). +To run the integration tests on the minikube cluster. +```sh +make tet +``` + +## Git Development Workflow + +### Always sync your local repository: +Open a terminal on your local machine. Change directory to the velero-plugin fork root. + +```sh +$ cd $GOPATH/src/github.com/openebs/velero-plugin +``` + + Check out the master branch. + + ```sh + $ git checkout master + Switched to branch 'master' + Your branch is up-to-date with 'origin/master'. + ``` + + Recall that origin/master is a branch on your remote GitHub repository. + Make sure you have the upstream remote openebs/velero-plugin by listing them. + + ```sh + $ git remote -v + origin https://github.com/$user/velero-plugin.git (fetch) + origin https://github.com/$user/velero-plugin.git (push) + upstream https://github.com/openebs/velero-plugin.git (fetch) + upstream https://github.com/openebs/velero-plugin.git (no_push) + ``` + + If the upstream is missing, add it by using the below command. + + ```sh + $ git remote add upstream https://github.com/openebs/velero-plugin.git + ``` + Fetch all the changes from the upstream master branch. + + ```sh + $ git fetch upstream master + remote: Counting objects: 141, done. + remote: Compressing objects: 100% (29/29), done. + remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66 + Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done. + Resolving deltas: 100% (79/79), done. + From github.com:openebs/velero-plugin + * branch master -> FETCH_HEAD + ``` + + Rebase your local master with the upstream/master. + + ```sh + $ git rebase upstream/master + First, rewinding head to replay your work on top of it... + Fast-forwarded master to upstream/master. + ``` + This command applies all the commits from the upstream master to your local master. + + Check the status of your local branch. + + ```sh + $ git status + On branch master + Your branch is ahead of 'origin/master' by 12 commits. + (use "git push" to publish your local commits) + nothing to commit, working directory clean + ``` + Your local repository now has all the changes from the upstream remote. You need to push the changes to your remote fork which is origin master. + + Push the rebased master to origin master. + + ```sh + $ git push origin master + Username for 'https://github.com': $user + Password for 'https://$user@github.com': + Counting objects: 223, done. + Compressing objects: 100% (38/38), done. + Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done. + Total 69 (delta 53), reused 47 (delta 31) + To https://github.com/$user/velero-plugin.git + 8e107a9..5035fa1 master -> master + ``` + +### Contributing to a feature or bugfix. + +Always start with creating a new branch from master to work on a new feature or bugfix. Your branch name should have the format XX-descriptive where XX is the issue number you are working on followed by some descriptive text. For example: + + ```sh + $ git checkout master + # Make sure the master is rebased with the latest changes as described in the previous step. + $ git checkout -b 1234-fix-developer-docs + Switched to a new branch '1234-fix-developer-docs' + ``` +Happy Hacking! + +### Keep your branch in sync + +[Rebasing](https://git-scm.com/docs/git-rebase) is very important to keep your branch in sync with the changes being made by others and to avoid huge merge conflicts while raising your Pull Requests. You will always have to rebase before raising the PR. + +```sh +# While on your myfeature branch (see above) +git fetch upstream +git rebase upstream/master +``` + +While you rebase your changes, you must resolve any conflicts that might arise and build and test your changes using the above steps. + +## Submission + +### Create a pull request + +Before you raise the Pull Requests, ensure you have reviewed the checklist in the [CONTRIBUTING GUIDE](CONTRIBUTING.md): +- Ensure that you have re-based your changes with the upstream using the steps above. +- Ensure that you have added the required unit tests for the bug fix or a new feature that you have introduced. +- Ensure your commit history is clean with proper header and descriptions. + +Go to the [openebs/velero-plugin github](https://github.com/openebs/velero-plugin) and follow the Open Pull Request link to raise your PR from your development branch. +