19:02:59 <cait> #startmeeting Development IRC Meeting 16 February 2016
19:02:59 <huginn> Meeting started Tue Feb 16 19:02:59 2016 UTC.  The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:59 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:59 <huginn> The meeting name has been set to 'development_irc_meeting_16_february_2016'
19:03:03 <cait> #topic Introductions
19:03:04 <wahanui> #info wahanui, a bot that has become sentient
19:03:07 <tcohen> #info Tomas Cohen Arazi, Theke Solutions
19:03:10 <kyr> been using koha on ubuntu via package instalation. want to stay on 3.18.11 atm but the "oldstable" has been changed to 3.20. So, if i i apt-upgrade it will install 3.20 (scary on my wanna be production system without any testing). Any straightforward way to stick to 3.18 (and be able to update to say... 3.18.13 and so on)?
19:03:11 <cait> please introduce yourself following wahanui's example
19:03:18 <oleonard> #info Owen Leonard, Athens County Public Libraries
19:03:18 <nengard> #info Nicole Engard, ByWater Solutions
19:03:26 <bag> #info Brendan Gallagher, ByWater
19:03:27 <kyr> ooops, was typing while you told me to wait :S
19:03:32 <magnuse> #info Magnus Enger, Libriotech, Norway
19:03:34 <jajm> #info Julian Maurice, BibLibre
19:03:41 <barton> #info Barton Chittenden, Bywater, Louisville, KY, USA
19:03:42 <cait> today's agenda can be found at
19:03:45 <cait> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_16_February_2016
19:03:58 <talljoy> #info JOy Nelson ByWater Solutions USA
19:04:05 <tcohen> hm, nicole and brendan messages asre suspiciously aligned
19:04:10 <pianohacker> oh hey meeting
19:04:25 <pianohacker> #info JEsse Weaver ByWater Solutions USA
19:04:52 <mtompset> #info Mark Tompsett
19:05:06 <cait> #info Katrin Fischer, BSZ, Germany
19:05:21 <barton> pianohacker does the studlyCAps.
19:05:34 <indradg> #info Indranil Das Gupta, L2C2 Technologies, India
19:05:46 <bag> bbias
19:05:59 <cait> RM runs away... :)
19:06:17 <cait> should we do a round of announcements?
19:06:18 <tcohen> just in time ;-)
19:06:42 <blou> #info Philippe Blouin, Solutions inLibro
19:06:58 <huginn> New commit(s) kohagit: Bug 11081: (followup) Rebuild debian/control <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=43bcc1c42cd347ab1565b27038ec3350a1ecf94f>
19:07:13 <pianohacker> brb
19:07:14 <cait> noone is speaking up
19:07:19 <cait> more running away...
19:07:25 <cait> let's move to thenext topic
19:07:31 <tcohen> I want to mention something i'm working on
19:07:36 <cait> aah
19:07:40 <cait> #topic Announcements and news
19:07:41 <tcohen> but maybe "big sutff..." ?
19:07:48 <tcohen> ok
19:07:53 <cait> use the opportunity and say it now :)
19:08:03 <bag> back
19:08:10 <tcohen> I'm working on some classes for handling Koha instances
19:08:35 <tcohen> the idea is to fully rewrite the CLI scripts with that
19:08:52 <tcohen> it should make life easier for rollback, recover, etc
19:09:14 <tcohen> it will also make Koha instances aware of their creation options
19:09:18 <kidclamp> #info Nick Clemens, ByWater Solutions
19:09:29 <tcohen> it should make maintenance easier
19:09:33 <cait> #info tcohen is woring on classes for handling Koha instances
19:09:48 <tcohen> read: upgrade path would be more manageable when adding new entries to the config file, etc
19:09:48 <barton> tcohen: do you have a bug number for that?
19:09:53 <tcohen> barton, I don't :-D
19:09:59 <mtompset> tcohen: How would that affect bug 15088?
19:10:00 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15088 enhancement, P5 - low, ---, gmcharlt, Needs Signoff , Notice when koha has been installed with --request-db instead of --create-db
19:10:01 <tcohen> it will be several of them
19:10:11 <cait> maybe a wiki page?
19:10:15 <tcohen> yes
19:10:34 <tcohen> mtompset: i haven't looked at it, but it could merge what's done there, at some point
19:11:03 <mtompset> I was just about to test an sign off. :)
19:11:10 <larryb> tcohen, if you're working on the maintenance scripts, I have a suggestion
19:11:45 <larryb> can we make the instance maintenance mode a flag, like for email, instead of editing and looking at the apache config files?
19:11:46 <tcohen> i would also like to mention it is also in line with srdjan's work
19:11:59 <tcohen> larryb, that's the whole point :-D
19:12:02 <larryb> cool
19:12:20 <tcohen> i'll put a YAML file for CLI controled options
19:12:21 <cait> #idea make maintenance mode a flag, like for email
19:12:42 <tcohen> and will probably migrate the koha-conf.xml entries there too, at a later stage
19:12:51 <tcohen> as rangi always says, step n
19:12:54 <tcohen> by step
19:12:57 <larryb> the other issue I often run into is I put a site into maintenance, so that visitors get that page, but then I can't actually do anything to the site, like upgrade it or run a rebuild, because those don't run against instances in maintenance
19:13:24 <tcohen> the idea is to make things more solid
19:13:35 <tcohen> less error prone, etc
19:14:06 <barton> plus 1.
19:14:18 <tcohen> ok, that's it
19:14:23 <cait> thx tcohen
19:14:26 <tcohen> i will write some stuff on the wiki
19:14:29 <cait> bag: something from the RM?
19:14:30 <larryb> thanks
19:14:34 <tcohen> and fill several interdependent bugs
19:14:38 <cait> #action tcohen to write up a wiki page
19:14:43 <bag> not much of an update
19:15:00 <bag> I have a little catch up to play in the next 2 weeks :)  get the queue low again
19:15:11 <cait> #action tcohen to write up a wiki page ... about using classes for handling Koha instances
19:15:27 <bag> As always I’m looking for people to test Elastic Search - I’d love to keep moving on that
19:15:48 <cait> #info People needed for testing Elastic search!
19:15:55 <cait> is there a public test instance available at the moment?
19:16:06 <bag> yes
19:16:14 <cait> link? :)
19:16:31 * bag looking for it
19:16:43 <pianohacker> demi-RM note: I'm learning a lot of the RM stuff on my feet (making DB updates, etc.) so don't be afraid to check my work and let me know if I make a mistake :)
19:17:29 <tcohen> pianohacker++
19:17:33 <fredericd> #info Frédéric Demians, Tamil (passing through)
19:18:12 <cait> I suggest we will see how far we get until about :45
19:18:15 <mtompset> pianohacker++ # willing to accept feedback -- awesomeness. :)
19:18:17 <cait> with the coding guidelines
19:18:37 <cait> so some time is left for the topics at the end this time
19:18:44 <pianohacker> +1 to that
19:18:59 <cait> might need to push something to next meeting again, but we will see how it goes
19:19:03 <pianohacker> cait: want to start with followups from last time?
19:19:14 <cait> i tihnk they are at the top anyway
19:19:17 <pianohacker> kk cool
19:19:35 <bag> #link http://elasticsearch.koha.catalystdemo.net.nz/
19:19:43 <cait> ah
19:19:45 <cait> now we can move on
19:19:51 <cait> #topic Review Coding Guidelines
19:19:59 <cait> the current coding guidelines can be found at
19:20:08 <cait> #link https://wiki.koha-community.org/wiki/Coding_Guidelines
19:20:31 <cait> Please refresh the wiki page if you have the agenda already open
19:21:07 <cait> the suggested wording for the new "Code plack friendly" guideline is:
19:21:08 <cait> Forbid global state variables in modules and CGI scripts, and discourage their use elsewhere. (see https://perl.apache.org/docs/general/perl_reference/perl_reference.html#my____Scoped_Variable_in_Nested_Subroutines for context)
19:21:27 <cait> i think most rules coudl do with some examples, but let's vote on the basic wording?
19:22:04 <cait> i suggest to keep it simple again today with a +1 indicating a yes, -1 for no and 0 for... <fill in the english word i forgot>
19:22:09 <pianohacker> neutral?
19:22:20 <mtompset> abstain?
19:22:23 <cait> ah abstain
19:22:24 <cait> yep
19:22:26 <nengard> :)
19:22:37 <pianohacker> ah that's better
19:22:46 <cait> i think both are valid
19:23:03 <cait> any change requests on the wording?
19:23:12 <pianohacker> cait: I think the link is probably better than an example, as  it has examples there and the issue is subtle
19:23:19 <cait> ok
19:23:34 <cait> i am +1
19:23:35 <cait> :)
19:23:37 <mtompset> I'm +1 for it as is.
19:23:50 <cait> please vote
19:24:13 <barton> +1
19:24:28 <mtompset> +1
19:24:31 <pianohacker> +1
19:24:34 * cait hands out some coffee
19:24:44 <kidclamp> +1
19:24:49 * nengard prefers tea :)
19:24:51 <talljoy> +1
19:24:54 <nengard> +1
19:25:01 * cait hands out some tea too
19:25:12 <nengard> :)
19:25:15 * mtompset grins at nengard, "I was thinking that too."
19:25:18 * barton hands out chocolate.
19:25:21 <nengard> oooo ....
19:25:24 <cait> ok, ending vote :)
19:25:25 <cait> #agreed New coding guideline "Code Plack friendly". Wording: Forbid global state variables in modules and CGI scripts, and discourage their use elsewhere. (see https://perl.apache.org/docs/general/perl_reference/perl_reference.html#my____Scoped_Variable_in_Nested_Subroutines for context)
19:25:31 <pianohacker> dirty chais with chocolate, everybody!
19:25:44 <cait> the next point on the agenda is a suggested workflow for handling disagreements
19:25:47 <mtompset> barton: Is it http://www.awakechocolate.com/?
19:26:14 <pianohacker> proposed wording at http://paste.koha-community.org/309 , but the basic idea is to close the feedback loop between coding style concerns and the coding guidelines
19:26:19 <barton> mtompset: that looks like it would do the trick.
19:26:22 <cait> pianohacker: we should move from the paste to the wiki later maybe - paste gets lost when the server is restarted
19:26:35 <cait> I'd like to suggest a generalisation
19:26:40 <pianohacker> cait: agreed, just couldn't figure out how to do so on the agenda with decent formatting
19:26:43 <cait> this is about the qa team member vs dev currently
19:27:10 <mtompset> While I think it is a good idea. The problem I've found is sometimes I seek feedback on the mailing list and get none.
19:27:21 <cait> i tihnk maybe we could say 'community member' and developer?
19:27:32 <pianohacker> cait: that's a good idea
19:28:10 <mtompset> But then again, I'm assuming it is a QA person doing the seeking not the community member?
19:28:13 <cait> it says mailing list - should we include dev meetings too?
19:28:28 <pianohacker> cait: I'd say mailing list then bump to dev meeting if no response
19:28:29 <cait> mtompset: i was thinking if the first tester disagrees
19:28:42 <nengard> that makes sense pianohacker
19:28:45 <cait> can we bring the dev meeting into it some way?
19:28:48 <pianohacker> cait: why the first tester specifically?
19:28:49 <cait> into the wording?
19:28:53 <cait> not especially
19:28:56 <cait> just another possibility
19:29:03 <cait> the potential sign offer looking at it
19:29:13 <cait> before qa
19:29:18 <cait> or just someone interested in the development
19:29:27 <pianohacker> cait: I think if we generalize it to "any community member" as you suggested that takes care of that
19:29:29 <cait> i just didn't want ti limit it to disagreement between qa/dev
19:29:33 <cait> yep
19:30:23 <mtompset> I concur, "any community member", if we are trying to include those who sign off as well.
19:30:40 <pianohacker> so, to formalize what we've said:
19:30:56 <pianohacker> Amend the first part of the wording to "If a community member has concerns with a patch that:"
19:31:05 <cait> then the patch and concern should be brought up on the development mailing list _and/or the developer irc meeting_ so a new coding guideline can be added. ?
19:32:05 <pianohacker> that seems reasonable
19:32:14 <mtompset> Something like that. Can we get an amended paste, so those of us who are visual can see it all. :)
19:32:20 <pianohacker> mtompset: one sec
19:33:01 <pianohacker> I'm also simplifying "patch and concern" to "concern"
19:33:51 <pastebot> Someone at 127.0.0.1 pasted "new wording" (13 lines) at http://paste.koha-community.org/310
19:34:40 <cait> can we vote?
19:34:53 <mtompset> I think so.
19:34:58 <cait> ok, please vote :)
19:34:59 <mtompset> +1 for the amended version.
19:35:00 <pianohacker> +1
19:35:01 <oleonard> +1
19:35:04 <nengard> +1
19:35:05 <cait> +1
19:35:06 <kidclamp> +1
19:35:06 <jajm> +1
19:35:08 <tcohen> +1
19:35:20 <talljoy> +1
19:35:31 <tcohen> gotta run, sorry!
19:35:44 <mtompset> Take care, tcohen
19:36:42 <cait> #agreed New coding guideline for handling disagreements: If a community member has concerns with a patch that: * Are specifically about coding style (not stated functionality or regressions in other code) * Are not covered by an existing coding guideline - then the patch and concern should be brought up on the development mailing list and/or next development IRC meeting so a new coding guideline can be added. (Rationale: While it is reasonable for c
19:36:51 <cait> sorry for the messsy paste
19:36:59 <cait> but the paste is not safe, so i wanted to have it in the logs
19:37:13 <cait> so we got time for one more i hope
19:37:42 <cait> [khall] All methods should take a single argument, bit it an object, an  id, or a hashref. This makes future modification of parameters for  subroutines far simpler and less error prone, and reduces the changes  needed.
19:38:14 <cait> this is a new one - while the last 2 were follow-ups from last meeting i think
19:38:19 <cait> or more we didn't get to discuss it last time
19:38:30 <cait> please discuss :)
19:38:55 <mtompset> I'm not sure how an id might allow for future proofing, where as objects and hasrefs are self-evident.
19:39:16 <pianohacker> I've run into enough pain with the positional style that I like this idea
19:39:20 <cait> i think the id would be something like an itemnumber, issue_id or similar
19:39:25 <pianohacker> mtompset: I think that's there as a sanity escape hatch
19:39:32 <cait> but it might cause problems when a second parameter is added maybe? not sure
19:39:40 <pianohacker> there's some methods that won't ever need more than that, like Koha::Objects->fetch
19:40:07 <pianohacker> but I think it's worth codifying that if you need two or more, just use named arguments
19:40:18 <pianohacker> otherwise you get a ModBasketHeader or AddReserve mess
19:40:37 <cait> do those requiere parameters in sequence?
19:40:44 <pianohacker> ohhhhh yeah
19:41:14 <pianohacker> ModBasketHeader has 8 and I have two patches to add more
19:41:23 <barton> namedarguments++
19:41:36 <mtompset> namedarguments++ # second that.
19:41:49 <pianohacker> are we ready to vote on this one?
19:41:56 <mtompset> Okay, so what we are saying is...
19:42:06 <jajm> i think we all agree we do not want another AddReserve. however should we enforce passing a hash(ref) as soon as we have two parameters ?
19:42:08 <mtompset> we don't care about the single parameter type.
19:42:17 <cait> bit it an... be it an? just for the agreed
19:42:32 <mtompset> but a second parameter must be hash ref or object?
19:42:53 <mtompset> (to keep it to only one parameter physically)
19:42:56 <cait> ihm i think we had a discussion about that we should use hashrefs
19:42:57 <cait> iirc
19:43:15 <pianohacker> mtompset: do you mean enforcing ($a, {...}) or ({...}) ?
19:43:23 <cait> i think the latter
19:43:29 <pianohacker> okay cool
19:43:45 <pianohacker> even if it kind of looks like an alien emoticon
19:43:49 <barton> yeah, good for extensibility.
19:43:54 <nengard> ha
19:43:55 <mtompset> I mean f($a)... adding $b becomes f($h{ a=> $a, b=> $b})
19:44:25 <pianohacker> jajm: how does the above look?
19:44:28 <mtj> hi folks... i kinda like the idea myself
19:44:29 <cait> hm it does... look like an alien... with helmet ears and 3 eyes
19:44:44 <nengard> :)
19:45:03 <pianohacker> cait: exactly :)
19:45:14 <cait> ok, do we have an amendment/change suggestion for hte wording?
19:45:27 <mtj> oops, i was replying to an old scollback msg - please ignore
19:45:52 <mtompset> Oh, and it says methods.
19:46:05 <cait> is that a change request? :)
19:46:18 <mtompset> methods technically have 2 parameters, self, and parameter. ;)
19:46:31 <pianohacker> mtompset: that can be clarified with an example I think
19:46:49 <barton> @examples++
19:46:50 <huginn> barton: I suck
19:46:54 <cait> i just need to know, can we vote as is or do oyu want to swtich out words? :)
19:47:24 <pianohacker> but question: if submitting a patch (after today) that would add a new parameter to a function with a bunch of positional ones, is that patch required to change the existing method to named-argument style?
19:47:30 <pianohacker> or does this only apply to new methods?
19:47:35 <pianohacker> (or functions)
19:47:49 <pianohacker> cait: I think we should correct methods to methods/functions for clarity
19:47:52 <cait> I'd like to see refactoring to be honest
19:47:53 <jajm> what about subroutines that take a list as arguments ? (like $sth->execute for example)
19:48:13 <cait> because otherwise you are just making it worse... possibly
19:48:14 <pianohacker> oh, hm.
19:48:16 <mtompset> A list is a single parameter.
19:48:24 <cait> but... might depend on the case
19:48:31 <cait> definitely for new ones
19:48:44 <pianohacker> mtompset: Perl makes that a tricky statement ;)
19:48:48 <barton> jajm -- an arrayref?
19:48:59 <mtompset> true enough, but in the simplest case, it is. :P
19:49:32 <pianohacker> cait: I'm gonna try to write up a new version that incorporates all of this
19:49:36 <cait> ok
19:49:43 <cait> i will give you 1 minute :)
19:49:46 <jajm> barton, why not, but that case should be in the guideline
19:50:06 <mtompset> but an arrayref is a single parameter.
19:50:26 <pianohacker> "All methods and functions should take a single argument: either a database ID, arrayref, or hashref with named arguments."
19:50:31 <mtompset> I think the goal is to avoid f($a,$b,$c,$d, etc. etc.)
19:50:58 <cait> ok, thx pianohacker
19:50:59 <pianohacker> (the oxford comma pains me but it's needed here)
19:51:21 <cait> please vote
19:51:26 <pianohacker> +1
19:51:30 <barton> +1
19:51:31 <nengard> +1
19:51:34 <mtompset> +1
19:51:37 <mtj> +1
19:51:41 <kidclamp> +1
19:51:47 <cait> +1
19:51:58 <talljoy> +1
19:52:09 * talljoy loves the oxford comma
19:52:10 <jajm> 0 (i don't think this is needed as a guideline, but i won't oppose)
19:52:42 <cait> #agreed New coding guideline: All methods and functions should take a single argument: either a database ID, arrayref, or hashref with named arguments.
19:52:59 <cait> we are over time - but i'd like to note something about the next one
19:53:07 <cait> [khall] I think we need something about limiting the use of the html filter to prevent XSS attacks (post Bug 13618)  [Joubu] New test added to the QA script, is it enough?
19:53:08 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13618 enhancement, P5 - low, ---, jonathan.druart, BLOCKED , Prevent XSS in the Staff Client and the OPAC
19:53:13 <drojf> #info Mirko Tietgen, broken internet connection
19:53:14 <cait> the bug sadly had to be reverted
19:53:29 <cait> hm the patches had to...
19:53:46 <cait> the general solution doesn't work - I'd be really happy if someone could write up some guidelines about when to use the |html filter
19:53:53 <bag> :(
19:53:56 <cait> to keep xss problems from happening
19:54:37 <cait> any volunteers?
19:54:40 <pianohacker> I think we need to fix the general solution... There's way too many cases where the |html filter is needed
19:55:01 <cait> not sure if we can, but it would be awesome if possible
19:55:17 <cait> from what Joubu told me it's too much of a performance hit with the number of variables on some pages
19:55:28 <cait> like it 'broke' adding an authority via z39.50 i think
19:55:45 <cait> maybe we should mov eit down to 'bugs in discussion' for next time
19:55:54 <cait> and see about other possible solutions?
19:56:14 <pianohacker> yeah
19:56:38 <mtompset> I was going to suggest reordering... because I think the Perl12 one will go quickly. ;)
19:57:01 <cait> #info General solution to prevent XSS problems (bug 13618) had to be reverted - other possible solutions to be discussed next time
19:57:17 <pianohacker> mtompset: I think we're outta time for coding guidelines for this meeting unfortunately
19:57:20 <mtompset> for the record, perlcritic doesn't complain about missing $VERSION until -2. :)
19:57:21 <cait> we said in the beginning to move topic at :45
19:57:32 <mtompset> I know.
19:57:32 <cait> that would put us to General development discusion next
19:57:34 <mtompset> :(
19:57:51 <pianohacker> mtompset: could you note that on the agenda for next time?
19:57:57 <cait> yes please
19:58:10 <cait> #action mtompset to add note about PERL12
19:58:15 <cait> :)
19:58:24 <cait> #topic General development discussion
19:58:29 <pianohacker> volunteerification complete
19:58:41 <cait> [Joubu] Merge borrowers and deletedborrowers tables
19:58:48 <cait> #link http://lists.koha-community.org/pipermail/koha-devel/2016-January/042207.html
19:58:55 <nengard> I don't understand this one ... why are we doing this? ... oh a link
19:59:14 <cait> i tihnk one of the problems is fk constraints in the database
19:59:45 <nengard> I worry that some of our larger libraries will see significant slow downs in patron management with a change like this
19:59:45 <cait> if we delete a borrower, the data is moved to deletedborrowers - so 2 tables
19:59:51 <nengard> the patron search is a sql search after all
20:00:05 <cait> some tables reference borrowers - but also contain deleted borrowernumbers
20:00:10 <cait> you can only have a FK to 1 table
20:00:11 <nengard> we have 2 tables for biblio, biblioitems, and items too
20:00:14 <cait> i hope i described that correctly
20:00:51 <pianohacker> Even having written painful reports, as barton describes, I'm still leery of this for performance and general DB cleanliness concerns
20:00:56 <cait> ... and whie we are talking about this... we really really should have a timestamp on borrowers and a script to delete from deletedborrowers after X days or at least anonymize
20:01:07 <cait> it's quit a privacy problem as is right now
20:01:43 <cait> timestamp on borrowers/deletedborrowers so it's easy to see hwen last  changed/deleted
20:01:46 <nengard> i would love that cait
20:01:51 <mtompset> Wouldn't it be better to add a "DELETED" marker on the biblio, etc., and then make the queries aware of this?
20:01:52 <nengard> i think i have a bug open about that
20:01:53 <barton> timestamp would be good.
20:02:07 <cait> yes, 2 bugs - one for the script and one ofr the timestamp :)
20:02:27 <nengard> timestamp
20:02:28 <wahanui> timestamp is usually the last time that row was touched
20:02:28 <nengard> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8926
20:02:29 <huginn> 04Bug 8926: enhancement, P5 - low, ---, gmcharlt, NEW , deletedborrowers should have a timestamp
20:02:32 <nengard> #link https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8926
20:02:33 <huginn> 04Bug 8926: enhancement, P5 - low, ---, gmcharlt, NEW , deletedborrowers should have a timestamp
20:02:40 <cait> now you beat me to it
20:02:48 <pianohacker> mtompset: my concern with that approach (which is the same as the one proposed for borrowers) is that EVERY query needs to be made aware of that
20:03:03 <pianohacker> and there's a lot of existing queries and reports out there that would have to be changed
20:03:07 <nengard> #link https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13667
20:03:08 <huginn> 04Bug 13667: enhancement, P5 - low, ---, gmcharlt, NEW , Provide script to regularly clean deletedpatrons table
20:03:09 <mtompset> But we now have Koha::Patrons.
20:03:29 <nengard> and am i wrong about the patron searching?
20:03:41 <mtompset> Yes, I see that it is a large job, but eventually shouldn't we reach there?
20:03:44 <nengard> for some schools for example, they are deleting patrons all of the time ...
20:03:53 <pianohacker> nengard: no, I think you're correct, though a periodic cleanup script helps with that
20:03:58 <cait> #info concerns about perfomance with one big table
20:04:30 <cait> pianohacker: you still might want to keep for a year - so better statistics
20:04:31 <nengard> also i should mention one other bug if we're going to do cleanups and thats the one to put patron category in stats
20:04:31 <mtompset> actually, isn't the concern too much to change if one big table?
20:04:33 <barton> we should benchmark that [not that I'm volunteering]
20:04:54 <nengard> #link https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7021
20:04:55 <huginn> 04Bug 7021: enhancement, P5 - low, ---, mathsabypro, ASSIGNED , patron category in the statistics table
20:05:07 <mtompset> Oh... right... performance... never mind.
20:05:10 <cait> #info concern, about having to change a lot of the code, sql queries etc to exclude deleted patrons etc.
20:05:20 <nengard> cause those stats need to be kept if you're going to clean out the table regularly
20:05:44 <pianohacker> I also worry about a lot of librarian concerns while reports/code is being ported over about "my patrons aren't actually deleted?!"
20:06:09 <cait> not talking about it doesn't make it much better heh
20:06:40 <mtompset> pianohacker: Yes, there is that too.
20:06:56 <barton> it might help if the borrowers table was better normalized...
20:07:14 <cait> i guess that could be a step later.. if we decide to combine
20:07:27 <cait> like borrower_phones, borrower_addresses?
20:07:33 <barton> exactly.
20:08:22 <cait> we have talked about concerns
20:08:23 <pianohacker> cait: I think this needs to be bounced back to Joubu so he can expand/clarify the problematic parts of his proposal :)
20:08:34 <cait> positive sides
20:08:35 <cait> ?
20:08:56 <cait> less complicated sql reporting?
20:08:57 <nengard> data all in one place is always easier :)
20:08:59 <nengard> yup
20:09:06 <pianohacker> aside from the reports that this makes more complicated, it makes some reports less complicated :)
20:09:11 <cait> #info plus: less complicated sql reporting
20:09:24 <pianohacker> (though snark aside, it's a net gain)
20:09:37 <cait> ok, moving discussion to next meeting with this one?
20:09:46 <cait> it owuld be nice if people could add notes to the agenda
20:09:50 <barton> I am generally in favor of merging borrowers and deletedborrowers, but I recognize that there could be performance issues that would block.
20:10:40 <pianohacker> cait: agree, move to next meeting
20:10:47 <cait> i'd like to skip the next one - as Joubu isn't here
20:10:56 <cait> and we are almost end of time
20:11:07 <barton> seconded.
20:11:33 <cait> ... and next one is from me
20:11:35 <cait> [kfischer] Performance issues: Benchmark for 3.22, Bug 15242
20:11:36 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15242 blocker, P5 - low, ---, nick, Pushed to Master , Missing subroutine in overdue_notices.pl
20:11:39 <cait> oh
20:11:45 <cait> i got the bug number wrong... once again
20:11:48 <cait> let me find the right one
20:12:11 <pianohacker> after making poor kidclamp's eyes go wiiiide
20:12:16 <cait> bug 15342
20:12:17 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15342 enhancement, P5 - low, ---, jonathan.druart, NEW , Performance 3.22 - Omnibus
20:12:30 <cait> that one
20:12:31 <wahanui> hmmm... that one is down more often than up
20:12:44 <pianohacker> wahanui: forget that one
20:12:44 <wahanui> pianohacker: I forgot that one
20:12:47 <cait> #link https://wiki.koha-community.org/wiki/Benchmark_for_3.22
20:12:49 <kidclamp> hah
20:13:00 <cait> looking at the benchmarking Joubu did it seems like we have a decrease in performance with each version :(
20:13:20 <cait> plack makes it better, but it's stillmoving up
20:13:37 <cait> drojf and some others have identified some possible problems
20:14:03 <cait> i'd encourage to look at those bugs with some priority
20:15:03 <cait> ... did i scare everyone off with those bugs?
20:15:13 <pianohacker> bug 15350 would be great great great to fix
20:15:15 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15350 enhancement, P5 - low, ---, jonathan.druart, NEW , DBIx::Class Startup speed
20:15:22 <mtompset> No, just exhausted. :)
20:15:47 <jajm> pianohacker, +1 to that
20:15:54 <cait> #info Please give some priority to performance related bugs - linked to the omnibus bug 15342
20:16:03 <cait> oh good, got the bug number right this time
20:16:09 * magnuse wanders off
20:16:10 <pianohacker> cait: but to do alot of the changes suggested there, It seems like we have to start maintaining the schema files ourselves, no?
20:16:12 <cait> ready to end meeting?
20:16:32 <cait> pianohacker: i can't say much about hte bugs - i get a bit lost there
20:16:39 <cait> i'd just like to see more work in that direction and feedback
20:16:40 <pianohacker> does anybody else know?
20:16:57 <cait> it seems like not much discussion about performance right now - while libraires complain
20:17:10 <pianohacker> I'd like to at least figure out if that's something we need to put on the agenda for next meeting
20:17:22 <cait> maybe we could split out the bug you mean?
20:17:25 <cait> which one is it?
20:17:33 <pianohacker> 15350
20:17:42 <cait> can i make you add that to next agenda? :)
20:18:19 <cait> #action pianohacker to add 15350 to agenda for discussion at the next meeting
20:18:23 <cait> you didn<#t say no fast enough
20:18:26 <cait> ;)
20:18:35 <pianohacker> okey doke :)
20:18:38 <cait> i'd like to move on to setting hte time of the next meeting :)
20:18:58 <cait> another 2 weeks ok?
20:19:12 <cait> march 1st?
20:19:19 <pianohacker> yeah, agenda is still overloaded
20:19:28 <pianohacker> 15 UTC next time?
20:19:39 <cait> the gneral meeting is at 9th
20:19:40 <cait> so no collision
20:20:04 <cait> hm would work for me
20:20:05 <barton> works by me.
20:20:24 <cait> please vote - next meeting to take place at march 1st, 15 UTC
20:20:33 <cait> oh
20:20:40 <cait> #topic Date and time of next meeting
20:20:45 <cait> oups
20:20:54 <cait> please vote :)
20:21:13 <pianohacker> +1
20:21:14 <talljoy> +1
20:21:15 <nengard> +1
20:21:18 <cait> +1
20:21:24 <drojf> +1
20:21:30 <barton> +1
20:21:37 <bag> +1
20:21:44 <cait> #agreed Next developer meeting will be on March 1st at 15 UTC
20:21:53 <cait> #endmeeting