Patch format

All patches for RAMSES have to pass our code review system. No code can be merged into the repository, without passing the review of another RAMSES developer. In order to enable fast patch reviews, patches are required to meet some requirements. Patches that do not obey these rules, will not be considered during review and have no chance of being merged into the code base (*).

• has a meaningful patch description
  • if reviewer does not understand the content of the patch from the description, review will be denied
  • patch description matches exactly the code change
• targets exactly one issue
  • changes exacty one issue in the code
  • no mixing of refactoring and other work
  • NOT: adds function to API and fixed memory leak
• small
  • typically only few lines
  • cannot be split
• self-contained
  • does not break anything
• includes unit tests
  • patch contains at least one test closely related to the change
  • see test strategy, how to test features
• works for all platforms
  • checked by zuul build jobs
  • patches not passing build servers will not be reviewed
• respects licenses and external IP
  • patch must not contain any copied code
  • patch content is free of external IP
  • all mandatory (open source) license restrictions are satisfied
• applies to latest master
  • conflicts with master have to be resolved by patch creator

If one patch depends on another patch in order for a change to be complete, that is OK and encouraged. Multiple smaller patches are generally better. A good reference for patch design is the Linux kernel documentation (parts 2, 3 and 4): https://www.kernel.org/doc/Documentation/SubmittingPatches