Skip to content
Snippets Groups Projects
Select Git revision
0 results
Blame History Permalink
  • Maksym H's avatar
    Command bot GHA v2 - /cmd <cmd> (#5457) · 8e0cefc8
    Maksym H authored 
    Closes https://github.com/paritytech/product-engineering/issues/93

- Deprecates old command bot bash scripts. New cmd implementation is
re-written on Python
- Deprecates `sync` command, which was never used
- Benchmarks:
- Uses new
[frame-omni-bencher](https://crates.io/crates/frame-omni-bencher)
- Simplifies usage to only providing a runtime and/or pallet name (even
multiple runtimes or pallets)
- Supports sub-modules (like `/cmd bench --runtime dev --pallet
pallet_asset_conversion_ops`)
- Can regenerate all weights with one command (substrate, polkadot,
cumulus) for provided pallet(s) name
- Adds [subweight](https://crates.io/crates/subweight-core) diff as a
result of bench command
    Unverified
    8e0cefc8
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
After you've reviewed these contribution guidelines, you'll be all set to contribute to this project.
CONTRIBUTING.md 8.59 KiB

Contributing

The Polkadot SDK project is an OPENISH Open Source Project

What?

Individuals making significant and valuable contributions are given commit-access to the project. Contributions are done via pull-requests and need to be approved by the maintainers.

Rules

There are a few basic ground-rules for contributors (including the maintainer(s) of the project):

  1. 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. No rewriting of the history after the code has been shared (e.g. through a Pull-Request).
  2. Non-master branches, prefixed with a short name moniker (e.g. gav-my-feature) must be used for ongoing work.
  3. All modifications must be made in a pull-request to solicit feedback from other contributors.
  4. A pull-request must not be merged until CI has finished successfully.
  5. Contributors should adhere to the house coding style.
  6. Contributors should adhere to the house documenting style, when applicable.

Merge Process

In General

  • A Pull Request (PR) needs to be reviewed and approved by project maintainers.
  • If a change does not alter any logic (e.g. comments, dependencies, docs), then it may be tagged A1-insubstantial and merged faster.
  • No PR should be merged until all reviews' comments are addressed.

Labels

The set of labels and their description can be found here.

Process

  1. Please use our Pull Request Template and make sure all relevant information is reflected in your PR.
  2. Please tag each PR with minimum one T* label. The respective T* labels should signal the component that was changed, they are also used by downstream users to track changes and to include these changes properly into their own releases.
  3. If you’re still working on your PR, please submit as “Draft”. Once a PR is ready for review change the status to “Open”, so that the maintainers get to review your PR. Generally PRs should sit for 48 hours in order to garner feedback. It may be merged before if all relevant parties had a look at it.
  4. With respect to auditing, please see AUDIT.md. In general, merging to master can happen independently of audit.
  5. PRs will be able to be merged once all reviewers' comments are addressed and CI is successful.

Noting breaking changes: When breaking APIs, the PR description should mention what was changed alongside some examples on how to change the code to make it work/compile. It should also mention potential storage migrations and if they require some special setup aside from adding it to the list of migrations in the runtime.

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:

  1. Buggy behavior.
  2. Undue maintenance burden.
  3. Breaking with house coding style.
  4. Pessimization (i.e. reduction of speed as measured in the projects benchmarks).
  5. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
  6. Uselessness (i.e. it does not strictly add a feature or fix a known issue).

The reviewers are also responsible to check:

  • if the PR description is well written to facilitate integration, in case it contains breaking changes.
  • the PR has an impact on docs.

Reviews may not be used as an effective veto for a PR because:

  1. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
  2. It does not fit well with some other contributors' longer-term vision for the project.

PRDoc

All Pull Requests must contain proper title & description, as described in Pull Request Template. Moreover, all pull requests must have a proper prdoc file attached.

Some Pull Requests can be exempt of prdoc documentation, those must be labelled with R0-silent.

Non "silent" PRs must come with documentation in the form of a .prdoc file.

See more about prdoc here

Crate Configuration Cargo.toml

The Polkadot SDK uses many conventions when configuring a crate. Watch out for these things when you are creating a new crate.

Is the Crate chain-specific?