15:07:58 <tcohen> #startmeeting Koha Developer IRC meeting, 9 September 2014 - part 1
15:07:59 <huginn> Meeting started Tue Sep  9 15:07:58 2014 UTC.  The chair is tcohen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:59 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:59 <huginn> The meeting name has been set to 'koha_developer_irc_meeting__9_september_2014___part_1'
15:08:11 <tcohen> #topic Introductions
15:08:12 <wahanui> #info wahanui, a bot that has become sentient
15:08:19 <oleonard> #info Owen Leonard, Athens County Public Libraries
15:08:27 <tcohen> please introduce yourselves using #info name
15:08:44 <tcohen> #info Tomas Cohen Arazi, Universidad Nacional de Cordoba
15:08:47 <clrh> #info Claire Hernandez, developments manager at BibLibre
15:08:48 <thd> #info Thomas Dukleth, Agogme, New York City
15:09:22 <Joubu> #info Jonathan Druart, BibLibre
15:10:09 <tcohen> ok, moving on
15:10:14 <tcohen> #topic RM 3.18 comments
15:10:46 <tcohen> #info facet retrieval from Zebra is complete, feedback is needed
15:11:13 <Joubu> good job tcohen :)
15:11:16 <ztajoli> #info Zeno Tajoli, Cineca (Italy)ù
15:12:01 <thd> tcohen: what is the bug number for that
15:12:02 <thd> ?
15:12:09 <tcohen> thd, was looking for it
15:12:14 <khall> #info Kyle M Hall, ByWater Solutions
15:12:19 <Joubu> bug 11232
15:12:23 <wahanui> i heard bug 11232 was relevant in the medium term, as one of the side effects of using Zebra to calculate facets will be to make library facets both more correct as well as easier to tweak
15:12:23 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232 new feature, P5 - low, ---, gmcharlt, Needs Signoff , Retrieve facets from Zebra
15:12:28 <ashimema> #info Martin Renvoize, PTFS Europe
15:12:29 <tcohen> #info facets from zebra is needs sign off, bug 11232
15:13:06 <tcohen> i have added a new syntax for facets specification
15:13:23 <nengard> #info Nicole Engard, ByWater Solutions
15:13:38 <tcohen> https://github.com/tomascohen/koha/commit/5b0b36895bad75052e8a0e362e561a8631f103f2
15:13:47 <tcohen> ^^^^^ there you can see the syntax
15:13:48 <ashimema> fantastic work there tcohen
15:14:12 <tcohen> ashimema: we need to first see how it develops
15:14:18 <tcohen> then drink some beers
15:14:19 <tcohen> :-P
15:14:42 <tcohen> ok, next
15:14:44 <ashimema> deffo
15:14:50 <thd> tcohen: Is this still bound to subfield a?
15:15:02 <tcohen> thd: no
15:15:05 <thd> ah no
15:15:09 <Joubu> tcohen: it's worth some beers, definitely ;)
15:15:20 <thd> yes I just saw the good part of the code
15:15:25 <tcohen> thd: https://github.com/tomascohen/koha/commit/281808cce6cc94e26beb6281ec44daada0a85595
15:15:34 <thd> Great tcohen++
15:15:45 <tcohen> UNIMARC is better as an example
15:15:56 <barton> #info Barton Chittenden, ByWater Solutions, Louisville, KY, USA
15:16:08 <atheia> #info Alex Sassmannshausen, PTFS Europe, UK
15:16:21 <tcohen> people that tested it already proposed future enhancements
15:16:58 <tcohen> ok, next topic
15:16:59 <wahanui> next topic is a tricky one...
15:17:09 <tcohen> we didn't know how to call it
15:17:12 <ashimema> Certainly there are enhancements to come.. but this is certainly an awesome start!
15:17:16 <tcohen> but here we go
15:17:21 <tcohen> #topic General technical discussion
15:17:43 <tcohen> This discussion might as well take place on the list
15:17:54 <tcohen> #subtopic To mock or not to mock...?
15:17:57 <tcohen> heh
15:18:36 <ashimema> that is the question...
15:18:41 <Joubu> discussion already started on trello: https://trello.com/c/vsrkdpvv/27-tests-mocking-when-to-and-when-not-to-that-is-the-question
15:18:47 * ashimema couldn't resist
15:19:10 <tcohen> as i wrote on trello, I think unit tests should be fully mocked
15:19:26 <tcohen> and integration tests should be written for using the DB
15:19:37 <ashimema> What are people thoughts generally.. I'm with tcohen and beleive if possible we should mock.. using db is as a last resort in my mind.
15:19:38 <tcohen> the problem is we don't have infinite time to do it
15:20:30 <Joubu> It's not a problem not to mock. I think the main problem is to be data agnostic, isn't it?
15:20:48 <tcohen> yes
15:20:58 <ashimema> I suppose they're two questions then..
15:21:18 <ztajoli> I have the same opinion of tcohen.
15:21:32 <ashimema> data agnostic is fine.. so long as you have a sql server running to push randomised data to..
15:21:34 <thd> You cannot always have a good test which is really data agnostic.
15:21:49 <ztajoli> data agnostic is good goal
15:22:00 <atheia> Definitely being data agnostic would be good. The tests that I wrote using mock were a little painful, but I'm not sure how else I would have tested.
15:22:09 <ashimema> do we ever need to test without a sql server on the system at all?
15:22:12 <atheia> So I'd rather go with mock than not to mock for unit tests :-)
15:22:13 <thd> Testing some behaviour requires data which will elicit the behaviour.
15:22:14 <ztajoli> all data to test inside the test
15:22:41 <ashimema> (that's a question for the package builders out there.. currently I know packages build without running ANY db_dependant tests.. the question is why?)
15:22:52 <ztajoli> clearly you need an sql working
15:22:58 <jcamins> ashimema: because when building a package there's no database available.
15:23:00 <tcohen> ashimema: during packages build, we run non db-dependent tests
15:24:01 <ashimema> so.. in the packages case.. it needs to be completely mocked.. not just data agnostic if we want it to get tested..
15:24:05 <ashimema> that's my point of question
15:24:22 <thd> Is this question concerning building or patch testing?
15:24:31 <tcohen> the thing is using the DB might prevent us from detecting side effects
15:24:52 <tcohen> our tests should be organized in a way they could be run randomly
15:24:58 <tcohen> and mocked
15:25:17 <ztajoli> I think that our standard db_dependant test could be: 1)insert data in sql server 2)test 3)drop data
15:25:18 <tcohen> and probably leave db-dependent tests to jenkins or smth like that
15:25:39 <ashimema> In which case.. do we need a TestBuilder like module that mocks instead of pushing random data to the database?
15:25:54 <thd> tcohen: What side effects would you have in a Db which would be missed there but caught by mocking?
15:26:27 <tcohen> thd: a test might be writing data that is making the next test to pass, just because the data is there
15:26:40 * ashimema is playing devils advocate..
15:27:20 <thd> tcohen: Refreshing would be required then but that would add to the overhead.
15:27:29 <Joubu> Maybe the question is "what is the next step?", not "what could be the ideal situation?"
15:27:49 <thd> s/Refreshing/Dropping and starting again/
15:27:52 <tcohen> ashimema: algorithmically mocking a package's API is harder than checking foreign key constrains, i guess
15:27:53 <ashimema> Joubu++
15:28:26 <Joubu> Yohann proposed a way to generate random data, to be data agnostic, (see TestBuilder).
15:28:34 <ashimema> So.. I'm happy to say that db_dependant have their place..
15:28:35 <thd> tcohen: Is this question concerning building or patch testing?
15:28:44 <Joubu> Who has already took a look??
15:28:56 <clrh> me ;)
15:29:06 <tcohen> thd: patch testing
15:29:11 <ashimema> so we agree that instead of 'To mock or not to Mock' the question is 'Should be be data agnostic' and the answer to that is obviosly yes.
15:29:33 <bag> morning (sorry to be late
15:29:42 <bag> #info Brendan Gallagher ByWater
15:29:45 <Joubu> ashimema: so, the next question: "how?" :)
15:29:49 <tcohen> hi bag
15:29:56 <bag> heya tcohen
15:29:59 <ashimema> and we come round to TestBuilder..
15:30:25 <thd> ashimema: What do you do with random data which does not trigger the behaviour against which the past needs to be tested?
15:30:48 <thd> s/past/patch/
15:31:41 <tcohen> thd: TestBuilder is supposed to (for example) create a branch (taking care of all needs to be set for that) and then you use the created branch
15:31:50 <ashimema> It's not random data so much, as adding foreign keys for you.
15:32:33 <ashimema> We have a bunch of tests that will fail if run against a database other than the one that resides on the jenkins server.. I think that wrong personally.
15:33:03 <ashimema> They fail due to the test assuming stuff about the data already in said database.. like default category codes for example..
15:33:42 <Joubu> I think we should give TestBuilder a try. We can remove it later if we find a better solution.
15:33:50 <ashimema> So.. the point of testbuilder from my understanding is so you can put some specifics in your database to check against (and test builder will take care to add all random foreign keys for you)..
15:33:57 <ashimema> so it's not about randomising everything..
15:34:22 <ashimema> it's just about ensuring you meet all foreign key constraints when attempting to add fake data for testing..
15:34:27 <ashimema> is that all correct Joubu?
15:34:41 <Joubu> s/fake/random
15:34:42 <Joubu> yes
15:35:13 <Joubu> example: http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30090
15:35:30 <ashimema> not s/fake/random in that last case.. you should still be able to add some specific data to a specific field.. so you can test for fringe case that are only caught with such data..
15:35:34 <Joubu> +my $order1 = $builder->build({ +    source  => 'Aqorder', +    value   => { +        datecancellationprinted => undef, +    }, +    only_fk => 1, +}); +C4::Acquisition::NewOrder($order1);
15:35:37 <Joubu> oops
15:35:46 <Joubu> no need to create biblio, budget, etc.
15:35:53 <ashimema> exactly..
15:35:57 <Joubu> they are created automatically with random data
15:36:08 <ashimema> anyone else care to chip back in?
15:36:47 <ashimema> Long term.. i'de prefer we added the functionality to the cpan module mentioned as an alternative in the bug..
15:36:57 <clrh> what does mean chip back in ashimema ?
15:37:03 <ashimema> but I tihnk for speeds sake we're probably best pushing TestBuilder as is?
15:37:23 <ashimema> clrh.. any other comments outside Joubu and My ramblings (conversation)
15:37:28 <clrh> (ok thanks)
15:37:32 <ztajoli> as is in debian stable better
15:38:00 <Joubu> ashimema: not sure, because we will certainly introduce some Koha specific stuff (the db structure is sometime not good, fk cannot be follow to create data).
15:38:27 <ztajoli> attention on use modules from CPAN, only if mandatry for same feature/fix
15:38:34 <ashimema> either way.. can we agree on TestBuilder being pushed or not?
15:38:45 <ashimema> it's bascially passed qa now.. I just felt this discussion was needed
15:39:53 <Joubu> great, moving on?
15:40:00 <ztajoli> In my opinion yes
15:40:07 <ashimema> tcohen?
15:40:07 <wahanui> tcohen is, like, obsessed with automated testing :)
15:40:20 <tcohen> sorry, i was called by te boss
15:40:58 <tcohen> i'm not sure about the approach to unit testing
15:41:05 <tcohen> i don't think we are doing unit testing either
15:41:27 <tcohen> but I see TestBuilder as a shortcut to something "closer" to unit testing
15:41:28 <ashimema> we're certainly mixing unit tests with integration tests..
15:41:31 <Joubu> tcohen: some tests are unit tests, others are integration tests
15:41:34 <tcohen> and also have some integration tests
15:41:37 <tcohen> at the same time
15:42:05 <tcohen> so, in the short term, I'd agree we can have *better* tests using testBuilder
15:42:26 <tcohen> my only concern is technical debt
15:42:30 <Joubu> I don't think so
15:42:41 <Joubu> but easily to write, so more unit tests :)
15:42:50 <ashimema> we aught to more clearly define when you should write a 'db_dependant unit test', a 'db_independant unit test', a 'integration test'
15:43:39 <ashimema> My last questions regarding testbuilder can go on off meeting.. (there are to do with that dbic followup)
15:43:39 <tcohen> i think it was gmcharlt_that said we could separate context-dependent vs. non-context-dependent
15:44:00 <ashimema> mocking context is actually pretty straight forward..
15:44:15 <tcohen> ashimema: mocking is pretty straightforward
15:44:16 <tcohen> :-D
15:44:28 <ashimema> and in fact.. there's a lib for it too t/lib/Mocks
15:44:45 <Joubu> quite empty...
15:44:51 <tcohen> i think we could push TestBuilder, butI'm confident I'll continue to write mocked tests
15:45:15 <barton> if you have a db_dependant test that passes, and a db_independant that doesn't, that could be useful information...
15:45:30 <ashimema> indeed..
15:45:33 <tcohen> barton: we need both, I agree
15:45:38 <ashimema> but that measn writing both ;)
15:45:42 <tcohen> yeah
15:45:50 <tcohen> that's what i was saying about infinite time
15:46:15 <ashimema> see.. I would like TestBuilder at some point to morph into a 'got db, test agianst it, not got db.. mock it' module
15:46:34 <barton> yeah, that's where I was going with that.
15:46:41 <ashimema> anywho.. lets either move on or vote ;)
15:46:50 <barton> +1
15:47:09 <tcohen> ashimema: i moved Testbuilder specific discussion to next meeting yesterday
15:47:30 <ashimema> I missed that.. sos
15:47:36 <tcohen> not sure how to deal with that
15:47:41 <ashimema> next topic then :)
15:47:58 <tcohen> i pretended that we discussed the basis for the decision today
15:48:11 <tcohen> and also hear the folks from part 2
15:48:39 <tcohen> ok, moving on for now
15:49:07 <tcohen> #info we are voting the inclusion of TestBuilder next meeting
15:49:18 <tcohen> ok
15:49:27 <tcohen> #subtopic bugs that need feedback
15:49:36 <tcohen> - Bug 10273 GST/VAT/Tax rewrite - Needs more feedback!
15:49:37 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10273 normal, P5 - low, ---, jonathan.druart, ASSIGNED , Unit tests should not be dependent on the Jenkins database
15:49:51 <tcohen> :/
15:50:12 <Joubu> tcohen: Can I explain a liittle or you just list them?
15:50:23 <tcohen> please, explain
15:50:32 <Joubu> ok, so the entry point is the wiki page (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC).
15:50:57 <Joubu> I started to submit some patches last week (and today), I would like to get feedback on patches I already submitted.
15:51:06 <Joubu> I propose to explode the Acquisition module into small module under the  Koha namespace. I will add missing unit tests and use DBIC when  possible.
15:51:20 <Joubu> I really think this plumbing part is inevitable for the future of the  Acquisition module and to add a correct vat management.
15:51:41 <Joubu> That's why I am a little bit stuck, I cannot continue to develop other parts if the method I used is not validated by the developer team.
15:52:19 <Joubu> How I see the next steps: I will try to provide as many small changes as I can without any behavior changes.
15:52:21 <Joubu> When the code will be refactored, it will be easy to change the way prices are calculated.
15:52:48 <Joubu> I still plan to add the column configuration stuff to the acquisition tables (invoices, basket, etc.). But this will be one of the  last steps.
15:53:16 <Joubu> Some wording should be decide too. How the DB columns should be named? What about the rrp term? Is there a better appropriated term?
15:53:27 <Joubu> need native speakers here
15:53:30 <thd> Joubu: Do you know if the code supports tax rates which are more granular than the smallest unit of the currency?
15:53:34 <tcohen> i think refactoring that code is a valuable task, we need to support Joubu's effort
15:53:45 <oleonard> Native speakers who understand acquisitions :P
15:53:56 <ashimema> agreed.. refactoring is certainly super sensible.
15:54:14 <ashimema> so far so good Joubu..
15:54:21 <Joubu> I am trying to add as many UT as I can
15:54:45 <Joubu> But I cannot continue without getting a consensus on the patches I already submited.
15:54:53 <thd> Refactoring may be essential to resolving the problem that every free software accounting program does rounding incorrectly from an accounting perspective.
15:54:58 <tcohen> can u add links to those small-step patches/bugs?
15:55:14 <ashimema> whats the bug number again?
15:55:19 <ashimema> what he said
15:55:26 <Joubu> thd: you can give feedback on the RFC if you want. Some of these questions have already been discuted
15:55:39 <Joubu> ashimema: the entry point is the wiki page :)
15:56:00 <Joubu> then bug 12825
15:56:01 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12825 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , GST / VAT rewrite
15:56:06 <Joubu> then bug 12826
15:56:07 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12826 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , GST / VAT rewrite - plumbing
15:56:10 <ztajoli> As Cineca we have many attention on ACQ. We are starting to test the present patch as are on 'Need Sign off' status
15:56:27 <tcohen> #link GST rewrite http://wiki.koha-community.org/wiki/GST_Rewrite_RFC
15:56:40 <thd> Joubu: I know that the issue has been raised in the RFC.
15:56:57 <tcohen> #info feedback is needed urgently
15:57:20 <thd> Joubu: The same issues have been raised with free software accounting software without resolving the issue.
15:57:52 <ztajoli> for us the refactory line on Joubu is OK.
15:58:21 <Joubu> thd: You can share on the wiki page what is a correct rounding management, if you like.
15:58:32 <tcohen> can everyone interested give Joubu feedback on the RFC?
15:58:50 <ztajoli> For name of DB coloums we prefer the "long_name" policy
15:59:17 <tcohen> ztajoli: we will be discussing that on the next topics
15:59:47 <thd> Joubu: That is the problem that correct might even vary by the accountancy rules in a particular jurisdiction and defies programmer centric rules about significant figures etc.
16:01:13 <tcohen> thd, Joubu: please include those aspects of the problem on the RFC
16:01:18 <Joubu> I am not aware of these rules.
16:01:24 <Joubu> thd: yes, please
16:01:46 <ashimema> Joubu.. I'll take a look at those bugs.. but I'm currently working through qa on the UTF8 bug and QA on an emails bug.. they're tkaing allot of me qa time at the minute.
16:01:58 <tcohen> heh
16:02:01 <thd> tcohen: I will try to add appropriate comment and link to some discussions of the issue in free software accountancy programs.
16:02:10 <tcohen> thanks thd
16:02:13 <tcohen> moving on then
16:02:38 <tcohen> another one that needs feedback Bug 12830
16:02:40 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12830 enhancement, P5 - low, ---, jonathan.druart, Patch doesn't apply , Move the order-related code into its own module
16:03:18 <Joubu> 12830 and 12896 (submited today). A (new) try with Class:Accessor and DbIC
16:03:45 <Joubu> I would like to base the code on these 2 new modules for the rest of the rewrite.
16:04:27 <Joubu> khall: maybe? :)
16:04:58 <tcohen> #info Jonathan needs feedback on bugs 12830 and 12896. Specifically his approach to Class::Accessor and DBIc
16:05:23 <ashimema> worth poking rangi too for Class::Accessor advice ;)
16:05:45 <tcohen> he will (hopefully) be on part 2
16:06:13 <tcohen> we need to move ahead
16:06:36 <tcohen> #topic Additions to Coding Guidelines
16:07:09 <tcohen> there is a proposal from dcook to amend the coding guidelines
16:07:21 <Joubu> https://trello.com/c/8d7pELLj/28-coding-guidelines-koha-preference
16:07:39 <tcohen> so TT plugins are used for fetching preferences instead of passing them from .pl
16:07:53 <tcohen> can everyone view that link?
16:08:14 <Joubu> tcohen: yes I think so, the board is public
16:08:37 <pastebot> "tcohen" at 172.16.248.212 pasted "Proposed text fro Koha.Preference usage on TT" (3 lines) at http://paste.koha-community.org/197
16:09:09 <khall> yep and agreed
16:09:16 <ashimema> agree
16:09:18 <tcohen> ok, objections?
16:10:01 <tcohen> Koha.Preference usage mandatory then
16:10:06 <tcohen> ?
16:10:13 <atheia> out of curiosity, what is the reason for not passing in the variable in pl
16:10:14 <atheia> ?
16:10:18 <thd> When is HTML 7 coming :) ?
16:10:19 <atheia> is it purely conciseness?
16:10:35 <ashimema> atheia.. basically yes ;)
16:10:57 <atheia> OK. I think I'm fine either way then :-)
16:11:46 <tcohen> #agreed (subject to votes from part 2) https://trello.com/c/8d7pELLj/28-coding-guidelines-koha-preference will be added to Coding guidelines
16:12:09 <tcohen> next one: should we use DBIC on .pl scripts?
16:13:33 <tcohen> opinions?
16:13:33 <wahanui> opinions are slightly divded :)
16:13:34 <Joubu> I think this has already been discussed :)
16:13:42 <Joubu> And nobody agrees
16:14:01 <tcohen> meaning? there is no agreement on either?
16:14:26 <Joubu> I think DBIC should only be used in pm script. For the maintainability, for UT and for reusability
16:14:44 <Joubu> tcohen: in pm script... In pm module
16:14:49 <ashimema> I kinda agree with Joubu.. I feel the need for database lookups in pl scripts highlights a flaw in the .pm
16:14:55 <khall> Joubu: I would disagree. I think we should move in the long run to reducing the number of modules and moving logic into DBIC
16:15:17 <Joubu> the logic should be tested :)
16:15:30 <khall> agreed, it can still be unit tested
16:15:54 <ashimema> but we currently only demand unit tests on modules.. not scripts..
16:16:35 <ashimema> the line between what belongs in a module and what belongs in a script becomes rather fuzzy if we allow this?
16:16:38 <tcohen> business logic should be removed from the .pl scripts
16:16:39 <khall> that would still apply, the code would only move to Koha/Schema/Result and Koha/Schema/ResultSet
16:16:55 <khall> tcohen: agreed, the logic should not be in pl scripts
16:17:18 <tcohen> ok, should we vote?
16:17:40 <ashimema> so assuming we went to allowing dbic in scripts.. would we impose limits upon what it can be used for?
16:17:41 <tcohen> or do we all agree (at least) that no db call should be done on the .pl scripts? (it includes DBIC)
16:17:52 <tcohen> ah, we don't yet agree heh
16:17:54 <khall> using DBIC in pl scripts should be equivilent to using pm subs in pl scripts
16:17:59 <Joubu> tcohen: not really fair to vote. :)
16:18:34 <ashimema> khall.. where do you see the line being drawn?
16:18:41 <khall> tcohen: I think there is a line to walk here. I think using find and simple searches should be allowable in pl files
16:19:18 <khall> otherwise we are just jumping through hoops that don't need to be there
16:19:18 <Joubu> khall: why it's equivalent? If you call create something in the pl script, you want to test it
16:19:18 <tcohen> khall: I think CRUD operations are ok
16:19:18 <Joubu> khall: simple example: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12891
16:19:19 <huginn> 04Bug 12891: critical, P5 - low, ---, koha-bugs, Signed Off , NewOrder does not return ordernumber
16:19:20 <Joubu> critical bug found yesterday
16:19:37 <Joubu> We have to have an unit test for this regression
16:19:59 <thd> tcohen: You might exercise your authority as RM during your term, however, further discussion towards some consensus would be helpful.
16:20:12 <tcohen> thd: :-D
16:20:57 <khall> I don't think that is a good and applicable example Joubu
16:21:00 <Joubu> khall: ok last link is not relevant :)
16:21:15 <Joubu> yes, read too fast, sorry
16:21:42 <tcohen> can we discuss this on the list? so we have broader opinions and maybe reach some consensus?
16:21:43 <Joubu> khall: how to you defined "simple" searches?
16:22:14 <khall> anything where the search criteria isn't determined at run-time
16:23:18 <Joubu> khall: if you need the same result somewhere else, you will have to c/c your code
16:23:24 <khall> anything complicated we can have as a canned method for the resultset
16:23:31 <Joubu> tcohen: ok for a discussion on the list
16:23:49 <ztajoli> also for me ok for a discussion on the list
16:24:01 <khall> we really aren't taking advantage of the power of dbic at the moment
16:24:18 <tcohen> khall: we will soon :-D
16:24:25 <khall> we don't need a sub in a perl module, we can have a method in the ResultSet, which would be unit testable
16:24:44 <tcohen> khall: can you post an email to the list with your POV
16:24:55 <khall> module subs should only be needed when evaluation across tables is required
16:24:58 <khall> tcohen: sure!
16:25:00 <tcohen> including how to properly test our ResultSet classes?
16:26:21 <tcohen> #action Kyle will start a discussion on the koha-dev list on taking advantage of DBIc in our code base. We will discuss where to use DBIc, and how to properly test our ResultSet classes
16:26:42 <ashimema> and a coding guideline for it ;)
16:26:55 <tcohen> of course :-d
16:27:45 <tcohen> #cochair ashimema
16:28:16 <tcohen> need to run, ashimema will continue to chair
16:28:31 <tcohen> #chair ashimema
16:28:31 <huginn> Current chairs: ashimema tcohen
16:28:40 <ashimema> ok.. so moving on.
16:28:44 <tcohen> bbl, thanks everyone
16:29:31 <barton> next topic?
16:29:31 <wahanui> next topic is a tricky one...
16:29:49 <ashimema> #topic Naming of database columns
16:29:59 <ashimema> sorry, had to catch up in the agenda
16:30:24 <ashimema> khall.. I think this one was one of your suggestions.
16:30:29 <Joubu> It's a request from khall
16:30:35 <khall> yep
16:30:48 <ashimema> did you do some wording for a new guidline?
16:31:33 <khall> tables should be named as plurals with each word separated by underscores
16:31:42 <khall> we should follow standard dbic naming conventions
16:31:49 <ashimema> or, whilst you come up with some wording.. can we agree to column_name as convenstions?
16:31:52 <khall> I'll try to locate a document that specifies them, if there is one
16:32:53 <ashimema> #info column_names made up of multiple words should be joined with underscore to maintain dbic standards
16:33:24 <ashimema> I'm happy to go with that.. does everyone agree?
16:33:29 <khall> and should be plural
16:33:32 <barton> +1
16:33:38 <ashimema> makes sense to go forward being dbic compliant
16:33:43 <ashimema> +1
16:33:48 <atheia> +1
16:33:53 <ztajoli> aslo for me makes sense to go forward being dbic compliant
16:33:55 <ztajoli> +1
16:34:02 <khall> koha_widgets rather than koha_widget
16:34:03 <Joubu> not sure about the plural form.
16:34:11 <Joubu> But +1 to follow DBIC conventions
16:34:24 <ashimema> plural form is a dbic convention too is it not?
16:34:31 <oleonard> +1
16:34:54 <ashimema> either way.. I think the dbic convenstions are sensible and it would be nice to tie it down to them..
16:35:04 <ashimema> khall you ok to add a rule to the guidlines?
16:35:31 <Joubu> an url could be useful
16:35:40 <khall> yes
16:36:20 <khall> I think the rule should just be 'follow dbic conventions' and list the important parts ( underscores, plurality, etc )
16:37:05 <khall> that would include the primary key being 'id' and any foreign keys being the table name, rather than the primary key name
16:37:06 <ashimema> #agreed To add a rule to the coding guidelines that mimicks that of the dbic conventions for column_names pending this evening meeting
16:37:52 <ashimema> #info exact wording of guidline to be decided (after looking up dbic specifics)
16:37:57 <ashimema> we ok to move on?
16:38:59 * ashimema wonders if he's started talking to himself?
16:39:08 <thd> yes
16:39:22 <ashimema> #topic Requirements for CLI scripts
16:40:04 <Joubu> I can c/c the note I put on the trello:
16:40:05 <ashimema> First:Are we happy with Joubu's suggestions?
16:40:14 <ashimema> yes please :)
16:40:17 <Joubu> I thought some guidelines existed for Koha scripts, but actually they don't (or I don't find them, I did not search for a lot).
16:40:18 <Joubu> I propose misc/cronjobs/delete_patrons.pl as an example of the best pratices (I don't tell that because I am the author...).
16:40:25 <Joubu> It uses: - Pod::Usage
16:40:25 <Joubu> - GetOpt::Long
16:40:25 <Joubu> - the -c parameter to confirm the changes
16:40:26 <Joubu> - call pod2usage if something wrong with the parameters
16:40:26 <Joubu> - add the POD at the end of the file
16:41:16 <thd> I am not certain about forcing -c as the confirmation parameter.
16:41:33 <ashimema> most seems sensible to me (and is how I've been writing recent scripts too).
16:41:38 <ashimema> I also wonder about the -c..
16:41:45 <ashimema> do 'all' scripts need a confirmation?
16:41:53 <khall> I agree in general, but these rules will mean I probably will not continue development of my cli patron importer.
16:42:04 <ashimema> and if they do.. should they all have a 'dry run' mode
16:42:05 <Joubu> ashimema: not all, but gmcharlt_ asked that when he was RM
16:42:23 <thd> I can see the advantage of consistency but adopting some script existing in the world may be a problem.
16:42:44 <ashimema> are you doing much on the patron importer khall?
16:43:26 <ashimema> I felt your bringing the liblime patch up to date was more of a stop gap, whilst a proper refactoring of the imports stuff was done.. (i.e splitting out import into a module)
16:43:27 <khall> it's good to go. I would like to just have the tools patron importer work from the command line, which is what my first addition of the patch did
16:43:48 <thd> I favour requiring a confirmation switch if running the script without parameters otherwise might do something bad or unexpected.
16:43:52 <khall> I was told this is frowned upon, so I made it cli only
16:43:59 <ashimema> (it doesn't work with patron attrbiutes btw; ;) )
16:44:10 <khall> but now it has alot of duplicate code
16:44:41 <oleonard> Are there objections to requiring that new cli scripts must have a confirmation parameter?
16:44:56 <khall> splitting everything out to a module is the best way to go, I can totally agree.
16:45:29 <barton> do we have any scripts that don't alter data?
16:45:44 <ztajoli> for me +1 on must have a confirmation parameter
16:45:55 <thd> All the scripts which I write merely display usage information if run without parameters.
16:46:09 <khall> question: what will the standard behavior for not passing -c be?
16:46:12 <atheia> What would happen if no -c parameter is passed?
16:46:15 <atheia> indeed :-)
16:46:18 <khall> dry run if possbile?
16:46:24 <Joubu> khall: yes
16:46:31 <khall> just a warning if lazy? ; )
16:46:38 <Joubu> khall: I set the verbose flag when -c is not given
16:46:47 <thd> I like even requiring a parameter for test mode.
16:46:48 <oleonard> I would expect the script to show help information if the -c was not passed
16:47:11 <ztajoli> also I  would expect the script to show help information if the -c was not passed
16:47:19 <ashimema> so we agree to needing some guidlines..
16:47:26 <ashimema> but can't agree yet on the -c
16:47:33 <atheia> but surely if you invoke a script you expect it to do something - why else would you invoke it?
16:47:36 <thd> If default displays usage information you do not need to read the source code to determine the help parameter.
16:47:42 <khall> agreed, we should require -c, display help if no -c, and have -t for dry runs
16:47:47 <atheia> So I think there should be a tangible benefit in forcing the user to pass -c
16:47:56 <atheia> like running in dry-run makes sense
16:48:03 <atheia> But just showing help does not…
16:48:08 <atheia> If you see what I'm saying?
16:48:23 <ashimema> hmm..
16:48:37 <barton> I'm with atheia...
16:48:39 <khall> atheia: I think the tangible benefit is getting the help and not altering the db by accident
16:48:40 <Joubu> atheia: yes, I agree
16:48:43 <thd> I object to requiring confirmation parameter to be -c.
16:49:00 <khall> thd: why?
16:49:59 <atheia> OK, so just running this through:
16:50:13 <ashimema> go on
16:50:20 <thd> It may be a good default but a strong requirement may complicate adapting and maintaining some existing script from outside Koha to Koha.
16:50:44 <atheia> If we require -c to do something to the db we're saying it's a fail-safe against accidental use.
16:51:05 <Joubu> thd: are you asking for scripts you are going to submit on bugzilla?
16:51:12 <oleonard> thd: Do you have an example?
16:51:15 <atheia> So we are targetting this at someone who normally does not use cli commands, and who would simply expect information when running a command, rather than behaviour?
16:51:57 <thd> Many scripts in the world use -c for other purposes.  FSF recommends -c for displaying copyright information.
16:52:14 <oleonard> thd: So all you object to is the letter choice?
16:52:21 <thd> Yes
16:52:34 <khall> how about —confirm
16:52:37 <thd> I perfectly agree with requiring some confirmation
16:52:38 <Joubu> thd: it's like that for a lot of Koha scripts...
16:52:39 * oleonard doesn't really care about the letter, just the behavior
16:53:04 <ashimema> I see..
16:53:16 <barton> I'm not so hot on the behavior -- it feels distinctly un-unixy.
16:53:22 <ashimema> so we're now agreeing to a --confirm..
16:53:30 <Joubu> atheia: yes
16:53:31 <ashimema> but not yet to it's action
16:53:37 <thd> Joubu: I merely identify a potential problem for bringing some new script into Koha adapted from another community.
16:53:42 <ashimema> i.e if missing.. dry run.. or if missing.. help
16:53:43 <khall> I do agree with barton's point
16:54:10 <barton> I would expect a dry-run without action.
16:54:26 <ashimema> I'm thinking without confirm it should dry run preferably..
16:54:33 <indradg> +1 for dry run
16:54:37 <khall> is there any precedent for this behavior with other unix utils?
16:54:38 <barton> ... if '--confirm' (or perhaps --commit) were missing.
16:54:43 <ashimema> but I don' think allo of our current scripts do dry runs at all ;)
16:54:46 <Joubu> ashimema: actually if the output is explicit, we don't care...
16:55:14 <thd> Does GetOpt::Long prevent a short form from doing something.  It had not in my past testing.
16:56:01 <atheia> I would like the behaviour to be dryrun but I think requiring it for cli scripts would be pretty difficult, just in terms of providing a 'dryrun mode' for existing and even new scripts.
16:56:29 <atheia> Generally one might require confirmation for dangerous behaviour so there is some precedent in unixy tools.
16:56:30 <thd> I favour requiring a parameter even for dry runs.
16:56:37 <ashimema> how about.. if possible to dry run.. then without confirm we get dry run.. if not possible to dry run.. we return help
16:56:44 <khall> are we just saying that we can't trust sysadmin's to use Koha's scripts correctly with this idea?
16:56:52 <thd> Dry runs of some possible scripts could thrash your system.
16:57:03 <atheia> But what we're saying here is that scripts are always dangerous, and that we don't trust the user by default.
16:57:09 <ashimema> very true.. hadn't thought of that case thd
16:57:50 <ashimema> i'm sort of edging toward.. no confirm always give help test.. and a dry run requires a -t (but not nessarily a --confirm)?
16:57:54 <thd> All of the scripts which I write do nothing but display usage information when invoked without parameters.
16:58:09 <ashimema> I also agree to that thd.
16:58:12 <oleonard> atheia: You can also think of it as making scripts user-friendly, since the user doesn't have to be afraid to try running them
16:58:18 <khall> ashimema: dry run should definitely not require confirm.
16:58:25 <khall> they should be mutually exclusive
16:58:32 <ashimema> agreed khall
16:58:34 <atheia> What dry-run would trash a system? that's a crazy dry-run? or am I naive here?
16:58:49 <khall> heavy db reading
16:58:58 <ashimema> heavy db reading
16:59:02 <ashimema> jinx
16:59:06 <khall> lol
16:59:07 <atheia> ah interesting :)-
16:59:08 <atheia> :-)
16:59:11 <atheia> makes sense.
16:59:29 <barton> atheia: I think that was thrash, not trash
16:59:34 <thd> khall: What about a script which reads your entire database and manipulates it without writing anything as thrashing dry run behaviour?
16:59:44 <Joubu> so we need to confirm the dry-run?
16:59:47 <Joubu> (;))
16:59:50 <ashimema> ok..  can i go for an agreed on.. we need guidlines for it.. and we agree on --confirm for all scripts.. and lack therof displays help
17:00:20 <atheia> fine by me.
17:00:45 <ztajoli> also for me
17:00:50 <khall> not sure we've reached consensus, but I can accept —confirm and —test with the default being the help
17:00:51 <Joubu> yep
17:00:51 <ashimema> #agreed To add requirement for new CLI scripts to guidlines
17:01:07 <barton> I'm with khall.
17:01:21 <thd> When I tried to write --something parameters in the past using GetOpt::Long I found that -s would have the same function.
17:01:26 <atheia> +1 for khall's statement.
17:01:31 <khall> —test shouldn't be mandatory, as some scripts can't do dry runs
17:01:40 <ashimema> #info Pod::Usage, GetOpt::Long, pod2usage, POD at end of file and --confirm (where lack of display help test)
17:01:51 <khall> thd: it can be done
17:02:22 <atheia> barton: indeed, subtle difference between thrash and drash :-)
17:02:22 <ashimema> is that info comprehensive enough without blocking too much?
17:02:23 <khall> please add examples with the rules when possible to help new developers
17:02:34 <indradg> +1 khall
17:02:43 <ashimema> anyone facny havig a punt at wording that for the guidlines and adding it?
17:02:48 <khall> what about —test ? are we not making a decision on that?
17:02:54 <thd> khall:  I may have solved it the past but you will show me if I do not see that in my old code ;)
17:02:59 <ashimema> I don't think --test should be mandatory..
17:03:00 <khall> we can just say it's a strong recommendation and best practice
17:03:20 <ashimema> ok by me..
17:03:27 <ashimema> but.. shall we move onto the next topic ;)
17:03:34 <khall> agreed.
17:03:37 <atheia> agreed.
17:03:46 <thd> Recommended with the explanation of please avoid thrashing the user's system by surprise.
17:04:02 <ashimema> #topic Wording of bug 10860
17:04:03 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10860 enhancement, P5 - low, ---, jonathan.druart, Needs Signoff , In-House Use
17:04:17 <Joubu> ashimema: could you explain for me please? :)
17:04:24 <ashimema> did anyone come up with any alternatives ti 'In house use'
17:04:39 <ashimema> So..
17:04:58 <khall> how about "on-site only"
17:05:01 <ashimema> The feature is for statistical tracking basically..
17:05:16 <ashimema> haha.. funnily enough. that's what I ended up suggesting.
17:05:58 <barton> I'm still not clear what this feature does.
17:06:26 <Joubu> Why "inhouse use" is for anonymous use only?
17:06:32 <ashimema> We've already go statistical users for tracking when an item has been 'used' withn the library (i.e left out on a desk at the end of the day)..
17:06:51 <khall> I'm assuming it gives the ability to track the use of an item that can't be removed from the library
17:06:56 <ashimema> Joubu's feature adds the ability to track specifc uses by patrons for say a monitored material that's not alloud to leave the library..
17:07:01 <jcamins> +1 for on-site use
17:07:02 <ashimema> that's about ti right, joubu
17:07:03 <khall> this connects the use of the item to a patron, correct?
17:07:04 <thd> khall: I think the issue I had with long parameters was forcing the same behaviour for shell scripts between bash MSDOS and Perl for parameters.
17:07:44 <khall> thd: I could see that happening. However, Koha no longer functions on Windows, so it should be a non-issue.
17:07:47 <atheia> yeah, from what I understand on-site is better
17:07:51 <jcamins> This is a very common scenario in rare book libraries.
17:07:52 <atheia> +1 on-site
17:07:52 <ashimema> We've got normal lending (off site), we've got statistical lending (were the librarian performs a check in to signify an anonymous has of I item on site) and finally there monitored reference only use (on site, but not anonymous).
17:08:19 <Joubu> ok thanks everybody :)
17:08:20 <jcamins> I'd vote for "in-house" except we're already using that for statistical purposes.
17:08:28 <nengard> local use?
17:08:33 <nengard> that's another way people refer to it
17:08:38 <ashimema> hehe.. jcamins don't stir ! ;)
17:09:01 <jcamins> ashimema: sorry!
17:09:05 <khall> my vote goes to 'on-site'
17:09:08 <ashimema> I felt 'local use' wasn't descriptive enough for some reason.. can't rmember why though
17:09:23 <ashimema> you happy with 'on-site' Joubu?
17:09:33 <ashimema> if so.. we'll move on :)
17:09:34 <Joubu> I am happy with what you want :)
17:09:54 <Joubu> I just don't want to do this massive change twice
17:09:58 <khall> %s/In-House/On-Site/g
17:10:01 <ashimema> #info Agreed that 'on-site' was a better wording than 'in-house'
17:10:05 <ashimema> :)
17:10:17 <Joubu> khall: yes, more or less :)
17:10:26 <ashimema> next topic
17:10:27 <wahanui> next topic is a tricky one...
17:11:01 <ashimema> #topic Big Stuff we're working on?!
17:11:09 <ashimema> any more for any more?
17:11:38 <Joubu> hea is coming (see hea.koha-community.org)
17:12:01 <ashimema> #info hea.koha-community.org is coming :)
17:12:02 <khall> Accounts Rewrite. It's been pretty much bullet proofed. I expect qa issues will involve internationalization
17:12:15 <ashimema> ooh.. that link didn't work for me last night..
17:12:17 <ashimema> it works today.
17:12:26 <Joubu> (Bug I don't find guinea pigs to test it)
17:12:29 <Joubu> but
17:12:38 <khall> neat!
17:12:51 <ashimema> #info account rewrite is getting there.. wohoo
17:12:57 <atheia> hea is looking nice!
17:13:29 <ashimema> I'm about to add it to our customer repository Joubu.. then i just need to talk customers into turning it on ;)
17:13:37 <Joubu> see bug 11926
17:13:38 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11926 new feature, P5 - low, ---, jonathan.druart, ASSIGNED , Render community koha statistic usages
17:13:58 <ashimema> #info hea is bug 11926
17:14:09 <Joubu> you can upload your data (test installation only!, the data will be deleted)
17:14:25 <ashimema> :)
17:14:50 <ashimema> any mroe for any more?
17:14:51 <ztajoli> UTF-8 QA ?
17:15:08 <ashimema> ztajoli, i'm still working on it..
17:15:12 <ashimema> it's a biggen ;)
17:15:51 <Joubu> ashimema: it could be good not to squash the patches. I think we need to keep the history, if something wrong happened
17:16:00 <ashimema> deffo.
17:16:09 <ashimema> shame tcohen has gone..
17:16:14 * Joubu does not know why he told that
17:16:18 <ashimema> he was working on tests for it was he not?
17:16:29 <Joubu> I don't know, I hope :)
17:17:02 <ashimema> #info bug 11944 is working it's way through QA
17:17:04 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944 major, P5 - low, ---, jonathan.druart, Signed Off , Cleanup Koha UTF-8
17:17:37 <Joubu> ashimema: no new stuff (except vat rewrite:)) from BibLibre planned
17:17:45 <ashimema> this actually moves us on nicely to
17:17:56 <ashimema> #topic Actions from last meeting
17:18:25 <ashimema> #info ashimema added a note to the wiki to encourage use of columns stuff for datatables
17:18:58 <ashimema> #info ashimema has started qa for UTF8 bug.. minimal comments left already
17:19:33 <ashimema> #info Waiting to hear from gmcharlt, tcohen regarding utf8 tests
17:19:49 <ashimema> that's all the actions in the minutes..
17:19:55 <ashimema> any more for any more?
17:20:40 <ashimema> #topic Next Meeting?
17:21:14 <ashimema> Worth keeping the momentum and having another same time next week.. or should we have a bigger gap..
17:21:21 <Joubu> next tuesday? (maybe a little bit shorter :))
17:21:23 <ashimema> hopefully these meets will get shorter soon.
17:21:29 <ashimema> what he said..
17:21:39 <atheia> next tuesday is fine with me.
17:21:44 <ztajoli> Ok for me
17:21:46 <ashimema> done
17:22:09 <ashimema> #agreed Same time next week.. assuming that's ok with the guys this evening
17:22:12 <Joubu> It would be great to have some discussion on the trello board, before the meeting
17:22:19 <ashimema> #agreed meeting needs to be kept shorter
17:22:24 <Joubu> in order no to debate from the beginning.
17:22:44 <ashimema> yeah.. I agree. we should make more sue of trello and use the meeting to bascially vote and assign tasks.
17:22:51 <Joubu> (trello or alternative)
17:23:18 <ashimema> #info more chat on the trello board before the meeting.. try to limit the meeting to agreements and assignments of work.
17:23:28 <thd> Joubu why does the trello board complain about my web browser?
17:23:39 <ashimema> #endmeeting