You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ You can contribute to libcstor by filling an issue at [openebs/libcstor](https:/
8
8
9
9
* If you want to file an issue for bug or feature request, please see [Filing an issue](#filing-an-issue)
10
10
* If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute) and code standard(code-standard.md).
11
-
* 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)
11
+
* 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/HEAD/community)
12
12
13
13
## Filing an issue
14
14
### Before filing an issue
@@ -94,7 +94,7 @@ For setting up a development environment on your local machine, see the detailed
94
94
## Code Reviews
95
95
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.
96
96
97
-
* 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)
97
+
* 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/HEAD/community)
98
98
99
99
* If PR is fixing any issues from [github-issues](github.com/openebs/libcstor/issues) then you need to mention the issue number with a link in the PR description. like: _fixes https://github.com/openebs/libcstor/issues/56_
Copy file name to clipboardExpand all lines: RELEASE.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ Once all the above tests are completed, a main release tagged image is published
20
20
21
21
libcstor is released as a container image with a versioned tag.
22
22
23
-
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 release is for v1.9.0.
23
+
Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `develop`. Name of the branch should follow the naming convention of `v.1.9.x` if release is for v1.9.0.
24
24
25
25
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 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:
44
+
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 `develop` with the following details:
45
45
1. update the changelog from folder `changelog/v1.9.x` to file `libcstor/CHANGELOG-v1.9.md`
46
46
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 `libcstor/CHANGELOG-v1.9.md` as part of step number 1.
47
47
3. If a release is not an RC tag then
48
48
- PR should include the changes to remove files from `changelog/v1.9.x` folder.
49
-
- PR should update the root [CHANGELOG file](https://github.com/openebs/libcstor/blob/master/CHANGELOG.md) with contents of file `libcstor/CHANGELOG-v1.9.md`
49
+
- PR should update the root [CHANGELOG file](https://github.com/openebs/libcstor/blob/develop/CHANGELOG.md) with contents of file `libcstor/CHANGELOG-v1.9.md`
50
50
51
51
Format of the `libcstor/CHANGELOG-v1.9.md` file must be as below:
Copy file name to clipboardExpand all lines: code-standard.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
## Sign your commits
4
4
5
-
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:
5
+
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/HEAD/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
Integration tests are written in c and c+. Test script is maintained at https://github.com/openebs/libcstor/blob/master/tests/cstor/script/test_uzfs.sh
102
+
Integration tests are written in c and c+. Test script is maintained at https://github.com/openebs/libcstor/blob/HEAD/tests/cstor/script/test_uzfs.sh
103
103
To run the run the integration tests go to cstor directory and run below command.
104
104
```sh
105
105
../libcstor/tests/cstor/script/test_uzfs.sh -T all
@@ -114,15 +114,15 @@ Open a terminal on your local machine. Change directory to the libcstor fork roo
114
114
$ cd libcstor
115
115
```
116
116
117
-
Check out the master branch.
117
+
Check out the develop branch.
118
118
119
119
```sh
120
-
$ git checkout master
121
-
Switched to branch 'master'
122
-
Your branch is up-to-date with 'origin/master'.
120
+
$ git checkout develop
121
+
Switched to branch 'develop'
122
+
Your branch is up-to-date with 'origin/develop'.
123
123
```
124
124
125
-
Recall that origin/master is a branch on your remote GitHub repository.
125
+
Recall that origin/develop is a branch on your remote GitHub repository.
126
126
Make sure you have the upstream remote openebs/libcstor by listing them.
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:
190
+
Always start with creating a new branch from develop 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:
191
191
192
192
```sh
193
-
$ git checkout master
194
-
# Make sure the master is rebased with the latest changes as described in the previous step.
193
+
$ git checkout develop
194
+
# Make sure the develop is rebased with the latest changes as described in the previous step.
195
195
$ git checkout -b 1234-fix-developer-docs
196
196
Switched to a new branch '1234-fix-developer-docs'
197
197
```
@@ -204,7 +204,7 @@ Happy Hacking!
204
204
```sh
205
205
# While on your myfeature branch (see above)
206
206
git fetch upstream
207
-
git rebase upstream/master
207
+
git rebase upstream/develop
208
208
```
209
209
210
210
While you rebase your changes, you must resolve any conflicts that might arise and build and test your changes using the above steps.
0 commit comments