Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
37 lines (30 loc) · 2.14 KB

CONTRIBUTING.md

File metadata and controls

37 lines (30 loc) · 2.14 KB
Raw

Contributing to qcom-ptool

Hi there! We’re thrilled that you’d like to contribute to this project. Your help is essential for keeping this project great and for making it better.

Branching Strategy

In general, contributors should develop on branches based off of main and pull requests should be made against main.

Submitting a pull request

  1. Please read our code of conduct and license.
  2. Fork and clone the repository.
  3. Create a new branch based on main: git checkout -b <my-branch-name> main.
  4. Make your changes, add tests, and make sure the tests still pass.
  5. Commit your changes using the DCO. You can attest to the DCO by commiting with the -s or --signoff options or manually adding the "Signed-off-by":
  6. Before pushing changes for review, run the following commands locally:
    • export PTOOL_SEED=qcom-ptool-ci
    • make lint
    • If a new file is added, its checksum also needs to be added. Run the command make generate-checksums to add it.
    • make all integration check-checksums
  7. Push to your fork and submit a pull request from your branch to main.
  8. Pat yourself on the back and wait for your pull request to be reviewed.

Here are a few things you can do that will increase the likelihood of your pull request to be accepted:

  • Follow the existing style where possible.
  • Write tests.
  • Keep the partition source formats in sync: when adding an option to the legacy .conf loader, add the matching typed field to the YAML schemas (qcom_ptool/schema/) and the YAML loader in the same pull request, with a test pinning that both formats load identically.
  • Keep your change as focused as possible. If you want to make multiple independent changes, please consider submitting them as separate pull requests.
  • Write a good commit message.
  • It's a good idea to arrange a discussion with other developers to ensure there is consensus on large features, architecture changes, and other core code changes. PR reviews will go much faster when there are no surprises.