15:00:27 #startmeeting Koha IRC Developer meeting, July 23rd, part 1 15:00:27 Meeting started Wed Jul 23 15:00:27 2014 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:27 The meeting name has been set to 'koha_irc_developer_meeting__july_23rd__part_1' 15:00:34 #topic Introductions 15:00:34 #info wahanui, a bot that has become sentient 15:00:45 please introduce yourself with #info 15:01:00 #info Owen Leonard, Athens County Public Libraries 15:01:02 #info Katrin Fischer, BSZ, Germany 15:01:03 #info Zeno Tajoli, CINECA (Italy) 15:01:12 #info Brendan Gallagher, ByWater 15:01:15 #info Kyle Hall, ByWater 15:01:16 #info Colin Campbell ptfs-europe (UK) 15:01:25 #info Barton Chittenden, ByWater 15:01:26 #info Jonathan Druart, BibLibre 15:01:33 #info Jane Wagner, LibLime/PTFS 15:02:12 tcohen won't make it to this meeting, but he has told me what he wanted to say :) 15:02:29 #info Galen Charlton, ESI 15:02:31 so i will try to relay it all correctly 15:03:04 #link http://wiki.koha-community.org/wiki/Development_IRC_meeting,_23_July_2014 15:03:07 today's agenda 15:03:07 well, today's agenda is on the wiki 15:03:37 #topic RM 3.18 comments 15:04:01 tcohen wants to make t/db_dependent/Search.t run for UNIMARC and needs some help on the default mappings for UNIMARC 15:04:21 and also records that match the specifics of the MARC21 counterpart records 15:04:34 see t/db_dependent/data/marc21/zebraexport/large_biblio_* 15:04:57 I should work on bug 11586 (improve framework and mapping for UNIMARC) 15:04:57 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11586 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , Better default framework for UNIMARC 15:05:12 but... I don't know when 15:05:21 #info Make tests pass for UNIMARC - needed: help with mappings and test records 15:05:33 time is a problem for us all i guess 15:05:36 i will add as info 15:05:46 #info Work on bug 11586 could help 15:05:55 hope that made sense 15:06:13 made sense to me, cait. 15:06:18 ok, moving on? 15:06:29 #topic Additions to Coding Guidelines 15:06:56 i think people have noticed... i like deprecating things. Today's victim is GRS-1 in favor of DOM indexing 15:07:09 i have an RM comment on this: 15:08:02 if we can agree to deprecate it, next steps would be adding it to the coding guidelines, filing an omnibus bug and linking everything missing from DOM and remaining problems with DOM to it 15:08:13 so we can trace what needs to be done to completely remove it 15:08:22 +1 15:08:41 i paraphrased it, i hope he will agree later :) 15:08:54 ok, can we get a quick vote? 15:09:15 Do we want to move forward officially deprecating GRS-1 with the first steps listed above? 15:09:19 for 3.18? 15:09:56 i am not sure if we can achieve that totally, but we could enforce dom in a coding guidelines as a first step i think - we don't have one about indexing so far 15:10:16 a coding guideline that says you have to provide a dom patch that is 15:10:36 i don't have something on the timeframe from tcohen, so not sure 15:10:42 maybe we can still have the vote on the general idea? 15:10:49 I like the idea. 15:10:57 On the general idea, +1 15:11:00 #info Greg Lawson 15:11:01 +1 15:11:03 +1 15:11:04 +1 for tcohen 15:11:07 +1 15:11:10 +1 15:11:17 I'm not sure that theres much grs specific code but on depreciating it +1 15:11:22 (don't know if that counts as voting twic ;-) 15:11:49 #info removing GRS-1 indexing in favor of DOM, first steps: coding guideline, omnibus bug for tracking what needs to be done (remaining issues, needed changes, etc.) 15:12:39 +1 15:12:44 #agreed move towards removing of GRS-1 in favor of DOM 15:13:25 can we also agree on having dom mandatory in patches for indexing? 15:13:34 i think we already do that, but it'smissing from the wiki page 15:14:03 Isn't it already mandatory? 15:14:06 opinions? 15:14:06 opinions are slightly divded :) 15:14:14 Joubu: that#s what i think but we haven't written it down 15:14:21 I'm agree on dom mandatory 15:14:41 It makes sense to add it to the wiki 15:14:45 i can't find anything about dom or indexing in the coding guidelines 15:14:56 if you want do a aptch on grs-1, but with the same feature/fix on dom 15:15:15 s/aptch/patch/ 15:15:30 wondering when anyone last saw a grs-1 specific patch 15:15:35 I volunteered gmcharlt to think up the coding guideline text for me 15:15:45 ColinC: not so far ago actually 15:16:04 well, mostly dom and grs1 now, but still changes to the indexes happen 15:16:18 i know we had some additions for 3.16 15:16:20 I wonder if we could deprecate make_zebra_dom_cfg_from_record_abs -- if DOM is standard, we should be making changes to the DOM config files, then proting back to GRS-1 if necessary. 15:16:23 obviously I'm not looking at the right patches 15:16:57 it would remove future confusion 15:17:04 s/proting/porting/ 15:17:06 #info Dobrica Pavlinusic, FFZG 15:17:07 we could say only adding to dom yes 15:17:15 proposed wording: http://paste.lisp.org/display/143215 15:18:12 For me is ok, +1 15:18:15 +1 from me, reads well 15:18:20 +1 15:18:42 +1 15:18:54 +1 15:19:07 #info proposed wording for new coding guideline: http://paste.lisp.org/display/143215 15:19:21 +1 15:19:29 (if that does not break Koha ft) 15:20:00 #agreed coding guideline about deprecating GRS-1 in favor of DOM, wording suggested by gmcharlt 15:20:20 anything to add about indexing? 15:20:53 Can we get rid of the record.abs line numbers in biblio-koha-indexdefs.xml as well? 15:21:10 #info Jacek Ablewicz, Cracow Univ. of Technology 15:21:19 about the script make_zebra_dom_cfg_from_record_abs - you are already supposed not to use it :) 15:21:25 hi abl :) 15:21:37 ithink that could be a bug on moving forward to deprecating it 15:21:54 if record.abs goes, the references wouldn't make much sense any mroe i guess 15:22:03 the next topic is a tricky one... 15:22:08 Indenting in templates 15:22:14 indentation in templates? 15:22:25 whatever sounds better to you :) 15:22:30 cait: that makes sense 15:22:33 there is some discussion between 2 or 4 15:22:36 spaces 15:22:37 no tabs! 15:22:40 well make_zebra_dom_cfg_from_record_abs is a script to migrate from grs-1 to dom, so it ie same of the last thing to do 15:22:54 we need a tidy script for TT, but every time I try to write one I give up 15:23:18 ztajoli: i think it was only used for initial move, shouldn't be used now as the file generated is different to the one we have (that's how i understand it at east) 15:23:31 oleonard: maybe you can explain? 15:23:42 we need to encourage folk to use those new-fangled newline things too 15:24:13 To my knowledge 4 spaces has always been a de-facto standard in the templates 15:24:31 I assumed that since the standard for Perl scripts was 4 that it would be so for templates as well 15:24:36 oleonard: I would agree 15:24:47 i at biblibre have started to work with DOM 15:24:50 #info coding guideline about indentation i perl scripts http://wiki.koha-community.org/wiki/Coding_Guidelines#PERL6:_Indentation 15:25:05 first for our MARC21 clients 15:25:38 we will soon start for a unimarc one, lyon3 15:25:40 the other 'side' has argued that the templates have lots of indentation, os 4 is too many and 2 would be better 15:26:07 I just have a request: don't fail qa on patches already submited 15:26:07 that is a valid point, the templates need far more indentation levels than most perl scripts 15:26:15 my understanding is that we have a mix now, with the bootstrap templates all using 4 15:26:31 Joubu: i think that's reasonable :) 15:26:42 I think I can find 10 indentation levels in some templates 15:26:45 10*4 ... 15:26:49 * gmcharlt tosses out an idea 15:27:06 a PostgreSQL-style reindentation at the beginning of each release cycle 15:27:07 I have a wide screen I don't care :) 15:27:16 * gmcharlt also has a wide screen :) 15:27:26 ok, i think i need help to get the joke :) 15:27:33 * khall must need a smaller font 15:27:38 the idea is that we'd write an automatic tool that can pretty up the indentation 15:27:50 and apply it at at each erlease cycle 15:28:20 gmcharlt -- there isn't a code beautifier for tt, unfortunately. 15:28:21 gmcharlt: it will be very bad for patches waiting in the queue... 15:28:21 but in between, *not* sweat changes, except in cases where a patch may need to be tossed back because it is unreadable due to bad indentation 15:28:22 gmcharlt: I think the same thing should be done with perltidy on the scripts, but when Paul wanted to do it, it was voted down. 15:28:32 well, to be clear 15:28:42 Sometimes its harders to decide how to indent in html than code 15:28:42 my proposal is offerred as a compromise 15:28:59 my actual preference is that we /not/ do global reindentation 15:29:10 gmcharlt: don't we need an automatic reindenter first? 15:29:13 I think the last time we talked about a mass Tidy of Perl scripts we didn't have/weren't aware of git's options for ignoring whitespace in diffs and blames 15:29:35 as I prefer that we don't do anything that makes it more difficult to integrate patches 15:29:42 agreed 15:29:50 * khall has tidied some scripts just to read them 15:29:51 i think i can live with both - as long as it's consistent 15:29:58 khall: yep, my proposal woudl require that we write one, but we wouldn't need it until the 3.20 cycle begins 15:30:03 and there is indentation 15:30:08 and it would also be incumbent on somebody to really cares to write it 15:30:11 I'm for it 15:31:02 ok, please add ideas as #infos 15:31:07 We also need to be explicit about what we want it to do 15:31:24 Do the people who want 2-space indentation in templates want to change the standard for Perl scripts as well? 15:31:30 i think probems with git will arise when it changes lines, not just the white space 15:31:37 so i would only want it to change whitespace 15:31:42 If not, does it really make sense to have two standards? 15:32:20 I have different standards for apples and oranges 15:32:39 I think two space indents for code is perfectly acceptable 15:32:42 hm not sure we can reach a conclusion really 15:32:59 i like 4 :) 15:33:24 can we get a quick vote on preferences on this? something like 2/4/-/both? 15:33:40 it would be nice if there was a way to know which files are affected by all the patches in process on bugzilla, that way we could perltidy any files that aren't affected on a periodic basis 15:33:55 khall: Joubu put something together that does exactly that 15:34:00 The trick with indentation in tt files is that the indentation of the template can fight with the indentation of the html around it. 15:34:12 gmcharlt: thanks for letting me know! 15:34:53 khall: bz_splitter 15:35:02 I tidy tt files locally when I'm eiditing them. 15:35:07 barton: I don't think that matters unless you care about the indentation of the HTML which is sent to the browser (which I don't think we do?) 15:35:12 Something to consider: if there are two different indenting standards, the people proposing that should probably take the time to write configuration instructions for making that work in commonly-used editors. Otherwise, it just sounds like a barrier to entry for non-expert-level ${TEXT_EDITOR} users. 15:35:17 cait: thanks! 15:35:18 I run the file through a parser to strip out the tt bits.. html tidy them.. then put the tt bits back. 15:35:19 hm not getting the URL right right now 15:35:22 it works reasonably well 15:35:35 khall: http://splitter.koha-community.org/ 15:35:36 i guess one question is: is it worth the trouble? 15:35:40 http://splitter.koha-community.org/ 15:35:46 ah thx 15:35:47 cait: IMO, it is not worth the trouble 15:35:58 we should have a standard perltidy config, and maybe a vimrc? 15:36:07 #link 6ocS88DLK6u7vtw9 15:36:09 eek 15:36:29 #link http://splitter.koha-community.org/ 15:36:34 and... just ignore that string. 15:36:46 cait it is greate 15:36:50 great :) 15:37:07 i use it a lot to look if a bug is already reported 15:37:16 my view: if a whitespace problem prevents somebody from working on a patch, they are free to tidy it (in a separate patch) 15:37:25 I feel like we should automate this, so we a server somewhere they nightly tidys any tt and perl files that aren't currently affected by patches, and the patch is sent to the rm 15:37:34 cait: click on Files and enter a text in Search 15:37:47 fridolin: i have tried it - it's really nice, just forgot the link :) 15:37:55 but I am really hesitant to go along with putting much effort to do global changes 15:37:58 khall: We can't automate the process because we haven't settled on a standard yet ;) 15:38:01 cait: oh ok 15:38:14 ok, i think we need to postpone this 15:38:15 and I'm a definite -1 on a *daily* tidying 15:38:23 gmcharlt: that has given me problems in the past. If I tidy a section so it's undertandable, then patch the code, it all gets broken by new commits. 15:38:44 if we do anything automatic at all, I don't think it should be more frequently than once a release cycle 15:38:45 my personal opinion is - 2 or 4, but consistent for a block of code at least, and spend the time on something like removing SQLHelper or GRS1 :) 15:38:46 tidying afterward is not as useful, because I neeed to tidy the code to make it readable 15:38:47 I'de love to see a mass tidy to start with.. 15:39:00 but not a nightly tidy after that.. 15:39:27 gmcharlt: if we tidy on a nightly basis, it keeps patches from having merge conflicts, if we only do it every 6 months, then every 6 months we'll have many patches that no longer apply 15:39:45 attempting mass reindentation caused pain with evergreen, fwiw 15:40:16 I'de say a tidy should be done before a merge into master for all patches.. jsut my two pence 15:40:20 #idea automated tidy at begin/end of release cycle 15:40:25 I think I've seen an emacs mode that tudies the code every time you save it eeek 15:40:27 #idea don't spend time on it :) 15:40:41 #idea nightly tidy 15:40:42 khall: which I'd actually interpret as an argument not to do periodic tidying at all :) 15:41:10 #idea no periodic tidying at all 15:41:17 ok, I think we need to continue that another time 15:41:21 I don't ; ) 15:41:22 I think it's something that we have to suffer through to have better code in the end 15:42:07 I have a shortcut in my vimrc, I select lines and perltidy them 15:42:16 How about this, if we do a pre-release tidy, then require all patches submitted to be tidied. 15:42:18 it's very useful for new code/block of code 15:42:19 As history would disappear would it be Koha 4.1? 15:42:37 that is, any file affected by a patch must be tided with a followup. 15:43:01 I tihnk we need to move this to the mailing list - please add #idea now if you want to add something 15:43:04 * gmcharlt has yet to see an RFP for an ILS that specified tidy whitespace as an evaulation criteria; IMO, effort is better directed at architectural issues and features, relegating whitespace to local improvements 15:43:15 I agree 15:43:23 but yes, cait is right that we should move disucssion to ML 15:43:32 thx ;) 15:43:39 #topic DBIC 15:43:51 #info MJ Ray, software.coop, England 15:44:02 The idea is to make Koha easier to work on for developers, not for users. 15:44:07 i'd like to suggest that we postpone some of the topics to the next meeting as we are running late already 15:44:16 khall: that sounds bckwards... 15:44:19 just because it doesn't make Koha more interesting to end users doesn't mean we shouldn't do it 15:44:49 dbic is an important topic, but it needs some time i think - would people agree to postpone it? 15:44:56 +1 15:44:59 I'm saying it's easier to read and modify tidied perl code 15:45:21 khall: dbic? :) 15:45:45 what is the topic exactly ? 15:45:50 dbic++ As part of the process of moving toward dbic, I have submitted a couple patches to dbic-ify existing perl modules 15:45:57 all things/questions around DIBC? 15:46:00 DBIC 15:46:19 if you want to discuss now it's ok, the nextmeeting would be in 2 weeks as suggestd by tcohen 15:46:35 but then we need to move something else to next i think 15:46:37 I suggest that we defer 15:46:48 that's fine by me. 15:46:51 i think if there are questions and kyle is around later 15:47:08 From me no 15:47:09 we can still talk some about it afte the general meeting 15:47:24 #topic Bugs 15:47:25 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12608 15:47:26 04Bug 12608: enhancement, P5 - low, ---, kyle, BLOCKED , Replace use of DBI with DBIx::Class throughout Koha 15:47:31 i will pull up bugs first, and we will see 15:47:41 today has been the GBSD for the UTF-8 patch 15:47:48 Joubu: can we get a quick summary? 15:47:54 whaou, we skipped DBIC, that's it, seriously? 15:48:15 Joubu: i move it to later 15:48:18 so, bug 11944 has been tested today by some guys 15:48:19 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944 major, P5 - low, ---, jonathan.druart, Needs Signoff , Cleanup Koha UTF-8 15:48:24 nothing to add 15:48:34 some bugs have been found, an bug reports opened 15:48:35 Joubu: any progresson the remaining issues? 15:48:48 as what I have seen, it's just small/specific issues 15:49:02 dpavlin was working on the search issues 15:49:05 dpavlin: ? 15:49:18 Any testing advice besides "type weird characters into everything?" 15:49:35 he has a patch, but it does not fix everything, we need a TT filter uri_escape_utf8, which does not exist (does not provide by TT) 15:50:10 oh 15:50:11 oleonard: no, use all sort of characters everywhere into Koha and verify they displays correctly 15:50:20 I think it's a good test plan 15:51:11 ok 15:51:12 What about testers? ztajoli? 15:51:28 I'm about to submit two patches (and sign-off rest of them) which hopefully fix remaining issues 15:51:44 dpavlin: all remaining issues ? :) 15:51:45 idea: have a koha server everyone can log into and create records/patrons/what-have-you using diacritics from his or her language. That test db can be dumped and loaded by qa testers. 15:51:56 all known issues :-) 15:51:59 After meeting I will test all ACQ and Serial fro 11944 15:52:09 dpavlin++ 15:52:22 there is search history bug documented at wiki, but I don't see it 15:53:06 From monday 28/07 Paola Rossi restart to test bug 11944 15:53:13 khall: i think we could dump the sandboxes maybe after testing is finished 15:53:45 but not sure how helpful 15:53:58 no, the sandboxes DB don't seem to be good. Facets don't work... 15:54:01 cait: I was thinking of something more long term and continuous 15:54:17 Joubu: Do you want to say something about Testbuilder? 15:54:24 yes, a lot 15:54:31 Yohann submitted a lot of patches this week. 15:54:40 Yohann++ 15:54:40 He has 2 'front lines': 1 to replace SQLHerlper with DBIC, another one to simply the write of UT (See email on the ML "TestBuilder", or entry point on bz is bug 12603). 15:54:41 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12603 enhancement, P5 - low, ---, yohann.dufour, Needs Signoff , TestBuilder - Module to simplify the writing of tests 15:55:00 He really needs feedback to continue. He did not want to write and rewrite UT if the general idea is not approved by the community. 15:55:10 It would be great if some UT gurus could take a look at his work. 15:55:19 Reminder: it is just a 3-months intership, only 1 remaining.. 15:55:52 that's all :) 15:56:03 #info Yohann is working on replacing SQLHelper with DBIC and simplifying unit test writing 15:56:13 #link Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12603 15:56:13 04Bug 12603: enhancement, P5 - low, ---, yohann.dufour, Needs Signoff , TestBuilder - Module to simplify the writing of tests 15:56:25 * khall puts that on the todo list 15:56:38 the entry point for sqlhelper is bug 11385 15:56:39 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11385 enhancement, P5 - low, ---, yohann.dufour, ASSIGNED , C4::SQLHelper should be removed 15:56:49 info http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11385 15:56:51 04Bug 11385: enhancement, P5 - low, ---, yohann.dufour, ASSIGNED , C4::SQLHelper should be removed 15:56:54 4 bugs need SO 15:57:03 next one is a discussion on lot item handling 15:57:18 the bug is bug 9805 15:57:19 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 normal, P5 - low, ---, kyle, In Discussion , Lost items are un-lost if returned, but not if renewed. 15:57:56 tcohen suggests that we change it to allow/disallow reneal of lost items as an option on the circulation conditions page (not necessarily the big table, but a by branch setting on that page) 15:58:15 currently it is about resetting the lost satus (finding he item) when you renew 15:59:08 in my opionion it makes sense to not allow renewal of lost items in the first place, but i am not totally sure how it would impact workflows 15:59:16 that would be a fine solution by me. 15:59:36 I would think we would need to both allow/disallow renewal of lost item *and* have a preference about whether the status should be removed upon renewal. 15:59:53 However I don't speak based on my library's policy, just in the abstract. 15:59:58 i am a bit worried if a patron canremove the lost status by renewing in the opac 16:00:11 that would be confusing about the replacement fee already charged 16:00:39 good point, cait. 16:00:47 Or if you allow phone renewals ... 16:00:51 agreed, it's better to block the renewing of lost items altogether 16:01:24 maybe people here can update the bug with opinions/ideas? 16:02:19 ok, quiet 16:02:24 moving on :) 16:02:25 #topic New status/field for bugzilla - abandoned/for adoption 16:02:55 it was an idea for bugs - to make it really clear that someone doesn't intend to continue work on something 16:03:12 we have a lot of things in doesn't apply, in discussion, etc. this might apply to 16:03:23 there are patches, but the work won't be continued 16:03:39 This would be an additional field, or another value on an existing one? 16:03:40 maybe a comment could suffice? but a field would be searchable 16:03:47 In this case, you just have to remove your name from the "asssignee" field, no? 16:03:49 i am not sure what makes most sense 16:04:06 Joubu: in theory yes... but people often forget to assign bugs to them too 16:04:15 I agree with Joubu. Un-assign yourself and set the status to NEW? 16:04:22 maybe we just need to enforce thismore :) it's an idea i wanted to put out there to see what people htink 16:04:36 that may be something to periodically do batch updates? 16:04:50 i.e., if X months have passed since the last action on a bug, reset the status 16:04:55 i amnot sure how safely we can do that - and if people might be unhappy by it 16:05:00 sounds good to me, I always assign bugs to myself if I plan to work on them. 16:05:47 see u 16:05:49 ok, quick preference vote? separate field/status (s) or use assigned (a)? :) 16:05:59 - for me 16:06:04 a 16:06:05 s from tcohen 16:06:06 -1 to separate status/field 16:06:13 * khall is sure he has a number of "doesn't apply" patches that can be closed out at this point. 16:06:14 use assigned for me +1 16:06:23 no opinion 16:06:31 use assigned for me +1 16:07:03 can we automate an email to the assignee that would warn of the impending status change? 16:07:12 #agreed encourage use of the assigned field - no assignee = open for adoption 16:07:19 hope i got that right? 16:07:37 Sounds correct to me 16:07:49 #idea automate 'unassigning' in some way, batch change, warning email or similar 16:07:59 #topic Big stuff we are working on 16:08:01 one of my favs :) 16:08:29 I sent an email for the VAT RFC, will be on it at the end of August, please have a look BEFORE 16:09:03 #info spec for GST/tax rewrite in acq: http://wiki.koha-community.org/wiki/GST_Rewrite_RFC 16:09:12 #info Please add comments before end of August! 16:09:24 Joubu: was the deadline in the email? might be good 16:10:11 Usually, when I asked for feedbacks, I am waiting for quick feedback :) 16:10:18 -ed 16:10:30 people often get moving when you give them a date, in my experience 16:10:48 :) 16:10:56 cait: I will sent a reminder later ;) 16:11:07 i still have to look through it actually, the math scaredme off a bit, but will try again :) 16:11:13 ok, khall? 16:11:14 it has been said that khall is now travelling home dpk 16:11:37 someone else? 16:11:37 i guess someone else is going to have to look at acquisitions 16:11:42 wahanui: forget khall 16:11:42 gmcharlt: I forgot khall 16:11:43 I'm going to release my Edifact ordering branch, it going out to a number of sites so they'll be testing 16:11:48 wahanui: forget someone else 16:11:48 gmcharlt: I forgot someone else 16:11:53 ColinC++ 16:11:58 ColinC++ 16:12:14 ColinC++ 16:12:23 I am going to test Shibboleth patches with ashimemas help 16:12:29 hopefully it will work :) 16:12:52 * khall is really looking forward to seeing the Edifact code 16:12:59 i had added the accounts rewrite...my hope is, that after we have settled the utf-8 patches, maybe we can have another gbsd on that 16:13:12 that would be great! 16:13:23 (TestBuilder is a 'big stuff' Yohann is working on) 16:13:33 I am volunteering to start a wiki page to gather workflows/current functionality for testing 16:13:48 Joubu: yep, and also the SQLHelper removal 16:14:03 I can tell you we have a number of libraries using the code in production, so it's pretty bullet-proof at this point, the biggest issue is likely to be internationalization ( i.e. diacritics ) 16:14:05 but probably will take me 1-2 more weeks to do it 16:14:16 cait: yes, but the TestBuilder is blocker for him 16:14:29 Joubu: so better test thos epatches first? 16:14:35 yep 16:15:03 I think the current accounting system is holding back many libraries who would otherwise be potential Koha adopters 16:15:04 #info Please test TestBuilder patches/give feedback on them first - bit higher prio then SQLHelper for now 16:16:23 ok, looking for actions from last meeting 16:16:26 #Action from last meeting 16:16:47 tcohen will ask on the mailing list if someone still uses misc/cronjobs/rss/rss.pl - has been done 16:17:13 not sure about the outcome 16:17:22 and ? The patch needs SO, we agree? 16:17:49 Joubu: I am not sure we agree - i think some peopel said it doesn't hurt someone so don't remove it 16:17:58 I think the outcome was that it shuld be updated to tt.. 16:18:03 when someone finds a moment. 16:18:09 well that would be best obviously 16:18:19 so we can remove it and reintroduce it later? 16:18:20 :) 16:18:23 so, we can end the meeting now, or we can get back to dbic 16:18:26 certainly.. but finding the moment is hard. 16:18:34 Actually, I don't care 16:18:52 +1 to ending the meeting 16:18:53 one more thing, I need input on bug 12632 16:18:55 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12632 major, P5 - low, ---, kyle, NEW , Hold limits ignored for record level holds with item level itemtypes 16:18:56 I wouldn't remove it.. I beleive a fair number of places are using it as is.. it does still work so long as you install the dependancy of html or 16:18:57 Joubu: i think people were worried about libraries using it not knowing how to bring back after an update - not sure f we remove it, if that would remove files changed locally too 16:18:58 if anyone is willing 16:19:01 I wouldn't remove it.. I beleive a fair number of places are using it as is.. it does still work so long as you install the dependancy of html pro 16:19:12 agreed 16:19:25 I would like anyone who objects to its removal to submit patches to update it. 16:19:37 i'd like to volunteer kyle to answer dbic questions after the meeting ;) and put it first on next times agenda 16:19:55 i think it doesn't hurt if it stays around 16:19:56 removing it may force someone to rewrite it 16:19:57 ; ) 16:20:00 and the dependency has beenremoved 16:20:02 can do! 16:20:03 i think 16:20:12 it's in the queue oleanard.. but so far down it's not going to be reached for like a year on my list. 16:20:19 I volunteer to work on rss.pl 16:20:26 no-one will pay us to update it whilst it still works 16:20:29 khall: wohoo :) 16:20:37 #action khall volunteers to work on rss.pl 16:20:44 khall.. awesome. 16:20:53 #info khall also needs feedback on bug 12632 16:21:03 it should be 'reasonably' trivial I hope.. but was super low priority for me at the moment. 16:21:17 ashimema: that's what I'm hoping! 16:21:18 ok, tcohen proposed that we change to a 2 week cycle for th emeeitngs... and seeing the amount of topics and discussion i'd agree with that 16:21:25 until we run out of things to deprecate and discuss :) 16:21:36 lol 16:21:39 +2 16:21:50 +1 16:21:55 tat would make the 6th of August a candidate for next meeting 16:22:05 #Set time of next meeting 16:22:13 #topic Set time of next meeting 16:22:25 does that work? 16:22:49 +1 to 6 August 16:22:57 I'll try to get my head around bug 12632 khall.. at least to comment on it 16:23:30 Note: I will be afk for 3 weeks from next Monday 16:23:31 FYI: NAKUG is meeting Aug 6th-9th. 16:23:48 but +2 for the the 2 week cycle! 16:23:49 tubaclarinet: ah 16:24:05 what about 5th? 16:24:16 tuesday that is, before nakug? 16:24:44 Maybe having fourty or so geeks 2gether in the same room during a dev mtg wud b a good thing? 16:25:08 tubaclarinet: i am not sure, i think it's also presentations - don't want to interfere with schedule 16:25:27 cait: true. 16:25:40 gmcharlt: 5th ok too? 16:25:46 yep 16:25:57 #agreed Next meeting will be (pending agreement from part 2) August, 5th, 15:00 + 22:00 UTC 16:26:16 #endmeeting