Sign off on patches
From Koha Wiki
Koha > Community > Participation
Koha > Technical > Development
Koha > Technical > Development
Koha > Technical > Development > Coding guides
In order to provide a bit of extra quality assurance on patches to Koha, we have been asked to sign off on each other's patches.
A note about signing off on patches
Signing off on a patch means that the tester has confirmed the following:
- They have stepped through any available test plan
- They confirm the functionality is working
- They note any anomalies and determine whether or not these block the patch from going into the next stage of QA.
A person signing off on a patch is responsible for making sure that the functionality is working as described in the patch (but we know that people miss stuff - that's OK! Just be willing to re-do your signoff for any revisions and no one will complain at you). Furthermore, it would also be appropriate to run the unit tests on the patch to make sure that the tests pass. You can do this from your kohaclone directory by typing:
prove t/ prove t/db_dependent prove xt/ prove xt/author
Note: for all of the tests in xt/author to complete, you will need a few perl modules:
Test::Pod Test::Pod::Spelling Text::CSV::Unicode
This will run all of the tests and show you any failures. Failure of a unit test on anything related to the feature you are looking at is an automatic "Failed QA." Paste your test results into your comments on the bug. You may want to set up your testing db with this testing database. This will prevent tests from failing unnecessarily.
Now, for the nitty gritty:
Method 1: "manually"
Download the patch
You can download the patch from Bugzilla using wget or fetch:
wget -O <name_of_patch_file> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=<attachment_number>
Or you can save it from your e-mail.
Apply someone's patch to your local repo. You can create a new branch for this purpose.
git checkout -b qa_bug_xxxx git am -3 -i -u <name_of_patch_file>
You test it.
If the patch has already been sent to the mailing list then ammend the commit so it's clear that this is a repeat with a sign off. You'll want to add [SIGNED-OFF] to the title/subject of the commit.
git commit --amend
The subject line of the commit email will be taken from the first line of the commit. You can add [SIGNED-OFF] to the beginning first line while amending the commit, or you can do so during the "format-patch" process as described below.
If the patch is ok, you prepare a new one for it (git format-patch -s). -s = signoff
git format-patch -s origin/master
If you did not amend the commit to include "[SIGNED-OFF]" in the previous step, you can do so now:
git format-patch -s --subject-prefix='PATCH] [SIGNED-OFF' origin/master
In Bugzilla, you should update the Status of the relevant bug from "Needs Signoff" to "Signed Off". You should also upload your signed-off patch as attachement and mark the initial one as obsolete.
Method 2: Using git bz
git bz helps a lot in testing patches. There is a dedicated page explaining how it works.
- Sign off on a pushed branch
- Bugzilla report of bugs that currently need a sign off
- Fixing whitespace when applying patches with git