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

Koha Foundation
by Joshua Ferraro 14 Apr '06

14 Apr '06

Hi all, Over the past few weeks we've discussed the idea of forming a Koha Foundation -- a non-profit organization for Koha. I'd like to open this topic up to koha-devel to hear what your reasons are for wanting such an organization, as well as how you think it should be set up (and where). Any takers? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

12 31

QA manager
by Pierrick LE GALL 14 Apr '06

14 Apr '06

Hi koha-devel, On the last Koha team meeting of March 20th, 2006, we discussed about the position INEO (me for instance) could officialy take on the project. Joshua and Paul proposed me to be Quality Assurance (QA) manager, and I personnaly accepted this role for a two months try. I've just asked my INEO managers for a formal validation. On IRC, the definition about QA manager was discussed, because everybody doesn't define it the same way. Paul said "responsible for heavy testing" and I answered I did not agree with this point of view, not in OSS model. thd asked what difference I made between open and closed source QA. Let's answer this question by mail, as requested by Russ. See details on IRC logs [1]. I first answer to the question "what difference I make between open and closed source QA", then I'll describe what is my vision of QA manager for an OSS project like Koha. QA, proprietay Vs OSS ===================== I've worked on the two sides of softwares : proprietary and OSS. I think I understand the advantages and drawbacks of each model, concerning QA. In a proprietary model, the software *must* be /stable/ when reaching customers. In my vision, /stable/ means: - without bug that may corrupt customers data - without blocking bug Consequently, a proprietary software vendor needs to have a QA team. This team assures the stability of releases. No right to mistakes because financial penalties will be requested by customers. OSS model is different because it *involves* customer on QA. This is a very important point in my opinion. An OSS project must provide efficient tools to communicate with core dev team. Customers/users are willing to propose patches. OSS model partially moves QA to customers. Not completely of course, and I'll describe muy vision of QA management later. I'm sure Koha developers have all read Eric Raymond essay "The Cathedral & the Bazaar" [2] (if not, I encourage the reading). In this essay, you can read the summarize of Linus's law : "Given enough eyeballs, all bugs are shallow.". Koha team will never have enough eyeballs, this is why customers must be involved in bug tracking, from notification to test & validation. Having worked nearly 3 years in a proprietary software company, I can assure you that QA is one of the most critical task, and very often underestimated since it costs a lot while not giving back money directly. QA team needs to grow at the same speed as development team output, and even more because complexity increases more than linearly. OSS offers a solution to assure software quality without costing a lot more. Indeed, the more customers, the more requested features, the more tests required. If customers are involved in QA process, the number of testers will increase the same as the number of features. My conclusion is that in OSS, QA dedicated team don't need to be as big as development team. My explanations are very theoretical, in the reality OSS vendors have to "release often, release early" [2] and involve their customer at an early stage of deployment, not only before production deployment. This is why HEAD builds, 3.0-RCx are necessary. I think some customers will accept to play the role of beta tester. I ask Paul, Joshua, Russ and other Koha services vendor to give their opinion. My QA manager vision on Koha ============================ I come to my vision of QA manager on Koha project. The most important of the QA manager is to know the content of the bug tracker: 1. being notified on every update 2. dispatch issue to developers (with developer authorization) 3. check that each issue is assigned/treated 4. reduce time between bug notification and its closure It is important that no bug remain a too long time unassigned/untreated. If this happens, customer won't feel useful to involve herself. A bug rapidly corrected with a efficient communication between reporter and developer will encourage customers to report bugs, thus improving Koha quality in the long run. An additionnal task of the QA manager is Bug Squashing Party (BSP) coordination. I need to be explained how Koha worked on this in the past. I'm waiting for your feedback. [1] http://tinyurl.com/n4234 [2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ Cheers, -- Pierrick LE GALL INEO media system

5 5

form buttons Vs simple links
by Pierrick LE GALL 14 Apr '06

14 Apr '06

Hi koha-devel, I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic. For example, in members/moremember, reaching members/readingrec (reading records) requires to use a form button. There are several reason not to do this: - semantically incorrect, a form is supposed to have textfields, select boxes, a reset button and a submit button. - when my mouse cursor is over the button I don't see in the status bar where clicking will bring me - most of form are with method post and have a variable (like a borrower number) so I have a warning a each reload of the new page. Furthermore, I don't see the borrowernumber in the URL. - painful to write in template HTML code In my opinion, for action links, we could have icons. For example in members/moremember, instead of a vertical list of possible action on the borrower, we could have a text-align:center horizontal list (display:inline) of pretty icons (there are plenty beautiful icons available for free applications like Koha). A tool tip for each icon giving details on each action. I don't know/understand the reasons why buttons where choosen instead of normal links to do links job, but I would be happy to have information :-) (found nothing in IRC logs and koha-devel archives). Bye -- Pierrick LE GALL INEO media system

6 9

Template Development
by Kyle Hall 13 Apr '06

13 Apr '06

Hey All, Is there any way to find out what branch an intranet browser is set to from any page? I tried using TMP_VAR NAME="branchname" but it is only accessible from circulation.tmpl. Thanks, Kyle

4 4

Investigations on Perl, MySQL & UTF-8
by Pierrick LE GALL 13 Apr '06

13 Apr '06

Hi koha-devel, Because the story of Perl, MySQL, UTF-8 and Koha is becoming more and more complicated, I've decided to start my tests outside of Koha or any web server. I wanted to check that Perl and MySQL could communicate with UTF-8 data. What I did : 1. copy some UTF-8 strings from http://www.columbia.edu/kermit/utf8-t1.html paste into a UTF-8 text file utf8.txt (open/past in UTF-8 console, with Vim having :set encoding=utf-8) 2. create a UTF-8 database with a simple table having a TEXT field $ mysql --user=root --password=xxx mysql> CREATE DATABASE `utf8_test` CHARACTER SET utf8; mysql> connect utf8_test mysql> create table strings (id int, value text); mysql> quit (no need to set connection character set to utf-8 in that case, default latin1 is fine) Note: my MySQL server is latin1... $ mysql --user=root --password=xxx utf8_test mysql> status Server characterset: latin1 Db characterset: utf8 Client characterset: latin1 Conn. characterset: latin1 mysql> set names 'UTF8'; mysql> status Server characterset: latin1 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 3. write and execute a Perl script which reads the UTF-8 text file, insert UTF-8 strings into database, retrieve UTF-8 strings from database, print UTF-8 strings to STDOUT. See details in attached file readfile_insertdb.pl. Important note: "set names 'UTF8';" is mandatory. Everything is *working fine*. My output is in UTF-8, I'm 100% sure of it. DBD::mysql : 2.9007 Perl : 5.8.7 MySQL : 4.1.12-Debian_1ubuntu3.1-log DBI : 1.48 (find your local versions with attached script versions.pl) I suspect that Paul's data stored in MySQL are not truely UTF-8. Maybe I miss the point, but it seems Perl, MySQL and UTF-8 are not working so badly altogether. Cheers, -- Pierrick LE GALL INEO media system

2 2

MARC Editor Visibility
by Joshua Ferraro 03 Apr '06

03 Apr '06

Hi all, thd and I have introduced some additional complexity into the MARC frameworks that offers a more complete handling of tag and subfield visibility. It's completely backwards-compatible so if you're happy with your current visibility options you don't need to do a thing and everything will behave exactly as it did before. First, I should introduce the problem: with the old scheme, there was a flag (INT(1)) that allowed hiding a subfield in the OPAC. You could also set a subfield to 'ignored' which was used for the special tags/subfields whose values are managed internally (e.g., 090). This would probably have sufficed but for the fact that thd has been working on a complete 'Standard MARC21 Framework'. In testing this framework (which includes 2/3s more fields than 2.2.5's default framework), we discovered that it was unusable due to long page loads (it's really quite a huge form with about 3,500 fields defined). (just to give you an idea of how slow it was, it took about 90 seconds to load a blank 'addbiblio' page and about 2-3 minutes to save a populated record). In addition, there is the problem of usability. With so many tags and subfields on a page it's very difficult to identify the most commonly used fields -- they are lost among the uncommon and rare fields. So we set out designing a 'visibility scheme' with three basic goals: 1. prevent very rare tags/subfields from being loaded into the MARC editor by default, but allow the user to add them if needed (with a page reload) and _definitely_ load them if they already exist in a record (ie, _no_ data lost when using the MARC editor). 2. allow uncommonly used fields to be collapsed and expanded quickly and easily without a page reload. 3. preserve the legacy 'hidden' functionality so the new framework isn't required for the upgrade to 2.2.6. As it turns out, there are quite a few possible visibility conditions that should be properly dealt with in a future version of Koha. Using the current framework's 'hidden' database definition (INT(1)) we can account for up to 19 such conditions (values -9 thru 9). Given that limitation as well as our current time constraint, we identified 17 conditions that will be defined in the new 'Standard MARC21 Framework' plus a 'Flag' condition that can be used to flag subfield definitions that will need to be revised when the framework can handle more conditions (ie, in 3.0). The scheme we devised is the following: ( ! means 'not visible' or in the case of Collapsed 'not Collapsed') -9 => Future use -8 => Flag -7 => OPAC !Intranet !Editor Collapsed -6 => OPAC Intranet !Editor !Collapsed -5 => OPAC Intranet !Editor Collapsed -4 => OPAC !Intranet !Editor !Collapsed -3 => OPAC !Intranet Editor Collapsed -2 => OPAC !Intranet Editor !Collapsed -1 => OPAC Intranet Editor Collapsed 0 => OPAC Intranet Editor !Collapsed 1 => !OPAC Intranet Editor Collapsed 2 => !OPAC !Intranet Editor !Collapsed 3 => !OPAC !Intranet Editor Collapsed 4 => !OPAC Intranet Editor !Collapsed 5 => !OPAC !Intranet !Editor Collapsed 6 => !OPAC Intranet !Editor !Collapsed 7 => !OPAC Intranet !Editor Collapsed 8 => !OPAC !Intranet !Editor !Collapsed 9 => Future use With this scheme, it's quite simple to check for the most important cases: *if (odd) { collapsed } *if (even) { !collapsed } if (>=0) { hidden in OPAC } if ((<=-4)||(>=5)) { not in the editor unless exists or is added} Those four checks take care of all the goals we set out to achieve. Of course, there are finer distinctions to be made, but we'll leave that for a future version. So just to clarify, we've implemented a subset of the scheme we devised -- a subset that doesn't comprimise where it counts (ie there won't be any data loss as with Koha 2.2.5). If you want to try out the new system feel free to use LibLime's demo: http://koha.liblime.com/cgi-bin/koha/acqui.simple/addbiblio.pl You'll notice that some tags (take 040 as an example) are listed but the subfields within them aren't -- simply click on the little + graphic to expand the fields (no page load) Likewise, some very rare tags/subfields don't appear by default. However, if you do a Z3950 search for a record and one contains them they will appear when you import the record (they will also import if they exist in records in the database). Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

3 5

borrower issues, work made twice
by Pierrick LE GALL 31 Mar '06

31 Mar '06

Hi koha-devel, circ/circulation and members/moremember are both showing a table of the unreturned issue of a borrower. The two page provides the same information, displayed with only very slight differences. I wonder why the same work is made twice. Should we have this table only on circ/circulation? and a link to circ/circulation on members/moremember? The link could give a summary of current issues (eg: "2 issues with 1 overdue"). Bye -- Pierrick LE GALL INEO media system

4 5

fieldsets in templates
by Pierrick LE GALL 31 Mar '06

31 Mar '06

Hi koha-devel, Still working on HEAD templates... Yesterday I made a commit on prog/en/circ/circulation.tmpl to make it comply with TemplateManual guidelines. (another commit to come in the day). To separate informations on the same page, I've used fieldsets. These HTML tag is made to group fields of a form in a logical way. On templates I've read so far, I mainly see multiple forms for each page, so I used one fieldset for each form. I wanted to have your feedback about using fieldsets. Bye -- Pierrick LE GALL INEO media system

3 2

Re: [Koha-devel] Koha Foundation
by COURYHOUSE＠aol.com 30 Mar '06

30 Mar '06

Greetings... I am back! There are lots of computers that get tossed here in the US .. A foundation would allow you to approach companies to set these in far away places and pick up the freight tab as a donation. Intel and other large US companies also donate stuff... Bill and Melissa gates foundation donates stuff... although the thought of them donating boxes to run LINUX on might not seem appropriate... Anyway bottom line... having a foundation or non profit corp. in the US you would be able to offer US companies and US citizens tax incentive for helping.. Sad to say ... most of the time if there is no tax incentive they will do nothing. OK now for the legal parts... > ... If you are going to incorporate in just one country II would incorporate the foundation in what ever country would offer the best donations, as you will have to be incorporated in that country to offer the citizens the tax benefit. The US with the abundance of technology stuff here seems to make sense. But you can also incorporate it in many countries just like you do a corporation for profit. Thanks, Ed Sharpe, Archivist for SMECC See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library - please advise if you have anything we can use. Coury House / SMECC 5802 W. Palmaire Ave. Phone 623-435-1522 Glendale Az 85301 USA I also know many libraries in Africa that could be interested by such computers, with Koha (server or client -firefox-) installed.

1 0

No way to reorder catalog search results?
by Kyle Hall 29 Mar '06

29 Mar '06

Hey all, I've been tinkering with the search.marc/search.pl and search.tmpl files because we'd like to add 'sort' links in the table headers for the search results (like the ones used in reserve.tmpl). I noticed the variable $orderby, but it is only used in function findseealso($dbh, @tags). So, as far as I can tell, what I would like to do is not possible without modifying search.pl. Can anyone confirm or refute this for me? Thanks for the help. Kyle IT Tech Crawford County Federated Library System

2 1