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