Update CONTRIBUTING.md Point Release Procedure (#7999)
* Update CONTRIBUTING.md * Update CONTRIBUTING.md Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com> * Update CONTRIBUTING.md Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com> * Update CONTRIBUTING.md Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com> * Update CONTRIBUTING.md Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com> * Update CONTRIBUTING.md Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com> * updates to concept & release approval process * update codeowners addition process * time bound updates * Update CONTRIBUTING.md Co-authored-by: Alessio Treglia <alessio@tendermint.com> Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com> Co-authored-by: Alessio Treglia <alessio@tendermint.com> Co-authored-by: Cory Levinson <cjlevinson@gmail.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This commit is contained in:
parent
227ac45dec
commit
2f1d8771df
101
CONTRIBUTING.md
101
CONTRIBUTING.md
|
@ -218,7 +218,7 @@ only pull requests targeted directly against master.
|
||||||
### Development Procedure
|
### Development Procedure
|
||||||
|
|
||||||
- the latest state of development is on `master`
|
- the latest state of development is on `master`
|
||||||
- `master` must never fail `make test` or `make test_cli`
|
- `master` must never fail `make lint test test-race`
|
||||||
- `master` should not fail `make lint`
|
- `master` should not fail `make lint`
|
||||||
- no `--force` onto `master` (except when reverting a broken commit, which should seldom happen)
|
- no `--force` onto `master` (except when reverting a broken commit, which should seldom happen)
|
||||||
- create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
|
- create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
|
||||||
|
@ -227,7 +227,7 @@ only pull requests targeted directly against master.
|
||||||
### Pull Merge Procedure
|
### Pull Merge Procedure
|
||||||
|
|
||||||
- ensure pull branch is rebased on `master`
|
- ensure pull branch is rebased on `master`
|
||||||
- run `make test` and `make test_cli` to ensure that all tests pass
|
- run `make test` to ensure that all tests pass
|
||||||
- merge pull request
|
- merge pull request
|
||||||
|
|
||||||
### Release Procedure
|
### Release Procedure
|
||||||
|
@ -306,9 +306,11 @@ new code owners is as follows: On a bi-monthly basis (or more frequently if
|
||||||
agreeable) all the existing code owners will privately convene to discuss
|
agreeable) all the existing code owners will privately convene to discuss
|
||||||
potential new candidates as well as the potential for existing code-owners to
|
potential new candidates as well as the potential for existing code-owners to
|
||||||
exit or "pass on the torch". This private meeting is to be a held as a
|
exit or "pass on the torch". This private meeting is to be a held as a
|
||||||
phone/video meeting. Subsequently at the end of the meeting, one of the existing
|
phone/video meeting.
|
||||||
code owners should open a PR modifying the `CODEOWNERS` file. The other code
|
|
||||||
owners should then all approve this PR to publicly display their support.
|
Subsequently after the meeting, and pending final approval from the ICF,
|
||||||
|
one of the existing code owners should open a PR modifying the `CODEOWNERS` file.
|
||||||
|
The other code owners should then all approve this PR to publicly display their support.
|
||||||
|
|
||||||
Only if unanimous consensus is reached among all the existing code-owners will
|
Only if unanimous consensus is reached among all the existing code-owners will
|
||||||
an invitation be extended to a new potential-member. Likewise, when an existing
|
an invitation be extended to a new potential-member. Likewise, when an existing
|
||||||
|
@ -318,6 +320,95 @@ should be taken. If however, a code-owner is demonstrably shown to intentionally
|
||||||
have had acted maliciously or grossly negligent, code-owner privileges may be
|
have had acted maliciously or grossly negligent, code-owner privileges may be
|
||||||
stripped with no prior warning or consent from the member in question.
|
stripped with no prior warning or consent from the member in question.
|
||||||
|
|
||||||
|
Other potential removal criteria:
|
||||||
|
* Missing 3 scheduled meetings results in ICF evaluating whether the member should be
|
||||||
|
removed / replaced
|
||||||
|
* Violation of Code of Conduct
|
||||||
|
|
||||||
Earning this privilege should be considered to be no small feat and is by no
|
Earning this privilege should be considered to be no small feat and is by no
|
||||||
means guaranteed by any quantifiable metric. It is a symbol of great trust of
|
means guaranteed by any quantifiable metric. It is a symbol of great trust of
|
||||||
the community of this project.
|
the community of this project.
|
||||||
|
|
||||||
|
|
||||||
|
## Concept & Release Approval Process
|
||||||
|
|
||||||
|
The process for how Cosmos SDK maintainers take features and ADRs from concept to release
|
||||||
|
is broken up into three distinct stages: **Strategy Discovery**, **Concept Approval**, and
|
||||||
|
**Implementation & Release Approval**
|
||||||
|
|
||||||
|
|
||||||
|
### Strategy Discovery
|
||||||
|
|
||||||
|
* Develop long term priorities, strategy and roadmap for the SDK
|
||||||
|
* Release committee not yet defined as there is already a roadmap that can be used for the time being
|
||||||
|
|
||||||
|
### Concept Approval
|
||||||
|
|
||||||
|
* Architecture Decision Records (ADRs) may be proposed by any contributors or maintainers of the Cosmos SDK,
|
||||||
|
and should follow the guidelines outlined in the
|
||||||
|
[ADR Creation Process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md)
|
||||||
|
* After proposal, a time bound period for Request for Comment (RFC) on ADRs commences
|
||||||
|
* ADRs are intended to be iterative, and may be merged into `master` while still in a `Proposed` status
|
||||||
|
|
||||||
|
**Time Bound Period**
|
||||||
|
|
||||||
|
* Once a PR for an ADR is opened, reviewers are expected to perform a first
|
||||||
|
review within 1 week of pull request being open
|
||||||
|
* Time bound period for individual ADR Pull Requests to be merged should not exceed 2 weeks
|
||||||
|
* Total time bound period for an ADR to reach a decision (`ABANDONED | ACCEPTED | REJECTED`) should not exceed 4 weeks
|
||||||
|
|
||||||
|
If an individual Pull Request for an ADR needs more time than 2 weeks to reach resolution, it should be merged
|
||||||
|
in current state (`Draft` or `Proposed`), with its contents updated to summarize
|
||||||
|
the current state of its discussion.
|
||||||
|
|
||||||
|
If an ADR is taking longer than 4 weeks to reach a final conclusion, the **Concept Approval Committee**
|
||||||
|
should convene to rectify the situation by either:
|
||||||
|
- unanimously setting a new time bound period for this ADR
|
||||||
|
- making changes to the Concept Approval Process (as outlined here)
|
||||||
|
- making changes to the members of the Concept Approval Committee
|
||||||
|
|
||||||
|
**Approval Committee & Decision Making**
|
||||||
|
|
||||||
|
In absense of general consensus, decision making requires ⅔ vote from the three members
|
||||||
|
of the **Concept Approval Committee**.
|
||||||
|
|
||||||
|
**Committee Members**
|
||||||
|
|
||||||
|
* Core Members: **Aaron** (Regen), **Bez** (Fission), **Alessio** (AiB)
|
||||||
|
* Secondary pool of candidates to replace / substitute:
|
||||||
|
* **Chris Goes** (IG), **Sunny** (Sikka)
|
||||||
|
|
||||||
|
**Committee Criteria**
|
||||||
|
|
||||||
|
Members must:
|
||||||
|
|
||||||
|
* Participate in all or almost all ADR discussions, both on Github as well as in bi-weekly Architecture Review
|
||||||
|
meetings
|
||||||
|
* Be active contributors to the SDK, and furthermore should be continuously making substantial contributions
|
||||||
|
to the project's codebase, review process, documentation and ADRs
|
||||||
|
* Have stake in the Cosmos SDK project, represented by:
|
||||||
|
* Being a client / user of the Comsos SDK
|
||||||
|
* "[giving back](https://www.debian.org/social_contract)" to the software
|
||||||
|
* Delegate representation in case of vacation or absence
|
||||||
|
|
||||||
|
Code owners need to maintain participation in the process, ideally as members of **Concept Approval Committee**
|
||||||
|
members, but at the very least as active participants in ADR discussions
|
||||||
|
|
||||||
|
Removal criteria:
|
||||||
|
|
||||||
|
* Missing 3 meetings results in ICF evaluating whether the member should be removed / replaced
|
||||||
|
* Violation of Code of Conduct
|
||||||
|
|
||||||
|
### Implementation & Release Approval
|
||||||
|
|
||||||
|
The following process should be adhered to both for implementation PRs corresponding to ADRs, as
|
||||||
|
well as for PRs made as part of a release process:
|
||||||
|
|
||||||
|
* Code reviewers should ensure the PR does exactly what the ADR said it should
|
||||||
|
* Code reviewers should have more senior engineering capability
|
||||||
|
* ⅔ approval is required from the **primary repo maintainers** in `CODEOWNERS`
|
||||||
|
* Secondary pool of candidates to replace / substitute are listed as **secondary repo maintainers** in `CODEOWNERS`
|
||||||
|
|
||||||
|
*Note: For any major or minor release series denoted as a "Stable Release" (e.g. v0.39 "Launchpad"), a separate release
|
||||||
|
committee is often established. Stable Releases, and their corresponding release committees are documented
|
||||||
|
separately in [STABLE_RELEASES.md](./STABLE_RELEASES.md)*
|
||||||
|
|
Loading…
Reference in New Issue