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

about Unimarc and Analytical record implementation
by Zeno Tajoli 11 Nov '10

11 Nov '10

Hi to all, about this request of Henri-Damien on koha-patches > Date: Wed, 10 Nov 2010 22:59:43 +0100 > From: LAURENT Henri-Damien <henridamien.laurent(a)biblibre.com> > Subject: Re: [Koha-patches] [PATCH] Analytical record: improved code > to create analytical record from an item > To: koha-patches(a)lists.koha-community.org > Message-ID: <4CDB15CF.2080104(a)biblibre.com> [...] > This is marc21 only. > Could you be so kind as to at least use some variables ? > Or create the variable and then populate it ? I'm the person that will do those changes. I wrote to Savitra and Amit and I said that I will do this type of changes. So you will see them. -- Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @)

1 0

3.2.x Release Maintenance Procedures
by Chris Nighswonger 10 Nov '10

10 Nov '10

During the general IRC meeting today, a question came up concerning how I plan to push patches to 3.2.x. Here is the general procedure I intend to follow, but am certainly reserving my right to change it as necessary. 1. The general policy will be to cherry-pick/merge patches from HEAD as they appear and are applicable to 3.2.x. Besides the fact that bugs in 3.2.x are also bugs in HEAD, these patches have already passed QA and are considered stable, so this greatly reduces the workload. 2. At such a time as a merge conflict should occur due to the eventually inevitable divergence of 3.2.x and HEAD, *the submitter* of a patch will be responsible to ensure that the patch applies to both branches (HEAD and 3.2.x) *before* submission, and if the patch does not apply to the 3.2.x branch, *the submitter* will be responsible to take whatever action is necessary to make it apply before submission. This will most likely mean submitting two versions of the patch: one for HEAD and one for 3.2.x. This responsibility is an ethical one as it is not ethical to expect the release maintainer who is one person to make the many patches apply when the submitter who is one person merely has to make one patch apply. One thing which will greatly reduce the burden of #2 is the RM's planned use of topic branches. Merge conflicts are much easier to manage and far less overwhelming with the use of topic branches. Suggestions and opinions are welcome. Kind Regards, Chris Nighswonger Koha 3.2 Release Maintainer

2 2

A Discussion on A Policy Setting Forth Standards of Code Submission, etc. [WAS: RFCs for 3.4 from BibLibre (serials & acquisitions)]
by Chris Nighswonger 10 Nov '10

10 Nov '10

Starting a new thread because this is indirectly related to Paul's request. 2010/11/2 Paul Poulain <paul.poulain(a)biblibre.com> > Hello, > > I have filed RFCs for all enhancements you can expect from BibLibre in the > next few months. All of them are sponsored (by Saint-Etienne University), > and will have to be delivered to the library for a "go live" in May-2011 > > * You can find them on the wiki (search biblibre rfc for3.4) : > http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir… > * You can also find them on bugzilla : i've added a saved search, shared > with everybody, called "Koha 3.4 enhancements". > > They are only related to serials and acquisitions. > > What's the next step ? > * read the RFCs > * comment them (on the wiki or on bugzilla) > * we will probably propose/organise an IRC meeting to discuss & get any > feedback for all those incoming developments. None of them (except the solR > one) has started, so if you want to give us an advice, add something, ... > it's now or it may be too late ;-) > > As a vendor-neutral voice, I would like to encourage everyone who has an vested interest in these areas and the best interests of the Koha project at heart to actively participate and respond to these RFC's. It seems that often there is little dicussion, etc. on RFCs in the community. And even when there is discussion, etc. it is often unclear if a consensus is reached (at least publicly). Furthermore, I would encourage vendors and others who post RFC's to do so with a willingness to adapt, adjust, bend, compromise, and/or <your-favorite-term-goes-here> to positions on those RFC's which may be different but are clearly the consensus of the community at large. Vendors may and often do have the resources to implement "what they want," however, this is not in the spirit of cooperation which this project so greatly depends upon for its success. Clients of vendors should be educated during the RFQ process as to this aspect of open source, and their expectations managed accordingly, imho. I would also suggest that we implement a policy that states in some agreeable way that code/features will not be pushed to master which have not passed through a review and consensus process by the community and the RM (as the elected head of development by the community). No one excepting possibly the RM should presuppose that their code is guaranteed inclusion by default. Secondly, I would suggest that we implement a strong recommendation that larger shops submit timely RFC's *prior to* beginning work on code and then promote discussion on those RFC's. This recommendation should with some lesser strength suggest that everyone submit timely RFC's to maximize productivity and usefulness of the resources of all concerned. Thirdly, I would suggest a stated policy (and such a policy is presently in place practically) which requires all submissions to pass through a QA branch and receive at a minimum one sign-off prior to being pushed into master. This policy should also assign a certain amount of responsibility to the one signing off to avoid "frivolous" sign-offs. It should also, perhaps, include a restriction that the required sign-off for pushing to master be a disinterested developer perhaps from another vendor or the community at large. This is a discussion we need to have. I would encourage everyone to invest time (the operative term here is 'invest') in this discussion. Kind Regards, Chris Nighswonger Koha 3.2.x Release Maintainer

12 23

Re: [Koha-devel] [Koha] Koha - Trouble loading patron files NOT solved
by Chris Nighswonger 09 Nov '10

09 Nov '10

On Mon, Nov 8, 2010 at 10:06 PM, Chris Nighswonger <cnighswonger(a)foundations.edu> wrote: > On Mon, Nov 8, 2010 at 9:54 PM, MJ Ray <mjr(a)phonecoop.coop> wrote: >> So I think that error means that either @columns contains an undefined >> value, or that $csvkeycol{$key} isn't defined but we test that it is >> so that shouldn't be the problem. How can @columns contain an >> undefined value? Maybe if a line doesn't have enough fields? >> >> Right now I'd be checking that CSV file very very closely. > > One of the problems *is* the CSV, but that's because the instructions > are not clear. Several fields in the borrowers table are NOT NULL > which means that several columns in the CSV which advertise themselves > as *not* mandatory are, indeed, mandatory. I'm in the process of > correcting this along with making the patron import tool more > informative as to errors which occur during attempted imports. I hope > to have this work finished and submitted the first part of this week. This patch should resolve these issues: http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=shortlog;h=refs/… It applies against the current HEAD, but should apply against 3.2.x as well. Once it is pushed to HEAD, I'll back-port to 3.2.x. In the meantime, testing and sign-off would be appreciated. (CC' ing the devel list to get more coverage.) Kind Regards, Chris

1 0

Re: [Koha-devel] Webcam Barcode reader
by Dobrica Pavlinusic 09 Nov '10

09 Nov '10

On Mon, Nov 08, 2010 at 09:28:04AM -0500, Galen Charlton wrote: > Hi, > > On Fri, Nov 5, 2010 at 5:35 PM, Dobrica Pavlinusic <dpavlin(a)rot13.org> wrote: > > p.s. additional benefit of zxing is that it has support for codabar > > which we have on our books, but that is specific for our library. > > Actually, quite a few libraries use Codabar, so zxing would be of broader use. Good point. However, I should note for future reference that zxing by default doesn't have Codabar enabled, so it has to be compiled using following patch: http://code.google.com/p/zxing/issues/detail?id=538 -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

2 1

opac-search.pl
by Toni Rosa 09 Nov '10

09 Nov '10

Hello, We are using Koha 3.0.5 I noticed that the opac advanced search in it (opac-search.pl) when running in a nozebra installation doesn't honor "publication period" intervals (e.g entering the 1800-1900 interval the search doesn't work). I followed the code to the "C4/Search.pm" file, method "NZanalyse" and it seems that it actually doesn't even try to build the sql query taking the intervals into account. Did anyone find the same behavior? (I'd guess everybody should, as it seems a bug/omission to me!) Thanks, Toni

4 6

General meeting on IRC: Wednesday, 10 November 2010 at 19:00 UTC+0
by Magnus Enger 09 Nov '10

09 Nov '10

Hi All Our next IRC meeting is on Wednesday, 10 November 2010 at 19:00 UTC+0 on the #koha irc channel on irc.katipo.co.nz. The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_Meeting,_10_November_2010 Currently the agenda looks like this: * Update on Roadmap to 3.2 * Update on Roadmap to 3.0 * Update on Roadmap to 3.4 1. BibLibre branches submitted to QA (roadmap & what's still expected from BibLibre. feedback from librarians) * Community building : 1. RFCs agreement workflow (discussion about the workflow for RFCs to be accepted/validated) 2. git management (branches) 3. jqueryui adoption instead of YUI 4. proposal to form a Technical Committee * Follow-up on actions from General IRC Meeting, 6 October 2010. * Agree times of next meetings. Please feel free to edit the agenda to add any issues you would like to talk about, and feel free to attend the meeting using your favourite irc client. Best regards, Magnus

2 1

Mails when patch pushed to git
by Paul Poulain 09 Nov '10

09 Nov '10

Hello, In the mail we recieved when RM/RMaint pushes a patch to git.koha-community.org I'd be happy to have the details of the patch. For instance, the mail contains: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "main Koha release repository". > OK (even if it could be shorter maybe) > The branch, master has been updated > via e5bdc1e9ab9465c618968eb32f2adbfeee56c445 (commit) > via 4e11a5ade37485a2822d7ce9682fbd84e4d6637b (commit) > via 20dce153b1f785a758d6924103e51a6cef173fd3 (commit) > via 653259e6216efa9359c6c8022de42a342e4a14d1 (commit) > from 5145eb59b786bd2010eb324197034dd210504543 (commit) > What can I do with the previous information? seems cryptic to me unless someone explains (note I know it's a git patchid, but as is, in the mail, I don't see how it is useful) > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > Is the previous paragraph needed? > - Log ----------------------------------------------------------------- > commit e5bdc1e9ab9465c618968eb32f2adbfeee56c445 > Merge: 5145eb59b786bd2010eb324197034dd210504543 4e11a5ade37485a2822d7ce9682fbd84e4d6637b > Author: Chris Cormack <chrisc(a)catalyst.net.nz> > Date: Wed Nov 3 16:52:21 2010 +1300 > > Merge remote branch 'kc/new/bug_5308' into kcmaster > > ----------------------------------------------------------------------- > > Summary of changes: > installer/data/mysql/kohastructure.sql | 11 ++++++++--- > installer/data/mysql/updatedatabase.pl | 27 +++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 3 deletions(-) > > Well, I would be VERY interested by the detailled content of the changes ! For at least 2 reasons : - if I have a patch waiting, it's unclear if that's what I've submitted or not. + as chris (3.4RM) pushed through a patch, we can't know who is the original author of the patch. - I could do a post-push if needed. Is it possible to improve the hook? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

5 4

DBIx::Class vs current Koha's DBI performance
by Dobrica Pavlinusic 08 Nov '10

08 Nov '10

I just figured out today that kohacon10 is in progress, and one of topics seems to be DBIx::Class migration. Let me start by saying that I'm all for it, but probably not for same resons as everybody else. I was trying to profile koha search page. On first run under Devel::NYTProf it showed 2220 invocations of DBI::st::execute. That's more than 2000 calls which wait for database to return answer. This might explain extremly high usage of mysql query cache which I'm seeing in production: http://mjesec.ffzg.hr/munin/koha/koha-mysql_queries.html So, I decided to experiment a bit. and few patches later I was able to reduce number of queries issued on each page load down to 876 If you are interested in what I changed, my code is at: http://git.rot13.org/?p=koha.git;a=shortlog;h=refs/heads/nytprof-cache It's basically using either global hash to cache values per request of simple memoize around function. Which brings me back to DBIx::Class. If we can cache values using dbic, this will be huge WIN for Koha performance as opposed to loss :-) I never used dbic in that contex, but google seems to think it's possible, and I'm willing to take a try at it. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

9 16

Webcam Barcode reader
by Charl 05 Nov '10

05 Nov '10

Did anyone try the ZBar open source webcam barcode reader? Is it practical to use in a library environment?

3 2