Guidelines for Patch Acceptance/Rejection

From Koha Wiki

Jump to: navigation, search
Home > Development

The following guidlines for getting your patch accepted in Koha were compiled from a thread on the koha-devel mailing list

  1. The patch must do what it claims to do, in all commonly-supported Koha environments
  2. The patch must not break existing functionality
  3. The patch must apply to the current HEAD of the master branch of the code
    • All patches which will not apply cleanly to 3.2.x should be ported and submitted as separate patches marked for 3.2.x
  4. The patch must follow the Coding Style Guidelines
  5. The patch must be MARC-flavour agnostic
  6. If a database update is require, the patch must handle the update both for new installs and upgrades
  7. If a new feature is added, the patch must include appropriate Help documentation
  8. The patch must have at least 1 (preferrably 2) signoff(s) from another party (preferrably the QA manager). Exceptions will be made for trivial patches
  9. The patch must refer to a bug number
    • To avoid cases where the bug number could be stripped from the patch during the Git workflow, please don't enclose the bug number in square brackets. In other words, don't do "[Bug 1234]", do "bug 1234:"

Additional characteristics of a good patch

  1. The patch covers a single topic
  2. The patch is easy to read
  3. The patch does not contain the detritus of your coding process
Retrieved from "http://wiki.koha-community.org/wiki/Guidelines_for_Patch_Acceptance/Rejection"