22:03:04 <tcohen> #startmeeting Development IRC meeting, 9 September 2014 (part 2)
22:03:04 <huginn> Meeting started Tue Sep  9 22:03:04 2014 UTC.  The chair is tcohen. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:04 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:03:04 <huginn> The meeting name has been set to 'development_irc_meeting__9_september_2014__part_2_'
22:03:26 <tcohen> #topic Introductions
22:03:26 <wahanui> #info wahanui, a bot that has become sentient
22:03:38 <cait> #info Katrin Fischer
22:03:38 <tcohen> #info Tomas Cohen Arazi, Universidad Nacional de Cordoba
22:03:47 <wizzyrea> #info Liz Rea, Catalyst IT
22:03:50 <bag> #info Brendan Gallagher ByWater
22:04:09 <JasonBurds> #info Jason Burds I.T. Supervisor Carnegie-Stout Public Library
22:04:29 <tcohen> which bug rangi?
22:05:09 <tcohen> #topic RM 3.18 comments
22:05:32 <tcohen> as i mentioned earlier, my work on facets is pretty complete
22:05:53 <cait> tcohen++
22:05:54 <tcohen> that is to say I'll try to focus on UTF-8 regression tests
22:05:58 <wizzyrea> \o/
22:06:13 <tcohen> #info facets from zebra is needs sign off, bug 11232
22:06:15 <wahanui> i already had it that way, tcohen.
22:06:15 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232 new feature, P5 - low, ---, gmcharlt, Needs Signoff , Retrieve facets from Zebra
22:06:40 <tcohen> thanks to jcamins and indexdata for their support
22:06:51 <cait> tcohen: just a quick question - it#s dom only now?
22:07:05 <tcohen> good question: yes
22:07:06 <cait> which is ok, just for testing
22:07:38 <tcohen> i focused on XSLT's and defining almost-good syntax for the XML file
22:07:42 <tcohen> to define facets
22:08:29 <tcohen> https://github.com/tomascohen/koha/commit/281808cce6cc94e26beb6281ec44daada0a85595
22:09:00 <bag> NateC?
22:09:00 <wahanui> I LIKE SPACE AND MY WIFE
22:09:14 <bag> heh my favorite - (sorry to interrupt the meeting)
22:09:25 <tcohen> heh
22:09:35 <tcohen> moving on?
22:09:46 <bag> yup
22:09:47 <tcohen> #topic General technical discussion
22:09:48 <cait> yep
22:09:58 <tcohen> #subtopic To mock or not to mock...?
22:10:21 <tcohen> there's been a discussion on the subject
22:10:24 <tcohen> https://trello.com/c/vsrkdpvv/27-tests-mocking-when-to-and-when-not-to-that-is-the-question
22:12:03 <tcohen> on part 1, it was discussed in a broader way
22:12:22 <tcohen> trying to speak about the whole testing stuff we've collected on the project
22:12:27 <tcohen> the pros and cons
22:13:15 <tcohen> my position was that ideally we should have complete unit tests for out methods, with all their dependencies mocked, to prevent side effects upon testing
22:13:28 <tcohen> *and* also have a means to have proper integration tests
22:14:06 <tcohen> TestBuilder appears as a way to write more tests in an easier way
22:14:28 <tcohen> they are more like integration tests
22:14:51 <tcohen> and there was some agreement they shouldn't have side effects, create its own semi-randomized data
22:15:12 <tcohen> I proposed they should be able to run randomly (no side effect between unit tests)
22:15:38 <tcohen> opinions?
22:15:38 <wahanui> opinions are slightly divded :)
22:16:33 <cait> I am a little worried about people forgetting what actualyl happens in the background with a tool like testbuilder
22:17:15 <cait> it#s also another tool to learn - would it be mandatory?
22:18:03 <tcohen> the main idea is that if your test needs a patron, you create it with testbuilder
22:18:22 <tcohen> no need to create all stuff needed to create a patron before creating it
22:18:25 <cait> why not create it with koha's methods?
22:18:38 <cait> hm
22:18:55 <tcohen> because if you cannot depend on DB's content (ideally)
22:19:07 <tcohen> you need to create the patron category, the branches, etc
22:19:11 <rangi> i think everyone knows that im against the idea
22:19:40 <tcohen> certaintly
22:20:08 <rangi> its 1/ another tool for people to learn 2/ something that needs its own tests 3/ something we have to maintain 4/ makes people not understand how the db actually works
22:20:29 <cait> i tend to agree
22:20:59 <rangi> but as long as its not mandatory
22:21:02 <rangi> then i can ignore it
22:21:38 <tcohen> I personally prefer to mock
22:21:59 <tcohen> it is methodologically cleaner
22:22:08 <tcohen> and it is simpler to write tests
22:22:13 <rangi> and something that other perl developers would have seen before
22:22:24 * gmcharlt_ feels much the same way as rangi; I don't think it that's hard to more directly create required rows in dependent tables
22:22:36 <tcohen> my experience with Test::MockObject is positive
22:22:50 <tcohen> hi gmcharlt
22:22:51 <cait> i'd like if there was a tutorial or something for beginners with mock
22:23:16 <tcohen> we can spend some time on that during hackfest cait
22:23:18 <cait> maybe hackfest?
22:23:19 <cait> :)
22:23:41 <tcohen> maybe *someone* can run a tutorial
22:24:30 <cait> but I think by adding more 'koha ways' of doing things, we might make things harder in the end
22:25:02 <tcohen> do you guys agree each test should build its own data?
22:25:21 <cait> yes, i think it would be nice to get the tests to be able to run on any database
22:25:32 <cait> without needing special data or leaving traces
22:25:54 <cait> if i got the question correctly
22:25:55 <tcohen> and also, should we spend time writing mocked tests or complete multiple-pieces integrated tests?
22:26:18 <cait> not sure about the terms/differences, sorry
22:26:39 * tcohen tends to be non-idiomatic
22:28:59 <tcohen> i'm trying to read questions raised on part 1, so we have more opinions
22:29:42 <tcohen> has anyone read the TestBuilder code yet?
22:30:49 <cait> not closely
22:31:38 <tcohen> ok, moving on then
22:32:22 <tcohen> will skip some items, and put them on the "bgs" topic
22:32:32 <tcohen> #topic Additions to Coding Guidelines
22:33:22 <tcohen> there is a proposal from dcook to add the use of Koha.Preference on TT instead of passing syspref values from .pl scripts
22:33:45 <tcohen> #link coding guidelines foe using Koha.Preference https://trello.com/c/8d7pELLj/28-coding-guidelines-koha-preference
22:34:12 <cait> ok for me for new code
22:34:19 <tcohen> part 1 agreed to add that to the coding guidelines, it is for new code
22:34:20 <cait> i think rewriting old code will only introduce bugs
22:34:42 <pianohacker> I like the guideline for new code, yes
22:34:51 <tcohen> if anyone has the time to do it, we'll see what happens
22:35:04 <tcohen> it could be done as training on the hackfest, dunno
22:35:24 <tcohen> should we vote?
22:36:15 <cait> +1
22:36:19 <tcohen> +1
22:36:46 <pianohacker> +1
22:36:55 <gmcharlt> +1
22:37:02 <rangi> +1
22:37:32 <tcohen> #agreed adding Koha.Preference use to coding guidelines
22:38:11 <tcohen> #topic should we use DBIC on .pl scripts?
22:38:31 <tcohen> during part 1 we decided to move the discussion to the list
22:38:47 <tcohen> and khall was forced to volunteer to post an email to the dev list on the subject
22:39:19 <tcohen> the key point being that sooner than later we should start using DBIc more extensively
22:40:30 <tcohen> and using DBIC ResultSet for crud operations is not different from using our own crafted packages
22:41:21 <rangi> havent really thought about it enough to know if i like it or not
22:41:25 <tcohen> anyone wants to write his/her opinion on the subject here?
22:41:28 <eythian> I don't think I like it.
22:41:48 <eythian> our modules should present a data-storage-independent API
22:41:59 <eythian> depending on a database at the .pl level doesn't mesh with that.
22:42:02 <rangi> im leaning that way, but dont have enough thoughts to write up an email yet
22:42:48 <tcohen> my opinion is, in principle, that using dbic is similar to using dbi at the .pl level, and i tend not to agree
22:43:07 <eythian> yep
22:43:11 <tcohen> khall thought he had a point on what we could be doing with dbic that we dont
22:43:16 <rangi> i think we shouldnt do either yeah, no dbi and dbic at the pl
22:43:22 <tcohen> so he offered to post that on the list
22:43:25 <rangi> cool
22:44:12 <tcohen> ok, we are all encouraged to post our opinions once that email is posted
22:44:21 <tcohen> don't leave khall aloooone
22:44:39 <cait> :)
22:44:46 <tcohen> #topic Naming of database columns
22:45:08 <tcohen> in line with the preivous one (not a coincidence) khall proposed that we adopt
22:45:28 <tcohen> a naming cenvention for table/column names
22:45:55 * eythian feels that horse may have bolted :)
22:46:08 <tcohen> essentialy, that we follow standard dbic naming convention
22:46:47 <tcohen> eythian: meaning?
22:47:02 <eythian> naming is already a bit of a mishmash
22:47:29 <tcohen> eythian: stop making me use google translate
22:47:31 <eythian> (that's not really a reason to not start having a standard though.)
22:47:37 <tcohen> :-P
22:48:39 <tcohen> part one voted to add to the coding guidelines
22:48:51 <tcohen> "To add a rule to the coding guidelines that mimicks that of the dbic conventions for column_names pending this evening meeting"
22:49:42 <tcohen> any objections
22:49:43 <tcohen> ?
22:49:46 <eythian> so the dbic convention is to use underscore_style?
22:49:52 <tcohen> yes
22:51:45 <cait> and plurals on table names i think
22:52:02 <tcohen> OO style
22:52:57 <tcohen> and 'id' for primary key
22:53:03 * tcohen is reading the logs
22:53:18 <tcohen> khall will propose the wording
22:53:37 <tcohen> maybe we should just vote/agree on following DBIC conventions and next meeting vote the wording
22:54:37 <cait> not sure what it implies, it does sound ok so far
22:55:26 <tcohen> as eythian said, that horse has already bolted
22:55:41 <tcohen> no harm on having *any* naming convention
22:55:50 <cait> tcohen: now you want to make me use google translate?
22:56:07 <gmcharlt> well, one question is whether anybody cares to make a committment to revise the schema to match
22:56:49 <gmcharlt> if not, then I think it would need to be very clear that any such convention applies only to new tables and columns
22:56:58 <cait> hm good point
22:58:14 <bag> I could agree with new tables and columns
22:58:38 <cait> i am not sure about the gain
22:58:44 <bag> either way - it's still a pain in the a..  and you really have to have an idea of what you are looking for
22:58:52 <eythian> I wonder if we can make dbic pretend like existing things have the properly styled names, to make renaming the actual existing tables/columns easier in the future.
22:58:59 <cait> just changing to meet guidelines is difficult, we tend to introduce bugs, even with careful rewrites all the time
22:59:30 <rangi> yeah, new ones seems ok, changing old ones seems like a way to make a mess
22:59:36 <tcohen> gmcharlt: people like Yohann worked on moving from DBI to using DBIc, maybe we should encourage people doing that, to revisit the current table/column names
23:00:29 <tcohen> eythian: i like your idea, maybe we could ask khall to do some research on that
23:00:36 <tcohen> (as part of the thread)
23:01:06 <cait> sorry much too late here, need to go
23:01:12 <cait> good night
23:01:13 <wahanui> If you feel like someone is looking through wahanui's window, it's OK, it's just me.
23:01:16 <tcohen> night
23:01:35 <gmcharlt> eythian: yeah, I think such aliasing would be doable
23:01:54 * bag sent a note to khall
23:02:51 <tcohen> can we say we agree new tables/columns should follow DBIc naming convention, and it should be written in the coding guidelines?
23:03:13 <bag> 0 - no vote
23:04:14 <tcohen> gmcharlt, eythian, rangi?
23:04:24 <tcohen> pianohacker?
23:04:25 <wahanui> I HATE XML
23:04:28 <tcohen> heh
23:04:29 <bag> HA
23:04:39 <eythian> I think so, yeah
23:04:40 <rangi> hmm yeah no opinion yet
23:04:43 <rangi> 0 for me
23:04:44 <gmcharlt> I LOVE XML (... followed by cavets)
23:04:46 <gmcharlt> 0 for me
23:05:03 <bag> I vote 0 cause I'd like some research first
23:05:09 <eythian> I also don't have a strong opinion on it :)
23:05:49 <pianohacker> no opinion on the changing existing tables, but I am in favor of new ones following guidelines
23:07:28 <tcohen> ok we agree we could have a coding guideline, and some research is needed to figure how a migration path would develop
23:07:33 <tcohen> ?
23:08:22 <bag> sure +1
23:08:30 <pianohacker> +1
23:08:59 <tcohen> #info there is a partial agreement on having coding guidelines that match DBIc ones, concerns raise about how to migrate existing tables/column names and research is needed
23:09:13 <tcohen> #topic Requirements for CLI scripts
23:09:31 <tcohen> Jonathan proposed some coding guidelines for CLI scripts
23:09:42 <tcohen> he proposes:
23:09:48 <tcohen> - Pod::Usage
23:09:53 <tcohen> - GetOpt::Long
23:09:59 <tcohen> - call pod2usage if something wrong with the parameters
23:10:05 <tcohen> - add the POD at the end of the file
23:10:10 <tcohen> - the -c parameter to confirm the changes
23:11:06 <tcohen> JOubu mentioned gmcharlt asked CLI scripts to have a dry run mode too when he was MR
23:11:08 <tcohen> RM
23:11:18 <pianohacker> all of these are close enough to a de facto standard that I think enshrining them is an excellent idea
23:11:27 <rangi> the only one
23:11:28 <rangi> is -c
23:11:37 <rangi> thats pretty much universally used for config
23:11:51 <rangi> in the posix world
23:11:52 <tcohen> you're right
23:12:02 <rangi> i think that might get confusing
23:12:13 <gmcharlt> --run ?
23:12:22 <pianohacker> rangi: isn't there a strong trend to use -f for that outside of coreutils?
23:12:24 <eythian> why not --dryrun
23:12:32 <eythian> or something like that
23:12:50 <eythian> i.e. reversing the sense so that you're putting it into a test mode.
23:13:49 <pianohacker> eythian: a lot of the scripts where this might apply can be massive data shotguns if fat-fingered or used without understanding, I vote for keeping dry-run as the default
23:14:16 <eythian> if you use it without understanding, you've got bigger problems anyway.
23:14:32 <pianohacker> true, but it makes for angrier mailing list posts ;)
23:14:39 <gmcharlt> an alternative might be adopting --dryrun, but also ensuring that just running the script without any parameters doesn't do anything except show the help
23:14:45 <rangi> yeah
23:14:46 <eythian> however, if it's dry run by default, it needs to make it _really_clear_, as there are some scripts that don't and it's very confusing.
23:15:02 <gmcharlt> at least for the ones that would be destructive if (passively) misused
23:15:03 <rangi> i like the do nothing without at least one param option
23:15:28 <eythian> the linkbibstoauthorities is one offender, its output is actually different when it's in dryrun mode.
23:15:43 <eythian> (in a way that you can't tell if it was going to do the right hting or not.)
23:15:52 <pianohacker> I like do-nothing-with-no-params regardless of dryrun being default or not
23:16:01 <eythian> yeah
23:16:14 <gmcharlt> at least in this case, there are a small enough number of such scripts that we can reasonably expect to ahve the tuits to bend them all to our will, whichever convention we decide on
23:16:19 <eythian> almost everything has options anyway
23:18:37 <pianohacker> I think we all agree on everything but dryrun; should we vote on the guidelines besides that portion?
23:19:18 <tcohen> guys, need to leave, can anyone chair?
23:19:28 <gmcharlt> I'll grab it
23:19:33 <tcohen> thanks
23:19:36 <tcohen> #chair gmcharlt
23:19:36 <huginn> Current chairs: gmcharlt tcohen
23:19:53 <gmcharlt> ok, I'll take up pianohacker's suggest
23:20:36 <gmcharlt> #startvote Shall we adopt the pod* & Getopt::Long sections of the propose CLI script guidelines? Yes, No, Abstain
23:20:36 <huginn> Begin voting on: Shall we adopt the pod* & Getopt::Long sections of the propose CLI script guidelines? Valid vote options are Yes, No, Abstain.
23:20:36 <huginn> Vote using '#vote OPTION'. Only your last vote counts.
23:20:40 <gmcharlt> #vote yes
23:20:43 <pianohacker> #vote yes
23:20:50 <tcohen> #vote yes
23:21:08 <eythian> #vote yes
23:21:12 <rangi> #vote yes
23:21:55 <gmcharlt> kk
23:21:56 <gmcharlt> #endvote
23:21:56 <huginn> Voted on "Shall we adopt the pod* & Getopt::Long sections of the propose CLI script guidelines?" Results are
23:21:56 <huginn> Yes (5): rangi, gmcharlt, tcohen, pianohacker, eythian
23:22:18 <gmcharlt> who wants to start a thread on koha-devel about --dryrun? eythian?
23:22:27 <eythian> sure
23:22:48 <gmcharlt> #action eythian will start a discussion on koha-devel about --dryrun behavior for CLI scripts
23:23:26 <gmcharlt> #topic Call for feedback
23:24:38 <gmcharlt> #info Joubu is requesting feedback on bug 10860, which adds a "reading room"/"in house use" feature
23:24:39 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10860 enhancement, P5 - low, ---, jonathan.druart, Needs Signoff , In-House Use
23:27:34 * gmcharlt has now left some feedback
23:27:43 <gmcharlt> any other comments on this before we move on?
23:27:51 <eythian> it needed a better explanation, it wasn't until I got to dcook's comment that I figured it out.
23:29:04 <rangi> ah yeah, i have nothing else to add
23:29:52 <gmcharlt> in that case, perhaps it might be as easy as changing a few variable, column, and syspref names
23:30:11 <gmcharlt> moving on
23:30:18 <gmcharlt> #topic Big stuff we are working on
23:30:22 <dcook> I heard my name
23:30:25 * dcook perks up
23:30:27 <gmcharlt> OK, watcha all doing?
23:31:18 <rangi> ncip stuff is in uat testing with masscat, in the meantime its being refactored by dyrcona
23:31:42 <rangi> but its always going to be a separate project, not merged with koha (like the SIP was) so it doesnt end up like the sip did
23:33:21 <gmcharlt> anything else?
23:33:24 <gmcharlt> also
23:33:33 <gmcharlt> #info Feedback still being sought on the VAT/GST rewrite
23:34:09 <pianohacker> Rancor patches coming soon, with new macro languages, bugfixes and optional chrome running boards
23:34:17 * pianohacker has to head out. Bye all!
23:34:54 <dcook> I don't think I'm up to anything with Koha at the moment. Non-Koha projects and local stuff at the moment.
23:35:05 <dcook> Actually, bbiab
23:35:20 <eythian> Elasticsearch is mosying along. I really ought to break out the bits I've had to build to support it, like Koha::Biblio and such.
23:35:29 <eythian> they can go upstream separately.
23:35:40 <gmcharlt> great
23:37:55 <gmcharlt> #topic Action items from previous meeting
23:38:03 <gmcharlt> #info ashimema added a note to the wiki to encourage use of columns stuff for datatables
23:38:11 <gmcharlt> #info ashimema has started qa for UTF8 bug.. minimal comments left already
23:38:38 <gmcharlt> #info gmcharlt and tcohen set deadline of 9/19 forwriting some unit tests for the utf8 bug
23:39:34 <gmcharlt> #topic Next meeting
23:39:54 <gmcharlt> the first meeting has agreed on holding the next meeting the same time next week
23:39:59 <gmcharlt> any objections?
23:40:24 <rangi> none from me
23:41:03 <gmcharlt> ok
23:41:10 <gmcharlt> #agreed We'll meet same time next week
23:41:15 <gmcharlt> and... that's a wrap
23:41:20 <gmcharlt> #endmeeting