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

Mysql error
by Scott Kushner 11 Apr '13

11 Apr '13

Hello, Has anyone else seen this error? Apparently, my SIP server fails from time to time and has to be restarted. I have no idea why. Any help is greatly appreciated. Thanks, Scott Kushner Middletown Library DBD::mysql::st execute failed: MySQL server has gone away at /home/koha/kohaclone/C4/Letters.pm line 540. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /home/koha/kohaclone/C4/Letters.pm line 542. DBD::mysql::st execute failed: MySQL server has gone away at /home/koha/kohaclone/C4/Letters.pm line 540. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /home/koha/kohaclone/C4/Letters.pm line 542. DBD::mysql::st execute failed: MySQL server has gone away at /home/koha/kohaclone/C4/Letters.pm line 540. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /home/koha/kohaclone/C4/Letters.pm line 542.

2 1

Proposal to be RM for 3.14
by Galen Charlton 10 Apr '13

10 Apr '13

Hi, I propose to serve as Release Manager for Koha 3.14.0. My primary goals, if elected, are: 1. Continuing our tradition of solid, well-tested releases. 2. Experimenting with the structure of the release team to spread the work and knowledge around. 3. Dealing with and finalizing long-outstanding patches and feature requests 4. Broadening Koha's appeal and making it ready for a post-MARC world. I have the support of my employer to commit significant time to this role. Organization of the release team ----------------------------------------------- The Koha Release Manager has traditionally been the sole individual (at any given point in time) authorized to push patches to the master branch. This has given us some advantages: it allows for a unity of architectural vision, it gives us an additional level of patch review after the sign-off and QA process, and empowers to RM to push back on patches that are not quite ready for prime time. I also think that giving the RM a personal stake in the success and quality of a particular release provides good motivation. However, the unitary RM model also has some disadvantages. Having only one RM can contribute to a backlog of patches. It puts a lot of work and responsibility on one person, leading to the distinct possibility of RM burnout. And given the breadth of Koha's functionality, it's increasingly unlikely that any one individual can be equipped to personally test in depth each and every patch. To lay the groundwork for spreading the release work around, I intend to try the following experiments during my tenure as RM: 1. Naming module maintainers. By module maintainer, I mean somebody who is an expert in an area of functionality (e.g., reports) and who agrees to actively maintain a Git tree of vetted patches related to that module. If a module maintainer does a good job, it opens up the possibility of the RM being able to pull it a group of branches from the maintainer's tree in one fell swoop, confident that the module maintainer has thoroughly tested it. Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master. 2. Naming master branch committers. These would be folks who share in the day-to-day work of reviewing QAed patches and pushing them to master. Committers would be expected to use their best judgment when applying patches, but also to follow guidelines discussed by the current RM and the Koha development community as whole. In time, this model might evolve to one where the release manager is just a named "first among equals" among the master branch committers whose primary responsibility is to be a final decision-maker in the case of dispute. These experiments may or may not work, but with any luck during 3.14 we will succeed in laying some groundwork for the release management load to be shared. If any folks are interested in becoming a module maintainer, please let me know. Major architectural and feature goals ----------------------------------------------------- My primary goal for 3.14 will be to significantly reduce the backlog of patches that has accumulated over the past few years. However, I also have some specific architectural goals: 1. Improve sharing of code with other projects. In particular, I'd like fold Koha's custom fork of SIPServer back into the standalone SIPServer project, and work with packages to have SIPServer become available as a stand-alone package. Another project I'd like to at least start is folding in the MFHD-handling code from Evergreen and spinning that out of as an indepdent Perl module. 2. Building on the Solr and Zebra DOM work and efforts to rewrite the search-subsystem, with the goal of having true pluggable search backend support in 3.14.0. 3. Adding support for non-MARC metadata. Communication ---------------------- I will continue to practice of a writing a monthly RM newsletter to be sent out via email to the mailing lists. I will also do a (roughly) weekly RM summary blog. To help encourage the spread of knowledge about the mechanics of performing the RM and RMaint roles, I also intend to do targeted blog posts and/or videos going into some depth. Examples of topics I might present include: * How to resolve a merge conflict. * Techniques for managing large topic branches. * A video showing the mechanics of cutting a release tarball. Timeline ------------ I propose the following general timeline: * 23 May 2013: we start (blearily) the push to 3.14.0 * 30 August 2013: release of pre-pre-alpha 3.14 - after this point, major architectural changes will be discouraged * 25 September 2013: feature slush * 3 October 2013: feature freeze * 31 October 2013: string freeze * 21 November 2013: release of 3.14.0 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

4 4

Call for news for the April newsletter
by Daniel Grobani 09 Apr '13

09 Apr '13

Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 18th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

2 1

Old bugs to check
by MJ Ray 08 Apr '13

08 Apr '13

Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Please leave your reply on the bug web page - I might not see replies to this mail. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5969 Add News Item displays all installed languages http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2069 Label Example Image http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5925 Authorities search in opac : Facets broken http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6041 Errors from _koha_modify_item are ignored in ModItem (C4/Items) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4013 road type missing on search results http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4115 print a batch of patron cards from an import http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2964 warning running commit_biblios_file.pl http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4363 Support the patron internet resources field in Sip2 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3298 Independent item "Status Check" functionality needed http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3673 Pazpar2 integration http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4800 Disable book cover image in the title view if the feature is on in the OPAC. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4373 Placing and Processing Items Simultaneously causes multiple issues http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5779 can't add funds to budget that has past http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4269 Module DBD::SQLite2 requirement will cause problems http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4249 can't place hold if one item not avail for hold http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5324 "bring out the dead!" in C4 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2533 Send OPAC user record change requests to branch email address http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5732 Adding permissions on viewlog http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3367 Overdue Rules not processed for patrons with checkouts more than 90 days overdue. -- Email robot driven by MJ Ray (slef), member of www.software.coop, http://koha-community.org supporter, web and library systems developer. Available for hire (including development) at http://www.software.coop/

1 0

Re: [Koha-devel] Koha.next: Consolidate OPAC themes?
by Quoc Uy 08 Apr '13

08 Apr '13

I agree with you that, each template should fit with the same html, css code, which is added by user in, for example, opacheader, opaccredit... i think we need more works to focus on this. i would love to learn how to write a patch and take a part in this. In relation with template, do you think about creating template for branches libraries? So earch branch library can create and manage their, for example, opac. Best regards! Nguyen Quoc Uy

1 0

Re: [Koha-devel] Koha numbering
by David Cook 08 Apr '13

08 Apr '13

I agree with Marcel and Owen. I don't think it's a good idea to jump from version 3.x to 14.x, and I think version numbering is an important discussion topic, since it affects how Koha is perceived by current and future users. Having worked in libraries for the past 6-7 years as library staff and not a developer, I can state with a high level of confidence that consistency almost always matters more in libraries than software conventions; it is logically consistent that version 3 be followed by 4. Like Owen said, if that varies, there are going to be questions. While we might debate the merits of different version numbering systems, I don't think we're going to be the ones answering these questions in most cases. They're going to be aimed at trainers, salespeople, and technical staff who might not be developers. With the exception of Nicole, the majority of these people might throw up their hands and say, "I have no idea why it went from 3 to 14. It's weird." In many cases, no questions might be asked. In either case, people might just make negative judgements about the reliability, predictability, and transparency of Koha, especially if the "reason" for changing version numbering systems isn't made explicitly and readily available. Personally, I think it would make Koha look bad. The more often a Koha front-person says "I don't know" or "that's weird", the worse that person looks and the worse Koha looks. I think the growing consensus of software users, interface designers, and sellers is "don't make me think". It should be intuitive. That said, maybe I'm projecting a bit of my own biases. Maybe there would be some confused conversation about why Koha went from 3 to 14, but after the majority started using 14 and upgrading from there, it might not be an issue, because that idea of consistency would be regained. As for whether or not users and libraries even look at version numbers...I imagine that the vast majority of people interacting directly with Koha never notice them. They don't appear in the OPAC and in the staff client it's tucked away in the system preferences and About page. The ones caring are likely to be the ones who manage Koha in-house or the people who liaise with support companies. In these cases, maybe it would be easy enough to say, "Oh, the community just decided to change how it numbered each version", but I think this discussion will quickly be lost to time and the average Koha user/developer will have no idea why it changed and as Owen said...I imagine people might wonder if/what they're missing by going from 3.x to 14.x. For me, I think the most logical end to this discussion is to decide on a goal/trigger to switch to 4.x, and to just continue 3.x until that goal/trigger is reached. David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook(a)prosentient.com.au -----Original Message----- Message: 1 Date: Sun, 7 Apr 2013 12:10:30 +0000 From: Marcel de Rooy <M.de.Rooy(a)rijksmuseum.nl> To: "koha-devel(a)lists.koha-community.org" <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310E20641A(a)S-MAIL-1B.rijksmuseum.intra> Content-Type: text/plain; charset="us-ascii" Cool discussion :) Here is my thought: If there is no big reason to jump to the next higher number (in this case 3->4) in some period, do it at least every so-much years. That is reason enough.. But please do not jump from 3 to 14 ! Marcel ------------------------------ Message: 2 Date: Sun, 7 Apr 2013 08:45:25 -0400 From: Owen Leonard <oleonard(a)myacpl.org> To: "koha-devel(a)lists.koha-community.org" <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <CAO4qe2O9eCbyG8RhMaku7ZiKCJVq7u3qijCKO4_N7oU7=aQwfg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I think this is a worthwhile discussion to have, and I'm actually in no hurry (yet) to cut it off. I think there are still aspects which need to be considered. Version numbering is important to different groups for different reasons. For developers, we need version numbering to keep track of where we are in the release cycle and to help us make judgements about how to manage and maintain previous releases. For users the version number gives them an indication about how important it is to upgrade. > But please do not jump from 3 to 14 ! When considering users, I think this is an important consideration. Jumping from 3 to 14 would be really confusing to users, and create expectations about what that version number means. Did we jump 11 version numbers because 3.14 is 11 version numbers better than 3.12? Did we jump 11 version numbers because a pseudo-Koha project has practiced version number inflation? No matter how well we communicate our reasons for switching numbering systems these questions are going to come up. Are we okay with that? I agree with those who worry that incrementing full version numbers like we did point releases before is going to make it more difficult for users to know how important it is to upgrade. As developers we know how much work goes into making 3.10 into 3.12, but users have to weigh a lot of factors when deciding whether and when to upgrade. Self-supporting libraries in particular may not have the resources to upgrade for every version. Will a new numbering scheme make this more difficult for them? All that said, I think it is problematic that we don't have a plan, under the current numbering scheme, to move from 3.x to 4.x. Just to muddy the waters more: What if we came up with a goal (or goals) to set to trigger the flip from 3 to 4, and then implemented the new version scheme from there? That would give the users the satisfaction of seeing a version jump, and give us some lead time to "sell" the new numbering scheme. With apologies to those who want this to be over, -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

4 3

Koha numbering
by Paul Poulain 08 Apr '13

08 Apr '13

Hello koha-devel, Throwing the question : after version 3.10, we're about to release 3.12, the next version is expected to be 3.14 My question is a small one : what does the "3." mean for us ? The 3.12 is really different from 3.0, that has been released 5 years ago. Remembering history, we switched from 1.x to 2.x when MARC support was added. We switched from 2.x to 3.x when zebra became our search engine. What could/should we expect to decide to switch to 4.x ? Another option I see could be to remove the "3." and name version 12.0, 12.1, 12.2, 14.0, 14.1,... (that would be fine for the current updatedatabase mechanism) Thoughts ? -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

20 32

Re: [Koha-devel] Koha numbering
by Paul 08 Apr '13

08 Apr '13

At 04:07 PM 4/7/2013 -0400, Jared Camins-Esakov wrote: >But please do not jump from 3 to 14 ! > > >Good point. I added the following proposal to the agenda for the next IRC >meeting: When does the vote take place, and how does one join in? I've no experience whatsoever with "IRC", what's needed for software (if anything?) Or is there another way to vote? Thanks - Paul >* Vote on (NOT DISCUSS) the proposal to increment the major version for >every feature release starting after version 3.14, which is due to be >released on November 22, 2013 or so. This means that the version released >on or about May 22, 2014 will be called Koha 4.0.0. (added by jcamins, but >to be presented by someone who cares) > >If there is consensus that the vote should be on a different versioning >scheme, that is absolutely fine with me, please change it on the agenda. I >merely wrote the compromise position that I had the impression that people >were leaning towards. As I state on the item, I will not be presenting the >motion, but action beats talk ten times out of ten, so I took the step of >adding it to the agenda so that it can be voted on. > >Regards, >Jared > >-- >Jared Camins-Esakov >Bibliographer, C & P Bibliography Services, LLC >(phone) +1 (917) 727-3445 >(e-mail) <mailto:jcamins@cpbibliography.com>jcamins(a)cpbibliography.com >(web) <http://www.cpbibliography.com/>http://www.cpbibliography.com/ >_______________________________________________ >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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 1

Re: [Koha-devel] Koha numbering
by Archives and Collections Society 08 Apr '13

08 Apr '13

At 04:07 PM 4/7/2013 -0400, Jared Camins-Esakov wrote: >But please do not jump from 3 to 14 ! > > >Good point. I added the following proposal to the agenda for the next IRC >meeting: When does the vote take place, and how does one join in? I've no experience whatsoever with "IRC", what's needed for software (if anything?) Or is there another way to vote? Thanks - Paul >* Vote on (NOT DISCUSS) the proposal to increment the major version for >every feature release starting after version 3.14, which is due to be >released on November 22, 2013 or so. This means that the version released >on or about May 22, 2014 will be called Koha 4.0.0. (added by jcamins, but >to be presented by someone who cares) > >If there is consensus that the vote should be on a different versioning >scheme, that is absolutely fine with me, please change it on the agenda. I >merely wrote the compromise position that I had the impression that people >were leaning towards. As I state on the item, I will not be presenting the >motion, but action beats talk ten times out of ten, so I took the step of >adding it to the agenda so that it can be voted on. > >Regards, >Jared > >-- >Jared Camins-Esakov >Bibliographer, C & P Bibliography Services, LLC >(phone) +1 (917) 727-3445 >(e-mail) <mailto:jcamins@cpbibliography.com>jcamins(a)cpbibliography.com >(web) <http://www.cpbibliography.com/>http://www.cpbibliography.com/ >_______________________________________________ >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/

1 0

Re: [Koha-devel] Koha numbering
by BWS Johnson 07 Apr '13

07 Apr '13

Salvete! Thank you for that, Jared. Hopefully my mail won't be ate. When the initial thread started, I didn't really care. At this point, I feel like the spirit of the discussion has shifted from pure numbering to the development release cycle. I also am a little torn on the large number being symptomatic of a larger problem. Are we losing enhancements in the hustle? I'll flesh this out more when I get home and have thought on the plane. Cheers, Brooke

1 0