Sign off on a pushed branch

Some patches are but in a branch of the official git repo by the Release Manager (RM), and can be tested and signed off from there.

Check out the branch

The RM will note on the when a patch or set of patches has been pushed as a branch for testing, giving the name of the branch.

Example:

 Pushed to new/awaiting_qa/enh/bug_5422

To check out this branch for testing, do:

 $ git checkout remotes/origin/new/awaiting_qa/enh/bug_5422

This will result in a message like this:

 Note: checking out 'remotes/origin/new/awaiting_qa/enh/bug_5422'.
 
 You are in 'detached HEAD' state. You can look around, make experimental
 changes and commit them, and you can discard any commits you make in this
 state without impacting any branches by performing another checkout.
 
 If you want to create a new branch to retain commits you create, you may
 do so (now or later) by using -b with the checkout command again. Example:
 
   git checkout -b new_branch_name
 
 HEAD is now at 130467d... Bug 5422: Adding handling of address2, state, country to guarantor add form

If you want to make the branch a "real" one, do this (you decide the name of the branch, bug5422so is just an example):

 $ git checkout -b bug5422so
 Switched to a new branch 'bug5422so'

Database updates

If the patch(es) affect the database you will probably have to make changes to kohaversion.pl and installer/data/mysql/updatedatabase.pl, in order to trigger the database update.

The first thing to do is figure out the next minor version of your version of Koha. If you are currently at 3.03.00.044 the next version will be 3.03.00.045.

kohaversion.pl

Change this line:

 our $VERSION = '3.03.00.XXX';

to this:

 our $VERSION = '3.03.00.045';

installer/data/mysql/updatedatabase.pl

Locate the line that contains "XXX" and change it from this:

 $DBversion = '3.03.00.XXX';

to this:

 $DBversion = '3.03.00.045';

Upgrade

When you visit the Intranet after doing these changes, a database upgrade should be triggered, and you should be ready to do the testing.

It is probably a good idea to do a backup of your database before you do this step, so you can return it to a known good state when you have finished testing. See Mysqldump Library for some tips on how to do this.

Test it

You test it!

Amend commit(s)

One commit

If the patch has already been sent to the mailing list then amend 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. If the branch differs from main by just one commit you can do this with:

 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 of the first line while amending the commit, or you can do so during the "format-patch" process as described below.

More than one commit

Do "git log" to find all the commits that have been made to the branch after it diverged from main. For example:

 commit 130467de782d7fd088078b43875d21af84d23e59
 Author: Owen Leonard <someone@example.org>
 Date:   Thu Jan 13 16:08:39 2011 -0500
 
   Bug 5422: Adding handling of address2, state, country to guarantor add form
   
   Should apply on top of new/awaiting_qa/enh/bug_5422
 
 commit a85391886036ec4ecbf1d39ef937d029cef9f655
 Author: Katrin Fischer <someone@example.org>
 Date:   Mon Dec 6 07:32:58 2010 +0100
 
   Bug 5422: Small layout correction to borrower search result list
 
 commit d3a36edd52ff7fd2ba8cda48eaf2dc53f3c9ab51
 Author: Owen Leonard <someone@example.org>
 Date:   Fri Dec 3 11:16:57 2010 -0500
 
   Adding state to output of patron search results screen
 
 commit 0ccba84808bcd1a7cf97d5781068fa195abdf47c
 Author: Katrin Fischer <someone@example.org>
 Date:   Thu Dec 2 07:30:42 2010 +0100
 
   Bug 5422: Add missing fields to deletedborrowers and change datatype to text

You will need to amend each commit, using the -c option with the commit IDs of all the commits, for example:

 git commit --amend -s -c 130467de782d7fd088078b43875d21af84d23e59
 git commit --amend -s -c a85391886036ec4ecbf1d39ef937d029cef9f655
 git commit --amend -s -c d3a36edd52ff7fd2ba8cda48eaf2dc53f3c9ab51
 git commit --amend -s -c 0ccba84808bcd1a7cf97d5781068fa195abdf47c

See the section above for how to amend the commit.

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/main

This will generate one patch per commit, 0001-... 0002-... etc

Resend patch(es)

Send the new patch(es) to koha-patches@lists.koha-community.org as usual.

For example, if you have 7 patches called 0001-... 0002-... etc you can send them all with :

 git send-email 000*

This will let you say yes or no to sending each individual patch, or you can say yes to sending them all. As an alternative, you can send each on individually:

 git send-email 0001-...
 git send-email 0002-...
 git send-email 0003-...
 git send-email 0004-...

Make sure that you have included [SIGNED-OFF] if this patch was sent to the mailing list already - if not, that doesn't need to be added.

Update Bugzilla

In Bugzilla, you should update the "Patch Status" of the relevant bug from "Needs Signoff" to "Signed Off".

Attach the signed off patches to the bug in Bugzilla OR push them to a public git repository and make a comment in Bugzilla with it's location.

Questions

• If there is more than one commit: Would it be a good idea to squash all the commits into one before signing off, so there is only one, unified, signed off patch?

See also

• Sign off on patches