10:00:01 <Brooke> #startmeeting
10:00:02 <huginn> Meeting started Wed Jan  4 10:00:01 2012 UTC.  The chair is Brooke. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:00:02 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:00:09 <Brooke> #topic Introductions
10:00:19 <kf> #info Katrin Fischer, BSZ Germany
10:00:30 <kmkale> #info Koustubha Kale Anant Corporation, India
10:00:31 <magnuse> #info Magnus Enger, Libriotech, Norway
10:00:31 <Brooke> Haere Mai welcome to the Koha Community Meeting feel free to introduce yourself with #info
10:00:39 <paul_p> #info Paul Poulain, France, 3.8 Release Manager
10:00:43 <jwagner> #info Jane Wagner, LibLime/PTFS
10:00:46 <thd> #info Thomas Dukleth, Agogme, New York City
10:00:55 <ColinC> #info Colin Campbell, PTFS-Europe, UK
10:00:58 <slef> #info MJ Ray, the http://software.coop's liaison to http://koha-community.org
10:01:01 <mbalmer> #info Marc Balmer, micro systems, CH, NetBSD committer, X.Org committer, Basel, Switzerland
10:01:05 <clrh> #info Claire, BibLibre, MArseille France
10:01:18 <asaurat> #info Adrien Saurat, BibLibre, France
10:01:25 <julian_m> #info Julian Maurice, BibLibre, Marseille, France
10:02:14 <Joubu> #info Joubu Jonathan Druart. BibLibre FR
10:02:15 <matts> #info Matthias Meusburger, BibLibre, Sélestat, France
10:02:26 <Joubu> hello
10:04:00 <Brooke> neat someone stuck announcements on the agenda
10:04:01 <paul_p> no one from NZ ? you're all sleeping already ?
10:04:04 <Brooke> #topic Announcements
10:04:21 <Brooke> anyone?
10:04:50 <slef> is KohaCon its own item?
10:04:51 <paul_p> yes, i've one: it's sunny in Marseille ;-)
10:04:56 * slef plays hunt the agenda
10:05:04 <Brooke> yes it is slef
10:05:07 <slef> paul_p: send the sun North, please!
10:05:08 <paul_p> (and more sunny in March, so come here for the hackfest :D )
10:05:09 <magnuse> #link http://wiki.koha-community.org/wiki/General_IRC_Meeting,_4_January_2012
10:05:30 <slef> magnuse: ta. Just found it :)
10:05:30 <Brooke> on a serious note, we didn't get the DML grant, but that's no surprise given how hostile their attachment thingy was
10:05:39 <mbalmer> my own announcement would be support for PostgreSQL, but that is already a point on the agenda
10:05:43 <slef> DML?
10:05:45 <Brooke> and also that submission was over KohaCon
10:05:48 <Brooke> the achievement thing
10:05:55 <Brooke> mebbe try next year, mebbe not
10:06:15 <Brooke> yeah stop hoppin the agenda :P
10:06:21 <slef> Hrm, too much eggnog for me, clearly.
10:06:26 <Brooke> #topic Roadmap to 3.4
10:06:34 <Brooke> update on old stuff anyone?
10:07:26 <paul_p> chris_n is not here, I suspect we won't have any update
10:07:49 <kf> I think he published some dates to the mailing list
10:08:22 <Brooke> k consult el mailing list
10:08:27 <kf> [Koha-devel] 3.4.8 Release Timeline Update
10:08:38 <Brooke> and I'm thinking that might affect the next point too but hey
10:08:43 <Brooke> #Topic Roadmap to 3.6
10:09:01 <kf> 26th december: string freeze on 8th, release on 14th january
10:09:12 <kf> for 3.4.8
10:10:08 <Brooke> kk
10:10:19 <Brooke> #topic Roadmap to 3.8
10:10:20 <slef> #info the Roadmap to 3.4 and Roadmap to 3.6 wiki pages need updating to reflect current release maintenance
10:10:21 <Brooke> take it away Paul
10:10:41 <paul_p> well, I've sent my monthly RM newsletter, where i've already written many things.
10:11:11 <paul_p> there is a lot of traffic. It seems the process of signing-QAing-pushing goes faster and faster, even if some patches stay stuck for a long period
10:11:22 <paul_p> mostly that's those who are hard/long to test
10:11:29 <magnuse> #link http://lists.koha-community.org/pipermail/koha-devel/2011-December/036711.html
10:12:05 <paul_p> otherwise, i'm working on my sandbox testing mechanism those days. I've something that start to work
10:12:28 <paul_p> I may open something soon, for some volunteers who could be candidate to test
10:12:46 * Brooke will guinea pig for that.
10:12:55 <kf> in general it would be great to see more different people signing off
10:13:10 <kf> some of the patches stuck in queue are hard to test without reading the code/looking at the code too
10:13:29 <paul_p> another topic: we plan to have BibLibre dev team dedicating half of his time to Koha (4 persons).
10:13:48 <paul_p> that will be dedicated to submitting our acquisition/serials/solR work to mainstream
10:13:52 <magnuse> yay!
10:14:05 <clrh> (Joubu: julian_m matts and me)
10:14:46 <slef> I'm still a bit confused about 3.6/3.8/master.
10:14:58 <Brooke> how so?
10:14:59 <slef> First of all, when should I tag a bug rel_3_8 and when master?
10:14:59 <paul_p> slef, could you explain ?
10:15:02 <thd> paul_p: What does the BibLibre development team do when not working on Koha?
10:15:13 <slef> Brooke: I can't type that fast :)
10:15:16 <paul_p> thd, BibLibre funded stuff ;-)
10:15:30 <kf> does the koha work include sign-offs and testing?
10:15:33 <paul_p> I answer to SLEF
10:15:51 <thd> paul_p: Is that not funded for Koha in reality or eventuality?
10:15:52 <paul_p> slef: if you declare a bug, please declare it against the version you get it (3.6)
10:16:01 <Brooke> @quote add paul_p "I answer to SLEF"
10:16:01 <huginn> Brooke: The operation succeeded.  Quote #174 added.
10:16:24 <slef> paul_p: I'll nearly always have confirmed it against master.
10:16:35 <paul_p> slef: if it's an ENH, declare it against master. when the patch is submitted/pushed, I (as RM) will tag it to rel_3_8 or rel_3_6
10:16:52 <paul_p> depending on if it's to be backported to 3.6 or will be in 3.8
10:17:07 <paul_p> SO :
10:17:07 <slef> paul_p: not usually an ENH
10:17:39 <paul_p> slef, small ENH are pushed in rel_3_6 by chris_n if they apply and don't change the workflow/display
10:17:44 <paul_p> so:
10:17:57 <paul_p> * rel_3_6 => the patch will be in 3.6 or is in 3.6
10:18:16 <paul_p> * master => the patch has not be merged, and we don't know in which version it will be merged
10:18:35 <paul_p> * rel_3_8 => should be used only by me when pushing to say "it's for 3.8"
10:18:48 <slef> paul_p: so what in my example case? Bug (not ENH) reported to me against 3.6 which I confirm is still present is master, but I feel should be fixed in a 3.8 release? => master?
10:19:02 <slef> paul_p: in other words, mortals should not use the rel_3_8 version?
10:19:27 <paul_p> slef, "mortals" should not use rel_3_8 (but, breaking news, i'm mortal too ;-) )
10:19:42 <slef> paul_p: yeah but you've temporary super cow powers.
10:19:45 <paul_p> in your example, you should use 3.6, and you can use master
10:20:06 <paul_p> (if you use master i'll update to rel_3_6 when pushing the patch)
10:20:15 <paul_p> sound clear ?
10:20:21 <slef> why should use 3.6? In the example, the bug is still in master.
10:20:26 <slef> s/still/also
10:20:53 <paul_p> slef, yes, but the workflow is to submit bugs against the version where it's detected.
10:21:03 <thd> paul_p: The better translation from the Greek is supposedly "liable to death".  However, death should be illegal.  Please let us have no fatal accidents.
10:21:18 <Brooke> #info submit bugs against the version where you detect it
10:22:11 <paul_p> #info if you detect a bug in 3.6, declare it rel_3_6. If you don't know, or if it's an ENHancement, use master
10:22:18 <slef> paul_p: I've detected it in both, so I'd intuitively thought it should be reported against the latest applicable and then the fix will spread backwards.
10:22:19 <kf> as paul_p mentioned the sign-off process - I would like to talk about that once paul_p is finished answering slef's question
10:22:45 <slef> Anyway, that clears that one up even if it's counter-intuitive to me. Thanks. My other confusion is how do I tell which public-reported bugs are from 3.6 and which are from master?  I think master now reports a 3.6 version number.
10:22:47 <paul_p> #info rel_3_8 is used by the Release Manager when pushing a patch that will, then, be in 3.8 once it's released
10:23:00 <slef> kf: oops, sorry!
10:23:27 <kf> slef: no reason :)
10:23:33 <paul_p> slef, yep, and that's a mistake (from me) i'll fix (vey) soon. We had a long (private) discussion about that with rangi & chris_n
10:23:45 <slef> paul_p: ok, temporary problem. Cool. Thanks.
10:23:50 <paul_p> I have to summarize everything and send a mail to koha-devel
10:24:02 <paul_p> kf, your question ?
10:24:09 <kf> not a question
10:24:19 <kf> but I want to remind people to look at patches
10:24:28 <paul_p> thd, about your question = yes, our halftime include signof & testing, of course
10:24:35 <kf> signing off can not only be done by a few people / bug wranglers
10:24:44 <slef> #info Koha master/dev versions reporting 3.6.x version numbers is a temporary problem which will be fixed. Email to koha-devel soon.
10:24:55 <kf> it's a task too big for a few people and very important
10:25:06 <paul_p> kf++
10:25:17 <Brooke> #help as always, we need more people to help with signoffs, and kf promised to bake for you *notintendedasafactualstatement
10:25:27 <kf> so please, if everyone here would sign off one bug a week, or look at it, coment, add information
10:25:31 <paul_p> and we will submit in the next months a lot of changes to acquisition & serials, so we will need everybody help here !
10:25:34 <kf> we could move much faster
10:26:13 <Brooke> I should hope a working sandbox will speed this up cait :)
10:26:28 <paul_p> I really hope too !
10:26:32 <kf> I am not sure it will
10:26:40 <kf> I think people here could work without sandboxes easily
10:26:49 <kf> the problem is making time for it and doing it
10:26:58 <Brooke> some of it
10:26:59 <wahanui> some of it is foolish pride
10:26:59 <paul_p> #info Paul is working on sandbox system and should have something in the next weeks. That will help librarians testing patches
10:27:17 <mle> #info Matthew Edmondson, software.coop/Project Manager (apologies for latenesss)
10:27:19 <paul_p> kf, yes and no : the problem is also having a git setup with at least a few git skills
10:27:20 <Brooke> but if it moved into pick up work at a Library, folks that don't usually code could contribute to the effort :)
10:27:35 <clrh> sandboxes should help, everything that automate things helps but right, we need time and people ;)
10:27:36 <paul_p> I really want to have more *librarians* involved
10:27:45 <Brooke> paul_p++
10:27:52 <kf> paul_p: I think it's not up to librarians to do all of the job
10:27:54 <Brooke> (not that Cait is not a Librarian)
10:27:57 <kf> developers have to do it too
10:28:03 <paul_p> and I mean true librarians, those that will never learn "git bz apply 1234"
10:28:04 <thd> paul_p++ more librarians
10:28:07 <kf> I mean we have to split time
10:28:18 <kf> between writing new features (which is always more fun) and looking at the code of others
10:28:23 <mbalmer> #info we are setting up a group with two librarians, one content guy and one tech guy
10:28:24 <kf> it's give and take
10:28:27 <paul_p> kf, agreed
10:28:33 <Brooke> I think it's important not to feel overwhelmed and rushed as a dev
10:28:46 <paul_p> well, we will see how the sandbox works & is welcomed by volunteers !
10:28:58 <thd> paul_p: True librarians should also learn git, even if that would not be necessary for all.
10:29:06 <paul_p> s/welcomed/use/
10:29:29 <paul_p> thd, in France, if librarian were 1st all learning english, I would be *very* happy.
10:29:36 <Brooke> ha!
10:29:43 <paul_p> thinking they could learn git ... no...
10:29:46 <mbalmer> mince ;)
10:29:54 <asaurat> we should all switch to latin
10:29:59 <paul_p> mbalmer, you speak french ?
10:30:01 <Brooke> asaurat++
10:30:02 <kf> paul_p: I think we shouldn't start the discussison again about what librarians can or not can do ;)
10:30:03 <slef> bah, you francophobe paul_p ;)
10:30:06 <mbalmer> mais oui
10:30:07 <paul_p> kf++
10:30:28 <paul_p> any more question about 3.8 ?
10:30:32 * magnuse has been working on a script to help make testing/signing off easier - improvements welcome https://github.com/MagnusEnger/kohatesting
10:30:39 <thd> paul_p: I try learning a little French to meet them a little way. :)
10:31:04 <slef> eh bon, nous choisons français comme langue official koha-community?
10:31:13 <asaurat> :D
10:31:15 <paul_p> je suis d'accord !
10:31:20 * slef pardonpetas
10:31:20 <kf> oh
10:31:21 <Brooke> no!
10:31:22 <kf> and as we talked about testing
10:31:25 <kf> GBSD is on friday!
10:31:27 <Brooke> Lingua Latina :P
10:31:38 <mbalmer> what is GBSD?
10:31:38 <wahanui> rumour has it GBSD is Global Bug Squashing Day
10:31:40 <Brooke> anyhow
10:31:47 <Brooke> moving on to the nerd fight
10:31:47 <kf> so if anyone has problems with testing or questions - I will be around and can answer questions (to my best knowledge)
10:31:47 <magnuse> #link http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day
10:31:54 <slef> wahanui++ for a useful contribution for a change
10:31:57 <mbalmer> ah, not another BSD...
10:31:58 <paul_p> kf, yep, GSBDing on all BibLibre  friday agenda
10:32:11 <Brooke> #topic Running Koha on PostgreSQL
10:32:34 <mbalmer> I have two goals which would like to be goals of the community:
10:32:45 <mbalmer> 1 Let Koha users run Koha on PostgreSQL
10:33:05 <mbalmer> 2 Help developers write proper SQL code that runs on both MySQL and PostgreSQL
10:33:17 <mbalmer> 1 will be achieved through 2
10:33:31 <thd> mbalmer++
10:33:42 <Brooke> step 3 profit?
10:33:47 <dpavlin> mbalmer++
10:33:50 <mbalmer> I think a shim layer is needed that produces some of the SQL code.
10:33:55 <thd> Step 2 is the difficult part.
10:34:30 <mbalmer> I did a code "audit" and identified already many problematic spots.  Some of the SQL code is just - excuse me - horrid ;)  But easy to fix.
10:34:33 <paul_p> mbalmer, would you be able to write a wiki page with incompatibilities ?
10:34:38 <paul_p> like ` iirc
10:34:52 <mbalmer> I already started that page.
10:34:57 <magnuse> #link http://wiki.koha-community.org/wiki/PostgreSQL
10:34:57 <thd> mbalmer: "shim"?
10:35:04 <mbalmer> and I already started to write the abstraction layer.
10:35:17 <mbalmer> shim as in as small as possible and as little overhead as possible.
10:35:20 <clrh> mbalmer: great, could you share it?
10:35:30 <slef> there must be other pages out there already. We are not the first project to move from mysql to multiple sqlds
10:35:33 <magnuse> isn't there some pre-existing code that can be used?
10:35:41 <mbalmer> no.
10:35:48 <clrh> because we begin to really think about this work
10:35:57 <ColinC> yes we dont want to reinvent
10:36:00 <mbalmer> and it is not needed.  it easy, if you understand the database stuff right..
10:36:04 <paul_p> mbalmer, about the abstraction be carefull, it may conflict with general code rewriting (remove C4 !)
10:36:05 <mbalmer> of course I can share.
10:36:24 <clrh> try to think of better code layers and splitting stuffs
10:36:32 <mbalmer> I have a pgsql git branch locally, btw.
10:36:45 <mbalmer> big question NR 1:  Is PostgreSQL a goal?
10:36:58 <Brooke> can you #info your git branch if it's amenable?
10:36:59 <mbalmer> If yes, then I can write up some best practices etc. documents
10:37:14 <Brooke> I think interoperability is always a goal
10:37:18 <slef> Brooke: mbalmer: or #link?
10:37:19 <Brooke> but I could be very wrong.
10:37:27 <paul_p> mbalmer, I don't think so, our goal should be to be database agnostic
10:37:30 <mbalmer> Brooke, what do you mean?  putting it online?
10:37:43 <Brooke> putting it here if possible so folks that are curious can poke at it
10:37:52 <slef> mbalmer: yes, I think it should be, as a step towards full DB Independence
10:37:54 <mbalmer> paul_p, yes support PostgreSQL as one possibility, of course.
10:38:21 <paul_p> ok, we agree then. And in this case, it's something that must be included in the general process rewrite/refactoring
10:38:30 <mbalmer> but that means that people should stop committing stuff that is MySQL only…  At least when a neutral form is easy to accomplish
10:38:48 <paul_p> so not a goal in itself, just a consequence of a "refactoring for more performance/stability/portability"
10:39:05 <mbalmer> that is why started a page with SQL idioms, MySQL form, PostgreSQL form, neutral form.
10:39:06 <Brooke> mm hmm
10:39:13 <paul_p> mbalmer, it's something for QA, if you can write guidelines, then that would be a good start !
10:39:20 <mbalmer> A neutral form is not always possible, that is way that SQL layer is needed.
10:39:37 <paul_p> mbalmer, you could even write a test, like complaining if you detect CURDATE() somewhere !
10:39:43 <paul_p> s/test/unit test/
10:39:51 <magnuse> unit_tests++
10:40:12 <thd> mbalmer: There is certainly some code which is not reducible to standard SQL.
10:40:19 <mbalmer> so you all agree that supporting PostgreSQL, in addition to MySQL, is a viable goal?
10:40:34 <mbalmer> thd, exactly.
10:40:45 <paul_p> mbalmer, yep
10:41:07 <mbalmer> but I think a way can be found to make such code work on MySQL _AND_ PostgreSQL by dynamically producing the SQL code in an optimal form for the respective database.
10:41:16 <clrh> at BibLibre, we have a hook "pre-cpommit" we use to filter bad practice before git commit, it helps
10:41:26 <thd> mbalmer: One very radical idea is to not use SQL at all for some problems which are not reducible to standard SQL.
10:41:37 <clrh> and we should have a list of good practices of what touse and what avoid
10:41:55 <paul_p> mbalmer, joubu is sitted just on my right, so you've already 2 members of the QA team that are OK to check SQL if they have directions to do so !
10:41:57 <magnuse> clrh++
10:42:02 <thd> mbalmer++ dynamically generated code
10:42:03 <clrh> what to use
10:42:07 <mbalmer> I can start such a document.  I have very long experience in the database area.  And I still think the Koha database is not too complex.
10:42:08 <Brooke> the goal is not to support Eurasia or Eastasia
10:42:15 <Brooke> the goal is to support all options possible
10:42:16 <ColinC> Surely the good practice is to factor out the sql to a db layer
10:42:27 <clrh> so mbalmer if you can share your best practices, it would be great
10:42:36 <clrh> ColinC: we agree too
10:42:46 <mbalmer> Brooke, I agree totally.
10:42:57 <paul_p> Other information: this afternoon, joubu & i have a meeting to list all inconsistencies in the database. We will write a wiki page.
10:43:00 <Brooke> kk just putting that out there
10:43:13 <thd> Brooke: the goal is to support Oceania. ;)
10:43:16 <paul_p> inconsistencies or strange things in DB (from a design point of view)
10:43:16 <mbalmer> If we can factor out the mysqlisms, and psqlisms, we can do the same for virtually *ANY* database
10:43:17 <Brooke> if you're gonna bother with compatibility might as well bother as much as poss
10:43:21 <clrh> clean layers, no circular dependencies, etc. but it is next subject ;)
10:43:28 <Brooke> thd: I have ate the taro and kumara ;P
10:43:46 <Brooke> it's not the *next* subject, but it's coming
10:43:47 <mbalmer> ok.  I am fine with the outcome.  Thanks!
10:43:56 <Brooke> #topic KohaCon2012
10:44:00 <kf> paul_p++ was writing database documentation today and I think some tables are no longer used
10:44:17 <mbalmer> how many people do usually attend a KohaCon?
10:44:26 <slef> OK. I think mle will scream if I'm wrong, but we're going to release the dates now.
10:44:33 * slef looks it up to make sure
10:44:56 <magnuse> ooh!
10:44:57 <paul_p> Brooke, can I say most of us (BibLibre) don't understand half of your sentences ?
10:45:12 <paul_p> I have ate the taro and kumara => ??
10:45:13 <Brooke> paul_p that's true of everywhere
10:45:23 <Brooke> slef said support oceania
10:45:34 <Brooke> I ate well when there, bro
10:45:57 <slef> #info Conference Tue 5 June 2012 to Thu 7th, Hackfest Sat 9th June-Mon 11th June
10:46:16 <mbalmer> where?
10:46:18 <Brooke> hooray for dates
10:46:23 <paul_p> slef++
10:46:28 <paul_p> hooray for dates !
10:46:40 <slef> #info That's in central Edinburgh
10:46:43 <kf> slef++ mle++
10:46:48 <mbalmer> oh, cool!
10:46:52 <slef> #link http://wiki.koha-community.org/wiki/Category:KohaCon12
10:46:59 <magnuse> slef++ mle++
10:47:12 <kf> slef: will you send a mail to the list too?
10:48:01 <jwagner> slef, when will you be asking for presenters?
10:48:04 <mle> : )
10:48:05 <slef> #info the wiki will be updated RSN (please help), the list emailed this week, some sort of sponsorship drive started this month and registrations taken
10:48:33 <mbalmer> slef, I could to a DB releated talk, about how to, what to, what not to, and so on.
10:48:36 <slef> jwagner: after we've contacted the volunteers
10:49:16 <paul_p> slef, do you plan to organize a trip like in NZ ?
10:49:37 <slef> We will give preference to things that appear on the Wishlist (and haven't been added by their presenter ;-) )
10:50:02 <slef> paul_p: I intend to, but at this point it is only an intention. We will prioritise organising the conference.
10:50:50 <magnuse> #link http://wiki.koha-community.org/wiki/Wishlist_for_KohaCon12
10:50:51 <paul_p> slef, of course, but the trip Auckland=> Wellington was so great that I would be very happy to do London=>Edinburg as well !
10:51:18 <mbalmer> norther scotland whisky trails ;)
10:51:26 <asaurat> a fishing session on Loch Ness
10:51:31 <slef> paul_p: ah, I was meaning the Friday off. I'd like to do a road trip too, if there is interest.
10:52:57 <paul_p> slef, you can consider there is an interest from BibLibre (for a roadtrip)
10:53:06 <paul_p> (+ for the friday off trip, of course)
10:53:40 <slef> paul_p: could someone from BL add a sign-up/interest list to the wiki, please? Just who to contact and how many seats?
10:54:03 <Brooke> #help now that we have dates and junk start adding things to the wiki
10:54:14 <mle> inital fishing enquiries suggest its expensive near edinburgh
10:54:58 <asaurat> I fish with my bare hands
10:55:06 <Brooke> asaurat++
10:55:11 <asaurat> but well, a road trip is fine too ;)
10:55:16 <slef> #action add initial interest/sign-up lists for conference, hackfest, road trip and Friday social to the wiki Category:KohaCon12
10:55:21 <ColinC> guggling in Scotland
10:55:29 <thd> slef: What are your plans to fish for defeating the expense problem?
10:55:57 <slef> mle: any answer to thd?
10:56:14 <slef> thd: I'm leaving that to mle because he's in that city and I'm not.
10:56:41 <AmitG> heya slef
10:57:00 * mle googles guggling : )
10:57:36 <slef> Any other questions, or tips, or whatever?
10:58:09 <mle> thd: we have some ideas, but notheing to announce as yet. : )
10:58:29 <thd> mle: the overall expense of the venue is a most important question.
10:58:57 <thd> mle: The lower the cost the greater the attendance.
10:58:58 <Brooke> are we exhausted on Conference yet?
10:59:05 <mle> thd the expense of the venue is very very affordable
10:59:14 <slef> OK, hearing nothing more...
10:59:15 <slef> #info we look forward to welcoming you in Scotland's capital during the UN International Year of Co-operatives!
10:59:33 <Brooke> #topic Discuss the move from C4 to Koha namespace
10:59:37 <mle> thd: ++
10:59:57 <thd> mle: Perhaps I was not taking your reference to 'fishing' literally enough.
10:59:58 <Brooke> galen up yet?
11:00:12 <clrh> as I said, we try to thing about koha design and layers
11:00:29 <slef> thd: yeah, some (jcamins?) suggested actual fishing for fish as an activity on the Friday.
11:00:57 <paul_p> s/thing/think/
11:01:18 <paul_p> was it me that added this topic ? I think so.
11:01:34 <thd> What is in a layer?
11:01:55 <thd> or What layers are there / should there be?
11:02:00 <Brooke> looks like Chris N
11:02:09 <clrh> a layer in app is parts of code that answer to some goals
11:02:20 <paul_p> We spoke a lot of code rewritting, and we (BibLibre) agree it's needed. I think most of us agree on how it should be done (separate business logic/ database for example)
11:02:31 <clrh> thd we talk before about "data layer"
11:02:39 <paul_p> what we need now, I think, is a POC !
11:02:42 <clrh> but there is to "front layer" and surely somthing between
11:03:12 <kf> paul_p: I think thre are some POC
11:03:21 <kf> patches already using a new Koha:: namespace
11:03:22 <paul_p> kf = where ?
11:03:29 <paul_p> kf that's not a POC !
11:03:42 <paul_p> a POC is a more general plan on where we want to go
11:03:53 <kf> Ithought it was code showing how something works
11:04:09 <magnuse> bug 7359
11:04:09 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7359 enhancement, PATCH-Sent, ---, gmcharlt, NEW , Begin migration to a new "Koha" namespace from the old "C4" namespace
11:04:13 <clrh> kf we talk about application design, we cant just drop some code lines
11:04:16 <paul_p> kf, yes it is.
11:04:17 <kf> paul_p: plans are different things
11:04:22 <slef> POC is Proof Of Concept
11:04:23 <wahanui> i already had it that way, slef.
11:04:32 <paul_p> kf, i'm not clear
11:05:04 <paul_p> we must have general directions about where we want to go, then a POC, then patches.
11:05:35 <magnuse> #link http://wiki.koha-community.org/wiki/Namespace_QA_Rules
11:05:38 <paul_p> I think most of the general directions are in our minds, but written nowhere.
11:05:47 <paul_p> magnuse, that's a good start, right
11:06:08 <thd> paul_p: I had thought that there was a list.  Separating business logic from X always seems much more difficult in practise than in mere contemplation.
11:06:47 <sekjal> #info Ian Walls, ByWater Solutions, QAM foe 3.8 (sorry I'm late, alarmclock malfunction)
11:06:49 <paul_p> thd, we had 2 meetings (at BibLibre) about that. Joubu even has written a 1st POC that could be shared soon
11:06:55 <kf> paul_p: I think if we take too much time planning, we will not get anywhere - there are already patches implementing something that has been talked about a while ago - why not look at those?
11:06:56 <paul_p> hello sekjal
11:07:14 <kf> if there is disagreement about how things are done there it can be improved, can be used to test the new plan
11:07:39 <paul_p> kf, the patch attached to 7359 contains nothing
11:07:48 <paul_p> just +  './Koha'                      => 'PERL_MODULE_DIR',
11:07:59 <kf> there are others
11:08:02 <kf> I think hourly loans
11:08:05 <kf> is one of them
11:08:13 <paul_p> kf, patch number ?
11:08:19 <kf> jared did something too for local cover images
11:08:44 <magnuse> 7359 was meant as an official starting point and center of discussion for starting moving things into Koha:: namespace, i think
11:09:02 <clrh> kf 5549?
11:09:05 <kf> agreed, so perhaps we can link the other bugs to that
11:09:06 <magnuse> jcamins chenged his patch so it does not use Koha:: after all
11:09:13 <thd> There is a fundamental problem that business logic creeps in or seems especially difficult to abstract just as many things for which we use the database cannot be abstracted to standard SQL alone.
11:09:16 <kf> yes, because there was disagreement about it
11:09:44 <kf> but perhaps we should encourage people working on new features to start using Koha::
11:09:45 <clrh> I think we just don't want to copy C4 into Koha but improve thinks
11:09:52 <magnuse> kf: yup, or rather that it had not been officially discussed/decided
11:10:00 <paul_p> I repeat : we had 2 meetings (at BibLibre) about this refactoring. Joubu even has written a 1st POC that could be shared soon
11:10:03 <clrh> kf yep, I did'nt see it (for links)
11:10:03 <magnuse> clrh++
11:10:09 <Brooke> so then
11:10:16 <paul_p> it's *much* more than hourly loan example.
11:10:17 <Brooke> if we're looking for official action
11:10:18 <mbalmer> clrh, maybe the move from C4 to Koha could be used to fix a few SQL things as well
11:10:23 <Brooke> do we vote now or do we vote later?
11:10:28 <paul_p> Brooke, later !
11:10:29 <clrh> mbalmer: of course
11:10:46 <kf> bug 7387, bug 7284, bug 929
11:10:46 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7387 enhancement, PATCH-Sent, ---, chris, ASSIGNED , Add Template::Toolkit plugin to allow caching of includes
11:10:47 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7284 enhancement, P5 - low, ---, jcamins, ASSIGNED , Authority matching algorithm improvements
11:10:47 <Brooke> galen's guidelines made sense even to me
11:10:48 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=929 enhancement, PATCH-Sent, ---, chris, ASSIGNED , See details of a budget
11:10:50 <Waylon> hello all!
11:10:51 <ColinC> without seeing the code we have nothing to go on
11:10:57 <kf> hm bug 7248 (typo sorry)
11:10:57 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7248 enhancement, PATCH-Sent, ---, gmcharlt, NEW , Caching for services
11:10:58 <paul_p> Brooke, yes, but they're not enough
11:11:07 <paul_p> ColinC++
11:11:09 <Brooke> surely that's enough for a start.
11:11:20 <Waylon> Ah.. a meeting currently in session?
11:11:23 <Brooke> yep
11:11:49 <Waylon> k. ill wait... watch. and might learn something.
11:11:50 <clrh> it is not just "putting a pm on a new namespace"...
11:11:51 <paul_p> Brooke, enough for investigating more. But WHAT do we put in this new namespace !
11:12:27 <paul_p> if we want to split business & data logic, for example, we need to define their namespace as well !
11:12:34 <clrh> it is not just "putting a pm on a new namespace", and I think it should contains data layer problematics too - we need a little bit of time to think about id
11:12:37 <clrh> it
11:13:20 <Brooke> can you guys add your reservations to the bug then? Because I'm not seeing those from here.
11:13:38 <kf> clrh: that's not like it was done I think
11:13:41 <mbalmer> I will pbly use two modules/namesspaces, SQL and DB, should they be within Koha or outside?  Maybe SQL, which is Koha agnostic, outside?
11:13:48 <sekjal> idea for Koha:: namespace:  two layers of .pm, Data access and Transactional.  Only Data access layer talks to DB, and Transactions talk to Data access layer
11:14:13 <magnuse> loose_consensus_and_running_code++
11:14:35 <magnuse> if we spend too much time discussing what to do we might never get around to doing anything...
11:14:44 <kf> yes
11:14:47 <Brooke> magnus++
11:14:55 <paul_p> sekjal, agreed ! and that's where/why we need a more detailled proposition !
11:14:56 <thd> clrh: The difficulty of abstraction is partly that what is returned by the data layer can improperly define the business logic.  I had written a meta-bug report about this problem.
11:14:57 <kf> magnuse++
11:15:00 <Waylon> hmm... so isolating db specific code, so one can develop db access for other databases without too much hassle eh?
11:15:03 <kf> I think we could take existing work as a start
11:15:17 <kf> people can make suggestions looking at this code - signingoff/qaing it
11:15:32 <clrh> thd what number please?
11:15:41 <Brooke> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7248
11:15:41 <huginn> 04Bug 7248: enhancement, PATCH-Sent, ---, gmcharlt, NEW , Caching for services
11:16:03 <thd> clrh: checking ...
11:16:26 <mbalmer> I suggest a SQL module which produces "optimal" SQL for a specific DB for operations that can not be expressed in standard SQL.  Should that be in Koha or outside?  I am for outside.
11:16:27 <sekjal> writing/migrating the Data Access layer should involve, I think, looking at some of the data structures we currently have in our DB, and what we can do to change/improve them
11:16:32 <sekjal> like primary keys for reserves, etc
11:17:23 <thd> clrh: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3092
11:17:23 <huginn> 04Bug 3092: normal, P1 - high, ---, frederic, NEW , Data values storage and use 100 bug meta-bug
11:17:26 <ColinC> there was some discussion of using a standard orm module earlier
11:17:47 <mbalmer> I think using SQL is not a mistake.
11:17:53 <clrh> The idea is not to write things from scratch but having best practice to refactor code little by little in a new workspace I think
11:18:02 <mbalmer> clrh++
11:18:04 <magnuse> clrh: agreed
11:18:12 <kf> clrh: agreed
11:18:13 <sekjal> clrh:  much more practical that way
11:18:16 <clrh> so we will continue how work
11:18:26 <clrh> s/how/our
11:18:51 <mbalmer> I will add my two modules, they can later be moved into Koha namespace, if it makes sense.
11:18:52 <clrh> to give you asap some concrete things to talk about
11:18:53 <magnuse> this is starting to sound like the topic for a separate meeting?
11:19:08 <thd> clrh++ the proposed remedy I have at the end of that meta-bug is fixing the problem tiny piece by piece in an isolated manner so that nothing breaks.
11:19:12 <clrh> magnuse: I think yes
11:19:19 <ColinC> I would see most of the current big C4 modules as candidate for refactoring into the new name space and code slowly migrating to them
11:19:22 <clrh> thd: did you find the reference?
11:19:27 <clrh> o I didnt see it!
11:19:29 <clrh> thx
11:19:34 <Brooke> that and not everything need take place in a meeting
11:19:47 <paul_p> Brooke++
11:19:49 <clrh> agreed Brooke :)
11:20:14 <Brooke> did we secretly move on to Coding Guidelines while talking about C4?
11:20:36 <Brooke> #topic Coding Guidelines
11:20:38 <magnuse> Brooke: don't think so ;-)
11:21:01 <thd> clrh: However, paul_p wrote about rewriting code which is an opportunity to avoid having features which function as poorly before rewriting as after.
11:21:13 <mbalmer> - Try to avoid SQL code that works only on a particular database.
11:21:28 <mbalmer> - Refactor existing SQL code to work on any database ;)
11:21:41 <mbalmer> that would be two guidelines.
11:21:49 <mbalmer> plus:
11:22:13 <mbalmer> - if in doubt, ask.
11:23:09 <thd> Refactoring and rewriting are not the same. rangi has stated this many times but had given up reminding and may be asleep now.
11:23:28 <Brooke> fool! Rangi never sleeps :P
11:23:59 <mbalmer> thd, I agree.  I meant rather rewrite or adapt, btw
11:24:00 <Brooke> you guys aren't talkative so
11:24:06 <Brooke> #topic GBSD
11:24:17 <Brooke> hey there's one coming up
11:24:36 <mbalmer> there's bugs?
11:24:44 <Brooke> it's Friday, or possibly Saturday depending on where you are
11:24:53 <Brooke> but you can always cheat and pretend you live someplace else. :D
11:25:18 <Brooke> http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day
11:25:25 <magnuse> nah, it's friday, in whatever timezone you happen to be in
11:25:58 <Brooke> Friday?
11:25:58 <wahanui> Friday is It's Friday, Friday Gotta get down on Friday
11:26:52 <Brooke> #topic Actions from Last Meeting
11:27:02 <thd> Brooke: one injection about the hastily left issue of coding practise?
11:27:03 <Brooke> the only stuff I see looks to be KohaCon 2013
11:27:09 <Brooke> any new stuff there?
11:27:26 <Brooke> thd: do you have a specific link to summat for something I've already moved past?
11:27:31 <Brooke> is it really, really pressing?
11:27:55 <magnuse> i think maybe kf had things to say about coding guidelines too?
11:28:07 <thd> Brooke: We had in the past suggested being clear in commits about ...
11:28:22 <magnuse> #link http://wiki.koha-community.org/wiki/Coding_Guidelines
11:28:23 <mbalmer> coding guidelines topic still open?
11:28:28 <Brooke> #topic Coding Guidelines *again*
11:28:32 <thd> fixing Perl coding style.
11:28:49 <Brooke> if we keep skipping back to stuff, these meetings are gonna get even longer. #justsayin.
11:28:55 <slef> did the "how to run tests" get updated? I'm elsewhere in the wiki
11:28:56 <mbalmer> I'd love of lines would not be longer than 80 characters and indents be tabs with 8 character width.
11:29:03 <kf> sorry, phone call
11:29:10 <mbalmer> s/of/if/
11:29:47 <thd> We should also be clear in commits between refactoring and rewriting where rewriting has altered functionality.
11:30:06 <magnuse> we already decided on http://wiki.koha-community.org/wiki/Perltidy
11:30:13 <mbalmer> a bit like http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&arch=default&format=html
11:30:14 <asaurat> must a patch correct only what the bug title implies, or should we add other enhancements when possi
11:30:15 <paul_p> mbalmer, we already have decided to use 4 spaces.
11:30:20 <mbalmer> ok.
11:30:24 <thd> The test for refactoring is that the same bugs are implemented in a different manner.
11:31:11 <ColinC> bugs/behaviour
11:31:12 <thd> Rewriting changes bugs fixes and/or adds new ones.
11:31:41 <Brooke> this is failing my mental tests for does it belong in a meeting, btw
11:31:46 <Brooke> I think I have to do those up
11:31:52 <Brooke> and vote on em at some point
11:32:01 <thd> Brooke: right
11:32:04 <magnuse> i think the question now was how much perltidy'ing should we be doing?
11:32:41 <magnuse> if we fix some bug, should we perltidy just the one line we touched, a block, a whole function?
11:32:50 <thd> magnuse: There was an unanswered question which paul_p posed about when to tidy?
11:32:53 <Brooke> magnuse I think the old consensus was new stuff pretty darn tidy, old stuff we'd get to eventually.
11:33:24 <thd> paul_p are you still here?
11:33:29 <paul_p> thd, yep.
11:33:34 <magnuse> so if a patch is tidying lines that were not otherwise changed, should it be failed qa?
11:33:36 <ColinC> If you tidy more than is chamged it gets hardr to see what the change was in the history
11:33:45 <paul_p> the problem is git blame.
11:34:00 <magnuse> yup
11:34:03 <clrh> something is to dig about "git blame -w"
11:34:15 <thd> paul_p: Do you remember that you had wanted to discuss when to tidy during KohaCon 2011 dev week?
11:34:39 <ColinC> but use taste i.e. a line before or after may  get tidied to make the indent obvious
11:34:54 <asaurat> yep, of course
11:34:56 <mbalmer> why not tidying a file before fixing a bug?  aka fix bugs in previously tidyied files?
11:35:13 <magnuse> "-w Ignore whitespace when comparing the parent's version and the child's to find where the lines came from." cool!
11:35:20 <paul_p> mbalmer, not in the same patch as the fix iteself !
11:35:25 <mbalmer> so these tidy ups get separate commits
11:35:34 <paul_p> (otherwise, QAing is almost impossible, you get 1000 lines changed !)
11:35:46 <paul_p> yep, in separate commits.
11:35:47 * kf reads back now
11:35:56 <mbalmer> paul_p, that is what I meant.  one patch to tidy up, no function changes, a separate one for the actual fix
11:36:01 <ColinC> you lose history if you tidy the file but it may be a good way to work on it just dont commit the whole tidied file
11:36:06 <magnuse> there's also git diff to think about
11:36:14 <paul_p> but a perltidy will result in git blame being wrong.
11:36:31 <Brooke> do we care if the code is nicer?
11:36:34 <paul_p> I think we must choose our poison !
11:36:45 <mbalmer> ColinC, why loose history?  the tyding up becomes part of the history, or do I miss sth?
11:37:04 <jwagner> Brooke, I think we definitely do care -- we frequently need to see when a particular change came in and who did it
11:37:05 <mbalmer> Brooke, nicer code is easier to maintain, and means less errors
11:37:17 <paul_p> either decide to perltidy everything, and loose history, or keep history and stop complaining about tidy
11:37:18 <ColinC> yes we do care because it becomes harder to see what introduced some behaviour
11:37:20 <thd> Brooke: It is not merely about having prettier code.  Readability and consistency helps avoid bugs.
11:37:27 <paul_p> I don't see another option !
11:37:28 <slef> mbalmer: maybe not lose history, but it can obscure it.
11:37:37 <mbalmer> I don't understand why do we loos the history?
11:37:51 <mbalmer> it's just an additional commit, right?
11:37:52 <paul_p> is our goal to keep history clear (you're right slef) or have something more readable ?
11:38:07 <Brooke> but that's not what was decided
11:38:18 <Brooke> and I don't see a reason to deviate from new code meeting new standards
11:38:18 <kf> mbalmer: it will not be clear who wrote the line
11:38:22 <paul_p> mbalmer, right. but git blame will say the perltidy author is to blame for almost everything
11:38:23 <sekjal> if we keep our tidy commits and our functionality commits distinct
11:38:25 <kf> mbalmer: only who last changed it
11:38:26 <Brooke> and old code would eventually phase itself out
11:38:26 <ColinC> paul_p in practice to compromise between the two
11:38:33 <paul_p> ColinC, how ?
11:38:33 <sekjal> and the commit message is "Tidying code" or the like
11:38:42 <mbalmer> paul_p, a now I see the issue.
11:38:51 <sekjal> we can easily skip over that patch in a git log, and look for the next functionality-based patch, when checking history
11:38:57 <paul_p> I think so.
11:39:04 <slef> ok, does anyone remember if git blame can drill down into history, or shall I test now?
11:39:05 <kf> I think one suggestion was tidying the parts where your bug fix is
11:39:24 <kf> perhaps we could say - tidy the whole code block in that case?
11:39:33 <paul_p> does it mean we would/should/could go for a big perltidy one day ?
11:39:35 <kf> not sure that's practical
11:39:38 <Brooke> do we have anything to discuss that we didn't already agree upon two months ago?
11:39:39 <mbalmer> is git blam so holy?  I mean the history is still there...
11:39:39 <magnuse> what's a block of code?
11:39:41 <Brooke> is there anything new here?
11:39:56 <paul_p> kf, you're right ! having a part tidied and a part not tidied is a nightmare very soon !
11:39:57 <kf> Brooke: the problem is, that it's not clear now - so people don't know what to do, we should clarify
11:40:03 <thd> Brooke: This issue was left unresolved two months ago.
11:40:04 <paul_p> s/is/will be/
11:40:27 <thd> Brooke: Tidy was resolved but not the issue about the rate of use.
11:40:28 <kf> paul_p: didn't mean the whole file  - not sure
11:40:28 <mbalmer> I am all for clean, consisten code.
11:40:35 <ColinC> if there was to be a big tidy choose your moment i.e. as part of the 3.8 release
11:40:38 <Brooke> http://wiki.koha-community.org/wiki/General_IRC_Meeting,_5_October_2011
11:40:41 <mbalmer> consistent, even.
11:40:42 <paul_p> mbalmer, everybody is for that ;-)
11:40:43 <sekjal> git blame is handy, but it's just one tool in our debugging arsenal
11:40:45 <kf> ColinC: that might be reasonable
11:40:51 <kf> similar to the template toolkit switch
11:40:59 <magnuse> +1
11:41:04 <paul_p> I agree for git blame is one tool !
11:41:16 <mbalmer> paul_p, hard to believe, because Perl code will never be nice ;)  (scnr)
11:41:19 <paul_p> ColinC++
11:41:22 <kf> if we do a global thing, we can check out the branch, but we should decide about it
11:41:34 <paul_p> mbalmer is a troller !!!
11:41:53 <slef> mbalmer: how do you find the history of a line otherwise?
11:42:04 <paul_p> I like ColinC idea of a big perltidy for 3.8
11:42:05 <mbalmer> well at least I went through the pain of learning the language the last weeks, paul_p ;)
11:42:15 <slef> mbalmer: reading all diffs for a file is not fun IMO.
11:42:35 <mbalmer> slef, I agree.  But you would have to do that, then
11:42:42 <mbalmer> afaict.
11:43:18 <mbalmer> maybe git blame is to blame for not being able to go back further in the history of a file
11:43:24 <thd> Brooke: Clarifying: we voted to use Perl standard for tidy but deferred how to approach the issue of when to tidy code which is not being modified otherwise.
11:43:56 <slef> paul_p: yes, a perltidy Day would make things a bit easier (if git blame on master is uninformative, run git blame on pre-perltidy-day tag).
11:43:59 <paul_p> the more I think of it the more I like the idea of a bit perltidy in 3.8 !
11:44:08 <slef> mbalmer: I'm sure they'd welcome patches to git-blame.
11:44:14 <Brooke> 12:09:26 <kf> I hve no strong opinion about the coding thing - make it consistent and choose one, change code not at once but bit by bit perhaps
11:44:15 <Brooke> 12:09:37 <paul_p_> kf++
11:44:15 <clrh> I agree paul_p
11:44:15 <Brooke> 12:09:43 <wizzyrea> kf++
11:44:15 <Brooke> 12:09:47 <ColinC> kf+
11:44:16 <Brooke> 12:09:51 <slef> mtj: git format-patch -o .. 'HEAD^'
11:44:16 <Brooke> 12:09:57 <wizzyrea> (and publish it somewhere)
11:44:16 <Brooke> 12:09:58 <thd> kf++
11:44:25 <Brooke> I really bloody hate talking things over that are minutia twice.
11:44:28 <sekjal> putting it off until the end of this release cycle would make coding 3.8 easier
11:44:45 <paul_p> sekjal, ???
11:45:12 <paul_p> why is it easier ?
11:45:16 <magnuse> Brooke: it's not minutia imho, it's a question of what patches to fail qa...
11:45:26 <thd> Brooke: Bit by bit had seemed to be the previous consensus but paul_p had raised problems with that approach on the mailing list.
11:45:35 <Brooke> fine
11:45:36 <Brooke> we vote
11:45:37 <clrh> magnuse: rebase + perltidy does not seems really big ;)
11:45:40 <paul_p> OK, i'll send a mail to koha-devel with this proposition.
11:45:41 <Brooke> instead of talking about voting
11:45:59 <clrh> ok Brooke
11:45:59 <paul_p> OK for voting Brooke !
11:46:10 <Brooke> so the proposal is we handle things as we code ensuring that they're in line with perl tidy and other suggestions with the coding guidelines
11:46:15 <Brooke> +1 for little by little.
11:46:24 <ColinC> +1
11:46:28 <kf> clrh: will give conflicts perhaps? patches in the list now changing same files and so on? not sure
11:46:33 <paul_p> -1 (i'm for big perltidy day)
11:46:42 <mbalmer> there is one technical problem, however:
11:46:45 <clrh> -1  (i'm for big perltidy day)
11:46:58 <magnuse> +1 for bit by bit
11:47:09 <kf> +1 for little by littel - will not hurt anything now
11:47:11 <sekjal> paul_p:  lets us differ the issue, focus on functionality for the next few months, then we can run scripts to do mass clean up after
11:47:12 <mbalmer> some of the better editors cut whitespace off the line endings, and that leads to whitespace patches when you edit a file.
11:47:15 <sekjal> maybe not any easier
11:47:16 <thd> -1 big perltidy day timed with release cycle if possible
11:47:25 <sekjal> seemed that way to my pre-coffee brain
11:47:28 * sekjal drinks a cup now
11:47:43 <paul_p> sekjal, that's also an option.
11:47:47 <kf> little by little for me means = fix things where you fix your bug
11:47:58 <kf> not the whole file, the lines you are working on
11:48:09 <magnuse> kf++
11:48:12 <Brooke> I agree with that kf
11:48:13 <paul_p> kf, NO NO NO !
11:48:15 <ColinC> kf++
11:48:21 <mbalmer> what if the editor clears up whitespace?
11:48:22 <paul_p> that will be unreadable quickly !
11:48:27 <slef> git log --pretty=oneline -S'string to search for' # may help with seeing behind a perltidy
11:48:29 <mbalmer> paul_p++
11:48:42 <kf> paul_p: I think for most things it will work quite ok - we already have it all mixed up
11:48:53 <thd> My position for a big tidy day is not against using tidy when you modify a file as a separately labelled patch.
11:48:54 <clrh> there is two little by little kf be carefull
11:48:57 <kf> can't get more unreadable, only moving into one direction now instead of a lto of directions
11:49:29 <Brooke> finish actual voting
11:49:30 <Brooke> :P
11:49:32 <mbalmer> err, so my editor question remains unanswered?
11:49:42 <Joubu> -1
11:49:45 <julian_m> -1
11:49:56 <matts> -1 too
11:50:16 <kf> perhaps I am misunderstood... I wanted to say write new things using perltidy, fix old when you work on that code, but not outside of the scope of your bug - like fixing the whole file?
11:50:35 <kf> because for now that will not hurt and we can still do a global day later with a release if that's agreed on
11:50:36 <paul_p> kf, i'm against this idea too ;-)
11:50:48 <mbalmer> what can you do if your editor does clean up whitespace when saving the file?
11:50:49 <thd> mbalmer: What do you mean by 'editor'?  Who or what is the 'editor'?
11:50:56 <mbalmer> text editor.
11:50:57 <kf> mbalmer: deactivate it
11:51:00 <Brooke> so it looks like little by little now fails.
11:51:07 <mbalmer> kf, for sure not.
11:51:14 <paul_p> kf, if you add a loop outside of existing code, you'll get a foreach that is perltidied & indented, and inside the loop, you may have a different indentation. unreadable quickly !
11:51:19 <Brooke> come up with an alternative and propose it, Paul.
11:51:28 <thd> Brooke: We need to clarify the issue.
11:51:34 <mbalmer> I am not only working on Koha, and otherwise whitespace at line endings is very much frowned upon
11:51:35 <paul_p> Brooke, big perltidy day on 3.8 release
11:51:36 <sekjal> git blame and git diff have "ignore whitespace" flags
11:51:39 <kf> I think in that case perhaps have a follow up doing the perltidy for that part?
11:51:42 <sekjal> so if it's just whitespace, we're fine
11:51:55 <mbalmer> sekjal, ok, that settles it, thanks.
11:52:10 <paul_p> sekjal, yep, but perltidy is also a matter of where to put {} and not only whitepsaces
11:52:17 <sekjal> ah
11:52:18 <mbalmer> it's only WS at line ends, *NOT* perltidy or so.  text structure gets not changed.
11:52:24 <thd> Brooke: Did we just vote never to use tidy for old files until tidy day or when modifying otherwise and a big tidy day?
11:52:31 <Brooke> vote: Big perltidyday on 3.8 release
11:52:44 <paul_p> +1 (already said ;-) )
11:52:48 <mbalmer> +1
11:52:50 <Brooke> #info Voting on perltidy
11:52:51 <clrh> +1
11:52:54 <thd> +1
11:52:57 <Joubu> =1
11:53:00 <Joubu> +1
11:53:05 <Waylon> +1
11:53:06 <Brooke> NO EQUALS! RAWR
11:53:07 <julian_m> +1
11:53:34 <sekjal> 0
11:53:39 <kf> 0
11:53:44 <jwagner> 0
11:54:04 <ColinC> 0 RM's prerogative tho
11:54:15 <paul_p> 1PM here, my stomash is asking for some food ;-)
11:54:17 <slef> 0
11:54:28 <thd> paul_p: Did we just vote never to use tidy for old files until big tidy day or when otherwise modifying a file and also a big tidy day?
11:54:35 <sekjal> we need to clearly lay out the pros and cons for this change
11:54:42 <sekjal> incremental vs. all-at-once
11:55:03 <mbalmer> paul_p, same TZ here, same problem, too ;)
11:55:05 <thd> sekjal: I agree that the vote was a little hasty
11:55:44 <kf> perhaps something to think about for the global change: you can't compare files between different versions then and patches will not apply backwards
11:55:46 <paul_p> yes, but many of us are hungry ;-)
11:55:47 <sekjal> if perltidy is going to give us more than just whitespace changes on single lines
11:55:58 <sekjal> then we're not going to be able to use a lot of our git tools effectively anymore
11:56:03 <sekjal> git diff and git blame, for one
11:56:05 <Brooke> thd we voted to have a big perltidy day on 3.8 release
11:56:14 <kf> yes
11:56:19 <kf> but perhaps we need to think more about it
11:56:22 <kf> to see all pro and cons
11:56:27 <kf> that have not been brought up here
11:56:32 <sekjal> would the tidy be backported to 3.6.x?
11:56:33 <thd> sekjal: Brooke was anxious to vote on something rather than rediscuss the old topic :)
11:56:47 <thd> sekjal++
11:56:48 <kf> sekjal: I think it does more, breaking lines differently
11:57:19 <sekjal> my understanding of perltidy is insufficient for me to make an informed choice
11:57:39 <kf> same here
11:57:46 <paul_p> OK, let's say = i send a mail to koha-devel to say "we propose the option of a big perltidy day, let's argue the cons of this idea if there are"
11:57:47 <asaurat> same for me, never used it
11:57:52 <mbalmer> so maybe we should revert that vote?  and give us a bit more time?
11:57:53 <thd> kf: Would applying tidy to the old release solve the problem for patching old versions?
11:58:04 <mbalmer> paul_p, sane idea.
11:58:14 <kf> thd: not sure - but I think we should find out before doing something drastic
11:58:28 <jwagner> paul_p, +1
11:58:33 <Brooke> why is this in meeting and not on devel?
11:59:04 <kf> ok
11:59:06 <kf> so for now
11:59:07 <ColinC> kf: but the patches in the in queue will be made against old formatted code
11:59:08 <jwagner> Because meetings are the place where we're supposed to discuss things of concern to the project?
11:59:09 <sekjal> Brooke:  heated discussions are more fun in realtime?
11:59:11 <thd> Brooke: It was on the koha-devel list, however, we have gone rather quickly here.
11:59:28 <thd> sekjal++ :)
11:59:49 <Brooke> jwagner: this is relevant in general, not in minutia.
12:00:00 <mbalmer> I have to leave now, next meeting, grr, so cul.  and whatever you still vote here:  I am all for it!  ttyl!
12:00:01 <Brooke> there's no reason to hash minutia at a meeting v over the listserv.
12:00:14 <thd> Brooke: The issue had been raised on koha-devel and then forgotten over the course of KohaCon.
12:00:37 <paul_p> Brooke, maybe we should go forward ? i'm not sure we will find a consensus. This is a trolling topic...
12:00:56 <Brooke> I would say
12:01:01 <thd> paul_p: Did we just vote never to use tidy for old files until big tidy day or when otherwise modifying a file and also a big tidy day?
12:01:02 <Brooke> keep hashing it out over devel
12:01:11 <Brooke> until you have something that you can vote a simple yes or no to
12:01:16 <Brooke> even if it's a little yes or no
12:01:21 <Brooke> as in 4 spaces or 8
12:01:25 <Brooke> and THEN bring that to the meeting
12:01:26 <Brooke> else
12:01:35 <Brooke> we have 20 people talking about 20 different pet to dos
12:01:45 <Brooke> and we have another glorious 2 hour meeting.
12:01:48 <paul_p> thd, I don't see how we can practically use a small bit by small bit.
12:01:49 <thd> Brooke: 4 spaces or 8 is resolved unless someone really wants to raise the issue again.
12:01:50 <Brooke> with no actual progress
12:02:04 <Brooke> thd it was an example of an actionable item.
12:02:09 <paul_p> thd, no, NOONE want to  raise the issue.
12:02:10 <ColinC> thd: please no
12:02:14 <paul_p> or i'll kick him !
12:02:27 * paul_p get his gun...
12:02:32 <thd> paul_p: yes no one of course :)
12:02:45 <paul_p> ;-)
12:02:50 <kf> paul_p: now you scareme
12:03:11 <sekjal> if anyone was going to be pulling iron, I thought it would be one of the Yanks
12:03:17 <thd> paul_p: So we just voted to only tidy new files until big tidy day?
12:03:26 <Brooke> paul, you need to get your sabre or foil, and then we can settle this like men. :P
12:03:27 <paul_p> thd, I would say yes.
12:03:49 <kf> seems so
12:03:54 <Brooke> we didn't but I will pretend that we did :P
12:04:01 <kf> ok for me
12:04:08 <kf> and big day still to be decided
12:04:27 <Brooke> thought big day was timed with the 3.8 release, but we'll leave that to paul and later.
12:04:41 <paul_p> Brooke, agreed.
12:04:52 <Brooke> so
12:04:57 <thd> paul_p: Ok, so we can continue to discuss the issue of applying tidied patches to the possibly untidied current release on the mailing list.
12:05:02 <Brooke> #topic Actions from December
12:05:20 <Brooke> once again the only thing I see there is KohaCon 2013
12:05:25 <Brooke> any new stuff on that?
12:06:07 <slef> did the "how to run tests" get updated? I'm elsewhere in the wiki
12:06:38 <slef> nothing new from me on KohaCon 2013. All replies were  on-list.
12:07:37 <Brooke> #topic Miscellaneous
12:07:50 <Brooke> I wanted to give a shout out for the Koha Academy project
12:08:07 <Brooke> we're attempting to get a proper distance education framework in place
12:08:18 <Brooke> so if you're good at constructing a syllabus or other such things
12:08:25 <Brooke> please contact kmkale
12:08:30 <slef> #link http://lists.katipo.co.nz/public/koha/2011-December/031479.html
12:08:40 <sekjal> I've got an announcement that the Koha community may find relevant
12:08:46 <Brooke> just like if you volunteered to teach different stuff at the last KohaCon, we will prolly be conning you into volunteering :)
12:08:49 <slef> actually not sure all replies were on-list. I'll find them and put them to a page.
12:09:30 <Brooke> go for it sekjal :)
12:09:33 <Brooke> and thanks slef.
12:09:56 <sekjal> at the end of this month, I'll be leaving ByWater Solutions to work at the library at the University of Massachusetts
12:10:15 <sekjal> I will continue to be part of the Koha community
12:10:34 <sekjal> but, as UMass is not a Koha institution, Koha will no longer be my primary workday focus
12:11:10 <sekjal> I intend to finish out my term as QAM, should the community approve
12:11:17 <thd> sekjal: Is UMass considering working on Koha at any future point?
12:11:23 <jwagner> sekjal, good luck with the new job!
12:11:34 <thd> s/working on/using/
12:11:35 <paul_p> sad news. (side effect: you'll miss the European hackfest)
12:11:50 <sekjal> thd: they're part of a 5 college consortium, so it will take a lot of effort to move them, but I will apply what pressure I can
12:11:57 <slef> sekjal: sorry to hear that, yes please and good luck with the new work
12:12:31 <kf> good like sekjal
12:12:37 <kf> hm good luck...
12:12:38 <paul_p> about the QAM role, my position is: if you can promize /think you'll be able to spend something like 8 hours a week on QA things, then go for it. Otherwise, we should ask for another volunteer
12:14:09 <sekjal> I think that, yes, I will be able to dedicate about that much personal time to the job
12:14:25 <slef> next item?
12:14:26 <Brooke> UMass is a great place to work, so look forward to it :)
12:14:27 <kf> sekjal++
12:14:38 <sekjal> thankfully, I'm not alone on the QA team this term, so I won't act as a bottleneck for everything
12:14:42 <paul_p> so i'm OK with this idea
12:14:43 <thd> sekjal++
12:14:46 <Brooke> hang on lemme post some stuff I said in whisper to main
12:15:03 <Brooke> Brooke: yeah I need to really crystalise what I have in mind for things
12:15:04 <Brooke> [07:10am] Brooke: the meetings traditionally were the place to vote
12:15:04 <Brooke> [07:10am] Brooke: however, we've done things like KohaCon outside the meeting
12:15:04 <Brooke> [07:10am] Brooke: so
12:15:05 <Brooke> [07:10am] Brooke: we need to figure out what the ultimate forum is
12:15:05 <Brooke> [07:11am] Brooke: and we also need to streamline how topics are mentioned
12:15:05 <Brooke> [07:11am] Brooke: I'm guessing folks would prefer an hour a meeting
12:15:07 <Brooke> [07:11am] Brooke: to like 2 and a half.
12:15:07 <Brooke> [07:11am] Brooke: it's possible if we do more work in small groups or hash things out over the list or irc much better
12:15:09 <Brooke> [07:11am] Brooke: and then bring something that can have a yes or no vote to the meeting
12:15:09 <Brooke> [07:12am] Brooke: or be put into a survey and sent to the list
12:15:11 <Brooke> [07:12am] Brooke: it seems to me that things that are overarching and affect the spirit of the project
12:15:11 <Brooke> [07:12am] Brooke: are always going to lend themselves to IRC
12:15:13 <Brooke> [07:12am] Brooke: where smallish things make sense for a ballot.
12:15:46 <slef> I would suggest timed agenda items again.
12:15:55 <paul_p> timed++
12:16:05 <paul_p> (clrh always uses timebox !)
12:16:28 <slef> If the chair doesn't mind having permission to break our legs^Wdiscussions to keep to time?
12:16:39 <Brooke> it depends
12:16:52 <Brooke> chairing is delightfully dynamic
12:16:57 <paul_p> i'm for it !
12:17:07 <Brooke> I tend to impose a time limit if I think summat is gonna be controversial AND beaten to death..
12:17:16 <paul_p> ++
12:17:19 <Brooke> I'll keep thinking on things
12:17:41 <slef> traditionally (hah, that old trick!), anyone in a meeting can call for the vote to be held or to move on to the next item... but times on the agenda reduces the surprise for people who don't know such things.
12:17:54 <thd> I think that things should take as long as they take but encouragement should be given to having good discussions outside the monthly meeting in our various fora.
12:18:13 <paul_p> agreed (and TZ things improve this need)
12:19:10 <thd> I think that social pressure such as are we taking too long here is a better solution than strict timing.
12:19:17 <slef> thd: sure. Get a room/workgroup/submeeting is also a valid request, usually combined with a vote or budge.
12:19:49 <slef> I think that social pressure is insufficient here. You can't see people fidget on IRC.
12:20:18 <thd> We could time an are we taking too long here prompt with the possibility that the answer is no.
12:20:19 <Brooke> meh
12:20:21 <Brooke> anyway
12:20:29 <Brooke> #topic Time and Date of next meeting
12:20:57 <Brooke> Feb 1 or Feb 8?
12:21:24 <slef> 8 Feb?
12:21:31 <Brooke> fine with me
12:21:32 * slef opens the bidding
12:21:42 <Brooke> any heavy objections to Feb 8?
12:21:44 <thd> +1
12:21:58 <thd> +1 8th Feb.
12:22:03 <asaurat> no objection
12:22:04 <ColinC> either ok
12:22:04 <slef> Is it 0200 UTC?
12:22:18 <paul_p> OK for me
12:22:27 <Brooke> 2 utc yes
12:22:47 <paul_p> 3AM for me... wonderfull meeting time ;-)
12:22:48 <Brooke> 10 > 2 > 18 is the cycle.
12:23:27 <Brooke> paul: guess what time it is in NZ right now :P
12:23:30 <slef> 1 hour meeting aim?
12:23:39 <Brooke> not nec
12:23:54 <Brooke> but I'm gonna say think about what you want to say given the agenda before hand
12:24:01 <Brooke> and if it's not on the agenda, stick it there.
12:24:23 <Brooke> so vote
12:24:28 <Brooke> 8 February 2 UTC
12:24:33 <slef> +1
12:24:45 <jwagner> +1
12:24:57 <ColinC> +1
12:26:02 <paul_p> +1
12:26:07 <thd> =1
12:26:14 <thd> +1
12:27:23 <sekjal> +!
12:28:22 <Brooke> #info next meeting is 8 Feb 0200 UTC
12:28:28 <Brooke> #endmeeting