[Koha-devel] [NEW] What's on in Koha devel

[Jonathan Druart]

Hi devs,

First, sorry for the [NEW] flag, but it is to make sure everybody
reading the ML will click :)

I'd like to start a monthly "what's on" email which I will send to koha-devel.
It comes after some discussions at the KohaCon16 with fellows that do
not have the time to follow what's going on in the community and where
they could help on important things.
I used to send one to my partners every month to explain what I did
and what I plan to do, but actually it sounds more a community report
to send to the Koha developers.
So here it is :)

The goal is to resume in a (relatively) short email what has been
developed in the previous month(s) and what testers/developers can
focus on. It could be critical/major bugfixes, code
refactoring/improvements or even big-but-amazing features waiting for
signoff/QA.

Over the last months I have mainly focused on refactoring stuffs, fix
plack-related bugs and improvement issues, as well as my usual QA
work.
The refactoring part is not going very well, I have suspended it 2
months ago. The main problem is that the patches are no pushed as fast
as I expected implying a lot of rebases which is time consuming.
By refactoring I mean "moving code from old C4 modules to the new Koha
namespace". The pattern I usually use in the bug report description is
"Move the stuff related code to Koha::Stuff[s]"

The plack-related bugs were minor, but to provide a full plack
compatibility it was great to have them push quickly. Luckily they
have been signed off and QAed quite quickly, only 2 are still waiting
for QA. The pattern I used in the bug description was "This module is
not plack safe".

A few words about the performances: You have to know that since 16.05
(and maybe also 3.22) it's highly recommended to use Plack and
Memcache to provide your user a good response time.
We have profiled the code in several areas to find useless processing
time. In some places, the code has been improved, in others it has
completely been removed.
Fixing plack bugs, we have found that we needed to improve our cache
mechanism and we have introduced a L1 memory cache which should bring
us performance gain between 3.22 and 16.05. Note that we do not have
completely finished the work and some more has to been done, so stay
tuned :) If you have any suggestions or leads on that, please open a
bug report and assign it to me.

There are 2 critical bugs waiting for signoff (bug 16554 and bug
16573), they fix the support of Ubuntu 16.04. So if you plan to
install Koha on the latest Ubuntu, you should have a look at these 2
reports.

A major enhancement is in the integration queue and it would be great
to see some people (librarians would be awesome) involved in the
testing process. It will allow a patron to place several holds on the
same record (bug 14695). This feature has been expected for more than
3 years now and this is the third attempt.

During the KohaCon16, I have organised a quick brainstorming about our
implementation of Koha::Object[s] and how we use DBIx::Class. The goal
was not to find a solution but to present the different issues we
face. I'd like to bring again this discussion on koha-devel this
month, listing the pros and cons of our current implementation, and
gathering ideas to improve it.

Hope this will be helpful for people not heavily involved on IRC or
the bug tracker.

Cheers,
Jonathan

References:
Refactoring to Signoff
  Bug 15758 - Move the C4::Branch related code to Koha::Libraries - part 4
  Bug 15803 - Koha::AuthorisedValues - Remove GetAuthorisedValueCategories

Refactoring to QA
  Bug 15451 - Move the CSV related code to Koha::CsvProfile[s]
  Bug 15839 - Move the reviews related code to Koha::Reviews
  Bug 15801 - Move the framework related code to
Koha::BiblioFramework[s] - part 2
  Bug 15407 - Move the patron categories related code to
Koha::Patron::Categories - part 2

Plack bugfixes to QA
  Bug 16441 - C4::Letters::getletter is not plack safe
  Bug 16443 - C4::Members::Statistics is not plack safe

Performances entry points are (look at the related bugs using the show
dependency graph):
  Bug 15342 - Performance 3.22 - Omnibus
  Bug 16044 - Define a L1 cache for all objects set in cache