Skip to content

Latest commit

 

History

History
76 lines (49 loc) · 3.31 KB

CONTRIBUTING.md

File metadata and controls

76 lines (49 loc) · 3.31 KB

Contributing to

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.

    git clone https://github.com/qualcomm-linux/docker_deb_build.git

  3. Create a new branch based on main:

    git checkout -b <my-branch-name> main

  4. Create an upstream remote to make it easier to keep your branches up-to-date:

    git remote add upstream https://github.com/qualcomm-linux/docker_deb_build.git

  5. Make your changes, add tests, and make sure the tests still pass.

  6. 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":

    git commit -s -m "Really useful commit message"`

  7. After committing your changes on the topic branch, sync it with the upstream branch:

    git pull --rebase upstream main

  8. Push to your fork.

    git push -u origin <my-branch-name>

    The -u is shorthand for --set-upstream. This will set up the tracking reference so subsequent runs of git push or git pull can omit the remote and branch.

  9. Submit a pull request from your branch to main.

  10. Pat yourself on the back and wait for your pull request to be reviewed.

Security Analysis of Pull Requests

To maintain the security and integrity of this project, all pull requests from external contributors are automatically scanned using Semgrep to detect insecure coding patterns and potential security flaws.

Static Analysis with Semgrep: We use Semgrep to perform lightweight, fast static analysis on every PR. This helps identify risky code patterns and logic flaws early in the development process.

Contributor Responsibility: If any issues are flagged, contributors are expected to resolve them before the PR can be merged.

Continuous Improvement: Our Semgrep ruleset evolves over time to reflect best practices and emerging security concerns.

By submitting a PR, you agree to participate in this process and help us keep the project secure for everyone.

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. INSERT LINK TO STYLE, e.g. PEP8 for python
  • Write tests.
  • 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.