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

Koha - city field in patrons
by Linda Culberson 16 Nov '10

16 Nov '10

This is only a suggestion, and not a formal RFP. When showing Koha to some of our staff, I was asked why the state (region/province/provincial district in the case of some countries) isn't separated from the "borrowers.city" field. (Sorry, not enough coffee yet, this morning. ) In other words, why doesn't the state (region/province/provincial district) have it's own field? When asked, I didn't have an answer. I will admit that one of my borrower_attribute_types.codes is STATECODE, so the state information is actually duplicated in our database, but I need it for statistical reasons. I apologize if I'm posting this to the wrong list, but I plead caffeine deprivation. Thanks. -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824

3 2

Time for reflexion
by Miguel Angel Calvo Lázaro 16 Nov '10

16 Nov '10

We want to take this opportunity to congratulate Biblibre for initiating the search engine change with which we are identified and in which we would like to collaborate, due to the important problem on the facets. We believe that it is time to examine some aspects of the project, with no intention of offending any member of the community in doing so. In Xercode, despite being a new company, some of our members have been working on the project since 2007, when we first came into contact with PERL. All of our present developers have been working on PHP and JAVA projects. Since then, we have been conscious that the structure of KOHA is unlike any other major project we have worked on previously. In our opinion, it has become necessary to upgrade technologies employed in the project making KOHA more competitive with similar software. We believe that is urgent to use a framework like DANCER, SOLR as an index engine (our main problem with clients), increase performance, ... We believe, however, that this will not completely resolve our present situation due to the fact that the project structure is not sufficiently defined. A good example is the propose of search engine change, a current point of conflict. We have traditionally followed an Object Oriented Metodology (working with interfaces and abstract classes). By doing this we would achieve an abstraction of the search engine and the result of using a method, for example “engineSearch”, would be the same with indifference to use SOLR or ZEBRA and the majority of problems that we are currently facing in the community (principally the integration of the diverse developments by each member) can be easily resolved. Applying this philosophy to .pl files would make them more concise and more easily understood. DRUPAL and OTRS (PERL) are good examples composed by a kernel and specific modules. Considering all of this, this is a perfect moment for reflexion due to the fact that these points may affect the scalability and evolution of KOHA. Regards, * Miguel Angel Calvo Lázaro* *Dirección de Soluciones* miguel.calvo(a)xercode.es Telf. 653 038 238 Rosalía de Castro, 53 4º C 15895 Milladoiro - Ames (A Coruña) Telf. 881 975 576 www.xercode.es info(a)xercode.es La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada.

8 11

Guidelines for Patch Acceptance/Rejection
by Ian Walls 15 Nov '10

15 Nov '10

Everyone, While there can be no guarantees as to whether a patch will be committed into the Koha codebase, I think in practice there are several requirements. This email is an attempt to identify a few of them, and hopefully start a discussion about whether they are truly requirements, and what others could possibly be added. 1. The patch must do what it claims to do, in all commonly-supported Koha environments 2. The patch must not break existing functionality 3. The patch must apply to the current HEAD of the master branch of the code 4. The patch must follow the Coding Style Guidelines 5. The patch must be MARC-flavour agnostic 6. The patch must contain appropriate copyright information 7. If a database update is require, the patch must handle the update both for new installs and upgrades 8. If a new feature is added, the patch must include appropriate Help documentation What do people think of these requirements? Are they reasonable? Should there be more? I understand that there may not be any set of requirements that's completely sufficient, but if we can identify as many as possible, it would make developers lives a bit easier, since we'd all have a better idea what is needed for our patches to be committable. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

8 12

Official Koha Newsletter: Volume 1, Issue 11: November 2010
by Nicole Engard 15 Nov '10

15 Nov '10

This issue has a lot of links and should be read online to see all of the external content: http://koha-community.org/koha-newsletter-volume-1issue-11-november-2010 Official Koha Newsletter (ISSN 2153-8328) Volume 1, Issue 11: November 2010 Table of Contents * KohaCon10 Summary o Summary of KohaCon10 in Blog Posts o KohaCon10 Presentations o KohaCon10 Videos o KohaCon10 Pictures KohaCon10 Summary of KohaCon10 in Blog Posts KohaCon10 took place in Wellington, New Zealand last month to honor 10 years of Koha development, use and community! It seems that your trusty documentation manager was unofficially names the official blogger of the conference, so excuse a newsletter full of links to posts written by me (and Ian Walls, my colleague who had cover the sessions I couldn’t). * Conference Proper o Keynote o Why a Librarian Loves Koha o Koha and Kete o Koha Adoption in Nigeria o Koha Governance o What’s Coming in Koha 3.4 o Fun with Library Data o Identifying eBooks o A cooperative view o Koha in Schools o Sharing is Good o History of Koha o Koha in Prison o Participation is Key o Koha in Malaysia o LAMP to Koha o Promoting Free Software in Libraries o Open Library and Koha o Koha: 10 years in 10 minutes * Hackfest o Intro to Git o Git and Koha o Template Toolkit o MySQL and Postgres Differences o Debian Packaging for Koha o Koha in the Cloud o An Argument for a project Coding Style o Ideas for Koha 4.0 o Koha Performance * Summaries o KohaCon10 is Finished o KohaCon10 Additional Posts KohaCon10 Presentations Some KohaCon10 presentations were posted on SlideShare, others posted on personal websites and others plotted on a map. If I’ve missed any please feel free to add them in the comments below. * KohaCon10 on SlideShare * KohaCon10 Presentation Map * Specific Presentations o Koha at ASHS by Mark Osborne o Fun with Library Data by David Friggens KohaCon10 Videos KohaCon10 videos are still making their way online, here are a few that are up so far. You can search for the rest as they’re added on blip.tv by using the keyword “kohacon10” * Keynote by Rosalie Blake * Why Librarians Love Koha by Lee Phillips o Video of Lee’s librarians * Kete and Koha by Walter McGinnis * Koha uptake in Nigeria by Olugbenga Adara * Library Data for Fun & Profit by David Friggens * Koha: 10 years in 10 minutes KohaCon10 Pictures Mostly KohaCon10 pictures were posted on Flickr and tagged “kohacon10“. My favorites were taken by Kristina, she knows how to take pictures!! Thank you to all who took pictures and shared them so that those back home could share in the festivities with us and so that we can all look back and remember our time together fondly. What we didn’t get was a group picture that I could post here, so you’ll have to go browse through the Flickr pictures and spot your friends and community members that way. Newsletter edited by Nicole C. Engard, Koha Documentation Manager. Please send future story ideas to me.

1 0

Externalizing PO files (Was Re: externalising translator and etc)
by Galen Charlton 15 Nov '10

15 Nov '10

Hi, [Splitting the thread, there are two distinct topics being discussed.] On Mon, Nov 15, 2010 at 4:16 AM, LAURENT Henri-Damien <laurenthdl(a)alinto.com> wrote: > Le 14/11/2010 22:51, Galen Charlton a écrit : > From my understanding of Scott Chacon (a git developer) book and git > talk, git stores the files in its database, since it is a DAG oriented > SCM. It may send the diffs, but actualy stores the files. A cursory reading of a Git book reveals that a statement that Git "actually stores the files" is simplistic, at particular as far as the implications for storage are concerned. Please take a look at: http://book.git-scm.com/7_how_git_stores_objects.html Git's object storage takes the form of compressed version of each object (commit, file, tag, etc.) a files and (and this is the important part) packfiles. Packfiles, roughly speaking, encode only the changes to objects, so a significant amount of space is saved. If one disabled automatic garbage collection in a git repo and never ran git gc, you might end up with something close to storing the (compressed) version of each changed file, but in practice that doesn't happen. > I don't think all the release tags would be broken. As it turns out, they would. I have actually tried running a git filter-branch to remove the PO directory. As I suspected, it does rewrite all of the commits (thereby changing the commit IDs), and it would be necessary to rewrite the tags. But doing so would invalidate the release tags that have a GPG signature. Rewriting history like this is a sure way to get months of complaints and calls for help on koha-devel with questions like "why does git rebase origin no longer work". > And it would allow to release localisation at a different pace... When > there is a need. There's is nothing stopping releasing localizations on a different schedule now. Packaging does not have any necessary connection with how the Git repository is laid out. I will grant that all other things being equal, it would have been a valid choice to have the PO files live in a separate repository. In fact, we perhaps can still do so. One thing that Chris Cormack mentioned to me yesterday is that Pootle has a Git plugin which can automatically commit changes to PO files to a repository. That would be a bit dangerous to allow for the main Koha repository, but safe enough for a separate translations file. Consequently, there is a possible compromise: [1] We seed a new repository for PO files. [2] We do a simple git rm misc/translator/po but *don't* rewrite history. This won't reduce the size of the main repository, of course, but achieves the separation. And, to be honest, it's mostly the possibility of integration with Pootle that would make me interested in this. However, since it is the translation manager who would be primarily affected by the split on a day-to-day basis, I would be interested in hearing from Frédéric as well as past TMs. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

2 2

externalising translator and etc
by LAURENT Henri-Damien 15 Nov '10

15 Nov '10

Hi I propose to get etc and translator as external git repositories. Why ? It would allow to have po files in their own repository and limit the weight of Koha git archives. For etc, it would allow to change the installer in order to keep track of local changes for every person and therefore be able to synchronize with community version properly. HOW ? operation is simple : git filter-branch --subdirectory-filter misc/translator -- --all and then git push on an external repository. for instance etc.git and translator.git on git.koha-community This would allow to have more than one branch for etc and for instance create and etc/apache etc/nginx etc/plack and so on... WHEN ? when you think operation should be done, if you think it could be interesting. and then we could have git submodules in the koha.git repository in order to keep in synch and synchronise versions when we want. http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html It is just a proposition. -- Henri-Damien LAURENT

7 8

Perl resource
by Colin Campbell 15 Nov '10

15 Nov '10

This may be of interest to some: http://www.onyxneon.com/books/modern_perl/index.html This new book is available as a free pdf. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

2 1

Re: [Koha-devel] Bug 5401: WYSWYG for Koha News
by MJ Ray 15 Nov '10

15 Nov '10

Galen Charlton wrote: > Since TinyMCE is used by only one page, if we decide to switch to > elRTE (or to something else entirely), it won't be a big deal. Has > anybody done a direct comparison? I've used TinyMCE and haven't used elRTE, but wouldn't this question get better answers if asked on koha-devel? Thanks -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha

5 7

Call for testing .. Reports module changes
by Chris Cormack 14 Nov '10

14 Nov '10

Hi all There is a branch at git.koha-community.org, new/biblibre_reports. It has had some good initial testing, with a few issues found and fixed, (Thanks Galen). If people could check it out and do some more testing, and let me know what they find. I think it is very close to being merged to master, I would just like a little more testing by some others. You can see the branch in gitweb here http://git.koha-community.org/gitweb/?p=koha.git;a=shortlog;h=refs/heads/ne… And can report your findings here http://wiki.koha-community.org/wiki/BibLibre_patches_to_be_integrated_for_3… Thanks in advance. Chris

1 0

November Newsletter
by Nicole Engard 13 Nov '10

13 Nov '10

Hello all, I'm thinking for the next Koha Newsletter we'll do a conference sum-up. So between the start of the conference and the 12th of November please send me links to posts you may have written about conference sessions, links to pictures from KohaCon, and anything else conference related. Thanks Nicole C. Engard

1 2