KohaCon10: Git and Koha

by ByWater Staff on Oct 28, 2010

Chris Cormack presents on Git and Koha.

The introduction includes setting up Git to send emails in a sensible fashion (your name, email, SMTP server, etc.). Tutorial is on the wiki.

Next, we discuss the Koha workflow. Only the Release Manager and a few other officers have Push access to the Koha repository. For everyone else, we format a patch as an email, and send it to the patches email list. All patches should be formatted against ‘master’, the git branch that will become Koha 3.4. Chris Nighswonger, Koha 3.4 Release Maintainer, will take care of backporting patches to 3.2.x. This will hopefully prevent too great a divergence between the stable release branch and the next release.

Read the Mailing List! Test patches, sign off, discuss, etc. This will make quality higher, and much integration that much smoother. “Many eyes make bugs shallow”. If you can get your patch signed off before you send it to the main mailing list, all the better (this is the standard ByWater practice). To sign off, see this wiki tutorial.

Another “best practice” is to put the bug number that the patch fixes into the first line of the commit message. This keeps the patch filename short, and makes it easy for people to reference more information about the issue you’re working on. Of course, this requires there to be a bug report. Check for your issue first, and if it exists, add it to your list. Otherwise, create it. This works for enhancements, which should have a bug number as well as an RFC on the wiki.

New bugfixes and features will be pulled onto their own branches based off master, and will be tested against our coding guidelines. Then Colin, our Quality Assurance manager, will sign off, and ask the Release Manager to pull it. The Release Manager will then pull to his repository, test again, and if it’s good, it will be signed off yet again, and merged into master.

We now have a continuous integration tool, Hudsonbot, which runs every 15 minutes, and will run all the unit tests every time a new commit is added. We need more unit tests. Chris says that adding more of these tests is the most needed contribution to Koha, and he will personally send you chocolate if you help with this. For 3.6 and beyond, any new features should come with tests, but Chris will be more lenient on that for 3.4.

In the future, we’re looking to build a Git Hook script to automatically add the patch to the bug report, but until then, please add it manually. This makes it very easy to wget the patch, and also alerts all the people on the Bugs mailing list that work is being done on their bug. When the bug is pushed, go in and test and close the bug report.

Also in the future, we’re going to see more “requests to pull”. This is an email that says “please grab these patches from this repository”. This can be a developers personal repo, or a branch on the Koha Git repo (just ask Chris, and he can create a branch for you!) Much like the format patch, you can use git to create this for you: git request-pull git://full.URL mybranch

Chris is working on an idea to pull patches into various folders on patches.workbuffer.org, so we can track the status of patches sent that don’t follow all the best practices. Using Bugzilla with some Git Hooks may also help with this purpose, as well.

[tag]kohacon10[/tag]

[Originally posted by Ian Walls]