Development workflow

From Koha Wiki
Jump to navigation Jump to search

Bug-enhancement-patch Workflow describes the different steps required to fix and enhance Koha code.

Different people are involved in the process. The bug fixing process works best when it has individuals from different companies work on the code so that fresh eyes and fresh perspectives improve our work.

This poll might help you decide what to work on first.

Steps

A basic workflow diagram of bug patching in the Koha community
  1. A bug/enhancement is submitted by the 'bug reporter'.
  2. A patch is submitted by the 'patch writer' and bug status is changed to Needs Sign-off.
  3. The patch is tested and signed off by the 'patch signer' and bug status is changed to Signed off.
  4. The patch is checked by the QA team member, and bug status is set to Passed QA
  5. The patch is tested and signed off by the RM
  6. If the patch passes, it is pushed to main by the RM and the status is set to Pushed to main.
  7. If the Release Maintainer ("RMaint") decides the patch can be pushed to the stable version too, they do that and set the status to Pushed to stable
  8. The bug is marked resolved/fixed by the 'bug closer'.
  9. The bug is closed when a release is made containing that patch.

Failure cases

  1. If the 'patch signer' can't test the patch because it does not apply anymore, the status is set to Patch doesn't apply
  2. If the 'patch signer' can apply the patch but after some tests sees that there is a functional problem with the patch, the status is set to In Discussion or Failed QA, depending on the kind of problem the tester has detected (Failed QA should be used if you run into problems when testing, whereas In Discussion should be used only if there is a disagreement that cannot be resolved without getting more people involved). The description from the tester must be as detailed as possible to be able to reproduce the failure.
  3. If the 'QA manager' has some objections during the QA process, the status is set to Failed QA
  4. If a patch has been pushed to main and a problem is detected after that, there are two options:
    1. The patch is reverted and a revised patch is requested on the original bug.
    2. A new bug is filed, linked to the original one, explaining that the fix is not complete, or has a side-effect. Under no circumstances should bugs in new functionality be reported on the original bug.

Roles

  • Bug reporter: the person who reported the bug. Can also be the patch writer
  • Patch writer: the developer who proposed a patch. Can also be the bug reporter
  • RM: the Release Manager (elected position)
  • QA Manager: the developer (elected member of the QA team) who says the patch is QA compliant
  • Patch signer: the user who tested the patch and saw it works
  • Bug closer: the person who checked that the bug is now fixed. Can be the reporter, it's preferred that the patch writer is not the closer.

Rules

  • A bug report must contain information allowing other people to reproduce the bug and test the patch. Usually, there is a section "steps to reproduce: do this, do that, you'll see this buggy behaviour)
  • Patch signer should not be patch writer. Preferably, patch writer and patch signer should not be from the same company or institution.
  • Patch signer and QA team member are two different persons.
  • Bug closer should not be patch writer, unless the patch was written by the original reporter too. Preferably, bug closer should not be patch signer too.
  • If a patch is not passed QA for a longer time, the developer can leave a note on the bug or send a mail to the mailing list as a gentle nudge to the QA team members.
  • If a patch is not passed QA for one month, then someone from the same company or institution as the patch author can QA it, as long as the patch signer is from another company or institution. The RM can still ask for a second sign-off in this case.


Developer handbook

Retrieved from "https://wiki.koha-community.org/w/index.php?title=Development_workflow&oldid=33828"