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

Re: [Koha-devel] [ByWater Partners] Kylie Brice Hall
by Christopher Davis 18 Mar '16

18 Mar '16

Kyle, Congratulations! I hope that mother and baby are both healthy and happy. Truly, Christopher Davis On Fri, Mar 18, 2016 at 7:31 AM, Kyle Hall <kyle(a)bywatersolutions.com> wrote: > Kylie Brice Hall was born at 8:41 am in Erie, Pennsylvania. Weight of 9 > pounds 11 ounces. > > Sent from my phone. Please excuse my brevity. > > > _______________________________________________ > Partners mailing list > Partners(a)lists.bywatersolutions.com > http://lists.bywatersolutions.com/mailman/listinfo/partners >

1 0

Call for News: March 2016 Newsletter
by kohanews 16 Mar '16

16 Mar '16

Fellow Koha users ~ I'm collecting news for the March newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: * - Please include dates for past events. If I can't find dates I may not add it. * - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon * - For past events -- **** one month back is the cut-off ***. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Global Bug Squashing Day - March 24th 2016!
by Katrin Fischer 13 Mar '16

13 Mar '16

Hi all, we have a Global Bug Squashing Day (GBSD) planned for Thursday, March 24th 2016! Please feel free to add your ideas for the day to the wiki page, things you want to learn about and bugs you'd like to test or see tested: https://wiki.koha-community.org/wiki/2016-03-24_Global_bug_squashing_day Hope to see you there! Katrin

1 0

A three-level cache?
by Jonathan Druart 11 Mar '16

11 Mar '16

Hi devs, I have worked on a three-level cache to cache our stuffs: L1 - hashref L2 - memcache L3 - DB Please have a look at bug 11998 and bug 16044. I really really would like to get your opinions on these patches. Cheers, Jonathan

4 3

Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard?
by Paul A 09 Mar '16

09 Mar '16

At 07:42 AM 3/9/2016 -0500, Kyle Hall wrote: >Also, are you saying any newly packaged libraries *must* make it in to >Debian? Can we not host our own packaged libraries on our apt server? Why >must packages meet the Debian requirements? >This seems like it's adding yet another barrier to entry for new Koha >developers. Now we all need to be Debian package maintainers as well? >It seems like we're taking away one of the most powerful features of Perl, >it's extensive library of available modules. One of Koha's strengths certainly was, and most probably still is, the ability for an admin to be able to aptitude/apt-get (even yum) dependencies that conform to her o/s. We used to publish "warnings" about using CPAN. Debian trickles down to Ubuntu -- with a possible time-lag -- and these two o/s are perhaps the most used by Koha-based libraries. If Koha needs to use a custom *library* and there is reticence to put it through the Debian/Ubuntu loop, surely the proper solution is to put it into the Koha environment (package and tarball) where it remains Koha-specific and the remainder of the o/s, including Perl, stays unchanged without potential repercussions on other installed applications/progammes. This might well also facilitate version control -- each Koha update has the correct libraries in /usr/share/koha/bin, /usr/share/koha/lib/C4, wherever, but not in /usr/lib/perl* (or /usr/bin/perl) (with or without /local/) available to the entire o/s. This removes any "barrier to entry for new Koha developers", might ease proper installation/upgrade operations and has the potential to obviate obscure security concerns. Best -- Paul >Just a thought. > ><http://www.kylehall.info>http://www.kylehall.info >ByWater Solutions ( <http://bywatersolutions.com>http://bywatersolutions.com ) >Meadville Public Library ( ><http://www.meadvillelibrary.org>http://www.meadvillelibrary.org ) >Crawford County Federated Library System ( ><http://www.ccfls.org>http://www.ccfls.org ) >Mill Run Technology Solutions ( ><http://millruntech.com>http://millruntech.com ) > >On Tue, Mar 8, 2016 at 6:03 PM, Galen Charlton ><<mailto:gmc@esilibrary.com>gmc(a)esilibrary.com> wrote: >Hi, > >On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher ><<mailto:info@bywatersolutions.com>info(a)bywatersolutions.com> wrote: >Do we have a defined role description of responsibility of the Packaging >Manager?Â (I've only read Robin's posts to the mailing list before - is >that it?) > > >We do now, seeded with my view of the position: > ><https://wiki.koha-community.org/wiki/Project_roles#Packaging_manager>https://wiki.koha-community.org/wiki/Project_roles#Packaging_managerÂ > > >On a side note, the overall page is new; I'm figuring that it might be a >useful exercise to outline minimum role responsibilities for all of the >named project positions. > >Regards, > >Galen >-- >Galen Charlton >Infrastructure and Added Services Manager >Equinox Software, Inc. / Open Your Library >email: Â <mailto:gmc@esilibrary.com>gmc(a)esilibrary.com >direct: <tel:%2B1%20770-709-5581>+1 770-709-5581 >cell: Â <tel:%2B1%20404-984-4366>+1 404-984-4366 >skype: Â gmcharlt >web: Â Â <http://www.esilibrary.com/>http://www.esilibrary.com/ >Supporting Koha and Evergreen: ><http://koha-community.org>http://koha-community.org & http://evergreen-ils.org > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >_______________________________________________ >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>

4 4

Packing needs - status to add to bugzilla and the dashboard?
by Brendan Gallagher 09 Mar '16

09 Mar '16

Hello All - I'd like to have a chance to talk about the packing work flow at the next developers meeting or even the general meeting. My thoughts are that we need a status in Bugzilla that says something like "Needs package created" or something. Also add a little spot on the dashboard under the Bugs Statuses which has a canned search for that queue. I imagine the workflow being something like... 1. RM pushes code to master 2. RM changes status to "needs package created" 3. PackingManager creates package 4. PM changes the status to "Pushed to Master" The work flow is important and I'd like to make it as transparent as possible and make sure that we don't miss something. Robin, Galen, or others do you have any thoughts on this? Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info(a)bywatersolutions.com

5 9

Attaching files in Koha 3.22
by Keith Kahn-Harris 09 Mar '16

09 Mar '16

Hello I am working on an archiving project for a library that has just adopted Koha 3.18. We are planning on undertaking a sizeable digitisation project for various special collections we hold - including sound files, pdfs and jpegs. The question we are looking at now is where to host these files. I understand that Koha 3.22 allows for attaching files to bibliographic records. What I’d like to know is how well this system works as a means of hosting archival material - and whether it obviates the need for a separate archiving and hosting system. So has anyone on this list used Koha 3.22 for this purpose? Are there any library systems I can look at that display attached files through Koha 3.22? Or does anyone have some screenshots they could send me? Do excuse the lack of technical literacy - we are only just getting going on this process and grappling with Koha. Many thanks Dr Keith Kahn-Harris

2 1

merge_authority.pl and merges in general not working correctly on 3.22 and master
by Remi MP 09 Mar '16

09 Mar '16

Hi, one of our clients has just migrated to 3.22.04 and noticed that even since bug15358, authority merge will not change the corresponding notices properly. It changes the authority number in the biblios but not the corresponding fields. Also, the merge_authority.pl script doesn't work on master : Can't locate object method "authtypecode" via package "2" (perhaps you forgot to load "2"?) at ./merge_authority.pl line 58. Is this an important issue for anyone else?

3 3

Proposal - Deal with modules versioning ($VERSION)
by Jonathan Druart 09 Mar '16

09 Mar '16

Hi devs, During the last dev meeting [1] we talked about how we should manage the $VERSION var of our Koha modules. (a)The first idea was to remove it: it is stuck to an old version and it does not make sense to keep it as it. Another idea would be to keep it and use it (i.e. update it). This idea has already been discussed on bug 7941 [2], but never been set up. In this second approach, there are different ways to do, either we update all of our modules to the Koha::version or update them individually, when they change. Based on 2 blog entries [3, 4] and the Perl Best Practices (Chap 17: Modules, Version Numbers), the way to do would be to use a three-part version numbers ('1.0.3') using the version module (`use version; our $VERSION = qv('1.0.3');`). But there are no specific guidelines to manage the different modules inside a project. I have checked several perl projects and they don't assign a version to each modules (Dancer, DBIx::Class, Mail-SpamAssassin). (b)Set the same $VERSION variable to all our modules does not seem very useful (unless making `perlcritic -2` happy). (c)On the contrary it would make sense to version them individually, following the Koha::version: when a module is modified, the minor version is increased. That would be easy to do for stable releases: the version is updated when releasing. But for master we could have a module version > Koha::version (indeed the Koha::version is only updated when a DB entry is added). To avoid that we could decide not to update the version during the development process (master). (d)Another way to do would be to initially set the version to 1.0.0 (or 3.0.0 or whatever) to all the modules and increase the version when they are modified, but the version numbers would not make sense and won't be helpful: some unchanged modules will have 1.0.1 and others 1.2.34. I think (c) makes sense: for instance if C4::Budgets is not modified between 3.22.x and 3.24.x, its version will stick to 3.22.x. Looking at this version we would know if this module has been updated recently or not. Concretely, we would set all of our modules to 3.24.00.000 (not that does not respect the 3-digit and 3-part version numbers "conventions") when releasing 3.24 (scripts will provided to automate everything), 3.25 will come and won't update the module versions until 3.26. 3.24 RMaint will update the versions of the modified modules when releasing 3.24.01.000 3.26 RM will update the versions of the modified modules when releasing 3.26.00.000 Note that we could "back-versioning" the modules of all our stable branches (3.18, 3.20 and 3.22). What are your thoughts? Are you more a, b, c, d or ... e? Cheers, Jonathan [1] http://meetings.koha-community.org/2016/development_irc_meeting_1_march_201… at 15:40:52 [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7941#c2 [3] http://www.modernperlbooks.com/mt/2009/07/version-confusion.html [4] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

5 8

General IRC meeting 9 March 2016 at 20:00 UTC
by Brendan Gallagher 08 Mar '16

08 Mar '16

Hello - Just a reminder that there is a General IRC Meeting tomorrow. Here is the link to the agenda. https://wiki.koha-community.org/wiki/General_IRC_meeting_9_March_2016 You'll also find a time converter in the wiki link so you can adjust to your local time. Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO

1 0