Sign off on a pushed branch
From Koha Wiki
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.
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'
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.
Change this line:
our $VERSION = '3.03.00.XXX';
our $VERSION = '3.03.00.045';
Locate the line that contains "XXX" and change it from this:
$DBversion = '3.03.00.XXX';
$DBversion = '3.03.00.045';
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.
You test it!
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 master 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 master. For example:
commit 130467de782d7fd088078b43875d21af84d23e59 Author: Owen Leonard <email@example.com> 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 <firstname.lastname@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 <email@example.com> Date: Fri Dec 3 11:16:57 2010 -0500 Adding state to output of patron search results screen commit 0ccba84808bcd1a7cf97d5781068fa195abdf47c Author: Katrin Fischer <firstname.lastname@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.
If the patch is ok, you prepare a new one for it (git format-patch -s). -s = signoff
git format-patch -s origin/master
This will generate one patch per commit, 0001-... 0002-... etc
Send the new patch(es) to email@example.com 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.
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.
- 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?