Pull Request

Contributing

To contribute to this project, follow the process described in CONTRIBUTING.md. Every author must electronically sign the Eclipse Contributor Agreement.

Description

A pull request description serves a similar purpose as a Commit Message. Therefore, all rules for commit messages also apply to pull requests, with the following exceptions:

  • The comment fields are not limited to 72 characters per line.

  • All markup syntaxes supported on GitHub are allowed.

If a PR consists of just one commit, the pull request description can be identical to the commit message.
If a PR consists of several commits, the pull request description should summarize the commits.

Approval Process

As per the Eclipse Foundation Specification Process, every committer has the “rights to make decisions regarding a Project”, including the authority to approve commits.

In OpenBSW, we follow that process with the following addition:

If the pull request is small enough and the committer has the complete overview of the pull request and its consequences, the committer can approve and merge the pull request without consulting other committers. Examples:

  • fixing typos or software bugs

  • improving documentation

  • making CI more robust

  • enhancing a feature

If the pull request changes processes, strategies, fundamentals or important APIs, the pull request must be discussed with other committers. Examples:

  • changing the workspace structure

  • adding a completely new feature

  • removing support for older compilers

  • changing guidelines

There is always a grey zone. In case of doubt, the committer must consult other committers.

Tags

The following tags are set on PRs for OpenBSW on Github:

  • tested_on_hw: This tag can be set if a defined set of tests did run successfully for the PR’s changes on the reference hardware s32k148. Currently, the defined set of tests is just a simple “sanity check” that starts up the application and checks if the initial console messages contain expected contents. This might change in the future to run the system tests involving CAN and Ethernet tests also. This tag can be set manually (by the author, if testing manually), or automatically (when hardware tests are automated).

  • no_hw_test_required: For changes involving only minor or non-functional changes, a PR can have this tag set instead of tested_on_hw. This tag needs to be set be the author or by a project committer.

Every PR shall have one of those tags defined before being ready for merge.

Checklist

The committer must take the following points into account before approving the pull request:

  • Do the commit messages and pull request description follow the guidelines?

  • Is the code useful and should it be part of OpenBSW?

  • Is documentation provided?

  • Are tests changed or added?

  • Is the contribution, including code, tests, and documentation, compliant with the guidelines?

Some checks might not be applicable, e.g., if unit tests are explicitly excluded in module.spec.

In case of findings, the pull request must not be approved or merged. Alternatively, e.g., if it is planned to post-deliver the documentation, a GitHub issue must be created and linked in the pull request.