Skip to content

Latest commit

 

History

History
87 lines (73 loc) · 3.95 KB

CONTRIBUTING.md

File metadata and controls

87 lines (73 loc) · 3.95 KB
Raw

CPAchecker Contribution Guidelines

CPAchecker is an open-source project and contributions are welcome! The following guidelines describe the workflow for contributions. For working on CPAchecker, please also have a look at the development documentation and the documents linked there, such as our style guide.

Code Hosting

We prefer contributions (for larger contributions even from external contributors) to be pushed into a branch in the official CPAchecker repository instead of a fork. This is more flexible for collaboration and prevents problems with CI (our own repository has access to more powerful GitLab runners). Thus, please contact us and request access to the GitLab repository providing your GitLab user name. Smaller changes can also be contributed via an MR from a fork.

Commits

  • Commit early, commit often.
  • Split the commits into reasonable changesets.
  • Add meaningful commit messages that help other developers to understand what was done and (even more importantly!) why it was done. Please read this post on how to write good commit messages. This is especially important for revert commits - do not just commit with the auto-generated commit message from git!
  • Try to have separate commits for bugfixes, refactorings, and new code.
  • Make sure all committed code is auto-formatted with google-java-format (install the respective plugin in your IDE!).

Branches

Development is done in branches. Please follow these guidelines:

  • Give your branch a meaningful name that describes the project / goal of the branch. Your name should typically not be part of the branch name. If an issue exists for your intended change, consider creating the branch directly from the issue or at least include the issue number in the branch name.

  • Keep each branch restricted to one specific set of changes, do not mix unrelated changes in a single branch.

  • Consider creating a MR early and use the MR description to explain the goal of the branch. MRs are also useful for ongoing discussions and feedback during the development, not just for final approvals.

  • While a branch exists, keep it close to the main branch, i.e., regularly merge the main branch into your branch. This allows you to detect merge conflicts early when it is often less effort to fix them.

  • Aim at integrating your branch into the main branch as soon as possible. This benefits everyone: Other developers can see and use your code, and you get the benefit of much more testing (the integration tests done by BuildBot run only on the main branch) and merges are less effort for you (CPAchecker is actively developed and waiting too long between merges can lead to a large amount of changes that are difficult to apply). The minimum bar for integrating a branch is that CI is green, a core developer has approved your merge request, and that no breakages of existing components are expected. This means that while you are developing a new component (like a CPA), you can merge early and often even if the component is not yet finished, because you will not cause trouble for other users (who will not be using your component).

  • Merging a merge request can be done by any developer as long as it is approved by a core developer.

  • All branches are protected and force pushes are not allowed. We clean up merged branches and delete them from time to time. So please do not link to them from outside of the project; use permalinks (with the git hash or a tag) instead.