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

Commentary on Paul's Koha 3.8 Release Manager proposal
by Ian Walls 05 Oct '11

05 Oct '11

Everyone, Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release Manager. The details of his document can be found here: http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38 I thoroughly agree that the time has come to start thinking beyond the next stable release, and on to Koha 4.0. Those of you who have seen either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very excited about the possibilities of where we can take Koha in it's next major iteration. However, I disagree with a couple of the details of Paul's proposal. The major disagreement is with the timeline. The proposal as it stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012. I feel that going from Koha 3.8 directly to 4.0 is unwarranted. To my mind, there are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth. This is supported by the actual database version numbers in Koha: the current release is actually 3.04.04; the zeros are squashed out for convenience. I would counter that, while we should continue releasing new features every 6 months on the 3.X line, Koha 4.0 should be defined by it's features. Paul's proposal calls several features to be key, including Solr integration, database abstraction, updated online help, improved authentication stack and automated tests. I agree that all these things are important and should be worked towards, but I'm not convinced they should be the sum total of the changes that define Koha 4.0 I would like to see the following in Koha 4.0: - arbitrary metadata formats (beyond MARC) - arbitrary biblio relationships - full support for authority records, including uploading through the GUI, automatic linking, "explode" searching and more - improvements to the borrower data structure (fewer pre-defined data fields, more flexibility) - separation of "receiving" and "payment" in acquisitions - serials import and export (MFHD, prediction patterns, etc) - many, many more things I think that the community should meet and discuss what features are both desirable and reasonably likely to be completed in the next few years (is there interest by libraries to sponsor these developments, or from developers to code it "for fun"?). Once a feature set is agreed on to "define" Koha 4.0, the developers of these features would meet to hash out what underlying structural changes would be required to make them happen. Hopefully commonalities could be found, so that the underlying structure could be developed in a way that accommodates multiple developments at once. Identifying these prerequisite changes early on would reduce the difficulties of rebasing developments, since we'd all be working off a similar set of base assumptions. It would also provide a reasonable basis for excluding or delaying developments that don't fit into the overall plan. Once the features were chosen and a framework for their development agreed upon, it would be time to code. The development and submission process would be the same as it is now (basing patches off master and submitting to the patches listserv and Bugzilla). As new features become ready, they would be incorporated into the time-based 3.X releases by the release manager for that particular cycle. This way, what works is made available, and what needs more time continues to be tested until it's stable for production use. Once all the agreed upon features were ready, it would be time to release Koha 4.0. Hopefully, that would be with 1-2 years, but there would be flexibility here. One of my other issues with the proposal was the "lightening" of Quality Assurance standards for the first 3 months of the 3.8 release cycle. If operating under the 1 year time frame for Koha 4.0 as outlined in Paul's proposal, this would seem necessary in order to get everything included in time. Unfortunately, while the next 3 months would be dedicated to clean up of features rolled in, there is never any guarantee of bug fixes being generated in a timely fashion. You cannot force people to write or sign off on bug fixes; we're all free agents here. So code that has not been rigourously tested could get in and stay in for a long time, long after 4.0 would release, because no one knows how to test it or fix it. However, if we operate under my proposed model, all code could continue to operate under the same quality assurance standards, and nothing that is broken or otherwise incomplete would make it in until it was ready. Releases would still come out every 6 months, even if a major development was inoperable, until that development could be completed. This has been a long email, so let me sum up. I think: - we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month cycles using the current community practices for feature inclusion - we should, as a community, meet and decide what features we want to define Koha 4.0 - the developers of those features should get together and come up with a unified plan for accomplishing them all, in a way that requires minimal rebasing - as new features become stable and tested, they should be folded into the 3.X line until all the features defined as "Koha 4.0" are ready - Once all the agreed upon features are complete, Koha 4.0 is then released. I've already gotten some feedback on this in today's Koha IRC meeting, but I'd very much like to hear what the rest of the community thinks about this, particular in relation to Paul's proposal for 3.8 Release Manager. Our time is limited for discussion, as the election time draws near, but hopefully I've made my thoughts clear enough for a dialogue to get started. Please let me know if I've been at all unclear. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

3 6

Koha 3.4.5 -- does it fix the "detect duplicates" when importing records?
by Hartman, David W. - GBTS Library 04 Oct '11

04 Oct '11

Does anyone know if this upgrade 3.4.5 will fix the "detect duplicates" feature when importing records? When I import records, Koha cannot identify the duplicate records (even though the ISBNs are identical). I have reported the problem to the bug fixers but was wondering if the upgrade fixes it. -----Original Message----- From: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Chris Nighswonger Sent: Tuesday, September 27, 2011 7:44 AM To: koha(a)lists.katipo.co.nz; koha-devel(a)lists.koha-community.org; koha-translate(a)lists.koha-community.org Subject: [Koha-devel] Koha 3.4.5 is now available It is with pleasure that I announce the release of Koha 3.4.5. The package can be retrieved from: http://download.koha-community.org/koha-3.04.05.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.05.tar.gz.MD5 http://download.koha-community.org/koha-3.04.05.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.05.tar.gz.sig Release notes for 3.4.5 are below. Come and get it! RELEASE NOTES FOR KOHA 3.4.5 - 26 September 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.4.5 can be downloaded from: http://download.koha-community.org/koha-3.04.05.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.4.5 is a bugfix/maintenance release. Highlights of 3.4.5 ====================== 4122 blocker WebBasedSelfCheck doesn't control anything 6704 critical merging records cuts off fields at quotation marks 6727 critical can't import frameworks 6750 critical Guarantor search broken on translated templates 4419 major Cannot change module for notice templates 4966 major no way to finish receiving 6318 major fields missing when editing a layout 6351 major Cannot delete library-specific circulation rules 6620 major Sip Server Output may be buffered 6651 major koha-upgrade-to-3.4 fails when multiple instances are present 6665 major advancedMARCeditor preference not functioning 6765 major Enable correct checksums for UTF-8 encoded data 6834 major $template->{param_map} is deprecated with the introduction of Template::Toolkit 6841 major A member with cataloging permissions cannot change branches (when independent branches is set on) Bugs fixed in 3.4.5 ====================== 520 Displaying ALL records 1016 Crashed mySql tables 1220 validation problems and usability in lynx 1664 Installer not picking up missing perl modules 2539 kohaspsuggest is deprecated, notes outmoded 2775 Test suite failing after change to cache sysprefs 2891 Cannot manually enter dates in some report forms 4866 Optionally enable Change event for item plugins 4868 Improve controls for cloning and deleting MARC subfields 4877 Create and update the manual pages for the koha-* scripts. 5028 Remove references to catmaintain.pl 5252 Emails & Phones On Patron Add/Edit form 5498 Standardize markup and style of pagination menus 5524 Can't delete list from second page of results 5602 Improve configurability of package building scripts 5866 At larger hold volume, waitingreserves.pl for all libraries times out, can cause generalized slowness 6121 waitingreserves: branchname instead of branch code 6129 ISSN url param for serialssolutions.com 6256 Many bib1 attributes missing 6275 Automated backups of data and config 6368 unimarc_field_4XX plugin does not work with new templates 6431 New Circulation modules for Hourly Circulation 6458 incorrect parsing result in translation processing 6479 Encoding problem in "recievedlist" when the numbering formula contains utf-8 characters 6516 koha-create makes assumptions about borrowernumber of staff user 6517 koha-create wants "use database" in DEFAULTSQL 6528 Cataloging search issues - Holdings not displayed in location column 6538 help on letter.pl is incorrect 6540 Add more options to koha-create 6555 only 10 lists in pull down when adding from a bib record 6562 Reserve request generates unnecessary runtime errors 6595 Add German translation for purchase suggestion mails 6602 Reports dictionary doesn't properly recognize text columns 6640 Template errors in defining default variable values causes information not to be displayed 6652 Zip showing in funny place on libraries admin 6656 Default sort preferences ignored on advanced search 6662 sort options in opac are dewey specific 6677 patron stats still refers to debarred 6695 Layout of patron category add/edit form slightly broken 6696 New category button broken when no categories defined 6712 Remove memberofinstitution markup from templates until it can be completed 6715 xmlControlField.js always fetches the value_builder xml files in the "en" directory. 6723 allow framework import with CRLF 6724 Holds Ratio does not allow decimals 6726 When SMS is enabled the messaging table is misaligned 6728 Table sorter for receiving acquisitions 6732 Missing Title for Manual Invoice 6733 printing routing list sends you to main serials page 6744 Acknowledge the actual es-ES translators 6747 Additional check in opac-export 6753 Markup corrections and improvements for label export window 6754 Improve breadcrumbs on lists pages 6768 Two unused include files can be removed: error-top.inc and error-bottom.inc 6791 editing list with apostrophe loses text 6794 Broken toggle in member-flags in ie 6822 RIS export problem in opac-export.pl with parsing the MARC 6829 Remove two warnings for opac-MARCdetail 6860 syndetics covers not showing on search results or shelf browse 6863 covers missing from shelf browse for various services System requirements ====================== Changes since 3.2: * Template::Toolkit Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the english version of the Koha manual is available: http://koha-community.org/documentation/3-4-manual/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.4 is Release Manager: Chris Cormack <chrisc(a)catalyst.net.nz> Documentation Manager: Nicole C Engard <nengard(a)gmail.com> Translation Manager: FrÃ©dÃ©ric Demians <frederic(a)tamil.fr> Release Maintainer (3.2.x): Chris Nighswonger <cnighswonger(a)foundations.edu> Release Maintainer (3.4.x): Chris Nighswonger <cnighswonger(a)foundations.edu> QA Manager: Colin Campbell Credits ====================== We thank the following individuals who contributed patches to Koha 3.4.5 Tomas Cohen Arazi Alex Arnaud Steven Callender Colin Campbell FrÃ©dÃ©rick Capovilla Chris Cormack Christophe Croullebois FrÃ©dÃ©ric Demians Nicole C. Engard Magnus Enger Katrin Fischer Srdjan Jankovic Janusz Kaczmarek Ulrich Kleiber Henri-Damien LAURENT Owen Leonard Chris Nighswonger Maxime Pelletier Paul Poulain Liz Rea Marcel de Rooy Salvador Zaragoza Rubio Robin Sheat Ian Walls Ward van Wanrooij Brett Wilkins We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches(a)lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix releases) is 3.4.x. The next major feature release of Koha will be Koha 3.6.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

3 3

Re: [Koha-devel] tt style point
by Mason James 02 Oct '11

02 Oct '11

reply inline On 2011-09-20, at 8:17 PM, LAURENT Henri-Damien wrote: > Le 20/09/2011 04:33, Mason James a écrit : >> >> 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... >> > it is always the same question : who will decide we can decide now the koha-devel mailing-list, or as a topic for the next Koha IRC meeting > and who will process > the files ? not sure on that bit yet :p , lets agree on a Perl style standard first, then decide who/how/when later >> 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 :) > When ? some things has already been committed. And things donot get > improved. when should we agree on a formatting style,? how about now... >> >> >> 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 > I am not. > git blame may be useful, but code readability is a much serious issue. > I think that some decision should be not only discussed but also taken, > announced and applied. ah, ok that would be the next thing to discuss, after we all voted on a Perl formatting style :) >> >> 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 > How can you enforce PBP or any formatting on part of a file ? its easy using vim!, and surely possible for all other respectable editors > If previous file indentation is broken, you will just add broken things. nope, perltidy corrects the indentation perfectly, without any syntax errors > If there is some magic I don't know please tell me. yes, there is some magic :) i added this to my .vimrc file, now F4 tidys a selected block of text :) fyi: i use this method many times a day ---------------------------------------- map <F4> <Esc>:%! perltidy<CR> ---------------------------------------- described here... http://www.modernperlbooks.com/mt/2009/10/from-novice-to-adept-cleaning-up-… i very rarely run perltidy on a whole Koha file, instead i run it *carefully* on small blocks of messy historical Koha code as i see them >> 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! >> > I don't know what ranty mean. "To speak agressivly about somthing. or to take your own tangent about a subject and talk for a long time in a passionate manner" :) http://www.urbandictionary.com/define.php?term=rant > But don't be mistaken, all I want is a change for better. The fact is > that ppl are working on the same code ignoring what other ppl are doing. > And with the need to revamp more and more things for security, > sustainability and performance issues. I think that it should be shared, > discussed, stated, worked in groups and done. yes... but thats a separate issue to what Perl formatting style to use for Koha so remember, there's a few who/when/how issues to discuss here... but can we at least agree on a Perl formatting style, for a start -PBP++ ;) cheers, Mason

3 3