- Koha-devel - lists.koha-community.org

RM holidays
by Paul Poulain 13 Jul '12

13 Jul '12

Hello koha-devel, Just to let you know: I'll be in holiday (and AFK) from Aug 4th to Aug 26th, included. I think I'll read my mails from time to time, but won't probably push patches, except if something is going really wrong. This period is usually very quiet, many ppl are in holiday too (northen hemisphere, at least ;-) ). If you leave today: happy holiday. If you stay for some more weeks like me, go sign-offing some patches, it's a good activity to do during summer ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Re: [Koha-devel] Authority indexing
by Stefano Bargioni 13 Jul '12

13 Jul '12

In my opinion, they can be the same. However, I'd like to have a way to search for authority number in the staff client, and obtain the authority record, not the biblio records linked to the heading. Bye. Stefano > Hello. > > Triggered by bug 8206 (add additional search options to authority browser > on OPAC: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8206) > Marcel, Katrin, and I have been discussing the inconsistent indexes used > for searching authorities in the staff client an OPAC. Somewhere in git > history (I can't remember exactly where I saw it) there was a note that the > OPAC "had" to use different authority indexes than the staff client, so > when I re-added the search options for bug 8206, I used the same indexes > that the OPAC had used previously. Marcel pointed out quite correctly that > if no one can explain *why* the OPAC should have to use different indexes, > it would be better to make the staff client and OPAC consistent. So, I turn > to the community: at this point could I just use the same indexes in the > OPAC as are used in the staff client? > > Regards, > Jared __________________________________________________ Il tuo 5x1000 al Patronato di San Girolamo della Carita' e' un gesto semplice ma di grande valore. Una tua firma aiutera' i sacerdoti ad essere piu' vicini alle esigenze di tutti noi. Aiutaci a formare sacerdoti e seminaristi provenienti dai 5 continenti indicando nella dichiarazione dei redditi il codice fiscale 97023980580.

2 1

Koha::Calendar broken since C4::Calendar split
by Dobrica Pavlinusic 13 Jul '12

13 Jul '12

With end of academic year near, I was forced to take a look why our due-dates aren't calculated correctly. Result is Bug 8418 - Koha::Calendar is_holiday ignores all user data http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8418 This is pure bug-fix patches to Koha::Calendar to restore functionality which used to work in C4::Calendar. I'm aware there are quite a few patches which touch this code, but some of them are wrong and others are stuck in sign-off because they also modify another parts of Koha. This is my attempt to provide simple bug fix only which should also be applicable for stable Koha versions. It makes useDaysMode work and remove one redundant SQL query so I hope that you will forgive me for making duplicate changes in separate bug. At least, I tried to block all bugs which also provide same fixes, but unblocking them is just removing relevant patches from them, making other bugs just functionality change. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

2 1

Authority indexing
by Jared Camins-Esakov 12 Jul '12

12 Jul '12

Hello. Triggered by bug 8206 (add additional search options to authority browser on OPAC: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8206) Marcel, Katrin, and I have been discussing the inconsistent indexes used for searching authorities in the staff client an OPAC. Somewhere in git history (I can't remember exactly where I saw it) there was a note that the OPAC "had" to use different authority indexes than the staff client, so when I re-added the search options for bug 8206, I used the same indexes that the OPAC had used previously. Marcel pointed out quite correctly that if no one can explain *why* the OPAC should have to use different indexes, it would be better to make the staff client and OPAC consistent. So, I turn to the community: at this point could I just use the same indexes in the OPAC as are used in the staff client? Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

2 1

Re: [Koha-devel] "The Plack effect" benchmarked
by Paul Poulain 11 Jul '12

11 Jul '12

Le 06/06/2012 13:36, Mark Tompsett a écrit : > Greetings, Hi Mark, (answer to koha-devel, as it's of general interest) > These results look good, but how much memory is on the machine you are > testing this on? Would it have the same effect in a VM server type > environment limited to 204MB? Is there an amount of memory which makes > it behave at similar or worse speeds? I think you missed a 8, and speak of 2048 and not 204MB :D I haven't tested/checked memory, but what I know for sure is that it costs only a small amount of memory. Plack pre-load a lot of things that are loaded on every page by cgi-bin anyway. So you would have 'spent' that memory at run time. Depending on Apache configuration, if 5 ppl are requesting a page at the same time, 5 cgi-bin are launched and 5x memory is consummed. So if you run starman instead of plackup (starman being multi-thread, plackup single thread), the result will be the same. What we have to be *very* careful with is memory hole that result in an always increasing memory consumption. In CGI mode, as everything is freed/deleted after each page, any memory hole is painless. With plack, memory hole will pile up and, at the end ... booom ! (All of this being not measured, so unguaranteed) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

4 4

"The Plack effect" benchmarked
by Paul Poulain 11 Jul '12

11 Jul '12

Hi, Just in case some of you have doubts about the interest of having Plack for staff interface, here is a result of misc/load_testing/benchmark_staff.pl made with and without Plack: benchmarking WITH Plack: Step 1: staff client main page 4178ms 4.786 pages/sec Step 2: catalog detail page 9991ms 2.001 biblios/sec Step 3: catalogue search 5631ms 3.551 biblios/sec Step 5: patron detail page 7037ms 2.842 borrowers/sec Step 5: patron search page 11800ms 3.389 borrowers/sec Step 6a circulation (checkouts) 8967ms 2.23 checkouts/sec Step 6b circulation (checkins) 13880ms 1.44 checkins/sec all transactions at once 55433ms 3.247 operations/sec (note = tests run with plackup, not with starman, the all transaction at once results would probably be better with starman) benchmarking WITHOUT Plack: Step 1: staff client main page 28576ms 0.699 pages/sec Step 2: catalog detail page 39106ms 0.511 biblios/sec Step 3: catalogue search 55524ms 0.36 biblios/sec Step 5: patron detail page 34610ms 0.577 borrowers/sec Step 5: patron search page 64964ms 0.615 borrowers/sec Step 6a circulation (checkouts) 37907ms 0.527 checkouts/sec Step 6b circulation (checkins) 39129ms 0.511 checkins/sec all transactions at once 138298ms 1.301 operations/sec It appears that the speed improvement is more x3 or x4 than x1.5 as I usually say -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Request for moremember page...
by Paul Poulain 10 Jul '12

10 Jul '12

Hello Koha-devel, The moremember.pl page, that display a patron detail, contain a lot of informations : patron detailled information (including some that are not daily useful), Patron image management (if activated), patron extended attributes (if used), patron messaging preferences (if used), checkout fines, holds I just pushed a new feature, that let the library upload any file attached to the patron (bug 8130) Overall, if someone want to relook this page, I think many ppl would applaude ! My suggestion (but I'm not a designer) : add tabs. The first tab displaying basic information & checkout/fines/holds, other displaying other less important informations. Note : on my 22" screen, the checkouts/fines/hold does not appear on the visible part of the screen, it's a shame, that's a major information. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

5 5

Kohacon 2013 voting: one week left
by Mirko 09 Jul '12

09 Jul '12

Hello everybody, just a little reminder that there is one week left to vote for the Kohacon 2013 location. If you have not done it so far, do it now! See the proposals here: http://wiki.koha-community.org/wiki/Kohacon2013 Vote here: http://survey.web2learning.net/limesurvey/index.php?sid=91534&lang=en - Mirko

1 0

Blog post about BibLibre development rebases
by Claire Hernandez 09 Jul '12

09 Jul '12

Hello all, I wrote a blog post about our developments and the community integration. You can read it here: http://drupal.biblibre.com/en/blog/entry/biblibre-developpments-rebase-and-… It is about: - 2012 goals development rebases - Vision and roadmap - Progress and learnt of january and february - Why the community needs you The purpose was to make visible our work and explain how people can invest into this development integration (for example for our french customers). If you have questions, juste ask. Have a good day, Claire;

5 9

Signing-off a patch for a customer
by Paul Poulain 06 Jul '12

06 Jul '12

Hello koha-devel, I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them) At BibLibre, we have 3 project managers: Stéphane Delaye / Gaetan Boisson / François Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch. I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works. I propose that we define a standard message, something like Signed-off-by: Delaye Stephane <stephane.delaye(a)biblibre.com> patch validated by <LIBRARY NAME>, signed-off in their name Can I have your agreement with this idea ? (of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

13 33