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:
Aaron Craelius
GitHub
parent
227ac45dec
commit
2f1d8771df
101
CONTRIBUTING.md
101
CONTRIBUTING.md
|
|
@ -218,7 +218,7 @@ only pull requests targeted directly against master.
|
|||
### Development Procedure
|
||||
|
||||
- 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`
|
||||
- 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`)
|
||||
|
|
@ -227,7 +227,7 @@ only pull requests targeted directly against master.
|
|||
### Pull Merge Procedure
|
||||
|
||||
- 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
|
||||
|
||||
### 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
|
||||
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
|
||||
phone/video meeting. Subsequently at the end of the meeting, 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.
|
||||
phone/video meeting.
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
means guaranteed by any quantifiable metric. It is a symbol of great trust of
|
||||
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