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