Pull Request Checklist¶
Before opening a pull request, check the following:
Does the code build? Execute
make
(or your build system’s equivalent, e.g.,cmake --build . --target ALL_BUILD --config Release
on Windows).Do all tests pass? To check if all tests have passed, execute
ctest
. If a test that is unrelated to your changes fails, check the nightly builds to see if the error is also indevelop
. If the error is in develop, [create a github issue](/manual/contribute.md#Write and Label GitHub Issues).Is the code documented? Document all new classes, including their methods and parameters. It is also recommended to document non-public members and methods.
Does the code introduce changes to the API? If the code introduces changes to the API, make sure that the documentation is up-to-date and that the Python bindings (pyOpenMS) still work. For each change in the C++ API, make a change in the Python API wrapper via the
pyOpenMS/pxds/
files.Have you completed regression testing? Make sure that you include a test in the test suite for:
Public methods of a class
TOPP tools
Bug fixes
Make sure to:
Rebase before you open a pull request. To include all recent changes, rebase your branch on
develop
before opening a pull request. If you pushed your branch toorigin
before rebasing, git will most likely tell you after the rebase that your local branch and the remote branch have diverged. If you are sure that the remote branch does not contain any local commits in the rebased version, you can safely push usinggit push -f origin <branch-name>
to enforce overwrite. If not, contact your local git expert on how to get the changes into your local branch.Capture similar changes in a single commit Each commit should represent one logical unit. Consolidate multiple commits if they belong together or split single commits if they are unrelated. For example, committing code formatting together with a one-line fix makes it very hard to figure out what the fix was and which changes were inconsequential.
Create a pull request for a single feature or bug If you have multiple features or fixes in a pull request, you might get asked to split your request and open multiple pull requests instead.
Describe what you have changed in your pull request. When opening the pull request, give a detailed overview of what has changed and why. Include a clear rationale for the changes and add benchmark data if available. See this request for an example.