Sign off on patches

From Koha Wiki

Jump to: navigation, search
Git > Git
Home
Home
Home
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.

Contents

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 patch

Apply someone's patch to your local repo. You can create a new branch for this purpose.

For example:

git checkout -b qa_bug_xxxx
git am -3 -i -u <name_of_patch_file>

Test it

You test it.

Amend commit

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.

Sign-off

If the patch is ok, you prepare a new one for it (git format-patch -s). -s = signoff

For example:

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

Update Bugzilla

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.

See also


Developer handbook

Personal tools