mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-04-27 17:28:00 +00:00
DemiMarie-parity
62b97a090d
* Update all dependencies * Upgrade dependencies whenever “easy” “easy” means that there are no major changes required. * Fix build and bump paste dependency to 0.1.6 * Remove dead code * Re-add = dependency for futures-preview * Add missing std features for runtime-io * Remove git dependencies as updated versions have been published to crates.io * try to debug bug * For sr-io, "std" should imply "no_oom" and "no_panic_handler". Otherwise, rustc complains (correctly) about duplicate lang items. * Add missing "runtime-io/std" features * Fix compilation errors * Prevent duplicate lang items Rust does not allow duplicate lang items. When compiled without the `std` feature, `sr-io` defines two lang items. Therefore, `sr-io` compiled without `feature = "std"` must not be linked with `std`. However, `pwasm-utils` and `wasmi-validation` both bring in `std` unless compiled with `default-features = "false"`. This caused a duplicate lang item error. Building both with `default-features = "false"` prevents this error. When building with `feature = "std"`, they should both be built with the `std` feature, so this feature needs to be explicitly depended on. * Bump `impl_version` * Make tests pass Three tests used 1 less gas than they had previously. * Try to un-break build * Add a Cargo.lock file * Revert offchain code * Revert "Revert offchain code" This reverts commit d216d08cc6ca0344614669c1d24cde3aa5c0d4e2. * Don’t try to send a body with a GET request without adding a Transfer-Encoding or Content-Length header. This has always been wrong, but hyperium/hyper#1925 hid the bug until hyper was upgraded to 0.12.35. * Change some more GET requests to POST requests * Fix excess line width and remove an `extern crate` * Delete commented-out extern crate Co-Authored-By: Sergei Pepyakin <sergei@parity.io> * Fix regression in Cargo.toml files dev-dependencies need `default-features = false`, too. * Bump parity-wasm dependency * Bump `futures-preview` * Apply suggestions from code review Co-Authored-By: Bastian Köcher <bkchr@users.noreply.github.com> * Update Cargo.lock files * Apply suggestions from code review Co-Authored-By: Bastian Köcher <bkchr@users.noreply.github.com> * Update core/service/src/chain_ops.rs Co-Authored-By: Sergei Pepyakin <sergei@parity.io>
78 lines
5.5 KiB
Plaintext
78 lines
5.5 KiB
Plaintext
= Contributing
|
|
|
|
The `Substrate` project is an **OPENISH Open Source Project**
|
|
|
|
== What?
|
|
|
|
Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.
|
|
|
|
== Rules
|
|
|
|
There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
|
|
|
|
. **No `--force` pushes** or modifying the master branch history in any way. If you need to rebase, ensure you do it in your own repo.
|
|
. **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be used for ongoing work.
|
|
. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
|
|
. A pull-request *must not be merged until CI* has finished successfully.
|
|
. Contributors should adhere to the https://wiki.parity.io/Substrate-Style-Guide[house coding style].
|
|
|
|
|
|
== Merge Process
|
|
|
|
Merging pull requests once CI is successful:
|
|
|
|
. A PR needs to be reviewed and approved by project maintainers unless:
|
|
- it does not alter any logic (e.g. comments, dependencies, docs), then it may be tagged https://github.com/paritytech/substrate/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3AA2-insubstantial[`insubstantial`] and merged by its author once CI is complete.
|
|
- it is an urgent fix with no large change to logic, then it may be merged after a non-author contributor has approved the review once CI is complete.
|
|
|
|
. Once a PR is ready for review please add the https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aopen+label%3AA0-pleasereview[`pleasereview`] label. Generally PRs should sit with this label for 48 hours in order to garner feedback. It may be merged before if all relevant parties had a look at it.
|
|
. PRs that break the external API must be tagged with https://github.com/paritytech/substrate/labels/B2-breaksapi[`breaksapi`], when it changes the SRML or consensus of running system with https://github.com/paritytech/substrate/labels/B3-breaksconsensus[`breaksconsensus`]
|
|
. No PR should be merged until all reviews' comments are addressed.
|
|
|
|
*Reviewing pull requests*:
|
|
|
|
When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
|
|
|
|
. Buggy behavior.
|
|
. Undue maintenance burden.
|
|
. Breaking with house coding style.
|
|
. Pessimization (i.e. reduction of speed as measured in the projects benchmarks).
|
|
. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
|
|
. Uselessness (i.e. it does not strictly add a feature or fix a known issue).
|
|
|
|
*Reviews may not be used as an effective veto for a PR because*:
|
|
|
|
. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
|
|
. It does not fit well with some other contributors' longer-term vision for the project.
|
|
|
|
=== Updating Polkadot as well
|
|
|
|
If your PR changes the external APIs or interfaces used by Polkadot, **a corresponding PR on Polkadot must** be submitted as well. If you tagged the PR with `breaksapi` or `breaksconsensus` this is most certainly the case, in all other cases check for it by running step 1.
|
|
|
|
To update a corresponding Polkadot PR:
|
|
|
|
0. Pull lastet Polkadot master (or clone it, if you haven't yet).
|
|
1. Replace `polkadot-master` in all `Cargo.toml` with the name of the PR-branch - e.g. by running `find . -name "Cargo.toml" -exec sed -i "s/polkadot-master/PR_BRANCH/g" {}` (and to your repo, if the branch is not on mainline); Commit this change.
|
|
2. Make the changes required to pass the build again.
|
|
3. Submit all this as a PR against the Polkadot Repo, link that new PR in the existing substrate PR for reference
|
|
4. Wait for reviews on both
|
|
5. Once both PRs have been green lit, merge the Substrate PR into master and sync the changes onto the `polkadot-master` on mainline (push it). Now revert that first commit in your Polkadot PR, reverting the name back to `polkadot-master`, push and wait for the CI to confirm all is fine. Then merge the Polkadot PR.
|
|
|
|
As there might be multiple pending PRs that might conflict with one another, a) you should not merge the substrate PR until the Polkadot PR has also been reviewed and b) both should be merged pretty quickly after another to not block others.
|
|
|
|
== Helping out
|
|
|
|
We use https://github.com/paritytech/substrate/labels[labels] to manage PRs and issues and communicate state of a PR. Please familiarize yourself with them. Furthermore we are organizing issues in https://github.com/paritytech/substrate/milestones[milestones]. Best way to get started is to a pick a ticket from the current milestone tagged https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ2-easy[`easy`] or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ3-medium[`medium`] and get going or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AX1-mentor[`mentor`] and get in contact with the mentor offering their support on that larger task.
|
|
|
|
== Releases
|
|
|
|
Declaring formal releases remains the prerogative of the project maintainer(s).
|
|
|
|
== Changes to this arrangement
|
|
|
|
This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
|
|
|
|
== Heritage
|
|
|
|
These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md
|