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

Official Koha Newsletter : Volume 2, Issue 9: September 2011
by Daniel Grobani 26 Sep '11

26 Sep '11

[Below is the text of the newsletter. For active links and a more readable format, please visit http://koha-community.org/koha-newsletter-volume-2issue-9-september-2011] Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 9: September 2011 Edited by Daniel Grobani, Koha Community Newsletter Editor. Please submit news items to danielg.koha(a)gmail.com. Table of Contents Koha Developments Koha 3.4.5 Release Delayed Koha 3.6 Feature Freeze Koha 3.8 Roles New Database Schema Site Koha Community New Koha Libraries Community Gossip Past Koha Events Global Bug Squashing Day #4 September General IRC Meeting Upcoming Koha Events Global Bug Squashing Day October General IRC Meeting KohaCon11 KohaCon12: Voting on Proposals Koha Developments Koha 3.4.5 Release Delayed Chris Nighswonger, Koha 3.4.x release maintainer, reports that the release of Koha 3.4.5, originally scheduled for 22 October, has been delayed a few days. Koha 3.6 Feature Freeze by Chris Cormack Why is it so cold in here? We are in feature freeze leading up to next month’s release of 3.6.0. No new features submitted will be considered for that release. Anything that is already in the needs-signoff queue is still OK, though. But get testing, signing off, etc. The next deadline is string freeze, coming up on 8 October, and the more we get signed off by then, the better. Koha 3.8 Roles by Paul Poulain A reminder: Everyone who plans to volunteer for a position in Koha version 3.8 is welcome to file his/her name on the wiki page: http://wiki.koha-community.org/wiki/Roles_for_3.8. The specific module maintainers and release maintainer positions are (desperately) empty. Elections will be held in October. New Database Schema Site by Chris Cormack For everyone who writes reports, or develops on Koha, we have a new site available to help: http://schema.koha-community.org. This, combined with the work Nicole has been doing to add comments, allows for nice information like this: http://schema.koha-community.org/tables/biblio.html. It is up to date with master (what will be 3.6.0 on October 22), and will continue to track master thereafter. Thanks to Robin for rediscovering SchemaSpy and to Nicole for adding comments. Koha Community New Koha Libraries Arcadia University (via ByWater Solutions) College of the Redwoods (via ByWater Solutions) Ducks Unlimited Canada (via Equinox Software) Mississippi Department of Archives and History (via ByWater Solutions) New Zealand State Services Commission (via Catalyst IT) New Zealand Treasury Department (via Catalyst IT) Community Gossip Thatcher Rea joined ByWater Solutions as their Lead Support Specialist. Paul Poulain of BibLibre is convening a working group to address integrating solR and a re-implementation of Zebra into Koha 4.0. Vandana Singh of University of Tennessee Knoxville is seeking people to interview for a study comparing technical support of open source ILSs and proprietary ILSs. For more info, or to participate, see http://www.facebook.com/pages/OSS-Lib-Tech/111245305579507. Bones 1: Nicole Engard is recovering from hip replacement surgery. Bones 2: Koustubha Kale is recovering from a broken arm and wrist. Six Koha libraries are jointly sponsoring development of customizable print slips. Past Koha Events Global Bug Squashing Day #4 Global Bug Squashing Day #4 occured on 2 September. For more info, see http://wiki.koha-community.org/wiki/2011-09-02_Global_bug_squashing_day. September General IRC Meeting The September general IRC meeting was held on 7 September 2011. For more info, including links to the minutes, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_September_2011. Upcoming Koha Events Global Bug Squashing Day by Magnus Enger String freeze for 3.6 has been set to 8 October 23:59 UTC. I’d like to propose a Global bug squashing day for October 7th, as a last, concerted effort to get as much as possible from the “needs signoff” queue into 3.6. Details are here: http://wiki.koha-community.org/wiki/2011-10-07_Global_bug_squashing_day. Happy squashing! October General IRC Meeting The next general IRC meeting is 5 October 2011 1000 UTC. Here’s the agenda as of publication time: Introductions Update on Roadmap to 3.4 Update on Roadmap to 3.6 Vote for Roles for 3.8 KohaCon2011 Results of the Vote for KohaCon2012 Global bug squashing days Actions from General IRC Meeting, 7 September 2011 Miscellaneous Follow-up on koha-devel thread “bugzilla & default assignee”. suggestion made : add koha-devel(a)lists.koha-community.org as a possible assignee for bugs the default assignee don’t want to handle. Adopt this proposition? any other proposition? Gamification and Open Badges Set time of next meeting For more info, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_5_October_2011. KohaCon11 KohaCon11 will be held 31 October 2011 to 6 November 2011 in Thane, India. For more info, see http://wiki.koha-community.org/wiki/Category:KohaCon11 or http://kohacon11.vpmthane.org/ocs/index.php/k/k11. KohaCon12: Voting on Proposals by Magnus Enger The deadline for proposals for KohaCon12 ended on 1 September, and we have two proposals: software.coop and other tbc: Edinburgh, Scotland, UK Washoe County Library System: Reno, NV USA Details on the proposals are at http://wiki.koha-community.org/wiki/Proposals_for_KohaCon12. Nicole Engard has created a survey where folks can vote on their preference: http://survey.web2learning.net/limesurvey/index.php?sid=63529. The deadline for voting is 1 October.

1 0

re-introducing myself
by Greg Barniskis 26 Sep '11

26 Sep '11

Hello all, Some of you may recognize my name from the context of my long-time employment at a leading Wisconsin public library system. My employer has a contract with LibLime to develop LibLime Koha in ways specific to their business needs as a very large public library consortium. That's not really central to my job description there; I am a technology integrator, a generalist for a pretty wide and deep tech stack that happens to include LibLime Koha. I mainly get to watch, and sometimes assist in integrating the outcomes of that contractual development process. I only bring up that subject so that I may acknowledge it as loosely relevant in an environmental way (I know some of what I know because of where I work), but then to really emphasize how little my employer or its vendor relationship has to do with my reasons for writing this today, or for that matter anything else that I may write in the future. Just to be clear, when I'm writing things or contributing code from my personal gmail address, I'm doing it on my own time, on my own equipment, for my own reasons in my own context as an informed private citizen. Anyway, I have decided that, all forkiness aside, I would like to contribute code and other content to the Koha community via the community's selected tools for bugs, wiki, git, etc. To that end I have registered for accounts on k-c bugs and wiki, and have for a long time now been subscribed to the devel and patches email lists (I sometimes even grok what passes on them =). I've been using Perl as an all-purpose utility glue for quite a few years, doing mostly smallish scripts for unix and windows systems management. My most celebrated Perl achievement: low-jacking my employer's old Sun server print spool in order to digitally shred its venerable but verbose Dynix Classic ILS greenbar paper reports directly into Excel spreadsheets on no paper. The customers seemed to really like that trick. In more recent years, I've also been using Perl a lot with HTML::Template and with DBI for lots of different Access, MySQL and Postgres contexts, all on relatively small scales. I don't really know any Template::Toolkit yet, but I have the ora book for it and expect the transition won't be too traumatic. I'm new to Git, but have read enough of the relevant Koha wiki pages to think that I have now correctly checked out the current development HEAD to play with, formatted my first patch file, and eventually even got that first patch emailed to the patches list (I think). I expect I'll be limiting my contributions to low hanging fruit in the short term, until I get a bit more comfortable with Git and Koha internals. For now, I just wanted to say hi, and that I plan to begin submitting small bug fixes soon and various enhancements someday, and that I'm doing so from a context strictly unrelated to my employment. Thanks to those who helped me get started on irc today (and to those who will undoubtedly have to clean up my Git newbie mistakes tomorrow =).

2 2

2011-10-07 Global bug squashing day - 3.6 String Freeze Sprint
by Magnus Enger 26 Sep '11

26 Sep '11

Dear Community! String freeze for 3.6 has been set to 8 October 23:59 UTC. I'd like to propose a Global bug squashing day for October 7th, as a last, concerted effort to get as much as possible from the "needs signoff" queue into 3.6. Details are here: http://wiki.koha-community.org/wiki/2011-10-07_Global_bug_squashing_day Happy squashing! Magnus Enger

1 0

Why is it so cold in here? Oh the features are all frozen
by Chris Cormack 23 Sep '11

23 Sep '11

Hi All That's right, we are in feature freeze leading up to next months release of 3.6.0. No new features submitted will be considered for that release. Anything that is already in the needs-signoff queue is still ok though. But get testing, signing off etc. The next deadline is string freeze, coming up in 2 more weeks, the more you get signed off by then, the better. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand

1 0

bug 6328 signed off, patch stopped (spam ?)
by Zeno Tajoli 23 Sep '11

23 Sep '11

Hi to all, I have signed-off the patch for bug 6328. I have done little changes on files installer/data/mysql/kohastructure.sql and installer/data/mysql/updatedatabase.pl I have send the patch to koha-patches(a)lists.koha-community.org this morning (time of Rome) but I don't see the message yet in mailng-list. I think the message si blocked by anti-spam of the mailing-list Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

1 0

Call for News for the September Newsletter
by Daniel Grobani 21 Sep '11

21 Sep '11

Hi, I'm gathering news for the September newsletter. Please send me by the 24th anything you think the community 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 about what you're currently working on for publication in the gossip/society column. And if you know of a go-live not announced on the list, please be sure to let me know about it. Many thanks, Daniel Grobani

1 0

Restructuring C4
by Ian Walls 21 Sep '11

21 Sep '11

Fellow Developers, Last night, I stayed up late running circ/circulation.pl through NYTProf, to get an idea where we may be able to optimize circulation for speed. After much frustration (darn session IDs...), I was able to get a report. The results were... not exactly what I expected. It seems that much of the time spent running circ/circulation.pl is spent BEGINing the various C4 modules, multiple times. C4::Items, for example, is BEGuN 14 times in the execution of circ/circulation.pl. More stats: C4::Accounts - 8 BEGINs C4::Acquisition - 14 BEGINs C4::Auth - 14 BEGINs C4::Biblio - 14 BEGINs C4::Branch - 5 BEGINs C4::Circulation - 22 BEGINs C4::Context - 18 BEGINs C4::Dates - 12 BEGINs ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, and C4::Search::PazPar2 are BEGuN several times, without any calls to any of their subroutines. Some modules, it seems, don't have an END at the end... I was also able to get a Graphviz file out, showing all the package calls (folks may remember my keen interest in such things from KohaCon). Running it through sccmap to detect cycles, I found a very long one between several of the modules. About 8 packages long. All this indicate to me that we REALLY need to start thinking about imposing some kind of structure on C4. I'm thinking something with two-levels: Level 1 : Calls to the database, other direct interaction with stored data Level 2: Calls to Level 1 functions to manipulate data all our scripts would then be modified to call only Level 2, which would take care of talking to Level 1. At the worst, a particular Level 1 package would be BEGuN as many times as there were Level 2 packages BEGuN in the script (and we could certainly do better). It would eliminate all the cycles, as well. I can provide access to my report for anyone who needs it, or more details about how I obtained it. Whatever any of you need to keep this conversation going. This is a big deal, in my opinion, and we need to start detangling our code before too much long, or we're going to get seriously bogged down. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

11 25

unsuscribed
by Suzanne Bellande 21 Sep '11

21 Sep '11

Please unsuscribed me. sincerely, Suzanne Bellande -- Suzanne Bellande, Bibliothécaire Chargée de mission réinformatisation Coordinatrice UBIB pour l'ULR Bibliothèque universitaire Université de La Rochelle 2 parvis Fernand Braudel 17042 La Rochelle cedex 1 Tél. 05 46 45 68 92 Fax 05.46.50.59.92 http://www.univ-larochelle.fr/-Bibliotheque-.html

2 1

incomplete list in install_misc/debian.packages
by Zeno Tajoli 21 Sep '11

21 Sep '11

Hi to all, I see that the file install_misc/debian.packages is quite incomplete. I think it is a bug, many modules that are avaible with apt in debian squeeze are not listed. So I send a bug about it. But I have same question: 1)In the list do I insert also packages that are dependeces of others ? For example libbusiness-isbn-perl wants to install also libbusiness-isbn-data-perl. Do I list only libbusiness-isbn-perl ? 2)I don't list modules about Memcached. Is it OK ? 3)The module Gravatar::URL in debian squeeze package is at version 1.02. The veesion request in C4::Installer::PerlDependencies.pm is version 1.03, so I don't list it. Is it OK ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

2 3

Re: [Koha-devel] tt style point
by Mason James 20 Sep '11

20 Sep '11

On 2011-09-19, at 8:09 PM, LAURENT Henri-Damien wrote: > Le 19/09/2011 04:06, Mason James a écrit : >> i too, sure would love to get an agreement on a consistent, mechanised formatting style for perl code in Koha >> fyi: Koha's current .perltidyrc was never agreed upon, it was simply submitted and accepted > As far as I know, it has never been enforced though. yes, its never been agreed upon or enforced - it was just a thoughtful suggestion from Andrew > And enforcing that globally would make it a pain in the neck for all > developpers and maintainers rebasing their features. i'm not suggesting existing code will be rejected if its not formatted to the new perltidy style, thats too painful!! i simply suggest we start the process by agreeing on a standard, and go from there... > Unless it is > planned, announced widely, and done when every ppl agree, I think that > perltidyrc would be just an idle file. the current perltidyrc file *is* just an idle file, because it was never agreed upon... lets agree on a formatting style, and make the spec official. then it wont be just an idle file :) > I once did that on our repository. It made it much harder to port > features and code back into the trunk. So I would love that. again... i'm not suggesting that we force people to perltidy their old code > Maybe it could be discussed and done just before splitting branches for > stable branch. Therefore, the maintainer and the new master would have > the same "coding standard" > It could also THEN be invoked as a git hook on edited files so that they > would not loose their tidyness. yep, those are both great ideas :) i'm strongly against having old code 'perltidy-fied' in huge commits, because i know the problems that causes with tools like 'git-blame', etc so i suggest we slowly and gently correct small blocks of existing code - as we work on it and the formatting in new Koha releases will start to become more consistent i personally don't mind *what* that standard is... i just want an agreed upon standard but hey... --PBP get my vote by a mile! cheers, Mason

1 0