15:04:25 #startmeeting Development IRC Meeting 1 March 2016 15:04:25 Meeting started Tue Mar 1 15:04:25 2016 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:25 The meeting name has been set to 'development_irc_meeting_1_march_2016' 15:04:31 #chair khall 15:04:31 Current chairs: cait khall 15:04:37 #chair bag 15:04:37 Current chairs: bag cait khall 15:04:44 #topic Introductions 15:04:44 #info wahanui, a bot that has become sentient 15:04:53 Please introduce yourself with #info 15:05:04 #info Brendan Gallagher, ByWater 15:05:06 Today's agenda is at https://wiki.koha-community.org/wiki/Development_IRC_meeting_1_March_2016 15:06:10 #info Katrin Fischer, BSZ 15:06:13 #info Jonathan Druart 15:06:45 #info Kyle M Hall, ByWater Solutions 15:07:07 #info MJ Ray, software.coop 15:07:29 hey slef 15:07:37 hi 15:07:37 hello, slef 15:08:26 moving on? 15:08:44 +1 15:09:02 #topic Announcements 15:09:09 just giving the RM a chance to say something ;) 15:09:25 caught up last week with the queue - well sort of 15:09:35 lots of follow up this week 15:09:46 somethings are broken - but we’ve got time to work on those 15:10:00 jenkins being stable is a going to be a big push in the next month or two 15:10:05 #info Nick Clemens, ByWater Solutions 15:10:24 I will keep looking at the patches 15:10:28 #info Alex Sassmannshausen, PTFS Europe 15:10:34 I am interested in a discussion about 11081 15:10:37 bug 11081 15:10:38 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11081 enhancement, P5 - low, ---, frederic, Pushed to Master , Port Koha::Contrib::Tamil indexer into Koha code base 15:10:49 #info Hector Castro, Universidad de El Salvador 15:10:51 bag: It's on the agenda 15:10:54 #info Nicole Engard, ByWater Solutions 15:10:57 ah, channel is filling up 15:11:02 #info Nate Curulla ByWater Solutions 15:11:09 but I think we need more people here - so maybe I’ll bring that to general meeting instead? 15:11:25 #info Owen Leonard, Athens County Public Libraries 15:11:49 bag: this or next meeting? 15:11:58 #info Barton Chittenden, Bywater 15:12:04 bag: I think the subject matter is more appropriate for a developer meeting than a general meeting, but that's your call 15:12:05 my feeling is that we should evaluate how much needed it is... becuse Moose is rather big I was tol 15:12:06 d 15:12:21 let’s talk now 15:12:24 and we keep adding a lot to the dependencies 15:12:27 wait a sec 15:12:28 switching topic 15:12:42 #topic Discussion on bug 11081 - Moose 15:12:48 ok now 15:13:08 yes cait that’s a “con” - it’s big 15:13:40 I don't consider that such a con unless that has an acutal impact somehow 15:13:47 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11081#c30 15:13:49 04Bug 11081: enhancement, P5 - low, ---, frederic, Pushed to Master , Port Koha::Contrib::Tamil indexer into Koha code base 15:13:51 it's always very popular and widely used 15:14:03 #link https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11081 15:14:04 04Bug 11081: enhancement, P5 - low, ---, frederic, Pushed to Master , Port Koha::Contrib::Tamil indexer into Koha code base 15:14:08 I think that’s the comment that we need to understand - right? comment number 30 15:14:49 i haven't had time to research where we left discussion last time 15:15:17 I think there was a big consensus that Moo is ok - but disagreements about Moose 15:15:36 what is not clear to me - we already have the koha indexer - does the tamil one bring a big advantage over it? 15:15:43 just trying to understand the importance of this dev 15:15:49 as far as my research has shown, the only downside to Moose is the startup cost, after startup Moose is about as fast as Moo, but that startup cost is why we cannot use it for CGI scripts 15:16:15 I ws told it pulls in a lot of packages - so that makes me a bit worried about maintaining it as a dependency for a single feature 15:16:36 cait: afaik the current indexing daemon has issues and is not recommended, this is a replacement for that 15:17:05 I think the standard practice at the moment is to use the fast indexer cron script 15:17:30 but, that means a delay of at least minutes between a record being catalogued and it showing in searches, which frustrates librarians 15:17:40 the daemon is meant to resolve that issue 15:18:17 khall: hm that's new to me 15:18:22 to my knowledge tcohen has used it for a while 15:18:32 i think we are talking about different things 15:18:37 cait: to address your last comment, Moose is very popular, so the only real issue is the use of MooseX modules which are not in Debian. However, they've already been packaged in our own debian repo 15:19:01 the old old way was dropped in prefrence of the cronjob, but i know tcohen has been running an indexer 15:19:15 I don't think we need to worry about Moose maintenance due to it's popularity 15:19:42 cait: I may be out of date on the current state of the old indexing daemon ; ) 15:19:47 i'd really like to get an opinion from gmcharlt is packaging maintainer 15:19:50 Is Moose upstream friendly towards packaging and backwards stability? 15:20:05 khall: give me a moment to dig it up 15:20:13 i think you might have missed something - but we will check that :) 15:20:25 (I've just seen another popular package elsewhere be abandoned due to upstream hostility/abusiveness) 15:20:36 koha-indexer in the packages i think 15:21:27 ok, this is a bug related to the feature, but not the base bug 15:21:27 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15011 15:21:44 gmcharlt: ? 15:21:56 ok well still more discussion is needed. I will leave it for now. I was hoping tcohen could be around 15:22:06 http://meetings.koha-community.org/2015/development_irc_meeting_15_april_2015___part_1.2015-04-15-15.06.log.html 15:22:15 khall: maybe bug 8773 15:22:16 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8773 enhancement, P5 - low, ---, tomascohen, CLOSED FIXED, Add per-instance koha-index-daemon in .deb setup 15:22:16 this is the meeting log of the Moo vs Moose discussion 15:22:42 ah good thanks Joubu - I’ll read that later - that should help me 15:22:57 Launch an indexing daemon (rebuild_zebra.pl -daemon) process for each enabled instance. Enabling/disabling the use of the indexer is handled by global configuration variables in /etc/default/koha-common. Also provides command line tools to manage the running indexer daemons for your instances. 15:23:00 I think we can move on for now cait - that has taking a bunch of time 15:23:07 ok, one sec 15:23:13 Joubu: That entire discussion was in the context of using Moose in CGI scripts, so I don't believe it applies in this case. 15:23:33 any action items we shoudl log? 15:23:37 What we need to do is decide if we should allow Moose in CLI applications, or make it verboten in general 15:23:51 cait: I suggest we start a koha-devel thread for this 15:23:57 ok 15:23:57 khall: I don't think so, it was about bug 11190, which is a cmd line script 15:23:59 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11190 new feature, P5 - low, ---, frederic, Pushed to Stable , sitemap.pl -- Generate a catalog sitemap 15:24:01 can you start it? 15:24:03 I would say - yup what khall said 15:24:26 #action khall to start mailing list thread about Moose in context of command line scripts 15:24:34 moving on to the coding guidlines 15:24:49 #topic Review Coding Guidelines 15:25:02 there are currently no proposals for new coding guidelines 15:25:08 Joubu: you are correct, my memory was not so good ; ) 15:25:09 so we will move to the 'reword/update' 15:25:27 i had something prepared... but left the file on my laptop at home 15:25:40 so if you are ok with that, i'd move to the second first 15:25:51 JS4 15:26:15 #link https://wiki.koha-community.org/wiki/Coding_Guidelines#JS4:_Avoid_joining_multiple_language_strings_with_other_variables 15:26:32 We used to recommend: Avoid building sentences by concatenating multiple translatable strings. Your language may not use the same sentence structure. The best options keep strings at the beginning or end of a construction. This is incorrect: 15:26:49 IMO this no longer applies 15:26:58 we have a better wy now to handle this 15:27:02 * oleonard agrees 15:27:19 Introduced by bug 15662 15:27:20 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15662 enhancement, P5 - low, ---, aleishaamohia, Pushed to Master , String and translatability fix to Label Creator 15:27:29 hmm 15:27:32 maybe that is the wrong bug 15:28:20 ok, does someone have the right informationa bout the format syntax? :) 15:28:22 bug 12138 15:28:23 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12138 enhancement, P5 - low, ---, pasi.kallinen, CLOSED FIXED, Use placeholders in translatable javascript strings 15:28:26 thx a lot 15:28:29 khall++ 15:28:33 : ) 15:28:41 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12138 15:28:42 04Bug 12138: enhancement, P5 - low, ---, pasi.kallinen, CLOSED FIXED, Use placeholders in translatable javascript strings 15:28:44 so we shoudl recommend that 15:29:06 and vetos? :) 15:29:36 +1 by me 15:29:41 the example looks somewhat like this: _("Are you sure you want to delete the %s attached items?").format(count) 15:30:07 and this will give the translator %s placeholders they can move around and a single sentence to translate instead of bits and pieces of a sentence 15:30:18 +1 by me too 15:30:23 +1 15:30:28 +1 15:30:46 would someone volunteer to rewrite the rule with an example? 15:30:52 +1 15:31:11 +1 15:31:16 * oleonard volunteers 15:31:22 thanks oleonard! 15:31:31 +1 15:32:39 #action oleonard to rewrite JS4 rule in light of bug 12138 15:32:54 next is PERL7 15:33:07 #link https://wiki.koha-community.org/wiki/Coding_Guidelines#PERL7:_Definitions 15:33:24 #link https://wiki.koha-community.org/wiki/Coding_Guidelines#Terminology 15:33:57 i'd like to replace PERL7 and the terminology link at the top by a single rule 15:34:25 referring to our terminology page first 15:34:40 and pointing out that the terms of the english interface should be considered the standard for naming things? 15:34:52 inside... andout - templates and code 15:35:03 agreed! 15:35:19 and maybe at odlis for new things to be named? 15:35:24 seconded! (or thirded?) 15:35:43 https://wiki.koha-community.org/wiki/Terminology is the page ref 15:35:43 cait: that sounds reasonable and good 15:35:54 Joubu++ for his work to this end 15:35:59 hm terminology link at the bottom not at the top.... but i gave you a link anyway :) 15:36:07 Joubu++ 15:36:16 Joubu++ 15:36:33 so... terminology, english templates, odlis? 15:36:36 Joubu++ 15:37:15 +1 from me 15:37:20 what is (are?) odlis? 15:38:10 #link http://www.abc-clio.com/ODLIS/odlis_a.aspx 15:38:24 barton: a standard for library terminology 15:38:41 +1 15:38:47 someon willing to write that up? 15:39:14 * khall volunteers 15:39:40 #action khall to write up a new PERL7 version "terminology wiki page, templates, odlis" 15:40:01 are we ok to move on? 15:40:06 yup 15:40:11 +1 15:40:12 PERL12 15:40:52 #link https://wiki.koha-community.org/wiki/Coding_Guidelines#PERL12:_VERSION 15:40:59 [Deprecated as of start of 3.12 release cycle] Each module should have a $VERSION variable to preserve progressive levels of compatibility with dependent code. 15:41:25 Action from last meeting: Verify if perlcritic complains about missing VERSION and figure out, if we want/can reconfigure it. 15:41:25 [mtompset] perlcritic does not complain about missing $VERSION until -2, but since we only perlcritic to -5, there is no need to keep this. 15:41:37 the vote would be to obsolete this one and remove it from the coding guidelines 15:41:50 i am not sure if there are remaining $VERSION that shoudl be actively removed from the codebase 15:43:46 Maybe the best would be to keep it up to date 15:43:54 hm? 15:43:54 perl-reversion can help us 15:44:04 https://metacpan.org/pod/distribution/Perl-Version/examples/perl-reversion 15:44:26 There is no point to keep $VERSION=3.07.*, as we don't update it 15:44:38 ok, so that would be a second proposal 15:44:41 instead of removing - using it :) 15:44:52 but it would make sense to keep it (I think I have read somewhere it's a good practice) 15:45:04 maybe a silly question... but what is it good for when we are using git to track all changes? 15:45:11 it could be added to the release script 15:45:40 hm what do people think? 15:45:43 it can help with dependency tracking. 15:46:34 I tend to agree, for example the NCIP server uses Koha libraries, and could have different connector modules depending on the Koha version. 15:46:41 since the API may change 15:47:26 I would suggest it be a function of the RM ( scriptable if possible ) to update the Module versions with each release. 15:47:39 could you write up proposal about this? 15:47:49 Joubu: would you be willing to add that to the release script? 15:48:24 cait: I think that pretty much *is* the proposal ; ) 15:48:35 yes, will do 15:48:40 sweet 15:48:42 Joubu++ 15:49:26 cait: Add and update $VERSION variables for all Koha modules so API changes can be dealt with by external projects using Koha modules 15:51:57 ok - waht about the coding guiedeline? 15:51:59 undeprecate it? 15:52:08 or just add a note that they will be dealt with automatically and hsould not be touched? 15:52:42 Joubu: what do you think? 15:53:13 yes, should not be touched, but what about new modules? 15:53:40 set as the version used in master I'd say 15:53:48 agreed 15:54:51 ok, someone to write that up? 15:54:57 Joubu: initially? I don't think the Module versions should change unless some api changes 15:55:30 but I think using the Koha version to set the initial version would be fine 15:55:35 the first version to be set on a new file? 15:55:38 was that the question? 15:55:41 I will have a look at the common best practices, and let you know 15:55:43 and then if any api changes, update the module version to the current Koha version? 15:55:51 Joubu: excellent 15:55:53 I'd say: Set Koha::version to all our modules 15:56:03 for new modules, use the current koha::version 15:56:22 and update module $version for stable branches only 15:56:28 #action Joubu will look into best practices for dealing with module versioning 15:56:49 I think that sounds pretty good 15:56:57 #info New proposal to make use of the Versioning instead of removing it 15:57:17 ok 15:57:33 the last is a proposal from khall about restructuring hte page 15:58:49 i think we have some double ups and inconsistencies 15:58:58 and also probably we need a better numbering/naming scheme 15:59:20 it's a bit long and daunting... maybe pslitting it up into smaller pieces? 15:59:30 Maybe we get rid of the numbering scheme altogehter and just use names 15:59:39 I'd love to get all of them on the same page 15:59:58 one page for all? 16:00:00 e.g. Coding Guidelines => Perl => Object Oriented 16:00:14 it would help with deprecating things 16:00:16 I think one page is still adequate for the time being 16:00:20 I thought the proposal was to break it into separate pages? 16:00:31 it was something i suggested 16:00:36 maybe it could be just clear sections 16:00:56 not every new developer will need database/perl - my idea was if we could make it a bit less daunting 16:00:59 I think one page vs many pages is not a serious issue at the moment, we can always break it up later if need be 16:01:21 but yeah, mostly it needs a restructuring i think 16:01:46 I would still propose we follow the structure of https://make.wordpress.org/core/handbook/best-practices/coding-standards/ 16:01:49 i'd like to see how khall's idea turns out 16:01:57 #link https://make.wordpress.org/core/handbook/best-practices/coding-standards/ 16:01:59 and maybe take some of it's suggestions as well 16:02:24 I like that, and plan to suggest some of their guidelines for HTML and CSS. 16:02:37 ok 16:02:40 so shall we vote? 16:02:51 on having kyle draw up a draft ? 16:03:01 sure! 16:03:07 +1 16:03:10 +1 16:03:14 +1 16:03:15 +1 16:03:20 +1 16:03:24 +1 16:03:27 +1 16:03:29 +1 16:04:01 #action khall to draw up a draft following the structure of https://make.wordpress.org/core/handbook/best-practices/coding-standards/ 16:04:30 khall: could you take over for your suggestion for PERL7? 16:04:58 ok 16:05:36 I propose the following verbiage: http://paste.koha-community.org/322 16:05:50 The same vocabulary should be used both in internally in source code ( Module names, variable names, etc ) and externally ( javascript, templates, etc ). 16:05:50 Canonical Koha terminology is listed on the [Terminology] page. 16:05:50 If you are developing a new feature that requires new terminology, please locate and use the matching term defined by [ODLIS](http://www.abc-clio.com/ODLIS/odlis_a.aspx). 16:05:50 If you cannot find an appropriate term via ODLIS, please bring the question to the Koha community via the Koha Developers Mailing List or the next Koha Developers IRC Meeting. 16:07:03 any questions? or shall we vote? 16:07:29 typo: …used both in internally in… 16:07:40 Should change to …used both internally in… 16:07:57 noted, thanks atheia. will fix 16:08:10 np :-) 16:08:23 The same vocabulary should be used both internally in source code ( Module names, variable names, etc ) and externally ( javascript, templates, etc ). 16:08:24 Canonical Koha terminology is listed on the [Terminology] page. 16:08:24 If you are developing a new feature that requires new terminology, please locate and use the matching term defined by [ODLIS](http://www.abc-clio.com/ODLIS/odlis_a.aspx). 16:08:24 If you cannot find an appropriate term via ODLIS, please bring the question to the Koha community via the Koha Developers Mailing List or the next Koha Developers IRC Meeting. 16:08:24 i already had it that way, khall. 16:09:06 /(members|borrowers|users)/patrons/g #easy 16:09:20 heh 16:09:46 any other questions or comments? 16:10:53 shall we vote then? 16:11:18 yes 16:11:25 +1 16:11:29 +1 16:11:32 +1 16:11:33 +1 16:12:07 +1 16:12:07 +1 16:12:33 +1 16:14:26 #action khall will update the PERL7 rule to match the agreed verbiage 16:15:14 thx khall 16:15:30 ok, onw it's about 1:15 in 16:15:42 shall we try to look at another topic or continue next time? 16:15:57 If we have a minute I think we can put the Moose / Moo issue to rest 16:16:27 I would like to recant my position based on the fact the Joubu pointed out that my memory is bad ; ) 16:16:48 ok? 16:16:54 so are we sticking with Moo? 16:17:02 i haven't read up on Joubu's link *confesses* 16:17:07 Based on the past discussion I think we should add a simple rule that says "No Moose, use Moo" and we should revert the bug 16:17:33 use Moo for cli scripts only? 16:17:56 I think the rule should just be "Use Moo, not Moose" in general 16:17:57 ok, quick vote? 16:17:59 that is the current consensus iirc 16:18:05 if it applies to CLI, it certainly applies to CGI 16:18:20 ok 16:18:28 if it applies to cgi, we will have to accept Koha::* using Moo 16:20:12 Joubu: would you propose only Koha::Object(s) and Class:Accessor only for CGI? 16:20:33 that's the current position 16:20:45 and bespoke OOP of course when applicable 16:21:09 that seems reasonable, I will write up a rule proposal for next time 16:21:27 IMO we should not accept 3 different ways to implement Koha classes 16:22:22 Joubu: I agree, I think Koha::Object(s) for db table driven objects, and Class:Accessor for non-db driven objects is acceptable 16:22:54 yep 16:22:57 * cait thinks either Joubu or khall shoudl write a proposal 16:23:05 we could also use this to fix the first point we left out today 16:23:13 [kfischer] Merge new PERL20 and PERL20.1 into PERL15 16:23:14 * khall volunteers 16:23:26 because that also touches koha::object and class::accessor 16:23:29 and shoudl be in one place imp 16:23:32 imo:) 16:23:42 cait: agreed, I will take all that into account 16:24:32 Speaking of the wiki, I'd love to get something like this to use: https://www.mediawiki.org/wiki/Extension:SyntaxHighlighter 16:24:40 #action khall to propose a wording for the Moo,not Moose and PERL20, PERL20.1 and PERL15 fusion ;) 16:25:06 off topic: It would be good to know if people are using 3.22 in production, and if they have perf issues or not 16:26:01 i worked with one of our installations today.. it seemed certainly slower than 3.18 16:26:04 it's not live yet 16:26:16 and not using plack 16:26:35 I'd not recommend 3.22 without Plack 16:26:43 it will be terribly slow 16:26:55 in general,.. there were complaints about speed in the comments from Marshall's survey - but hard to tell without knowing specs/hardware 16:27:42 oleonard: i'd like the wiki to be updated a bit 16:27:45 not sure how possible it is 16:28:42 oleonard: maybe ask gmcharlt or put it on next meeting's agenda? 16:29:10 are we good to end here? 16:29:37 I think so 16:29:38 I have asked once to add a plugin to the wiki, someone told me no. 16:29:53 * Joubu does not remember who/what/when 16:29:57 #topic Set time and date of next meeting 16:29:58 I think a syntax highlighting plugin makes sense for the wiki 16:29:58 * oleonard will think of a good bribe 16:30:04 i think our wiki is a bit nonstandard... that's my impression 16:30:13 but first step will be a general mediawiki upgrade, as it's long overdue for one 16:30:45 gmcharlt: action item? ;) 16:30:58 cait: sure, why not 16:31:26 #action gmcharlt to update wiki and consider highlighting plugin 16:31:38 #link https://www.mediawiki.org/wiki/Extension:SyntaxHighlighter 16:31:47 we got a lot done 16:31:57 do we need a meeting again in 2 weeks or switch to monthly? 16:32:52 no opinion 16:33:17 * oleonard votes 2 weeks 16:33:28 ok 16:33:30 so that woudl leave us with 16:33:35 15th 16:33:44 I won't be able to attend in that week 16:34:04 because I will be at the german library congess 16:34:16 so someone else would have to take over chairing 16:34:29 I’ll be in italy so I can’t make it either 16:34:39 Okay never mind :) 16:34:57 3 weeks? :) 16:35:03 tuesdday 22nd 16:35:20 19UTC? 16:35:30 seems doable 16:36:16 #agreed next dev meeting will be at 22 march, 19 UTC 16:36:19 #endmeeting