Skip to content

Commit

Permalink
Merge branch 'master' into fix-hb-v2-monitor-after-nodes-restart
Browse files Browse the repository at this point in the history
  • Loading branch information
iulianpascalau authored Oct 21, 2022
2 parents 4fe2d19 + 821d981 commit 8ff569c
Show file tree
Hide file tree
Showing 2 changed files with 38 additions and 7 deletions.
34 changes: 29 additions & 5 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,15 +3,19 @@

If you are unfamiliar with the workflow of contributing to github, you can refer to this [this article](https://github.com/firstcontributions/first-contributions/blob/master/README.md)

## Fork & clone this repository
## External contributions

The development should happen in a personal fork, cloned on the local machine.
If you are not part of the team and want to contribute to this repository, you must fork & clone this repository

## Use development branch
The development should happen in a personal fork, cloned on the local machine. **Make sure you use signed commits before opening** a pull request.

External contributions should happen against the `development` branch.
For external contributors, the PRs should be targeted towards the `master` branch. A team responsible will instruct
the PR owner to re-target it against another branch, in accordance to internal branches management.

Other branches may be used by the team members in accordance to internal decisions.
**tl;dr**:
- fork `elrond-go` and use `master` branch.
- use signed commits. [docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits).
- open a PR against the `master` branch of `ElrondNetwork/elrond-go`.

## Use linter

Expand Down Expand Up @@ -44,3 +48,23 @@ Although the nominal use case looks good, the linter runs without issues, as wel
Depending on the PR type, there are multiple ways of manual testing the new code:
- if it only affects an API, a log, or something not critical, one could sync a node with new code on Testnet or Devnet and see if everything works good.
- if the changes would affect the entire network (consensus, processing, and so on), a local testnet should be started. Also, make sure backwards compatibility is maintained.

## Branches management

Internal Branches/Releases Management (to be checked by both the code owner and the reviewers)

### `elrond-go`
If the PR is:
1. a hotfix: it will be targeted towards `master` branch.
2. a feature:
2.1. a small feature (a single PR is needed): targeted towards an `rc` branch.
2.2. a big feature (more than one PR is needed): create a feature branch (`feat/...`) that is targeted towards an `rc` branch.

### Satellite projects (`elrond-vm-common`, `elrond-go-core`, and so on)
If the PR is:
1. a hotfix: it will be targeted towards `master`/`main` branch.
2. a feature:
2.1. a small feature (a single PR is needed): targeted towards an `rc` branch and create a new tag&release after merging, and reference it in `elrond-go` (if needed).
2.2. a big feature:
2.2.1. a small satellite PR: targeted towards an `rc` branch. For each change, reference just the commit hash on `elrond-go` and create a tag&pre-release when the `elrond-go` PR is to be merged.
2.2.2. a big satellite PR: create a feature branch (`feat/...`) targeted towards an `rc` branch. For each change, reference just the commit hash on `elrond-go` and create a tag&pre-release when the `feat` branch is merged
11 changes: 9 additions & 2 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
## Description of the reasoning behind the pull request (what feature was missing / how the problem was manifesting itself / what was the motive behind the refactoring)
## Reasoning behind the pull request
-
-
-

## Proposed Changes
## Proposed changes
-
-
-
Expand All @@ -12,3 +12,10 @@
-
-
-

## Pre-requisites

Based on the [Contributing Guidelines](CONTRIBUTING.md#branches-management) the PR author and the reviewers must check the following requirements are met:
- was the PR targeted to the correct branch?
- if this is a larger feature that probably needs more than one PR, is there a `feat` branch created?
- if this is a `feat` branch merging, do all satellite projects have a proper tag inside `go.mod`?

0 comments on commit 8ff569c

Please sign in to comment.