Koha Release Manager newsletter #4 2012-02

Welcome to the 4th RM newsletter.
First of all, it means i’ve started this role for 4 months. wow, times passes very quickly.
When I applied, I said I planned to dedicate half of my time to this role. Chris C., the previous RM, said he dedicated more than this. The good news is that I could dedicate a little bit more than half of my time. The bad news is that I could dedicate more, Chris was right. There are so many things that could be done that I could dedicate 2 full time in fact.

So let’s go with last month news…

Just one number to begin with: more than 200 patches have been pushed in february. Good job everyone !

Bugzilla news

There are 74 bugs that are waiting for a sign-off. That’s only a few less than last month, but many have been signed, and many have been added.
I see that 12 of them have been submitted in january or before. Maybe we should discuss of setting a very high priority to those “old” patches.
Also note that I have submitted a new script that is able to check all patches that “need signoff”, and check if they still apply. You can find this script on bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7553

The very good news is that the pile of bugs that have been signed-off and are waiting for QA is now very small: there are only 14, and the oldest one is less than one week old ! Thanks to the hard work of Marcel that helped me a lot QAing.

Important new features

Template Toolkit caching (technical)

The bug 7511 add a new feature : templates (the layout of Koha pages) can now be cached. It means they are pre-built and can be retrieved very quickly. It results in an overall improvement of speed of 10%, just with 4 lines of code !

general caching

After a discussion on the mailing list, we made some changes on the general caching: the reference to memcached is now made in Apache configuration, this let us cache koha configuration file itself, this result in a 10% speed gain once again.
You can find the discussion at: http://wiki.koha-community.org/wiki/Cache_handling_in_Koha
All patches have been applied on koha code, will be available for Koha 3.8. It means that existing setups using memcached will have to be updated when upgrading to 3.8

Test suite improved

Catalyst NZ has organised, in january, an “OpenSource Academy”. Some of the students choose to work on Koha test suite, and 5 new contributors have been added during this Academy. They have added some tests to our test suite. Congrats to all of them (and thanks to Catalyst ppl that trained them !)

Code cleaning

The effort for cleaning code continued:

• Owen has written a patch that standardize how we call the book vendor (in the code, not in the interface). It used to be sometimes supplierid, sometimes booksellerid, sometimes id. Now it’s always booksellerid.
• De nesting effort: All access to database are made through Perl packages that are located in C4 directory. the problem is that circulation needs patrons, that needs catalogue that needs circulation. At the end, almost all packages are loaded for almost all scripts. There is a de-nesting effort i’ve started on bug 6875, that could be continued, but the first patches have been pushed onto Koha. It’s a long term effort, but it’s worth the price, as it also improve speed.
• Capitalizing strings: The bug 2780 is back: we had decided a long time ago, to use capital letters only on 1st word. For example, adding an item button should not be spelled “Add Item” but “Add item”. This may sound a minor thing, but it’s a consistency things, and it’s very important for translators. If we have “Add Item” and “Add item” and “add item”, translation must be written 3 times ! There’s now a strong QA rule for this, and you’re welcomed to submit patches fixing remaining strings with useless capital letter !

funny and not that small new features

• The patron password is now entered as hidden *****
• you can run rebuild_zebra.pl with an offset and a length, to quickly test or reindex a small chunk of your database (bug 7246)
• we can now search patrons on their name, but also on their phone or email (bug 7544)
• you can now add and remove a biblio to the cart from the biblio itself, not only add it (bug 3215)
• you can print transfer slips for transfers without hold (bug 7467)

bugs “in discussion”

The first discussions took place for bugs/patches/enhancement that require a community decisions.
I’ve added on bugzilla a “in discussion” query, if you use it now, you’ll see that there are 13 bugs set “in discussion”. Feel free to start the discussion, by adding a page to the wiki and starting a thread on koha-devel.

Coding Guidelines

For those who don’t know, the coding guidelines describe the rules for coding, that are used for Quality Assurance. For example, we have decided to use 4 spaces to indent the code and have it more readable.
So the following code is OK:
if ($RMnewletter eq '4') {
    say "end of february";
}
while this one is not:
if ($RMnewletter eq '4') {
  say "end of february";
}
(yes, it’s a detail, but when you have 100 000+ lines, it’s the kind of detail that is important !)

Many things where already made, but not written, now they are. The more things will be written, the easiest it will be to do the QA !

I’ve added code & number to the guidelines. That will be usefull when QAing, to point a breaking of a guideline. For example [PERL2] rule says “All scripts and modules should enable the strict and warnings pragmas”. If the QA team says “PERL2 rule broken failed QA”, you know what it refers to.

If you want to look at all those guidelines, it’s on the wiki: http://wiki.koha-community.org/wiki/Coding_Guidelines

sandboxes and patch workflow

The sandbox system is done & has been deployed on 10 BibLibre servers. Head to http://wiki.koha-community.org/wiki/Sandboxes
What are those sandboxes done for ? That’s a handy way for non developpers to test and validate patches.
The community workflow is the following:
1 someone report a problem or announce an enhancement
2 someone submit a patch to fix the problem or add the enhancement
3 someone test and validate the fix or the enhancement
4 someone (from the QA team) validate that the code respect the coding guidelines
5 the release manager “push” the patch into official Koha.
(this workflow is also described here: http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow)

The step 3 (test & validate) is also called “signing off”, and can be done by anyone. The best being when it’s a librarian !
However, it can be tricky to have a working koha, and apply the patch. The sandbox system hope to fix this point, by letting anyone with no technical skill test a patch !

Don’t hesitate to use it, ask for more information if you want. you can catch me on IRC

Note that the code of this sandbox system will be published soon at http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary