-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #87 from zeta-chain/fix-dependencies
fix: dependencies should not point to upstream
- Loading branch information
Showing
301 changed files
with
1,546 additions
and
1,666 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,31 +1,13 @@ | ||
| # Contributing | ||
|
|
||
| - [Contributing](#contributing) | ||
| - [Architecture Decision Records (ADR)](#architecture-decision-records-adr) | ||
| - [Pull Requests](#pull-requests) | ||
| - [Pull Request Templates](#pull-request-templates) | ||
| - [Requesting Reviews](#requesting-reviews) | ||
| - [Reviewing Pull Requests](#reviewing-pull-requests) | ||
| - [Forking](#forking) | ||
| - [Dependencies](#dependencies) | ||
| - [Protobuf](#protobuf) | ||
| - [Testing](#testing) | ||
| - [Branching Model and Release](#branching-model-and-release) | ||
| - [PR Targeting](#pr-targeting) | ||
| - [Development Procedure](#development-procedure) | ||
| - [Pull Merge Procedure](#pull-merge-procedure) | ||
| - [Release Procedure](#release-procedure) | ||
| - [Point Release Procedure](#point-release-procedure) | ||
| - [Code Owner Membership](#code-owner-membership) | ||
|
|
||
| Thank you for considering making contributions to Ethermint! | ||
|
|
||
| Contributing to this repo can mean many things such as participating in | ||
| discussion or proposing code changes. To ensure a smooth workflow for all | ||
| contributors, the general procedure for contributing has been established: | ||
|
|
||
| 1. Either [open](https://github.com/evmos/ethermint/issues/new/choose) or | ||
| [find](https://github.com/evmos/ethermint/issues) an issue you'd like to help with | ||
| 1. Either [open](https://github.com/zeta-chain/ethermint/issues/new/choose) or | ||
| [find](https://github.com/zeta-chain/ethermint/issues) an issue you'd like to help with | ||
| 2. Participate in thoughtful discussion on that issue | ||
| 3. If you would like to contribute: | ||
| 1. If the issue is a proposal, ensure that the proposal has been accepted | ||
|
|
@@ -35,10 +17,9 @@ contributors, the general procedure for contributing has been established: | |
| make a comment on the issue to inform the community of your intentions | ||
| to begin work | ||
| 4. Follow standard GitHub best practices: fork the repo, branch from the | ||
| HEAD of `main`, make some commits, and submit a PR to `main` | ||
| - For core developers working within the ethermint repo, to ensure a clear | ||
| ownership of branches, branches must be named with the convention | ||
| `{moniker}/{issue#}-branch-name` | ||
| HEAD of `main`, make some commits, and submit a PR to `main` - For core developers working within the ethermint repo, to ensure a clear | ||
| ownership of branches, branches must be named with the convention | ||
| `{moniker}/{issue#}-branch-name` | ||
| 5. Be sure to submit the PR in `Draft` mode submit your PR early, even if | ||
| it's incomplete as this indicates to the community you're working on | ||
| something and allows them to provide comments early in the development process | ||
|
|
@@ -54,7 +35,7 @@ taken place in a GitHub issue, that PR runs a high likelihood of being rejected. | |
| Other notes: | ||
|
|
||
| - Looking for a good place to start contributing? How about checking out some | ||
| [good first issues](https://github.com/evmos/ethermint/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) | ||
| [good first issues](https://github.com/zeta-chain/ethermint/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) | ||
| - Please make sure to run `make format` before every commit - the easiest way | ||
| to do this is have your editor run it for you upon saving a file. Additionally | ||
| please ensure that your code is lint compliant by running `make lint-fix`. | ||
|
|
@@ -63,12 +44,12 @@ Other notes: | |
|
|
||
| ## Architecture Decision Records (ADR) | ||
|
|
||
| When proposing an architecture decision for Ethermint, please start by opening an [issue](https://github.com/evmos/ethermint/issues/new/choose) or a [discussion](https://github.com/evmos/ethermint/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/evmos/ethermint/blob/main/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/evmos/ethermint/tree/main/docs/architecture). | ||
| When proposing an architecture decision for Ethermint, please start by opening an [issue](https://github.com/zeta-chain/ethermint/issues/new/choose) or a [discussion](https://github.com/zeta-chain/ethermint/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/zeta-chain/ethermint/blob/main/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/zeta-chain/ethermint/tree/main/docs/architecture). | ||
|
|
||
| ## Pull Requests | ||
|
|
||
| PRs should be categorically broken up based on the type of changes being made (for example, `fix`, `feat`, | ||
| `refactor`, `docs`, and so on). The *type* must be included in the PR title as a prefix (for example, | ||
| `refactor`, `docs`, and so on). The **type** must be included in the PR title as a prefix (for example, | ||
| `fix: <description>`). This convention ensures that all changes that are committed to the base branch follow the | ||
| [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. | ||
| Additionally, each PR should only address a single issue. | ||
|
|
@@ -95,13 +76,7 @@ for all checked items unless they have indicated otherwise by leaving their hand | |
| items. In addition, use the following review explanations: | ||
|
|
||
| - `LGTM` without an explicit approval means that the changes look good, but you haven't thoroughly reviewed the reviewer checklist items. | ||
| - `Approval` means that you have completed some or all of the reviewer checklist items. If you only reviewed selected items, you must add your handle next to the items that you have reviewed. In addition, follow these guidelines: | ||
| - You must also think through anything which ought to be included but is not | ||
| - You must think through whether any added code could be partially combined (DRYed) with existing code | ||
| - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes | ||
| - Naming must be consistent with conventions and the rest of the codebase | ||
| - Code must live in a reasonable location, considering dependency structures (for example, not importing testing modules in production code, or including example code modules in production code). | ||
| - If you approve the PR, you are responsible for any issues mentioned here and any issues that should have been addressed after thoroughly reviewing the reviewer checklist items in the pull request template. | ||
| - `Approval` means that you have completed some or all of the reviewer checklist items. If you only reviewed selected items, you must add your handle next to the items that you have reviewed. In addition, follow these guidelines: - You must also think through anything which ought to be included but is not - You must think through whether any added code could be partially combined (DRYed) with existing code - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes - Naming must be consistent with conventions and the rest of the codebase - Code must live in a reasonable location, considering dependency structures (for example, not importing testing modules in production code, or including example code modules in production code). - If you approve the PR, you are responsible for any issues mentioned here and any issues that should have been addressed after thoroughly reviewing the reviewer checklist items in the pull request template. | ||
| - If you sat down with the PR submitter and did a pairing review, add this information in the `Approval` or your PR comments. | ||
| - If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review. | ||
|
|
||
|
|
@@ -111,12 +86,12 @@ Go requires code to live under absolute paths, and this requirement complicates | |
| While my fork lives at `https://github.com/rigeyrigerige/ethermint`, | ||
| the code should never exist at `$GOPATH/src/github.com/rigeyrigerige/ethermint`. | ||
| Instead, we use `git remote` to add the fork as a new remote for the original repo, | ||
| `$GOPATH/src/github.com/evmos/ethermint`, and do all the work there. | ||
| `$GOPATH/src/github.com/zeta-chain/ethermint`, and do all the work there. | ||
|
|
||
| For instance, to create a fork and work on a branch of it, I would: | ||
|
|
||
| - Create the fork on GitHub, using the fork button. | ||
| - Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/evmos/ethermint`) | ||
| - Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/zeta-chain/ethermint`) | ||
| - `git remote rename origin upstream` | ||
| - `git remote add origin [email protected]:rigeyrigerige/ethermint.git` | ||
|
|
||
|
|
@@ -163,12 +138,12 @@ For example, in vscode your `.vscode/settings.json` should look like: | |
|
|
||
| ```json | ||
| { | ||
| "protoc": { | ||
| "options": [ | ||
| "--proto_path=${workspaceRoot}/proto", | ||
| "--proto_path=${workspaceRoot}/third_party/proto" | ||
| ] | ||
| } | ||
| "protoc": { | ||
| "options": [ | ||
| "--proto_path=${workspaceRoot}/proto", | ||
| "--proto_path=${workspaceRoot}/third_party/proto" | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
|
|
@@ -192,10 +167,10 @@ Here is an example check: | |
| ```go | ||
| <some table> | ||
| for tcIndex, tc := range cases { | ||
| <some code> | ||
| for i := 0; i < tc.numTxsToTest; i++ { | ||
| <some code> | ||
| require.Equal(t, expectedTx[:32], calculatedTx[:32], "First 32 bytes of the txs differed. tc #%d, i #%d", tcIndex, i) | ||
| <some code> | ||
| for i := 0; i < tc.numTxsToTest; i++ { | ||
| <some code> | ||
| require.Equal(t, expectedTx[:32], calculatedTx[:32], "First 32 bytes of the txs differed. tc #%d, i #%d", tcIndex, i) | ||
| ``` | ||
| ## Branching Model and Release | ||
|
|
@@ -219,7 +194,7 @@ should be targeted against the release candidate branch. | |
| - `main` must never fail `make lint test test-race` | ||
| - `main` should not fail `make lint` | ||
| - no `--force` onto `main` (except when reverting a broken commit, which should seldom happen) | ||
| - create a development branch either on github.com/evmos/ethermint, or your fork (using `git remote add origin`) | ||
| - create a development branch either on github.com/zeta-chain/ethermint, or your fork (using `git remote add origin`) | ||
| - before submitting a pull request, begin `git rebase` on top of `main` | ||
| ### Pull Merge Procedure | ||
|
|
@@ -233,11 +208,8 @@ should be targeted against the release candidate branch. | |
| - Start on `main` | ||
| - Create the release candidate branch `release/v<major>.<minor>.x` (going forward known as **RC**) | ||
| and ensure it's protected against pushing from anyone except the release | ||
| manager/coordinator | ||
| - **no PRs targeting this branch should be merged unless exceptional circumstances arise** | ||
| - On the `RC` branch, prepare a new version section in the `CHANGELOG.md` | ||
| - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md` | ||
| - 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. | ||
| manager/coordinator - **no PRs targeting this branch should be merged unless exceptional circumstances arise** | ||
| - On the `RC` branch, prepare a new version section in the `CHANGELOG.md` - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md` - 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. | ||
| - Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks) | ||
| - If errors are found during the simulation testing, commit the fixes to `main` | ||
| and push the changes to the `RC` branch | ||
|
|
@@ -320,7 +292,7 @@ stripped with no prior warning or consent from the member in question. | |
| Other potential removal criteria: | ||
| - Missing 3 scheduled meetings results in Tharsis evaluating whether the member should be | ||
| removed / replaced | ||
| removed / replaced | ||
| - Violation of Code of Conduct | ||
| Earning this privilege should be considered to be no small feat and is by no | ||
|
|
@@ -341,8 +313,8 @@ is broken up into three distinct stages: **Strategy Discovery**, **Concept Appro | |
| ### Concept Approval | ||
| - Architecture Decision Records (ADRs) may be proposed by any contributors or maintainers of Ethermint, | ||
| and should follow the guidelines outlined in the | ||
| [ADR Creation Process](https://github.com/evmos/ethermint/blob/main/docs/architecture/PROCESS.md) | ||
| and should follow the guidelines outlined in the | ||
| [ADR Creation Process](https://github.com/zeta-chain/ethermint/blob/main/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 `main` while still in a `Proposed` status | ||
|
|
@@ -381,9 +353,7 @@ Members must: | |
| meetings | ||
| - Be active contributors to Ethermint, and furthermore should be continuously making substantial contributions | ||
| to the project's codebase, review process, documentation and ADRs | ||
| - Have stake in Ethermint, represented by: | ||
| - Being a client / user of Ethermint | ||
| - "[giving back](https://www.debian.org/social_contract)" to the software | ||
| - Have stake in Ethermint, represented by: - Being a client / user of Ethermint - "[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** | ||
|
|
@@ -405,4 +375,4 @@ well as for PRs made as part of a release process: | |
| > 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)* | ||
| > separately in [STABLE_RELEASES.md](./STABLE_RELEASES.md)\* | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.