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
Thank you for considering making contributions to Cosmos-SDK and related
21
21
repositories!
@@ -80,12 +80,12 @@ All PRs require two Reviews before merge (except docs changes, or variable name-
80
80
81
81
-`LGTM` without an explicit approval means that the changes look good, but you haven't pulled down the code, run tests locally and thoroughly reviewed it.
82
82
-`Approval` through the GH UI means that you understand the code, documentation/spec is updated in the right places, you have pulled down and tested the code locally. In addition:
83
-
- You must also think through anything which ought to be included but is not
84
-
- You must think through whether any added code could be partially combined (DRYed) with existing code
85
-
- You must think through any potential security issues or incentive-compatibility flaws introduced by the changes
86
-
- Naming must be consistent with conventions and the rest of the codebase
87
-
- Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code).
88
-
- if you approve of the PR, you are responsible for fixing any of the issues mentioned here and more
83
+
- You must also think through anything which ought to be included but is not
84
+
- You must think through whether any added code could be partially combined (DRYed) with existing code
85
+
- You must think through any potential security issues or incentive-compatibility flaws introduced by the changes
86
+
- Naming must be consistent with conventions and the rest of the codebase
87
+
- Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code).
88
+
- if you approve of the PR, you are responsible for fixing any of the issues mentioned here and more
89
89
- If you sat down with the PR submitter and did a pairing review please note that in the `Approval`, or your PR comments.
90
90
- If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review.
91
91
@@ -229,10 +229,10 @@ should be targeted against the release candidate branch.
229
229
- Create the release candidate branch `rc/v*` (going forward known as **RC**)
230
230
and ensure it's protected against pushing from anyone except the release
231
231
manager/coordinator
232
-
- **no PRs targeting this branch should be merged unless exceptional circumstances arise**
232
+
- **no PRs targeting this branch should be merged unless exceptional circumstances arise**
233
233
- On the `RC` branch, prepare a new version section in the `CHANGELOG.md`
234
-
- All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
235
-
- Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on github.
234
+
- All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
235
+
- Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on github.
236
236
- Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
237
237
- If errors are found during the simulation testing, commit the fixes to `master`
238
238
and create a new `RC` branch (making sure to increment the `rcN`)
@@ -314,22 +314,21 @@ have had acted maliciously or grossly negligent, code-owner privileges may be
314
314
stripped with no prior warning or consent from the member in question.
315
315
316
316
Other potential removal criteria:
317
-
* Missing 3 scheduled meetings results in ICF evaluating whether the member should be
317
+
318
+
* Missing 3 scheduled meetings results in ICF evaluating whether the member should be
318
319
removed / replaced
319
-
* Violation of Code of Conduct
320
+
* Violation of Code of Conduct
320
321
321
322
Earning this privilege should be considered to be no small feat and is by no
322
323
means guaranteed by any quantifiable metric. It is a symbol of great trust of
323
324
the community of this project.
324
325
325
-
326
326
## Concept & Release Approval Process
327
327
328
328
The process for how Cosmos SDK maintainers take features and ADRs from concept to release
329
329
is broken up into three distinct stages: **Strategy Discovery**, **Concept Approval**, and
330
330
**Implementation & Release Approval**
331
331
332
-
333
332
### Strategy Discovery
334
333
335
334
* Develop long term priorities, strategy and roadmap for the SDK
@@ -356,6 +355,7 @@ the current state of its discussion.
356
355
357
356
If an ADR is taking longer than 4 weeks to reach a final conclusion, the **Concept Approval Committee**
358
357
should convene to rectify the situation by either:
358
+
359
359
- unanimously setting a new time bound period for this ADR
360
360
- making changes to the Concept Approval Process (as outlined here)
361
361
- making changes to the members of the Concept Approval Committee
@@ -378,8 +378,8 @@ Members must:
378
378
* Be active contributors to the SDK, and furthermore should be continuously making substantial contributions
379
379
to the project's codebase, review process, documentation and ADRs
380
380
* Have stake in the Cosmos SDK project, represented by:
381
-
* Being a client / user of the Comsos SDK
382
-
* "[giving back](https://www.debian.org/social_contract)" to the software
381
+
* Being a client / user of the Comsos SDK
382
+
* "[giving back](https://www.debian.org/social_contract)" to the software
383
383
* Delegate representation in case of vacation or absence
384
384
385
385
Code owners need to maintain participation in the process, ideally as members of **Concept Approval Committee**
Copy file name to clipboardExpand all lines: STABLE_RELEASES.md
+20-17
Original file line number
Diff line number
Diff line change
@@ -52,13 +52,13 @@ To smoothen the update to the latest stable release, the SDK includes a set of C
52
52
### What qualifies as a Stable Release Update (SRU)
53
53
54
54
***High-impact bugs**
55
-
* Bugs that may directly cause a security vulnerability.
56
-
**Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues
55
+
* Bugs that may directly cause a security vulnerability.
56
+
**Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues
57
57
that may cause the core packages or the `x/` modules unusable.
58
-
* Bugs that may cause **loss of user's data**.
58
+
* Bugs that may cause **loss of user's data**.
59
59
* Other safe cases:
60
-
* Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known.
61
-
* Relatively small yet strictly non-breaking changes that introduce forward-compatible client
60
+
* Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known.
61
+
* Relatively small yet strictly non-breaking changes that introduce forward-compatible client
62
62
features to smoothen the migration to successive releases.
63
63
64
64
### What does not qualify as SRU
@@ -71,27 +71,29 @@ To smoothen the update to the latest stable release, the SDK includes a set of C
71
71
72
72
Pull requests that fix bugs that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release:
73
73
74
-
***Severe regressions**.
75
-
* Bugs that may cause **client applications** to be **largely unusable**.
76
-
* Bugs that may cause **state corruption or data loss**.
77
-
* Bugs that may directly or indirectly cause a **security vulnerability**.
74
+
***Severe regressions**.
75
+
* Bugs that may cause **client applications** to be **largely unusable**.
76
+
* Bugs that may cause **state corruption or data loss**.
77
+
* Bugs that may directly or indirectly cause a **security vulnerability**.
78
78
79
79
## What pull requests will NOT be automatically included in stable point-releases
80
80
81
81
As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases:
82
82
83
-
***State machine changes**.
84
-
***Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
83
+
***State machine changes**.
84
+
***Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
85
85
86
86
In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a *Stable Release Exception*.
87
87
88
88
## Stable Release Exception - Procedure
89
89
90
90
1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [0.42 «Stargate»](https://github.com/cosmos/cosmos-sdk/labels/0.42%20LTS%20%28Stargate%29) to the issue.
91
91
2. Add a comment to the issue and ensure it contains the following information (see the bug template below):
92
-
***[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release.
93
-
* A **[Test Case]** section containing detailed instructions on how to reproduce the bug.
94
-
* A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release.
92
+
93
+
***[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release.
94
+
* A **[Test Case]** section containing detailed instructions on how to reproduce the bug.
95
+
* A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release.
96
+
95
97
3.**Stable Release Managers** will review and discuss the PR. Once *consensus* surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/v0.42.x`) and the PR included in the point-release's respective milestone (e.g. `0.42.5`).
96
98
97
99
### Stable Release Exception - Bug template
@@ -119,9 +121,10 @@ according to the [stable release policy](#stable-release-policy) and [release pr
119
121
Decisions are made by consensus.
120
122
121
123
Their responsibilites include:
122
-
* Driving the Stable Release Exception process.
123
-
* Approving/rejecting proposed changes to a stable release series.
124
-
* Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md).
124
+
125
+
* Driving the Stable Release Exception process.
126
+
* Approving/rejecting proposed changes to a stable release series.
127
+
* Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md).
125
128
126
129
The Stable Release Managers are appointed by the Interchain Foundation. Currently residing Stable Release Managers:
Copy file name to clipboardExpand all lines: cosmovisor/README.md
+8-5
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ if there was an error.
28
28
29
29
## Data Folder Layout
30
30
31
-
`$DAEMON_HOME/cosmovisor` is expected to belong completely to `cosmovisor` and
31
+
`$DAEMON_HOME/cosmovisor` is expected to belong completely to `cosmovisor` and
32
32
subprocesses that are controlled by it. The folder content is organised as follows:
33
33
34
34
```
@@ -66,6 +66,7 @@ directory layout:
66
66
## Usage
67
67
68
68
The system administrator admin is responsible for:
69
+
69
70
* installing the `cosmovisor` binary and configure the host's init system (e.g. `systemd`, `launchd`, etc) along with the environmental variables appropriately;
70
71
* installing the `genesis` folder manually;
71
72
* installing the `upgrades/<name>` folders manually.
@@ -95,19 +96,21 @@ valid format to specify a download in such a message:
95
96
96
97
1. Store an os/architecture -> binary URI map in the upgrade plan info field
0 commit comments