Time Nick Message 21:44 eythian Yep 21:42 pianohacker that was a rather rapid descent into complete nonsense 21:39 eythian http://homeopathyonline.org.uk/8-2/berlin-wall/ 21:37 cait good night all 21:12 liw yellow leaf falls down / I can yes has cheezeburger / cat hunts mighty mouse 21:07 cait i think there is a haiku somewhere too 21:07 pianohacker credit goes to atz apparently 21:07 cait hehe 21:07 pianohacker heh: tools/import_borrowers.pl:146: my @bad_dates; # I've had a few. 21:06 kidclamp yeah, I think a separate bug 21:05 cait could it have been a jquery trick? some customization that is broken now? 21:05 cait but still wouldn#t work like stated on the bug :) 21:05 cait kidclamp: i wanted to file a comment about the changed bheaviour - if people don't like it, we should revisit 21:04 kidclamp if they came from 3.16 it would make sense 21:04 kidclamp but I don't know what they were on befroe 3.20 21:04 kidclamp you know, I would read that as that change of items not showing by default on the checkout screen 21:03 cait that#s why i was scratching my head 21:03 cait he just commented on the bug 21:03 cait he says items checked out :( 21:02 kidclamp yeah, what did Karl end up saying barton? 21:02 cait hm but comment 2? 21:01 barton ;-) 21:00 barton I think that I filed it on kidclamp's behalf... he was ... ... 'annoyed' by the new behavior. 21:00 kidclamp or I guess "not checked out items nto showing" is what i want 21:00 kidclamp I think it was a confusion, though the bug title is a good one :-) 20:57 cait but i am pretty sure... it didn't work that way - the recent change is still debatable, but i can't imagine us showing items that haven't been scanned at all? 20:57 cait :) 20:57 cait barton filed it 20:56 pianohacker barton or kidclamp: any insights? ^ 20:55 cait "... -- checking an item in previously showed other items checked out by the same borrower, which was useful for renewing items and/or telling patrons what items they still had checked out." (on returns.pl?) 20:54 cait not sure if it's me misunderstanding or something else? 20:53 huginn 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15551 enhancement, P5 - low, ---, koha-bugs, NEW , checked out items not showing on returns.pl 20:53 cait hm bug 15551 20:48 cait feeling silly now for not trying that :) 20:48 cait thx :) 20:48 cait so it must have died pretty to the end of it 20:47 cait only missing the next meeting date at the end i think 20:47 cait almost complete too 20:47 cait :) 20:47 gmcharlt ;) 20:47 gmcharlt THE LONGEST MEETING EVER! 20:47 cait awesome 20:47 cait oooh 20:47 huginn Log: http://meetings.koha-community.org/2016/developer_irc_meeting__2_february_2016.2016-02-02-15.01.log.html 20:47 huginn Minutes (text): http://meetings.koha-community.org/2016/developer_irc_meeting__2_february_2016.2016-02-02-15.01.txt 20:47 huginn Minutes: http://meetings.koha-community.org/2016/developer_irc_meeting__2_february_2016.2016-02-02-15.01.html 20:47 huginn Meeting ended Tue Feb 2 20:47:20 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 20:47 cait #endmeeting 20:47 cait sure 20:47 gmcharlt hmm, could you try it, cait? since you started the meeting? 20:46 cait hm, he forgot :( 20:45 gmcharlt #endmeeting 20:45 gmcharlt hmm 19:08 cait i haven't read all of today's bug mail yet - guess i will find it sooner or later 19:08 cait maybe it's a language thing? 19:06 oleonard I imagine there exists a project where the newer bug always gets marked as the duplicate even if it has patches on it. 19:00 gaetan_B bye 18:56 pianohacker oleonard: yeah, that's the same error 18:52 huginn 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14121 minor, P5 - low, ---, mtompset, RESOLVED FIXED, Silence warnings t/db_dependent/Auth_with_cas.t 18:52 oleonard pianohacker: Bug 14121 similar? 18:50 cait gmcharlt: anyhtng we could do about the meeting logs? 18:49 cait oh you got huginn breathing again 18:47 pianohacker do we even have a bug for that yet? 18:46 oleonard My error logs these days are all "CGI::param called in list context from package..." Makes it hard to see the real issues. 18:43 pianohacker ah kk 18:42 gmcharlt pianohacker: Linode in Atlanta sufferred a routing snafu 18:42 pianohacker gmcharlt: any idea why it died? 18:23 pianohacker gmcharlt++ 18:23 pianohacker cool 18:23 huginn 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12321 normal, P5 - low, ---, gmcharlt, NEW , indicators not editable after linking authority 18:23 pianohacker bug 12321 18:18 huginn gmcharlt: Quote #240: "<wizzyrea> we will have no hazing of RM's" (added by gmcharlt at 10:22 PM, April 05, 2013) 18:18 gmcharlt @quote random 17:28 Joubu have to go, see you tomorrow #koha! 17:27 pianohacker old_issues which is used vs deletedborrowers/deleteditems/etc. which are really only in reports 17:26 pianohacker yeah. It doesn't help that Koha's database schema isn't really black and white on this point 17:25 Joubu pianohacker: I need to think about it. That was the idea of my email on koha-devel: try to get more ideas, try to know if it's useful or not :) 17:25 Joubu pianohacker: As you can see, it's not clear in my mind :) 17:15 cait sorry... not making sense i guess and have to leave :) cya all later 17:14 Joubu I wrote the patch to avoid that borrowernumber is linked to a nonexistent patron 17:14 cait maybe too strict - keeping the borrowernumber and working on actually anonymizing/killing a deleted staff member would be good 17:13 cait I initially wrote it up when i was working on our data privacy documentation 17:13 pianohacker acq, the everlasting pile of exceptions... 17:13 cait you might not be able to access some things without a borrowernumber in the right places there as the visibility is determined by the person who did things... 17:12 cait acq 17:12 cait I think... i'd be ok with it now, as we also need to keep the number in some other places i think 17:11 pianohacker okay, so it's not so much an anonimity issue as a database issue? 17:11 cait It's in the logs now, but not really that useful information 17:11 oleonard pianohacker: Does neatness count? 17:11 cait pianohacker: also, we only store the initial writer... what about someone changes it? 17:11 pianohacker cait: and no, bywater would grind to a partial halt without our bot :) 17:10 pianohacker I know it's not the only reason you're proposing the merge, but I'm mostly just curious as to why it needs to be wiped out :) 17:10 Joubu The idea would be to know how did create the report, even if the patron is "deleted" 17:10 cait the argument "i want to know who wrote it" is not really valid here for keeping things forever I think :) 17:10 cait it kidn of woudl be more ok if we ever deleted deletedborrowers... or anonymized 17:10 Joubu pianohacker: with the patch, it will be set to null (because the patron is removed from the borrowers table) 17:10 pianohacker It seems like knowing just the borrowernumber that created a report is very innocuous 17:10 Joubu pianohacker: yep, at the moment, without 13668, reports.borrowernumber is kept when the patron is deleted 17:09 cait we really depend on those bots.... shoudl we worry? :) 17:09 pianohacker https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13668 17:09 pianohacker ugh hugiiiiiiiiinn 17:09 Joubu pianohacker: sorry, didn't get it neither :) 17:09 pianohacker cait: bug 13668 17:09 cait ? 17:07 pianohacker Joubu/cait: yeah. Granted, I'm just an American, but it seems like a bare borrowernumber given credit for a report is a very innocuous piece of data to be generating this much fuss 17:05 nengard back to work 17:05 nengard they're waving 17:04 bag hello 17:04 talljoy hi! 17:04 cc Hi 17:04 oleonard Hi nengard 17:04 * cait waves 17:04 Joubu hi :) 17:04 cait they just missed the big meeting :) 17:04 nengard (and be nice you're on the big screen) 17:04 nengard Hi #koha I'm at a conference teaching open source say hi!!! 17:04 cait cc: also keeping itemtype on bib-level... just have a workflow on how to use them that doesn't has so many ifs 17:04 cc cait: ah should have read up on it 17:04 Joubu pianohacker: are you talking about bug 13668? 17:03 cait cc: i thik the question is only about removing the preference - not removing the itemtype on item level 17:03 bag ok 17:02 Joubu bag: yes of course 17:02 Joubu Are you referring to a bug in particular? 17:01 bag or just drop the functionality of moving data into deletedborrowers and keep the deletedborrowers table? 17:01 reiveune bye 17:01 bag part of the fix would be a migration of data from deleted borrowers back into borrowers table? 17:01 pianohacker Joubu: one question: the anonimity was related to staff members writing reports, correct? 17:00 Joubu :) 17:00 bag :P 17:00 bag jinx 17:00 Joubu and it will break existing reports 17:00 bag reports would have to be changed 16:59 Joubu on the other way, we will have to manage some deletion manually (to preserve anonymity) 16:59 bag right 16:59 Joubu bag merging the table will simplify some problems and allow us to keep a track of some data 16:59 bag either way I’m trying to think of a spot. no feedback for you Joubu 16:58 bag yeah but merging the tables would not cause FK problems right? 16:58 Joubu But I am a bit afraid to find some big problems I have not thought about it 16:58 talljoy right. 16:57 Joubu talljoy: actually we could already implement that, but we will lost some info (foreign keys) 16:57 bag ok right I see that would be easier to fix some of those. 16:56 talljoy that would be nice functionality. 16:56 Joubu and could allow to restore a patron is deleted accidentally (but not a big deal) 16:56 * bag looking at those bugs 16:56 Joubu It will permit to keep a track of some info 16:55 Joubu bag, for instance I tried to fix some bug recently (bug 14849, bug 13668, bug 13534, bug 13533, bug 13515) which could be fixed easier with only 1 table 16:55 Joubu cc: yes 16:54 talljoy cait++ 16:54 cc joubu: I think a lot of places rely on item-level_itypes 16:54 pianohacker Joubu: yeah, I get ya 16:54 bag just curious Joubu what is the benefit of doing a “delete†flag for the borrowers? 16:53 Joubu The ML did not work, so I wanted to try the dev meeting 16:53 Joubu pianohacker: basically I wanted to get feedback on the 2 topics: item-level_itypes pref and merge deleted* tables 16:50 pianohacker Joubu: could you put some quick notes on your thoughts regarding the stuff we didn't get to on the agenda, so somebody else can take point if you can't attend the next meeting? 16:50 barton cait++ 16:50 kidclamp cait++ 16:50 pianohacker but aside from that 16:50 cait shame on me 16:50 cait ... right 16:50 pianohacker cait: well, you broke the bot 16:50 pianohacker huginn` more often than not 16:50 cait hope it was not totally awful 16:49 pianohacker barton: yeah 16:49 pianohacker cait++ 16:49 barton pianohacker: it's huginn, I think. 16:49 bag cait++ 16:49 pianohacker agreed 16:49 oleonard cait++ # thanks for running the meeting 16:49 talljoy ha 16:49 pianohacker @later tell bwsbot physician, heal thyself 16:49 barton pianohacker: nice word. 16:49 barton heh. 16:48 cait will try to do the later... later 16:48 cait maybe some sever problem 16:48 cait hm no gmcharlt online either 16:48 pianohacker yeah, it's flubbernucked 16:48 pianohacker . 16:48 pianohacker @later tell pianohacker HI 16:47 cait and... also does the laters 16:47 Joubu Missing "VERSION" section in POD at line 86, column 1. See pages 133,138 of PBP. (Severity: 2) 16:47 Joubu khall: No package-scoped "$VERSION" variable found at line 1, column 1. See page 404 of PBP. (Severity: 2) 16:47 cait huginn does 16:47 cait @later tell gmcharlt could you take a look at the meetbot/huginn? It seems something went wrong during the dev meeting today. 16:47 tajoli quit 16:47 barton cait, which bot runs the meetings? 16:46 cait #endmeeting 16:45 cait that would be not so good 16:45 cait hm did we lose the bot? 16:45 cait #endmeeting 16:45 cait #agreed Next meeting will be February 16 at 19 UTC 16:45 cc +1 16:45 barton +1 16:45 tajoli +1 16:45 talljoy +1 16:45 cait +1 16:45 pianohacker +1 16:45 cait 19utc then? 16:44 bag ok 16:44 cait hm... it doesn't work 16:44 Joubu bag I can try to attend, but not 100% sure 16:44 bag then march 2nd we can go back to 15utc most likely :D 16:44 cait #topic Next Meeting 16:43 cait #Topic Next meeting 16:43 bag ok let’s do 19utc 16th of Feb 16:43 cait ok, so 16th for next meeting 16:43 barton 19 utc is fine by me. 16:43 cait i am tired.. i just saw imagined kyle growing wings :) we need to end this meeting :) 16:43 bag yeah that’s what I was worried about 16:43 Joubu late :) 16:42 * khall is an early bird 16:42 bag Joubu: 19utc ok for you? 16:42 cait 19 utc shoudl be better for them - 8 am if i amnot mistaken 16:42 khall ok, I'd pick 17utc if we were voting on it ; ) 16:42 bag khall: oceana couldn’t join 16:42 cait khall: for some it's a really bad time :) 16:42 pianohacker khall: ;_; 16:41 cait hm would both work for me 16:41 khall 15utc was great for me, any reason we shouldn't keep it at that time? 16:41 bag this one started at 15utc 16:41 khall agreed 16:41 cait we can go monthly 16:41 cait i think once the agenda empties out 16:41 bag ok 16th at 17utc or 19utc 16:41 khall +1 16:41 barton +1 for the 16th. 16:41 pianohacker it might be a good idea to schedule both now 16:40 cait i am fine with 16th 16:40 cait i think a sooner meeting as we didn#t get through the agenda would be good 16:40 bag :D 16:40 cait 2nd of march 16:40 Joubu I should have put them at the beginning 16:40 bag happy birthday cait 16:40 cait bag: my birthday... 16:40 bag 16th of Feb 16:40 Joubu I wanted to talk about the 2 last entries... 16:40 pianohacker it would make these meetings less of a marathon :) 16:39 barton agreed. 16:39 khall I think sooner would be better 16:39 khall would be nice if we could do bi-monthly dev meetings ( 2 a month ). Is that too often ? 16:39 bag 2nd of March ? 16:39 pianohacker should we go for sooner than later, as there's plenty we couldn't get to? 16:39 bag looking 16:38 wahanui cait: I forgot next meeting 16:38 cait forget next meeting 16:38 wahanui it has been said that next meeting is December 5th 18 UTC 16:38 cait bag: next meeting? 16:38 cait that way... if i messed up the minutes i will have to sort it out :) 16:38 cait #action cait to apply agreed to changes on the wiki 16:37 tajoli ok 16:37 barton np. 16:37 khall cait: let me know when you've done it and I can review it 16:37 cait ok? 16:37 cait once done 16:37 cait i can send an email to the list 16:36 cait I can try to - but woudl encourage people to check the wiki changes 16:36 cait barton: toolate :) 16:36 cait who is going to amek the agreed to changes? 16:36 barton *templates 16:36 cait ok 16:36 cait #agreed to remove HTML5: Deprecation of the 'prog' and 'CCSR' OPAC themes.' Templats are long gone 16:35 cait #agreed to remove PERL11: No CVS - Development has moved from CVS to git. Therefore the use of CVS keywords $Id$ and $Revision$ should be discontinued. 16:35 kidclamp +1 16:35 talljoy +1 16:35 bag +1 16:35 barton +1 16:35 cait +1 16:35 cait Joubu: yeah i think we need to investigate :) 16:34 Joubu +1 16:34 tajoli +1 16:34 cc +1 16:34 pianohacker but +1 16:34 cait html5 and perl11 16:34 khall +1 16:34 cait perl 11 16:34 Joubu Actually I don't understand, we have added some new module without the $VERSION var defined, and the tests passed 16:34 cait argh 16:34 pianohacker cait: well, I think we're in agreement about removing the rule 16:34 cait please vote on removal of html5 and perl12 16:34 khall sounds good 16:34 pianohacker yar 16:34 cait let's postpone that one and vote on the other 2 for now? 16:34 cait hm right now i wonder where i got my perlcritic file from... that it uses 16:34 pianohacker Joubu: are you comfortable volunteering to make perlcritic happy? 16:33 cc almost certainly -- (if you want to spend time configuring it) 16:33 Joubu there is certainly a perlcritic rule to remove it 16:32 cait hm haven't seen that in my qa script - possible we already did? 16:32 pianohacker cc: is that configurable? 16:32 cait oh 16:32 cc we say run perlcritic at one point but it complains if VERSION is missing 16:32 cait I think the koha plugins check version differently? 16:32 pianohacker then I'd say kill 'em 16:32 khall plugins can specify a *Koha* version though 16:32 khall pianohacker: not plugins I'm aware of do that. 16:31 pianohacker would that break any plugin that put the version number in the use statement? 16:31 khall I volunteer to remove them if we so wish 16:31 Joubu We never used them 16:31 khall easy enough to do 16:31 cait they appeared earlier today in discussion as not being readonly - but i am not sure what they are used for actually 16:30 cait for the last one, just a question: shoudl re remove existing VERSION variables? 16:30 Joubu pianohacker: yes indeed there are exceptions :) 16:30 cait the code is no longer there .) 16:30 pianohacker I'm up for a vote to remove all of the above, any objections? 16:30 cait html5 - is easy i think 16:30 cait [kfischer] 'PERL12: VERSION [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.' A bit confusing - should remaining VERSION variables be removed? 16:30 pianohacker Joubu: things like adding new circ functionality as Koha:: modules without just calling back into a million C4 modules would be a pretty high bar 16:30 cait [kfischer] 'PERL11: No CVS - Development has moved from CVS to git. Therefore the use of CVS keywords $Id$ and $Revision$ should be discontinued.' Is this rule still needed? 16:29 cait [kfischer] 'HTML5: Deprecation of the 'prog' and 'CCSR' OPAC themes.' Templats are long gone. 16:29 Joubu perl11 and perl12? 16:29 khall what's left for removals? 16:29 bag (Ginny was distracting me) ;) 16:29 cait then we will probably have to stop 16:29 cait i'd like to finish removals if ossible 16:29 cait we already voted on removing perl 18 / perl 19 16:29 khall cait: I'd like to table my sub-rule on that ( single argument stuff ) for another meeting so we can get though more important stuff this meeting ; ) 16:28 pianohacker Joubu: I think that's a bit too tricky to codify 16:28 cait Joubu: would you have tomove the wholemodule in this case? or just make a new one for the routine? 16:28 talljoy lol 16:28 cait bag, you are too slow :) 16:28 Joubu new subroutine as well actually... 16:28 bag +1 16:28 cait ok 16:28 cait #agreed PERL XXX: New modules should be added to the Koha namespace as C4 is deprecated. 16:28 Joubu +1 # yes please... 16:27 barton +1 16:27 khall also agree 16:27 cc +1 16:27 pianohacker I agree with cait's proposed wording 16:27 cait wording can be refined of course 16:27 cait +1 16:27 khall +1 16:27 cait PERL XXX: New modules should be added to the Koha namespace as C4 is deprecated. ? 16:27 talljoy +1 16:27 pianohacker +1 to add 'new modules should be in Koha::' 16:26 pianohacker let's get that outta the way 16:26 khall ok, quick vote on that? 16:26 cait an oversight 16:26 cait not in the coding guidelines as of today 16:26 Joubu It has been voted years ago, isn't it?? 16:26 khall oh, I mis-understood 16:26 cait did we vote on 'new modules shoudl be in Koha::'? 16:26 cait sorry, help me 16:25 khall right 16:25 pianohacker khall: because of the new %s support? 16:25 pianohacker oleonard_: https://wiki.koha-community.org/wiki/Coding_Guidelines#JS4:_Avoid_joining_multiple_language_strings_with_other_variables 16:25 oleonard_ Sorry, but what is JS4? 16:25 khall how about the update to JS4? 16:25 pianohacker yeah, very very defacto, should be dejure 16:25 khall yes 16:25 cait we i think the namespace rule is already passed? 16:24 cait ok 16:24 Joubu but I will try to think about that when failing qa 16:24 cait #action pianohacker to suggest a possible guideline for handling disagreements 16:24 khall the problem is often we get either radio silence or a split down the middle when we discuss things 16:24 Joubu no, I don't have any in mind 16:24 cait pianohacker: ok i wil action 16:24 cait Joubu: can you give a quick example? 16:23 cait i mean it goes both ways - devs shoudl talk about what they do.. as should qa 16:23 Joubu I definitively agree to have a list of "best pratices" to fill when QAing and vote them on the next dev meeting 16:23 khall jk ; ) 16:23 cait yeah... i'd like to avoid that a bit heh 16:23 khall QA court! 16:23 khall thanks pianohacker! 16:23 cait if you introduce a design change - aks others... if you don't agree with a qa ruling... bring it to a dev meeting 16:23 pianohacker cait: I'll send a possible wording to the dev list after the meeting :) 16:22 cait i thnk maybe this can be both sides 16:22 barton aaand on that note... next topic? 16:22 bag ha 16:22 bag :D 16:22 cait yeah... running out of time soon :) 16:22 Joubu pianohacker: yes, that's what we are doing for 90min :) 16:21 cait i am just not sure how that would read as a rule 16:21 pianohacker Joubu: I agree not everything can be codified, but as much as is reasonable _should_ be :) 16:21 cait and disagreeing with QA is fine (well... maybe not that TOO often ;) ) 16:21 pianohacker and what khall said 16:21 pianohacker so that code can be written to match those practices from the beginning 16:20 khall Joubu: you are correct, but we should do out best to help out those devs that haven't been around for years 16:20 Joubu but if you need to introduce a design change, ask other devs 16:20 cait i'd just like to say that i thik we have followed that 16:20 Joubu it's impossible to list all we can do or not do :) 16:20 cait this is one of the thing sthat I am nt sure it needs to be a rule... it seems more like a right to me... people disagree, it should lead to discussion 16:20 khall de jure - rule codified in law ( i.e. coding guielines ) 16:20 pianohacker cait/Joubu: the main reason I'd like this (and khall as well, to my understanding), is that it would be much better to have up-to-date coding guidelines that reflect as much as possible of our current practices 16:19 khall de facto - rule in practice 16:19 khall cait: just means it should be a codified rule 16:19 cait khall: now i need the dictionary 16:19 pianohacker as it is, the guidelines are incomplete and somewhat unloved 16:19 khall I think you both agree. It'd like it to be dejure 16:19 Joubu pianohacker: if a dev wants to use a new pattern, the easier is to ask on koha-devel or here on #koha 16:18 pianohacker cait: I think that's somewhat the practice, but we should connect such things more strongly to the coding guidelines 16:18 cait i see this is a defacto actually 16:18 cait I think failing without a coding guileline should actually be an 'in discussion' - it indicates a disagreement about something and it should lead to a discussion with more people / dev meeting 16:18 pianohacker I'm not pushing for anything dramatic, but I think we should codify that, if a QA team member has concerns about coding style (as opposed to intended functionality not working correctly), they should be either in the coding guidelines or the patch should be used to introduce a new coding guideline in a meeting / koha/devel 16:17 barton Joubu++ 16:17 cait Joubu: noone disagreed so far... we will see if the topic reappears on next agenda ;) 16:17 khall Joubu: I think everyone is happy with it 16:16 Joubu It's *my* good example, I don't know if everybody agrees with that 16:16 cait ok, go for it 16:16 pianohacker cait: what I mentioned above (:13t 16:16 barton next. 16:16 cait ok, any loose ends right now or can we move to next? 16:16 cait #info PERLXX shoudl link to admin/cities.pl for a good example 16:15 cait #agreed PERLXX: CGI scripts that handle CRUD operatiosn ( Create, Rad, Update, Delete ) should all be handled in the same script when possible. 16:15 jajm +1 16:15 bag +1 16:14 kidclamp +1 16:14 pianohacker +1 16:14 pianohacker cc: and it can help address Joubu's concern about consistency in the details without having to put them in stone 16:14 cc +1 16:14 Joubu +1 16:14 cait +1 16:14 barton +1 16:14 khall +1 16:14 cait can we have +1 or -1 please? 16:14 khall cc: also agreed 16:13 cait cc: totally agree 16:13 barton vote. 16:13 cc We might want to show good examples - an example is more useful than a rule for someone learning the codebase 16:13 Joubu khall: yep, agreed 16:13 pianohacker no, though I think we should revisit Kyle's general concern about failing QA for rules not in the coding guidelines after we vote on this :) 16:13 Joubu if everybody had a look at it already 16:13 cait can we vote please? 16:13 khall Joubu: I understand. We can work out a basic action list later, but I think the example should suffice for now 16:13 Joubu so you can add admin/cities.pl 16:13 cait pointing to an existing file 16:13 cait as suggested 16:13 cait i think adding an example would be good 16:12 Joubu but not important 16:12 Joubu khall: if we don't specify, we will get different wording for the same action 16:12 bag no disagreement here 16:12 cait i think? 16:12 cait ok, no general disagreement 16:11 khall Joubu: I don't think we need to be *quite* that specific in the rule, but yes, that's what we are looking for. 16:11 Joubu There is no need to have a different op, if an id is passed, you are modifying, otherwise you are adding 16:10 Joubu add_form 16:10 cait hm modify? 16:10 marcelr afk 16:10 Joubu admin/cities is the smaller one I guess 16:10 Joubu add_form, add_validate, list, delete_confirm, delete_confirmed 16:09 khall we can include a script to point to as the best example 16:09 Joubu using the same $op value would be better 16:09 Joubu I have rewritten the admin scripts to follow this pattern 16:09 cait hah 16:09 pianohacker I think it's a good rule for future patches; a majority though not all of Koha follows this pattern 16:09 marcelr sounds reasonable 16:09 cait I also commented, so ok as well 16:08 Joubu I have failed it, so I am ok with the proposition 16:08 barton that looks sensible to me. 16:08 cait any questions, comments? 16:08 huginn` 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14610 enhancement, P5 - low, ---, kyle.m.hall, Signed Off , Add ability to place article requests in Koha 16:08 khall s/Rad/Read 16:08 cait triggered by bug 14610 16:08 khall PERLXX: CGI scripts that handle CRUD operatiosn ( Create, Rad, Update, Delete ) should all be handled in the same script when possible. 16:08 cait Kyle suggested a rule about the handling of CRUD operations 16:07 cait next 16:07 cait ok 16:07 cait #agreed Grandfather clause: XXX - Patches submitted before the introduction of a new rule may pass QA even if they do not meet the current coding guideline requirements of the discretion of the QA team member. 16:07 cait i will log as suggested if there is no strong opinion 16:07 cait head of QA is mean i have heard... better not 16:07 marcelr only one rule 16:07 cait heh 16:07 khall well, we can always elevate it to the head of QA ; ) 16:06 cait if noone insists 16:06 cait i think only the wording 16:06 cait i think the question was if one qa'er or after asking other qa'ers for opinions 16:06 khall should we revote, or are we just discussing the specific wording? 16:06 cait yes 16:06 khall the idea behind XXX is that even if a patch fails the current qa guidlines, a QA'er can still give it a pass if the rules it fails were made after the patch's submission 16:05 cait just tell me which, i will log and we can move on 16:05 cait thx 16:05 khall ok, let's table my recent discussion and finish XXX 16:05 khall I would propose PERLXX: CGI scripts that handle CRUD operatiosn ( Create, Rad, Update, Delete ) should all be handled in the same script 16:05 cait there was discussion about the wording 16:04 barton cait: I'm ok with any of consulting, dicrestion or agreement. 16:04 khall I thought the XXX rule was finished 16:04 cait so we can move on? 16:04 cait so can we finish please with the XXX rule? 16:04 khall yes, and a failure without a rule should generate discussion and a new rule 16:04 cait transparency is also key 16:03 marcelr the rules are just tools :) 16:03 marcelr but you should explain of course 16:03 marcelr i think it should be possible to fail although there is no rule 16:03 wahanui I know! The blade went right through that child! 16:03 bag good point 16:03 cait anyway consulting, dicrestion or agreement? 16:03 cc maybe less rules but more recommendations 16:03 khall right, it's better to allow a rule to get broken than to fail someone who hasn't broken a rule 16:02 cait i thin we need to find somethin gin between 16:02 cait i think what rangi said in argentina always applies... rules are good, but rules can be broken (I choose to read broken as questioned :)) 16:02 khall marcelr: I was failed qa for something not in the qa guidlines, I don't want that to happen to future developers or forgetful me ; ) 16:01 marcelr khall: you cannot catch every exception in a rule (or you don't want to) 16:01 bag yes cait is correct there - phew 16:01 cait quick please 16:01 khall cait: yes, you are correct ; ) 16:01 cait which is the preferred phrasing now? so i can add it to the minutes 16:01 huginn` 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14610 enhancement, P5 - low, ---, kyle.m.hall, Signed Off , Add ability to place article requests in Koha 16:01 cait one thing after the other please 16:01 pianohacker khall: do you mean bug 14610? 16:00 khall the general consensus is that we shouldn't do this, so I think this should have a rule as well 16:00 cait consulting would practically mean asking for opinions - if response is low... so it's up to those who work it out 16:00 huginn` 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8753 enhancement, P1 - high, ---, charles.farmer, Pushed to Master , Add forgot password link to OPAC 16:00 khall I would also like to bring up bug 8753 for a quick discussion and vote. In that but I wrote two scripts, one for display, and the other for CRUD 16:00 barton I like that wording, cait. 15:59 marcelr some things are trivial 15:59 cait if noone chimes in... that woudl be ok 15:59 marcelr at discretion of QA team member (and possibly another QAer) 15:59 cait i am nto sure how to phrase that there shoudl be a window for discussion 15:59 Joubu imo, more than 1 is needed 15:59 cait #agreed Grandfather clause: XXX - Patches submitted before the introduction of a new rule may pass QA even if they do not meet the current coding guideline requirements after consulting with the QA team members. ? 15:58 marcelr whole team is not needed i guess 15:58 Joubu ok, let's forget that, not important 15:58 cait Grandfather clause: XXX - Patches submitted before the introduction of a new rule may pass QA even if they do not meet the current coding guideline requirements in agreement with the QA team. 15:58 marcelr but is not a coding rule 15:57 cait hm what about 15:57 Joubu anyway 15:57 Joubu it did not fit the requirements, *we* agreed to let it pass 15:57 pianohacker it's an existing habit, should be written down :) 15:57 Joubu What we did for the recovery pwd patchset for instance 15:57 pianohacker that's probably a good thing to put in the guideline 15:57 Joubu I'd ask for another QA POV in this case, so I won't be alone 15:56 cait it's adifference indeed 15:56 marcelr the one doing the qa 15:56 marcelr Joubu: member is the member at hand 15:56 cait qa team members? 15:56 Joubu The 's' is important I think 15:56 cait pianohacker: ah right - can say 'yes' 15:56 bag :) 15:55 khall pianohacker is correct 15:55 bag yes sounds about right khall 15:55 pianohacker khall: is that what you had in mind? 15:55 pianohacker cait: my understanding of the wording (which I think should be slightly clarified) is that QA team members can choose to say _yes_, not no, on grandfathered patches 15:55 marcelr yeah there are more 15:54 Joubu +1 #QA team member*s* 15:54 marcelr +1 for XXX :) 15:54 cait do we want to keep it that way? so i can say 'no'? :) heh 15:54 tajoli +1 15:54 cc +1 15:54 barton +1 15:53 khall +1 15:53 cait for the XXX rule - at the discretion of the qa team member... 15:53 cait #agreed PERL16 - Modules in the Koha namespace should be object oriented when possible, using Koha::Object(s) as a preferred base. PERL16.1 - If an Koha::Object already exists, use it instead of other methods of table CRUD. 15:53 tajoli +1 15:52 bag +1 15:52 tcohen +1 15:52 Joubu +1 15:52 indradg +1 15:52 cc -1 15:51 barton +1 15:51 kidclamp +1 15:51 pianohacker +1 15:51 marcelr +1 15:51 khall +1 15:51 cait ok, voting on PERL16/16.1 please 15:51 cait no comments? 15:51 khall twice 15:51 khall going once 15:50 cait don't go quiet... 15:50 cait any comments? 15:49 pianohacker seems reasonable 15:49 cait pianohacker: i hope not, but probably will do so when the problem arises :) 15:49 pianohacker cait: are there any patches old enough that we should do some wiki archeology to figure out the date-added of the existing rules? 15:48 khall but that's implied 15:48 khall also, we'll want to put the date on new rules from now on 15:48 khall XXX - Patches submitted before the introduction of a new rule may pass qa even if they do not meet the current coding guidline requirements of the discretion of the QA team member. 15:47 khall PERL16.1 - If an Koha::Object already exists, use it instead of other methods of table CRUD. 15:47 khall PERL16 - Modules in the Koha namespace should be object oriented when possible, using Koha::Object(s) as a preferred base. 15:47 khall cait: I was just going to paste them here 15:47 cait yes, where? 15:47 khall cait: I've got those writeups, should we do a quick review / vote? 15:47 barton cait++ 15:46 cait pianohacker: will return to all the 'write up somethings' at the end 15:46 pianohacker sorry, just missed timing :) 15:46 cait i think this is pretty clear 15:46 pianohacker while it sounds like we're pushing the K::O discussion to the mailing list, should we vote on the grandfather rule here and now? 15:46 cait [marcelr] New modules should be added if possible into the new Koha namespace (and not in C4). 15:46 cait moving on to next opic for now 15:45 cait thx 15:45 khall cait: will do 15:45 cait but again, i need someone to write it up - the grandfather rule 15:45 cait i'd like to stick with +1 actually, becuase it's a littler faster today 15:43 cait formal vote or +1? 15:43 marcelr ... for exceptions to this rule we need convincing arguments for using or skipping DBIx/Koha::Object 15:43 wahanui vote is probably going to the list regardless of what we decide 15:43 tcohen vote? 15:42 pianohacker cait: agreed 15:42 cait or 'grandfather rules stated below applies' or whatever 15:42 Joubu and with "feel free to provide an alternative if you are not convinced with this one" clause? :) 15:41 cait my suggestion woudl be: we should state the date and the meeting in the guidelines added clearly. Then we can say, code submitted before guidelines with a clear 'start from' date is still ok 15:41 marcelr probably 15:41 marcelr grandfather is implicit for more rules 15:41 cait the grandfather clause 15:41 cait moving on for now 15:40 cait thx 15:40 cait and with a clear escape clause - as the proof might be in the code... i don't know 15:40 cait that someone will udnerstand outside of this meeting 15:40 khall cait: ok, I'll get something written right now 15:40 cait i'd like something a bit more polished in full sentences for the wiki:) 15:40 tcohen period 15:40 tcohen it's the RM call 15:39 Joubu pianohacker: yep 15:39 tcohen no one answers, deve does what he wants 15:39 khall it's simple enough 15:39 khall cait: I think we can vote on what you just wrote 15:39 tcohen the worse situation we've seen is starvation 15:39 pianohacker Joubu: and http://koha.1045719.n5.nabble.com/Koha-and-DBIC-td5811156.html ? 15:39 Joubu yep 15:39 wahanui well, koha-devel is most likely the best koha list there is (Hey, Im a bot, im biased) and can be found at http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel 15:39 tcohen koha-devel 15:39 pianohacker what Joubu said 15:39 tcohen arguments against an approach supporting the other will raise, win-win situation 15:38 Joubu "core team" needs to be defined 15:38 pianohacker Joubu: are you referring to http://koha.1045719.n5.nabble.com/Koha-Object-td5848332.html ? 15:38 cait again, someone willing to draft? 15:38 tcohen i think every medium sized project for improving Koha (new module) should be discussed with the core team so (without interfering) we agree on different alternative approaches 15:38 khall that sounds reasonable and good to me! 15:38 cait ? 15:38 cait ß 15:38 cait - use preferrably 15:38 cait - use where an Object already exists 15:37 marcelr pianohacker: nobody tends to provide the args 15:37 cait maybe we coudl summarize 15:37 pianohacker marcelr: basically every rule has that escape, out of necessity, but I agree :) 15:37 khall marcelr++ 15:37 marcelr i would prefer a rule now with an escape for convincing arguments to qa/rm 15:36 Joubu then "Koha::Object" on July 2015 15:36 marcelr that discussion never reached a good conclusion iirc 15:36 Joubu you can refer to "Koha and DBIC" from Septembre 2014 on Koha-devel 15:36 cc I've never seen a convincing rationale for using them 15:35 marcelr it was not decided yet 15:35 bag I was under that thought too - the defacto 15:35 khall The defacto recently has been to use Koha::Object(s) 15:35 Joubu cait: yes, everybody has doubts about Koha::Object, but nobody never provided either a an alternative or valid arguments not to use it 15:35 pianohacker cait: yes 15:34 pianohacker not to pick on Joubu, just to point out what I mean 15:34 khall I'd like to understand cc's doubts. I don't think we've heard anything against from anyone else 15:34 cait so where a Koha::Object module exists - use that? 15:34 cait I think there are still some doubts about Koha::Object - see cc's comment, so giving some room to move would be good 15:34 huginn` 04Bug 14659: enhancement, P5 - low, ---, jweaver, Needs Signoff , Allow patrons to enter card number and patron category on OPAC registration page 15:34 pianohacker cait: for context: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14659#c4 15:33 cait I am sorry, I got a bit lost 15:32 pianohacker cait: Perhaps to enforce usage where a Koha::Object already exists, to match what is current QA practice? 15:32 marcelr the rule under discussion 15:32 cait marcelr: sorry, not sure i understand - the rule about not using in .pl files? 15:32 marcelr cait: maybe add the DBIx rule with some clause that we need good arguments to bypass it or so 15:32 khall pianohacker: seems that way 15:31 pianohacker And PERL12, by its own admission? 15:31 cait I am not sure if I remember correctly, but I think we didn't vote to enforce Koha::Object and agreed not to use DBIx in .pl files directly 15:31 khall Joubu is right about PERL11 15:30 cait let me read back a second for the dbix discussion 15:30 bag +1 15:30 cait actually removing ws a later topic, i just jumped into as we were already discussing it 15:30 cait #agreed PERL18 and PERL19 to be removed, as the deprecated modules are no longer part of the codebase (C4::Dates and SQLHelper) 15:30 Joubu (add PERL11 to the list) 15:30 cc Performance, aldo negates some of the benefits of DBIIx::Class by obscuring the interface to the returned objects with an extra layer - it seems to add code rather than functionality 15:29 indradg +1 15:29 talljoy +1 15:29 kidclamp +1 15:29 barton +1 15:29 jajm +1 15:29 tajoli +1 15:29 Joubu +1 15:29 khall +1 15:29 pianohacker +1 15:29 cait +1 15:29 cait one is C4::Dates deprecated, the other SQL::Helper 15:29 marcelr +1 15:29 cait can we agree on removing those right away? 15:29 tcohen +1 15:28 khall agreed 15:28 Joubu and* 15:28 Joubu PERL18 a PERL19 should be removed, yes 15:28 tcohen pianohacker: khall: I agree 15:28 cait cc: can you detail the problems you encountered ? 15:28 cait SQLHelper is no longer part of the codebase 15:28 pianohacker what khall said 15:27 khall tcohen: that's the situation we should avoid. It's better to give devs the info they need to write it correctly the first time 15:27 cait Joubu: correct - so that's not ideal... but i suggest removing the PERL19 entirely 15:27 Joubu cait: this page has not been updated 15:27 pianohacker yup, we need something stronger 15:27 tcohen i'd leave it as a de-facto coding guideline, and let the RM have the last call on each situation 15:27 marcelr i remember that this was not a decision 15:27 cait the lin goes here: https://wiki.koha-community.org/wiki/Examples_of_DBIC_in_Koha 15:26 cait hm we only have this in the coding guidelines: PERL19: The use of C4::SQLHelper module is deprecated C4:SQLHelper has been superseded by DBIC (examples), please use this instead. 15:26 khall marcelr: Koha::Object(s) is what came out of that discussion 15:26 Joubu lot* 15:26 Joubu especially because we will get ot of example 15:26 marcelr we had this discussion before about allowing DBIx in all modules or not 15:26 Joubu it will be more and more easier for devs to use it 15:26 Joubu it's not possible to force people using dbix::class, but we get more and more module using Koha::Objects in the Koha namespace 15:26 barton grandfather clause: a case that violates the proposed rules, but will be allowed because it's already there. 15:25 khall for older patches, we can give them more latitude 15:25 khall cait: meaning these new rules affect only patches submitted after the rules were voted in 15:25 pianohacker agreed, there's a lot of precedent for that 15:25 cait can you quickly explain a grandfather clause? :) 15:25 cc I'm very unpersuaded by Koha::Objects in their current form 15:25 khall to give them some leeway 15:25 cait khall: ? 15:25 khall cait: I think we should add a grandfather clause for all new rules 15:25 tajoli #info Zeno Tajoli, CINECA, Italy 15:24 cait i think we can say DBIx before SQLfor sur, but not sure about enforcing Koha::Object for everything 15:24 cait the problem is that we have patches of different 'age' sitting in the queue 15:24 cait hm in part 15:23 pianohacker I think the above has been so strongly enforced on new patches that it's a de facto coding guideline 15:23 cait there are some rules about use of SQL in the current coding guidelines 15:23 cait [marcelr] What about DBIx, Koha::Object versus old school MySQL statements in code ? [khall] I think the use of direct DBIx should be deprecated in favor of Koha::Object, and direct sql statements should be limited to queries that don't work well with the object model 15:22 cait moving on to the next item for now 15:22 cait thx 15:22 pianohacker #action pianohacker will draw up a draft of a coding guideline regarding global variables in modules/CGI scripts, see https://perl.apache.org/docs/general/perl_reference/perl_reference.html#my____Scoped_Variable_in_Nested_Subroutines for context 15:21 marcelr ok 15:21 cait marcelr: I thought adding the addtional remarks to it as discussed 15:21 pianohacker cc: https://perl.apache.org/docs/general/perl_reference/perl_reference.html#my____Scoped_Variable_in_Nested_Subroutines <- for context 15:20 marcelr from the agenda 15:20 cait just to summarize the discussion here in a short form 15:20 pianohacker I volunteer 15:20 cait marcelr: hm? 15:19 cait a coding guideline: :) 15:19 marcelr cait: i think we already had a draft 15:19 pianohacker cait: either way, sure 15:19 tcohen cc: +1 15:19 pianohacker cait: does the above work, or are you talking in the form of a coding guideline 15:19 cait pianohacker: can you wite a draft that we can review later? 15:19 cc Document what the issue is with plack lets try and minimise "magick" 15:18 * cait volunteers pianohacker 15:18 marcelr i think that we all understand exceptions for EXPORT etc. 15:18 jajm that sounds right pianohacker 15:18 cc lots of modules thouch EXPORT for good reasons 15:17 pianohacker jajm: I'd say so. Forbid state globals in modules/CGI scripts as it causes issues with plack, and discourage them in other places for style reasons? 15:17 cait again, someone willing to make a draft? I am eager on an #action :) 15:17 tcohen cc: forbid touching VERSION and EXPORT could be another rule :-P 15:16 cc VERSION and EXPORT are not readonly 15:16 jajm pianohacker, tcohen, ok, so forbid global variables that are storing state ? 15:16 pianohacker cc: huh? 15:16 * ashimema will read the minutes 15:16 cc no they can be manipulated at runtime 15:15 barton #info Barton Chittenden, bws, Louisville, KY, USA 15:15 * ashimema has gotta go collect kids.. sorry for me absence.. again! 15:15 tcohen jajm: but they are not storing state 15:15 pianohacker jajm: those are read-only, though, correct? 15:15 marcelr obviously 15:15 jajm i believe global variables can't be completely avoided in modules (for instance $VERSION, @EXPORT, ...), so why forbid it ? 15:14 cait would someone be willing to work out a draft? 15:14 cc yes 15:14 pianohacker cc: to clarify, by "scripts which will never be used by plack", do you mean things like cronjobs? 15:13 cc A good guideline would be to discourage globals where possible 15:13 Joubu There is no new things, we just need to update the wiki page 15:13 cait or a scope where this applies? 15:13 tcohen who likes global variables in modules? 15:13 cait ok, so shoudl we note exceptions? 15:13 Joubu I almost agree with everything too 15:13 khall I totally agree 15:13 tcohen :-P 15:12 tcohen I agree with the proposal, as it is also a clearer way to program 15:12 bag examples are good :) 15:12 cc It would be more useful yo explain the rational behind this than to make it a rule it dosent apply to scripts which will never be used by plack 15:12 marcelr the first part needs some common sense 15:12 cait i am a bit out of my depth here - any comments, questions? 15:11 ashimema #info Martin Renvoize, PTFS Europe 15:11 ashimema ooh.. meeting 15:11 cait I'd suggest that ideally all additions to the coding guidelines should include a good/bad example if possible 15:11 marcelr first part is less mandatory than the second part, i guess 15:11 cait #info [marcelr] In relation to Plack: Should we add a PERL rule that prohibits defining lexical variables (my $var) in MODULES at the outermost block (file level), and also prohibits directly accessing file level lexicals in subroutines of SCRIPTS. 15:10 cait let's start with the first item 15:10 cait I will go through them by sequence, but we have to watch the time a bit today with our long agenda 15:10 cait we have a lot to get through in this meeting, for some topics i think we can only start discussion and will need a draft to vote on next 15:09 cait I have tried to group the various topics a bit - I hope people are ok with it :) 15:09 cait #topic Review of Coding guidelines 15:09 bag if I miss something - just shoot me an @later and I’ll get on it 15:09 cait ok, let's move to our first big topic 15:09 bag that is it for me - I will keep pushing what I see from PQA 15:08 cait #info Elastic search branch: remotes/origin/new_12478_elasticsearch 15:08 bag yes ^^ 15:08 Joubu the branch is named remotes/origin/new_12478_elasticsearch 15:08 cait #link https://wiki.koha-community.org/wiki/Elasticsearch 15:08 bag so that I start to hopefully clean up the tests and get master to be passing stable on jenkins 15:08 tcohen thanks cait 15:07 cait I think there is a page on the wiki with some notes at least 15:07 * bag will catch up with tcohen sometime this week to get some more lessons - especially with jenkins and packaging 15:07 wahanui instructions are coming right now to the wiki near you or at http://i.imgur.com/oyZhY.jpg 15:07 tcohen instructions? 15:07 cait #info Elastic search needs testing as well - please use the branch on the main repository 15:07 indradg #info Indranil Das Gupta, L2C2 Technologies 15:07 bag kc :) 15:07 bag there is a branch in kc 15:07 Joubu kc 15:07 cait catalyst or kc? 15:07 cait bag: which branch is recommended for testing? 15:06 bag Still looking for more testers of Elastic Search 15:06 bag yes :) awesomeness 15:06 cait #info XSS patches were pushed, please test and help to find any remaining problems 15:06 Joubu (there is one already, patched, passed qa) 15:06 bag the web-installer needs some touch up - but I think mtompset caught some of that 15:05 bag pushed the XSS so please test test that and let’s see if we can find any missing spots 15:05 bag Currently few notes 15:05 cait RM notes? :) 15:04 cait before we start with the topics on the wiki - any announcements? 15:04 bag hi mirko not really here :D 15:04 NateC #info Nate Curulla, BWS 15:04 khall #info Kyle M Hall, Bywater Solutions 15:03 tcohen #info Tomas Cohen Arazi, Theke 15:03 drojf2 #info mirko tietgen, not really here 15:03 kidclamp #info Nick Clemens, ByWater Solutions, USA 15:03 cc #info Colin Campbell, PTFS-Europe 15:02 bag #info Brendan Gallagher ByWater 15:02 andreashm #info Andreas Hedström Mace, Stockholm University Library 15:02 marcelr #info Marcel de Rooy, Rijksmuseum, Netherlands 15:02 matts #info Matthias Meusburger, Biblibre, France 15:02 Joubu #info Jonathan Druart 15:02 jajm #info Julian Maurice, BibLibre, France 15:02 talljoy #info Joy Nelson, ByWater Solutions, USA 15:02 cait #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_2_February_2016 15:01 pianohacker #info Jesse Weaver, ByWater Solutions, USA 15:01 oleonard #info Owen Leonard, Athens County Public Libraries 15:01 cait #info Katrin Fischer, BSZ, Germany 15:01 cait Please introduce yourself using #info like wahanui just did 15:01 wahanui #info wahanui, a bot that has become sentient 15:01 cait #topic Introductions 15:01 huginn` The meeting name has been set to 'developer_irc_meeting__2_february_2016' 15:01 huginn` Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01 huginn` Meeting started Tue Feb 2 15:01:10 2016 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01 cait #startmeeting Developer IRC Meeting, 2 February 2016 15:01 cait ok, about to start the meeting, get ready everyone :) 15:00 cait https://wiki.koha-community.org/wiki/Development_IRC_meeting_2_February_2016 15:00 cait one sec 15:00 cait yes 15:00 oleonard Is there an agenda? 14:58 andreashm haha 14:57 pianohacker strong coffee 14:56 cait ... and coffee/tea... etc. 14:56 cait get out your notes everyone 14:55 cait t-5 minutes 14:53 talljoy ha 14:51 oleonard You're in luck wahanui, this meeting may kill it! 14:50 wahanui the only good morning is a dead one 14:50 bag good morning 14:45 andreashm hi marcelr 14:45 marcelr hi #koha 14:34 * magnuse will be eating dinner during the dev meeting, then 14:08 cait yes 14:08 oleonard dev meeting in just under one hour? 13:41 tcohen let me ask him 13:41 tcohen i'm not sure 13:40 oleonard Hi tcohen. Do you know if nengard was able to get in touch with bgkriegel? 13:38 tcohen morning 13:25 huginn` 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15106 enhancement, P5 - low, ---, koha-bugs, Needs Signoff , Batch Patron Modification Performance Improvement 13:25 oleonard Who worked on Bug 15106? I don't recognize the name. 13:07 kidclamp hi oleonard 13:05 oleonard Hi #koha 12:50 cait morning tcohen :) 12:22 tcohen morning 11:17 Monis1 hi all 10:24 * mveron waves 10:21 * magnuse waves 10:19 * Francesca waves 09:58 mveron-away Hi #koha 09:32 * magnuse could not imagine life without servers 09:04 cait hm reminds me... i should look into getting a server again probably 09:03 paul_p :D 09:03 paul_p yikes, much more than 15 : 15.99€ !!! 09:03 paul_p cait 15€ for one month. paying now ;-) 09:01 cait or be safe with another month :) 09:01 cait maybe sent him a twitter dm or email instead 09:01 cait hi paul_p ;) 09:00 * paul_p feel he will take another month. Not a big expense. 08:59 * paul_p has seen tweets about the conf 08:59 paul_p well, in fact, it's a better TZ for us in AUS. But he may be AFK... 08:59 paul_p :( 08:59 paul_p hi cait 08:59 Joubu hi #koha 08:59 cait paul_p: he is in australia at a conf at the moment - so different timezone than usual 08:56 paul_p rangi = are you around & available ? the "old" jenkins server will be switched off in a few minutes by our provider, I'd like so see if I renew it for 1 month or not. The only missing thing is the DNS change AFAIK 08:42 cait magnuse: it appears so... 08:25 magnuse cait: that does tend to make things more permanent, yes 08:15 gaetan_B hello 08:12 cait wiki editing works better when you actually save your changes... *sigh* 08:06 cait me waves 08:00 wahanui bonjour, alex_a 08:00 alex_a bonjour 07:40 reiveune hello 06:55 * cait waves back 06:48 * magnuse waves 05:28 mtompset Have a good day (24 hour period), #koha. 04:41 huginn` mtompset: The operation succeeded. 04:41 mtompset @later tell khall git grep uniout only shows that one line of code. Throwing 'my' on it only masked a larger problem. I can't find a definition even back to 3.0.x 01:51 mtompset Is there any benefit to "use Foobar;" when neither foo nor bar are used at all in the code? 01:43 kathryn we can fill the room just with locals :) 01:41 kathryn no, we mostly invited people via local library mail lists 01:41 mtompset But I'm not sure people from India or the Philippines would be able to come on such short notice and so far away. :) 01:41 kathryn thanks heaps! 01:41 mtompset I've posted it to two others that I know about. :) 01:38 kathryn I didn't have to look far 01:37 kathryn oh it's nicole 01:37 kathryn ^ I was on that one 01:37 kathryn https://www.facebook.com/kohails/info/?tab=page_info 01:37 kathryn all sharing is welcome 01:37 kathryn Just trying to put the word out 01:36 kathryn ohhh hmmn true..the best one? :) 01:36 mtompset which one, kathryn? 01:35 kathryn hi, does anyone admin the Koha facebook account? I wondered if they would be able to post about this event https://www.catalyst.net.nz/training/course/intro-koha-library-management-system-melbourne 01:12 mtompset http://ccsr.qc.ca/ 00:59 dan_ pianohacker: Thank you very much for your answer 00:59 dan_ pianohacker: Indeed, we have not met. I'm just an occasional visitor of this channel, whenever I have exhausted all my solving resources 00:51 pianohacker dan_: hi, by the way, don't think we've met 00:51 pianohacker I can't remember what we called the themes in Koha 2, those are old dark memories 00:50 pianohacker dan_: according to git, we only finally got rid of it in 3.18 00:48 dan_ That was previous to Koha 3, isn't it? I really didn't know it 00:45 pianohacker dan_: it was the name of an old theme for the Koha OPAC 00:40 huginn` 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11347 normal, P5 - low, ---, oleonard, CLOSED FIXED, PROG/CCSR deprecation: Remove opacsmallimage system-preference 00:40 dan_ In bug titles as "Bug 11347 - PROG/CCSR deprecation: ...", someone could tell me what's the meaning of the abbreviation 'CCSR', please? 00:40 talljoy hiya 00:39 dan_ Hi people