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

Some suggestions for dashboard
by Paul Poulain 18 Jul '12

18 Jul '12

Hi koha-devel, and mainly Chris_c, http://dashboard.koha-community.org/ is really an interesting tool, that will, I hope, become more and more used ! I've some suggestions: * The "Last 5 sign-off" is less important than "Needs signoff" and "New features recently pushed". It could be in 3rd place * whey does the "Needs signoff" not have the date information ? That would highlight old bugs. * Maybe we could set a red color to "needs signoff" had no activity for more than 1 month? * Why having only 5 for each case ? Would it be possible to have 5, and a link "show more", that would display -say- 20 ? * Bug status could have 2 values the total and the "unmodified since more than 1 month", for example Need Signoff 122 (15 old) Signed off 30 ( 3 old) Passed QA 8 ( 1 old) * Bug status could have colors (green / yellow / red). I would say * signoff <40 green, <80 yellow >80 red * signed off <15 green, <30 yellow >30 red * passed QA <10 green, <20 yellow, > 20 red (for "old", I would say <5 green, <10 yellow >10 red) * random bug = I think the update every 10 seconds is a little bit too often. 30 seconds would be better. and/or display 3 change the oldest one every 10 seconds * put the random bug on top & in the middle, will be more eye-attracting * Important dates = they should be before monthly scoreboard-july * Update "Dashboard" title to "Koha ILS dashboard" * not sure we need the hours on all dates (which timezone is it ? it's not highly readable) * monthly scoreboard = what about having only the 5 first by default, with "show more" option ? * Bug Activity = what about seeing a graph ? listing 5 days and "show more" option ? Note = Chris, if you give me access and some explanations, I can deal with some of these suggestions myself -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Sandbox improved
by Paul Poulain 18 Jul '12

18 Jul '12

Hello Koha users & developers, Irma & Bob, from Calyx sent me a file with some MARC21 records. I just added them on the MARC21 database you can load in sandboxes. So if you choose database 1 (MARC21) when setting up your sandbox, you will have 101 biblios and 130+ items. For more informations: http://wiki.koha-community.org/wiki/Sandboxes -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 2

Giving credit where credit is due
by Jared Camins-Esakov 17 Jul '12

17 Jul '12

Good morning. I have been working on polishing the release notes generator script, and encountered a problematic section: the section of the release notes that thanks libraries which have sponsored developments. In order to make it so that the section can be automatically generated (and to make sure that no one is missed) I propose adding the following to patches which were sponsored by a particular library: Sponsored-by: The Library Unless there are any strong objections, I will create an empty commit on 3.6.x that lists the libraries that sponsored developments in the 3.6.x branch, and starting with 3.6.7 will automatically generate the listing. 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/

4 4

Call for News for the July Newsletter
by Daniel Grobani 16 Jul '12

16 Jul '12

Dear Koha Kommunitarians, I'm harvesting news for the July newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

1 0

Re: [Koha-devel] frameworks and Bug 7432
by Paul 16 Jul '12

16 Jul '12

At 02:37 PM 7/15/2012 -0400, Jared Camins-Esakov wrote: >Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) >modifying frameworks never gave "instant gratification" due to memcached, >so I use netcat: >echo -e "flush_all\nquit\n" | nc localhost 11211 >(and even have a temp 1 min cron job if I need more than a very simple >change.) > >If the only thing using memcached is Koha, you might find it easier to >simply have a cron job that runs `service memcached restart` every hour. Koha is only about 10% of our memcached load, but I do cron "flush-all", "sleep 10" then "restart" every 24 hrs (at 3am, low/no use, gets around the time delay "gotcha".) Also, as far as I know "restart" might not totally *flush* memcached (there's a lot of debate about it, particularly in the php world where memcached's garbage collection seems to be a dirty word) but I haven't done any serious testing. At least "flush-all" is virtually instantaneous, and meets the needs of Koha frameworks. >Do not mix and match files from different versions. My recommendation >would be to upgrade to a recent version of 3.6.x. Thanks for the confirmation. That was my gut feeling. But ... I really am trying to avoid trashing the work I've done on 3.8 on the sandbox (which is too old to successfully run two versions of Koha.) I'm nowhere near ready at this time to put 3.8 into production, so I guess my $64,000 question is "what is the most stable version of 3.6 that I can upgrade the production server to, with the least chance of running into problems?" There's probably a lot of other bug fixes and enhancements that could be useful. Maybe wait for your 3.6.7? :=) >[snip] (WARNING: the following is irrelevant to your question) I would >argue this is a bug (reported it as one, in fact), but that's the way it >is, so -- for the moment -- no need to mark both the tag and subfield >mandatory. Based on the way the MARC standard is written, marking a >subfield mandatory should make it so that if any subfield in that tag is >populated, that subfield must be populated, but not require that the tag >be populated at all. However, that's not the way it works, so it's kind of >a moot point. Sorry, but I can't find the bug you reported (number?) From my perspective, it was a [probaly very rare] combination of circumstances and as you say "a moot point", hence my calling it an "oddity" rather than a bug. We're back on track, the cataloguers see a red asterix, and the help file (ours, not LoC) pops up when requested. Thanks again and regards, Paul _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

Re: [Koha-devel] "The Plack effect" benchmarked
by Waylon Robertson 16 Jul '12

16 Jul '12

This is for Staff interface, what about OPAC interface? On Thu, Jul 12, 2012 at 2:34 AM, Waylon Robertson <wrobertson1981(a)yahoo.co.nz> wrote: just some of the speed improvement we look forward to in koha 3.8.2 > > >----- Forwarded Message ----- >From: Paul Poulain <paul.poulain(a)biblibre.com> >To: Koha-devel(a)lists.koha-community.org >Sent: Wednesday, 6 June 2012 4:02 AM >Subject: [Koha-devel] "The Plack effect" benchmarked > >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 >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ > > >

1 0

Translation of KOCT (Koha Offline Circulation Tool)
by Paul Poulain 16 Jul '12

16 Jul '12

Hi, BibLibre is working on a new version of KOCT (http://wiki.koha-community.org/wiki/Offline_circulation_firefox_plugin) that enable translation of the plugin. We are currently testing the translation to french. Once we're sure things are OK, I'll send here some explanations and example file for those who want to translate the plugin in their own language. There are only a few strings (less than a dozen) Stay tuned. -- 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] frameworks and Bug 7432
by Archives and Collections Society 15 Jul '12

15 Jul '12

At 02:37 PM 7/15/2012 -0400, Jared Camins-Esakov wrote: >Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) >modifying frameworks never gave "instant gratification" due to memcached, >so I use netcat: >echo -e "flush_all\nquit\n" | nc localhost 11211 >(and even have a temp 1 min cron job if I need more than a very simple >change.) > >If the only thing using memcached is Koha, you might find it easier to >simply have a cron job that runs `service memcached restart` every hour. Koha is only about 10% of our memcached load, but I do cron "flush-all", "sleep 10" then "restart" every 24 hrs (at 3am, low/no use, gets around the time delay "gotcha".) Also, as far as I know "restart" might not totally *flush* memcached (there's a lot of debate about it, particularly in the php world where memcached's garbage collection seems to be a dirty word) but I haven't done any serious testing. At least "flush-all" is virtually instantaneous, and meets the needs of Koha frameworks. >Do not mix and match files from different versions. My recommendation >would be to upgrade to a recent version of 3.6.x. Thanks for the confirmation. That was my gut feeling. But ... I really am trying to avoid trashing the work I've done on 3.8 on the sandbox (which is too old to successfully run two versions of Koha.) I'm nowhere near ready at this time to put 3.8 into production, so I guess my $64,000 question is "what is the most stable version of 3.6 that I can upgrade the production server to, with the least chance of running into problems?" There's probably a lot of other bug fixes and enhancements that could be useful. Maybe wait for your 3.6.7? :=) >[snip] (WARNING: the following is irrelevant to your question) I would >argue this is a bug (reported it as one, in fact), but that's the way it >is, so -- for the moment -- no need to mark both the tag and subfield >mandatory. Based on the way the MARC standard is written, marking a >subfield mandatory should make it so that if any subfield in that tag is >populated, that subfield must be populated, but not require that the tag >be populated at all. However, that's not the way it works, so it's kind of >a moot point. Sorry, but I can't find the bug you reported (number?) From my perspective, it was a [probaly very rare] combination of circumstances and as you say "a moot point", hence my calling it an "oddity" rather than a bug. We're back on track, the cataloguers see a red asterix, and the help file (ours, not LoC) pops up when requested. Thanks again and regards, Paul

1 0

frameworks and Bug 7432
by Paul 15 Jul '12

15 Jul '12

Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) modifying frameworks never gave "instant gratification" due to memcached, so I use netcat: echo -e "flush_all\nquit\n" | nc localhost 11211 (and even have a temp 1 min cron job if I need more than a very simple change.) However, I've just come across bug 7432, and while 10 minutes might be a bit painful, I would appreciate advice for updating in a production environment (I normally work on the principle that "if it ain't broke, don't fix it", but...) Is it better for me to attempt to modify our existing biblio.pm (4 minuses, five plusses as far as I can see) or find a more recent biblio.pm, in which case "which one and where"? (maybe from a complete tar of 3.6.5?) How do I find release details at component level? How do I check for side effects? (None are apparently visible from the bug page.) By the way, I've found a possible "oddity"; making a subfield mandatory so that the "manadatoryness" is not just functional but also appears in the fourth column of marctagstructure.pl, I have to use both: marctagstructure.pl?op=add_form AND marc_subfields_structure.pl?op=add_form -- am I doing something wrong? Many thanks, Paul

2 1

About test suite & jenkins
by Paul Poulain 13 Jul '12

13 Jul '12

Hello, Jenkins is still unstable. This happens from time to time. chris_c take care of fixing what is related to the test database or installing new dependencies, or things like that. I try to take care of fixing patches that cause failure, -but I must admit I don't understand easily what jenkins is usually saying- So I had 2 ideas: Idea 1 = I was wondering if we should not have a new elected position of "jenkins guardian". Idea 2 = And if we could not have the test suite in a repository different than Koha itself (or as a submodule), or if the jenkins guardian should not be able to push into $KOHA/t and $KOHA/xt The idea with a separate repository, would be that it could also have all jenkins parameters, databases, hooks, whatever,... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 2