Development workflow

From Koha Wiki

Jump to: navigation, search
Home
Koha > Community > Participation
Koha > Technical > Development

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

Different people are involved in the process.

Contents

Steps

  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. (optional) The release manager ("RM") pushes it as a Quality Assurance ("QA") branch.
  4. The patch is tested and signed off by the 'patch signer' and bug status is changed to Signed off.
  5. The patch is checked by the QA team member, and bug status is set to Passed QA
  6. The patch is tested and signed off by the RM
  7. If the patch passes, it is pushed to master by the RM and the status is set to Pushed to master.
  8. 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
  9. The bug is marked resolved/fixed by the 'bug closer'.
  10. 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 the problem the tester has detected. 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 master 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 your patch is an ENHancement, please add [ENH] just after the patch number in your patch comment 1st line (example: "Bug 6543 [ENH] I add a very nice feature")
  • 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 it can be QA'd by someone from the same company or institution. The RM can still ask for a second sign-off in this case.


Developer handbook

Personal tools