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