Skip to content

Commit

Permalink
docs(release): fixing project tracker link for openebs (#71)
Browse files Browse the repository at this point in the history 
* fixing project tracker link for openebs
* fixing the link and updating changelog with example
* Adding image information for ARM64 in README and RELEASE file
* adding release and license label in readme
* updating CODE_OF_CONDUCT.md
* adding design doc link in CONTRIBUTING.md

Signed-off-by: mayank <[email protected]>
  • Loading branch information
@mynktl
mynktl authored May 5, 2020
1 parent e8a01d2 commit 90171f7
Show file tree
Hide file tree
Showing 6 changed files with 100 additions and 59 deletions.
36 changes: 32 additions & 4 deletions .github/pull_request_template.md
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,37 @@
## 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: `<type>(<scope>): <subject>`.
Please, go through these steps before you submit a PR. ## Remove this line

**Why is this PR required? What issue does it fix?**:


**What this PR does?**:


**Does this PR require any upgrade changes?**:


**If the changes in this PR are manually verified, list down the scenarios covered and commands you used for testing with logs:**


**Any additional information for your reviewer?**:
_Mention if this PR is part of any design or a continuation of previous PRs_


**Checklist:**
- [ ] Fixes #<issue number>
- [ ] PR Title follows the convention of `<type>(<scope>): <subject>`
- [ ] Has the change log section been updated?
- [ ] Commit has unit tests
- [ ] Commit has integration tests
- [ ] (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
- [ ] (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:


**PLEASE REMOVE THIS TEMPLATE BEFORE SUBMITTING**

PR title/commit message must follow convention: `<type>(<scope>): <subject>`.

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
Expand All @@ -12,5 +42,3 @@ Please, go through these steps before you submit a PR.
* `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**
47 changes: 2 additions & 45 deletions CODE_OF_CONDUCT.md
View file
Original file line number Diff line number Diff line change
@@ -1,46 +1,3 @@
# Contributor Covenant Code of Conduct
## Community 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 [email protected]. 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/
This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
9 changes: 6 additions & 3 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -68,8 +68,8 @@ For setting up a development environment on your local machine, see the detailed
- 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)
- 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: `<type>(<scope>): <subject>`.

For example:
Expand Down Expand Up @@ -101,7 +101,10 @@ All submissions, including submissions by project members, require review. We us

* 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.
* 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 and their changelog files are created under `changelogs/v1.9.x` instead of `changelogs/unreleased`, if release branch is `v1.10.x` then this folder will be `changelogs/v1.10.x`

## Design document
Detailed design document for velero-plugin is available at [Google Doc](https://docs.google.com/document/d/1-4WsM0AjLORb3lTCUUGyYOY_LNdTOATFesi7kTAr7SA).

### For maintainers
* We are using labeling for PR to track it more effectively. The following are valid labels for the PR.
Expand Down
10 changes: 9 additions & 1 deletion README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,8 @@ OpenEBS velero-plugin.
[![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)
[![Releases](https://img.shields.io/github/v/release/openebs/velero-plugin.svg?include_prereleases&style=flat-square)](https://github.com/openebs/velero-plugin/releases)
[![LICENSE](https://img.shields.io/github/license/openebs/velero-plugin.svg?style=flat-square)](https://github.com/openebs/velero-plugin/blob/master/LICENSE)

## Table of Contents
- [Compatibility matrix](#compatibility-matrix)
Expand Down Expand Up @@ -51,7 +53,11 @@ _OpenEBS version **< 0.9** is not supported for velero-plugin._

_If you want to use plugin image from development branch(`master`), use **ci** tag._

Plugin images are available at [quay.io](http://quay.io/openebs/velero-plugin) and [hub.docker.com](https://hub.docker.com/r/openebs/velero-plugin/tags).
Plugin images are available at:

For AMD64: [quay.io](http://quay.io/openebs/velero-plugin) and [hub.docker.com](https://hub.docker.com/r/openebs/velero-plugin/tags).

For ARM64: [quay.io](https://quay.io/repository/openebs/velero-plugin-arm64?tab=tags) and [hub.docker.com](https://hub.docker.com/r/openebs/velero-plugin-arm64/tags).

## Prerequisite for velero-plugin
A Specific version of Velero needs to be installed as per the [compatibility matrix](#Compatibility-matrix) with OpenEBS versions.
Expand All @@ -65,6 +71,8 @@ Run the following command to install development image of OpenEBS velero-plugin

`velero plugin add openebs/velero-plugin:1.9.0`

For ARM64, change image name to `openebs/velero-plugin-arm64`.

This command will add an init container to Velero deployment to install the OpenEBS velero-plugin.

## Developer Guide
Expand Down
47 changes: 41 additions & 6 deletions RELEASE.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# 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).
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/orgs/openebs/projects).

## Release Candidate Verification Checklist

Expand All @@ -22,17 +22,52 @@ 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`.
Once the release branch is created, changelog from folder `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:
for AMD64:
```
https://quay.io/repository/openebs/velero-plugin?tab=tags
https://hub.docker.com/r/openebs/velero-plugin/tags
```
for ARM64:
```
https://quay.io/repository/openebs/velero-plugin-arm64?tab=tags
https://hub.docker.com/r/openebs/velero-plugin-arm64/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.

Once a release is created, update the release description with the changelog mentioned in folder `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 folder `changelog/v1.9.x` to file `velero-plugin/CHANGELOG-v1.9.md`
2. If a release is an RC tag then PR should include the changes to remove the changelog from folder`changelog/v1.9.x` which are already mentioned in `velero-plugin/CHANGELOG-v1.9.md` as part of step number 1.
3. If a release is not an RC tag then
- PR should include the changes to remove files from `changelog/v1.9.x` folder.
- PR should update the root [CHANGELOG file](https://github.com/openebs/velero-plugin/blob/master/CHANGELOG.md) with contents of file `velero-plugin/CHANGELOG-v1.9.md`

Format of the `velero-plugin/CHANGELOG-v1.9.md` file must be as below:
```
1.9.0 / 2020-04-14
========================
* ARM build for velero-plugin, ARM image is published under openebs/velero-plugin-arm64 ([#61](https://github.com/openebs/velero-plugin/pull/61),[@akhilerm](https://github.com/akhilerm))
* Updating alpine image version for velero-plugin to 3.10.4 ([#64](https://github.com/openebs/velero-plugin/pull/64),[@mynktl](https://github.com/mynktl))
* support for local snapshot and restore(in different namespace) ([#53](https://github.com/openebs/velero-plugin/pull/53),[@mynktl](https://github.com/mynktl))
* added support for multiPartChunkSize for S3 based remote storage ([#55](https://github.com/openebs/velero-plugin/pull/55),[@mynktl](https://github.com/mynktl))
* added auto clean-up of CStor volume snapshot generated for remote backup ([#57](https://github.com/openebs/velero-plugin/pull/57),[@mynktl](https://github.com/mynktl))
1.9.0-RC2 / 2020-04-12
========================
* ARM build for velero-plugin, ARM image is published under openebs/velero-plugin-arm64 ([#61](https://github.com/openebs/velero-plugin/pull/61),[@akhilerm](https://github.com/akhilerm))
* Updating alpine image version for velero-plugin to 3.10.4 ([#64](https://github.com/openebs/velero-plugin/pull/64),[@mynktl](https://github.com/mynktl))
1.9.0-RC1 / 2020-04-08
========================
* support for local snapshot and restore(in different namespace) ([#53](https://github.com/openebs/velero-plugin/pull/53),[@mynktl](https://github.com/mynktl))
* added support for multiPartChunkSize for S3 based remote storage ([#55](https://github.com/openebs/velero-plugin/pull/55),[@mynktl](https://github.com/mynktl))
* added auto clean-up of CStor volume snapshot generated for remote backup ([#57](https://github.com/openebs/velero-plugin/pull/57),[@mynktl](https://github.com/mynktl))
```
10 changes: 10 additions & 0 deletions code-standard.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,3 +22,13 @@ If PR is about adding a new feature or bug fix then the Author of the PR is expe
velero-plugin/changelogs/unreleased <- folder
12-github_user_name <- file
```

For example, if `xyz` user has raised a PR `16` to add support for s3 base storage for remote backup then
channgelog file name will be
```sh
velero-plugin/changelogs/unreleased/15-xyz
```
and content of the file will be
```sh
adding support for s3 base storage for remote backup
```

0 comments on commit 90171f7

Please sign in to comment.