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

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

Proposal to change phone and email language on patron
by Nicole Engard 25 Sep '10

25 Sep '10

Hi all, I was talking with some librarians today and they were wondering if we could change the language on the patron record. Instead of saying Phone (home) could it read Phone (primary)? This suggestion came from the fact that many people now have only a cell phone and if you enter that number in the Phone (cell) box you don't see it on the transit slips or the patron record quick view on the left. This suggestion carries over to the email addresses as well. I recommend we use Primary, Secondary, and Tertiary instead of Home, Work, Cell so that the librarians and patrons can decide what's most important for the patron. What do you all think? Anyone have any strong feelings either way? I will gladly make the change if others think this makes sense, but I wanted to bring the question to you all first. Thanks Nicole C. Engard

7 15

system preference question (anonymous preferences)
by Nicole Engard 19 Jul '10

19 Jul '10

There are 2 system preferences in my most recent version of HEAD: - AnonSuggestions -- Set to anonymous borrowernumber to enable Anonymous suggestions - AnonymousPatron -- Set the identifier (borrowernumber) of the 'Mister anonymous' patron. Used for Suggestion and reading history privacy Does this mean that AnonSuggestions is not used? I personally think we need both and that Anon should be for suggestions and AnonymousPatron for reading history. Can someone please clarify these for me? Thanks Nicole

3 6

Re: [Koha-devel] Graphics::Magick 1.3.5
by Partha Mukhopadhyay 30 Jun '10

30 Jun '10

Dear Chris I downloaded the package and it goes on this way......... -------------------------------------------------------------------------------------------------- psm@libra25:~/Desktop/koha_sw$ sudo dpkg -i libgraphics-magick-perl_1.3.5-6_i386.deb ----------------------------------------------------------------------------------- Selecting previously deselected package libgraphics-magick-perl. (Reading database ... 98452 files and directories currently installed.) Unpacking libgraphics-magick-perl (from libgraphics-magick-perl_1.3.5-6_i386.deb) ... dpkg: dependency problems prevent configuration of libgraphics-magick-perl: �libgraphics-magick-perl depends on libgraphicsmagick3 (>= 1.3.5); however: � Package libgraphicsmagick3 is not installed. �libgraphics-magick-perl depends on libwmf0.2-7 (>= 0.2.8.4); however: � Package libwmf0.2-7 is not installed. dpkg: error processing libgraphics-magick-perl (--install): �dependency problems - leaving unconfigured Processing triggers for man-db ... Errors were encountered while processing: �libgraphics-magick-perl -------------------------------------------------------------------------------------------------------------- psm@libra25:~/Desktop/koha_sw$ sudo apt-get install libwmf0.2-7 --------------------------------------------------------------------------------------------------------- Reading package lists... Done Building dependency tree�� Reading state information... Done Package libwmf0.2-7 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libwmf0.2-7 has no installation candidate -=---------------------------------------------------------------------------------------------------------------------- psm@libra25:~/Desktop/koha_sw$ sudo apt-get install libgraphicsmagick3 --------------------------------------------------------------------------------------------------------------------------- Reading package lists... Done Building dependency tree�� Reading state information... Done Package libgraphicsmagick3 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libgraphicsmagick3 has no installation candidate psm@libra25:~/Desktop/koha_sw$ sudo apt-get install libgraphicsmagick Reading package lists... Done Building dependency tree�� Reading state information... Done E: Couldn't find package libgraphicsmagick psm@libra25:~/Desktop/koha_sw$ sudo apt-get install libgraphicsmagick3 Reading package lists... Done Building dependency tree�� Reading state information... Done Package libgraphicsmagick3 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libgraphicsmagick3 has no installation candidate psm@libra25:~/Desktop/koha_sw$ partha As mentioned the mailing list archive, the proper package name is libgraphics-magick-perl and not libimage-magick-perl. $ sudo apt-cache search libgraphics-magick-perl libgraphics-magick-perl - format-independent image processing - perl interface Kind Regards, Chris Parthasarathi Mukhopadhyay Department of Library and Information Science University of Burdwan, Burdwan, West Bengal, India -- _______________________________________________ Search for products and services at: http://search.mail.com

3 2

Re: [Koha-devel] Graphics::Magick 1.3.5
by Partha Mukhopadhyay 30 Jun '10

30 Jun '10

Dear Mr. Koustubha Thanks for a quick response. Please see the result..... ----------------------------------------------------------------------------------------------------- psm@libra25:~$ sudo apt-get install libimage-magick-perl [sudo] password for psm: Reading package lists... Done Building dependency tree Reading state information... Done Package libimage-magick-perl is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libimage-magick-perl has no installation candidate psm@libra25:~$ ---------------------------------------------------------------------------- ----- Original Message ----- From: "Koustubha Kale" To: "Partha Mukhopadhyay" Cc: koha-devel(a)lists.koha-community.org Subject: Re: [Koha-devel] Graphics::Magick 1.3.5 Date: Wed, 30 Jun 2010 18:20:17 +0530 On Wed, Jun 30, 2010 at 6:13 PM, Partha Mukhopadhyay <psm_vu(a)india.com> wrote: Dear all I have attempted an upgrade from Koha 3.06 to Koha 3.2 Beta (early bird!!! ha ha). Got stuck in the middle. CPAN failed to found Graphics::Magick 1.3.5. The package is available although. Should I try apt-get? Dr. Parthasarathi Mukhopadhyay Please see http://lists.katipo.co.nz/public/koha/2010-March/022977.html Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 Parthasarathi Mukhopadhyay Department of Library and Information Science University of Burdwan, Burdwan, West Bengal, India -- _______________________________________________ Search for products and services at: http://search.mail.com

3 2

Graphics::Magick 1.3.5
by Partha Mukhopadhyay 30 Jun '10

30 Jun '10

Dear all I have attempted an upgrade from Koha 3.06 to Koha 3.2 Beta (early bird!!! ha ha). Got stuck in the middle. CPAN failed to found Graphics::Magick 1.3.5. The package is available although. Should I try apt-get? Dr. Parthasarathi Mukhopadhyay Lecturer (Sr.), Department of Library and Information Science University of Burdwan, Burdwan, West Bengal, India -- _______________________________________________ Search for products and services at: http://search.mail.com

2 1

Koha Newsletter: Call for Articles
by Nicole Engard 28 Jun '10

28 Jun '10

It's that time again! The newsletter will be released on the 15th of next month and that means I need some submissions from users and developers alike! Articles can be as short as 2 sentences - so send along any news/tips/guides/ideas you want to share with the community. Thanks Nicole

1 0

Koha 3.2 beta released
by Galen Charlton 25 Jun '10

25 Jun '10

Hi, I am pleased to announce the release of the beta version of 3.2. The tarball can be downloaded from: http://download.koha-community.org/koha-3.02.00-beta.tar.gz Checksums and signatures to verify the download can be retrieved from: http://download.koha-community.org/koha-3.02.00-beta.tar.gz.sig http://download.koha-community.org/koha-3.02.00-beta.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.00-beta.tar.gz.MD5 Bugfixes since 3.2 alpha2 include: bug 4312 change default for tagsmoderation to 0 from NULL (BUG #4857) aqplan.pl: consideration of Planning categories with authorised values MT3652 : Unifying the search of neworder with Search (BUG #4811) suggestion.pl: display borrowers name in suggestion information filters (Suggested By, Managed by, Accepted by) (BUG #4810) parcel.pl: Fix a bug with applying a filter on pending orders displaying (bug #4523) possibility to show / hide the filters menu Bug 3217 Impossible to change biblio record FW to Default (MT2371) basket.tmpl, in basket details, change Open on => Opened on (BUG #4356) Basket.pl: adding a link to the basketgroup (BUG #4521) aqbudgets.pl - Transform undefined budget spent value to 0.00 value Bug 4905 Runtime errors in about.pl fix two broken calls to _FixPriority bug 3344: display in-transit status on holds priority list bug 4224: explicitly mark hold requests as being handled by item in transit Fix for Bug 4532, Use include file for bibliodefaultview logic Fix for Bug 4821, With multiple 5XX fields, the font display gets progressively smaller Bug 4423, Staff Client XSLT is just a copy of the OPAC one Followup fix for Bug 4453: Removing invalid template fragment. Fix for Bug 4278, canceling vendor add refreshes wrong Fix for Bug 3895 - Menu on left of Contracts is for Admin Pages Fix for Bug 4886, missing 404 redirection on wrong biblionumber for MARC and ISBD details Fix for Bug 4884, opac-showmarc.pl can't find compact.xsl Fix for Bug 4859, Formatting cleanup for merge biblio record interface Fix for Bug 4869 - Non-staff patrons logging into the OPAC don't have option to place holds from Public Lists Bug3916 : Batch Modify tool overwrites branches fields Bug 4474 swap options for sys pref singleBranchMode Bug 4902: Add missing b_phone and b_email to borrower details bug 4900: add in missing value for usedaysmode pref Bug 4897: Invalid XHTML in opac-userupdate.tmpl. fixes to xt/sysprefs.t test case fixed permissions for item batch deletion and modification for French fixed problems in xt/permissions.t test case Bug 4895: Add missing granular permissions Bug 3682: change message_attributes.message_name from varchar(20) to varchar(40) Fix for Bug 4868 - Improve controls for cloning and deleting MARC subfields Page structure correction, helps Bug 3850 (Page Need Design Work) Fixes bug 3619: _send_message_by_email not respecting AutoEmailPrimaryAddress = 'OFF' BUG 4883: Staff - remove \n from strings for translation Bug 4833: OPAC - remove \n from strings for translation Bug 4895: Add missing granular permissions to ru-RU, uk-UA Bug 4895: Add missing granular permissions to de-DE, pl-PL But 4890: Fixes invalid XHTML in basket.tmpl Bug 4889: Fixes minor XHTML error in booksellers.tmpl. Bug 4827: Fixes library drop-down list in aqbudgets.tmpl bug 4896: granular permissions now always on (DB rev 138) MT 1816: Granular permissions for the serials module Bug 4472 - Missing / in img tags breaking xslt (and other img tags) Bug 2789 Fix UNIMAC leader plugin (bug #4853) change rights needed to renew loans Bug #4864 Add SIPServer Perl Module Dependencies MT2938 : Adds a permission for editing items Fix for Bug 3081, Url's contain spaces Fix for Bug 3770, 'Add to list' page only allows adding to private lists Fix for Bug 3722 - Branch deletion results in incorrect message Fix for Bug 3926, inadvertantly resurrected by me. Fix for Bug 3992 - New Sys Prefs Branch - Local Use Tab not Highlighted bug 4205 remove extra 'plan by' option Bug 4844 Remove a circular dependency in koha_perl_deps.pl Fix for Bug 4504, Confirmation messages in opac account not translated bug 4845 change language from reserves to holds German web installer files, including translation of MARC21 frameworks bug 4445: Upping the daily limit for XISBN bug 4445 update OCLC text tips on preferences bug 4834 split joined preferences bug 4027 fix testStatus typo to textStatus (MT #2565) fix aqplan csv export, and turn off debug bug 4508: fix crash when editing patron attributes or message prefs bug 4816: require authentication for placerequest.pl bug 4386: fix email hold filled notifications removed needless imports of the YAML module Bug 4199: Adds ability to print routing slip. Patch 2. Bug 4199: Adds ability to print routing slip from serials-collection. Bug 4805: Fixes multiple subscriptionid's being passed to serials-collection. bug 4377: ensure HOLD_PRINT letter added during installation and upgrade (DBrev 135) bug 4311: respect OPACXSLTResultsDisplay bug 4018: remove duplicate unAPI link when XSLT bib details display on (bug #4487) permit - and . in callnumber plugin Correct position of non-sorted table column Corrected: Fix for Bug 4529, columns on circ history all screwy (BUG #4521) aqbudgets.pl - Transform undefined budget spent value to 0.00 value Bug 4510 Script processes single supplier not an array (bug #4522) fix plugin unimarc 210$c Bug 4517 - add authentication to reorder_members.pl update sample news on new install with koha-community.org urls Fix for Bug 4534, Box for SQL not visible in "Create Report from SQL" moved INSTALL.debian-lenny to INSTALL.debian bug 4464: properly check if a subfield is populated if it is in a textarea Bug 2889: Adds highlighting to serials-collection.tmpl Bug 3910: Removes an erroneous heading from the serials search results. bug 4505: updated release notes Bug 4505 - Bumping the perl version to 5.8.8 or greater bug 4802 - fix swapped files in acq help bug 4802 add missing order search help file bug 4801: fix paging in display of staged bibs and import batches bug 4802 add new acq help files update main page help file fix XHTML error in bib details print page (bug #4519) fix record printing Bug 4525: Invalid XHTML in currency.tmpl. bug 4151: fix migration_tools typo Bug 4516 (Character shift in MARC21 Field 008) Backing down the required version of Graphics::Magick Enhancement Bug 4444: Centralize Code Handling Perl Dependencies bug 4509: remove references to PINESISBN system preference Bug 4507 Don't return null vendor to claims processing Bug 3768 (Bibliographic Framework Test) fix XHTML error in about.tmpl BUG 4499: Javascript error messages not translatable Bug 4141 Reconcile 3.0.x and HEAD database updates for 3.2.0 Correct URL for Baker & Taylor ContentCafe (MT3318) RSS OPAC: Adding CDATA term in title and description tags. Fix for Bug 4485, System preferences page uses non-standard warning style A couple of CSS and markup corrections Bug 4300 Display 866z summary holdings public note in OPAC stocknumber not saved properly MT2582: Fix user deletion without permission wr-70205 Rental discount not being respected Bug 3093 add syspref to turn off multiholds button Bug 3928: Modified date should follow syspref Bug 3928: Modification of date for serials. Display current selected category when editing lists. Fix for Bug 4475, AmazonLocale not used consistently Markup corrections for validity and to eliminate horizontal scrollbar Fix for Bug 4400, BIBTEX export from OPAC results in empty file Bug 4470 Patron search result pagination bar Do not declare variables within (bogus) conditionals Reserve and onloan were reporting the same cardnumber, due to a little bug in detail.pl fixed by this patch Fix for Bug 3666, Overriding renewal limit means negative count in OPAC Bug 3671 Workaround for font display problem bug 4403: look in appropriate theme/lang for bib display XSL quell 'non-initialized variable defaulttab' warning fix malformed call of XSLTParse4Display Further corrections for Bug 4244, Use "checkouts" instead of "issues" Style changes to cart popup window more compact display: - compact holdings list - adds list bullet image from the staff client (MT #2966) fix opac-user.pl function problem Bug 4465 Fixes translated boolean syspref inversion exclude TinyMCE from non-UTF8 file checks move misc source file test and fix scripts to xt/ Further fixes for Bug 4208, Many submit buttons are not translatable in 3.2 fixed Syndetics breakage Fixes bug 4448: &'s in itemcallnumber Fix for Bug 4416, renew all and return all buttons too close together Fix for Bug 4453, Improve formatting of batch item operations Fix for Bug 2375, Serials holdings data does not display in opac-detail Fixes bug 4452: CircControl syspref listed as ItemHomeBranch rather than ItemHomeLibrayr Changes to kohastructure.sql to add some missing drop if exists + change in install.pl mysql show tables Web Installer -> Step 3 --> ERROR 1050 (42S01) at line 301: Table 'branch_item_rules' already exists fix template translation issues Fixed Patron Search Results Use CSS3 box-shadow property for Cart tooltip In addition, various improvements to the Debian packaging were made. At this point, I am declaring a string freeze with the following exceptions: * forward ports from 3.0.x (for which translated strings can presumably be grabbed from the 3.0.x translations) * remaining 3.2 release blockers. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 0

BibLibre strategy for Koha 3.4 and next versions
by Paul Poulain 23 Jun '10

23 Jun '10

Hi, In this mail, I want to share with you our situation, our problems, and our ideas. You'll be probably surprised by this mail. Please consider it's a good news. It's not a threat - not my cup of tea (frenchism suspected) - . But I think things must be done this way, so I share it with you, and I'm impatiently waiting for koha-community reaction & thoughts. BibLibre situation =========== We are very successful. Koha is really a success in France. One french university is now live, we are on the way to migrate a very large public library (500k items), 3 other universities should go live in September, and a lot of business coming. We are 11, are on our way to hire 3 new ppl, have on board Philippe Chabanon, that is very experienced in managing a company, is fully enthusiastic about free softwares and community, and knows a lot of people in the french library world. Is everything perfect ? nope. Our problems ========= Organizational problem ------------ Some of our clients sponsor new developments. Those are done under "marché public" rules, that usually define a very strict date (if we fail, then we have to pay fines, based on how many days late we are !). That's why we started 3 different branches for our 3 different major sponsored works (Aix-Marseille, Nîmes, Lyon 3, you can see everything on git.biblibre.com) Everything that was in Aix-Marseille branch is now in koha 3.2 . But we have a lot of things done for Lyon 3 (that is live already) and Nimes (that will go live in early july) that are not in koha 3.2 Our main short-term problem is that koha 3.2 is very (very) late. It has been announced one year ago ! We did a lot of testing for Lyon 3 before putting them live. Some of them resulted in some bugfixes that could/should have been submitted to koha mainstream. But, we couldn't. Thus we face a situation where someone fixes in official 3.2 some things we already fixed in our Lyon3 branch (shame on us, but really, we couldn't find time. Delivery to Lyon3 was on time, but is was shorter than short) The situation is the same with Nimes : they will probably be live (with 3.2 + Lyon3 + Nimes sponsored stuff) before 3.2 is released -going live planned for july 1st, Galen, we challenge you ;-) -. So, frankly, dealing with our contracts and the official version of Koha has been a pain, and has resulted in a "virtual fork" for Lyon3 (and in 1 month for Nimes). We strongly want to submit our code to the main trunk, but dealing with a so-long-delayed version is really a nightmare (and I understand PTFS deploying "Harley" -even if i share community opinion about the version being advertised when released in a way it can be understood as an official version-). We must find a solution to this situation, or the "virtual fork" will result in a "real fork" that we strongly want to avoid ! As of today, we have something like 400 patches to integrate into koha main trunk ! Technical problem ----------- With some customers having more than 1 million items (Aix-Marseille : 1247686), and with more and more customers, we reach some limits with the structure of Koha, in term of performances and stability/maintainability. Chris suggested some improvements with koha 3.4, and we have some complementary ideas, I want to share with you, and would like to implement ASAP. Ideas/proposal ======= Technical : Koha architecture --------------------------------- At the begining of may 2010, we staff had a meeting at Marseille to know if it would be possible to make koha easier to maintain and evolve, we are now doing some experiment to split koha into several layers that provides completely independant set of tasks based on the MVC architecture (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) Koha can be seen as a stack with communication between the closest layers. 4 layers at all (does it make you remember TCP/IP? ;) ) VIEW: interactions with different clients ( browser, REST, XMPP, Z3950, ... ) ?? CONTROLLER: Controls the model by transmitting the CRUD tasks requested by the VIEW ?? MODEL: Business objects, as close as possible to the real world ?? PERSISTENCE: Make the Business objects persistent Plus, we expect to use external tools as often as possible to take experience of other communities and reduce the amount of code we have to debug by ourselves. We think tools exists for every layers, actually we just have to choose between them: View: ------- HTML::Template, Template Toolkit 2, Template::Declare, SOAP::Lite, any REST, XMPP, Z3950, SRU/SRW wrapper, ... (Infobot ;)) Controller: ---------- Dancer, Mojo, The Controller parts of existing MVC frameworks ( Jifty, Catalyst, ...), ... Model: ------- Any OO Framework ( prefer those which comes with persistence extension as MooseX::Storage, KiokuDB, ... choose one ) Persistence: ----------- DBIx::Class, Document DB clients, SQL::Abstract, Jifty::DBI, .... Ideally, the communication between each layers must be specified, provable by unit testing, and well documented ( pods in the t/* ?). Today, Koha works in CGI mode, so there is no persistence at all. And having no persistence means we can't implement the MVC model -some tests we did with OO frameworks show very poor performances-, and won't be able to improve performance heavily -the main loss of perf in koha as of today is loading datas that are almost static & should be available immediatly : systempreferences & all the admin tables -. So: 1st step => remove CGI, to have persistent code, enabling persistent DB connection. We did some tests with Dancer, that are very encouraring, we will send a mail about that soon. 2nd step => Once we will be OK with dancer to get rid of CGI => head to persistence & OO framework. We vote for Moose & KiokuDB, but we still have POC to write to confirm the idea. 3rd step =>view part, by moving to T::T (POC still to do to confirm the idea) It may look like a koha rewrite but it's not: every parts would be added step by step into koha by wrapping the new design behind the old API during a transition phase. An example of current code sub GetBranchesInCategory($) { my ($categorycode) = @_; my @branches; my $dbh = C4::Context->dbh(); my $sth = $dbh->prepare( "SELECT b.branchcode FROM branchrelations r, branches b where r.branchcode=b.branchcode and r.categorycode=?" ); $sth->execute($categorycode); while ( my $branch = $sth->fetchrow ) { push @branches, $branch; } $sth->finish(); return ( \@branches ); } would became transition code: sub GetBranchesInCategory($) { my $id = shift or return; # - Category would be the Business object with a member transition (which can be # deprecated at the end of transition) that encapsulate every # persistance specific data used in the C4::* api # - the find method could be delegated to the DBIx::Class find that returns the # record associated to the id # returns if ( my $category = Category->transition->find($id) ) { # codes to deal with branches comes de facto with tools as DBIx::Class # it returns the list of branches for the category $category->branches; } else { undef } } You can find in attachement a small graph with all our ideas, and the beginning of a timeline. ppl reading carefully will see a "changing indexing system (solr)". 4 years after starting with it, we still find zebra being a nightmare, with a lot of problems for unicode (with ICU). We did some tests with solr, and they are very encouraging. We will provide the results soon too. But i'm really enthusiast about what we did in a few hours ! Organizational : Koha team ------------------------------- Koha team organisation ............... If we (BibLibre & the Koha community) want to be able to implement such a roadmap (that also includes some new functionnality, as customers sponsors some...), we must have a heavily organised team. I think we must : * manage release by date (not by features). This is probably the more important part for us (see our "marché public" problem). The timing of the versions would be defined by the companies contributing the most and synched with sponsored devs roadmap. That will be tricky to organize when there are more than one company involved, but, for instance, BibLibre is the largest contributor ( PTFS: you're welcomed to enter the thread ! ). In fact, "a koha 3.4" could be released in a few weeks (look at out master branch, it contains 3.2 + Lyon3 + Nimes sponsored work). A "koha 3.6" could be released in december/february,... a regular release, that's something that is probably "non-negociable" for us. * define very clear coding guidelines & be very stricts on their use : everything that does not respect the guidelines must be politely but firmly rejected. * have a very efficient patch workflow : a patch can't be in the wild for weeks. The submitter must have an answer in a very short timeline (is 48H possible ?). ie : We can't rely on only one person to push patches. We must have back-ups for major roles like RM & "patch pusher". * we could divide Koha in functionnal (serials / acquisition / cataloguing / ...) or technical (perfs / SQL structure / view layer / indexing engine / ...) parts, with some working group for each of them, and something like a monthly report of the WG (with a weekly internal meeting) * write tests ! technical tests (.t) and functional tests (selenium ?) Our involvement (BibLibre) : .................... We want to improve our involvement in Koha, by dedicating Henri-Damien to work at 75% for Koha and be the link between the work done internally by BibLibre, and the work done by everyone else. This mean : * publish our RFPs as soon as possible * gather all the work done every month and communicate about that on the wiki and blog and translate on koha-fr.org * manage patches coming out from BibLibre, and coming out from everyone else (to deal as soon as possible with any problem) I know we have elected a team recently, and I know chris will do an awesome job as RM (I don't know for others, I didn't saw them in their responsability yet. For chris, i'm the team for 8 years, I know who he is ;-) ), but I think hdl should have a responsability more important than "bug wrangler" to reflect the time he (will) dedicate to the project. Is something like "co-RM" possible ? any other idea ? Any other idea ? Next step ----------- We are *really* willing to implement this roadmap and way of doing things. The goal of this mail is to ask everybody involved in Koha development about their opinion: we want our proposal to be a chance for Koha (new deal ?). On the technical side, stay tuned. Some POC will fall in the next weeks !!! On the organizational side, the ball is on your side: let's go to update/improve our organization ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

11 26

New preferences editor
by Marcel de Rooy 17 Jun '10

17 Jun '10

Hi all, I was just testing a small patch for 3.2 with a new preference not listed in the pref templates. Although the pref exists, you cannot find it or add it. (The manual does not yet explain how to add preferences too, or I could not find it.) I think it should be interesting to include (possibly older) local preferences that are not yet in the templates on a separate tab or so. The same holds for searching the prefs; the new version does not find preferences that are not listed in the pref files, but are in the database and can be used via C4::Context. This is somewhat confusing (to me)? Would it be better to allow finding them at least? Any thoughts? Regards, Marcel

6 8