15:03:52 <cait> #startmeeting IRC Development Meeting 5 February, part 1
15:03:52 <huginn> Meeting started Thu Feb  5 15:03:52 2015 UTC.  The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:52 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:52 <huginn> The meeting name has been set to 'irc_development_meeting_5_february__part_1'
15:03:54 <barton> Coffee: |=============>|.....| 75 %
15:03:55 <cait> welcome
15:03:55 <wahanui> Welcome to zombo.com
15:04:00 <cait> #introductions
15:04:05 <cait> please introduce yourself with #info
15:04:11 <tcohen> #info Tomas Cohen Arazi, Universidad Nacional de Cordoba
15:04:17 <NateC> #info
15:04:24 <NateC> woops
15:04:25 <barton> #info Barton Chittenden, Bywater Solutions, Louisville KY, USA
15:04:27 <bensinober> #info Benjamin Rokseth, Oslo Public Library
15:04:28 <cait> #info the agenda for today's meeting can be found at http://wiki.koha-community.org/wiki/Development_IRC_meeting_5_February_2015
15:04:29 <NateC> s
15:04:34 <bag> #info Brendan Gallagher ByWater Solutions
15:04:38 <cait> #info Katrin Fischer, BSZ
15:04:41 <oleonard> #info Owen Leonard, Athens County Public Libraries, Ohio
15:04:44 <NateC> #info Nate Curulla ByWater Solutions
15:04:47 <edveal> #info Ed Veal, ByWater Solutions
15:04:58 <jcamins> #info Jared Camins-Esakov, C & P Bibliography Services
15:04:59 <barton> #info Coffee: |=============>|.....| 75 %
15:05:16 <barton> couldn't resist.
15:05:33 <cait> #topic RM 3.18 comments
15:05:48 * cait hands the keyboard to tcohen
15:05:49 <tcohen> 3.20?
15:05:58 <cait> you are right, but the agenda was not updated :)
15:06:08 <cait> #topic RM 3.20 comments
15:06:17 <tcohen> it is
15:06:32 <cait> now :)
15:06:33 <bag> magnuse: HI
15:06:57 <tcohen> oh
15:07:10 <tcohen> the agenda is missing the "deprecate Squeeze support" line
15:07:21 <tcohen> ok, I'm worried about several stuff that is stuck
15:07:31 <tcohen> most of it is on the next topic list
15:07:46 <tcohen> we need to make a decision on how/what to catch
15:08:17 <tcohen> it is a trade-off between the minimum possible db access vs reasonable invalidation
15:08:33 <tcohen> will discuss that later
15:08:49 <tcohen> and there's also the recent problems with zebra's performance on the list
15:08:52 <tajoli> #info Hi Zeno Tajoli, Cineca (Italy)
15:09:37 <tcohen> we are in talks with indexdata on some problems we found (dcook and I)
15:09:44 <tcohen> they promised a response
15:10:10 <tcohen> but it seems that some important koha bits are not having enough attention
15:10:26 <tcohen> - plack support (what's missing needs devs to take a look)
15:11:02 <tcohen> - searching (neither QP completeness or search performance have people worried/working on that)
15:11:19 <magnuse> bag: HI
15:11:19 <wahanui> bidet, magnuse
15:11:29 <tcohen> I started some tests on optimizing/refactoring C4::Search::searchResults
15:11:47 * magnuse wanders off
15:11:52 <tajoli> we testing on bugs about QueryParsing ?
15:11:57 <tcohen> but that's WIP, and we have stuff already on the pipe, i.e. bugs
15:12:09 <khall> #info Kyle M Hall, ByWater Solutions
15:12:13 <tcohen> welcome tajoli, nice to hear that
15:12:35 <tcohen> this is just general comments on what is worring me now
15:12:49 <tcohen> ok, that's it for now
15:13:10 <tcohen> GRS1 and non-XSLT view removal would ease the refactoring
15:13:19 <tcohen> so, lets move forward, ciat
15:13:20 <tcohen> cait
15:13:36 <cait> ok
15:13:37 <Joubu> #info Jonathan Druart, BibLibre
15:13:46 <cait> any comments tho?
15:14:10 <cait> #topic REST API RFC
15:14:21 <tcohen> ashimema: all yours
15:14:32 <cait> #link http://wiki.koha-community.org/wiki/New_REST_API_RFC
15:14:51 <ashimema> ahh..
15:14:51 <khall> REST all the things!
15:14:55 <ashimema> didn't realise thre was a meeting
15:15:00 <talljoy> #info Joy Nelson ByWater Solutions
15:15:14 <ashimema> #info Martin Renvoize, PTFS Europe
15:15:29 <ashimema> yeah.. beyond what we've said so far on that page this isn't much..
15:15:39 <ashimema> we're hoping to have a gathering to discus it as hackfest..
15:15:51 <khall> I fail to see why we should move svc to svc_legacy, which will break existing services when we can just start fresh with /rest/v1/
15:15:56 <ashimema> I was hoping to find a time that means people across the world can join in a bit.
15:16:05 <tcohen> khall: I agree
15:16:16 <ashimema> I'm fine with that..
15:16:17 <bensinober> agree, versioning APIs are crucial
15:16:22 <ashimema> 'twas Joubu's thought to shift it..
15:16:43 <tcohen> ashimema: I guess he wanted to keep /svc
15:16:53 <tcohen> besides the name....
15:17:16 <tcohen> Joubu: what's your experience with koha-resful regarding how you manage the routing?
15:17:31 <ashimema> I think the main thing is that we should be ancourages work in the new namespace.. and discourages work in the old as soon as we decide to go for it..
15:17:32 <Joubu> I don't have any experience with koha-restful
15:17:39 <Joubu> I didn't dev it
15:18:04 <Joubu> koha-restful dev will be present at the Marseille hackfest, will be good to talk with them
15:18:04 <jeff> #info Jeff Godin, Traverse Area District Library (TADL)
15:18:09 <bensinober> we have been using koha-restful some at OPL, though we are wondering about if its maintained
15:18:14 <ashimema> definitely.
15:18:28 <tcohen> what i'v seen about koha-restful
15:18:30 <Joubu> bensinober: we used it, yes
15:18:37 <Joubu> we use it!
15:18:42 <jeff> serendipitously stumbling into this meeting and finding it interesting/potentially-relevant. :-)
15:18:47 <tcohen> is that it is well organized, and has a single front-end script
15:18:48 <ashimema> I think the real first stage in this is to get some good clear guidlines for it bashed out..
15:18:55 <tcohen> that handles the routing for each endpoint
15:18:55 <Joubu> maybe not tested with koha 3.18
15:19:01 <bensinober> there are some issues on 3.16 and 3.18 both
15:19:09 <ashimema> then no-one's in the dark with how things 'should' be done.. and the QA team have somthing to refer to when feeding back
15:19:20 <tcohen> I think that's the way to go
15:19:44 <khall> agreed.
15:20:01 <tcohen> either using something like dancer, or mimicking koha-restful using  CGI::Application::Dispatch or an equivalent solution
15:20:04 <ashimema> koha-restful is compeletly self contained and doesn't really lend itself to inclusion in koha as is..
15:20:19 <khall> I really like Jesse Weaver's work
15:20:42 <ashimema> having said that.. in some ways being self contained is nice
15:20:47 <bensinober> as a sidenote, /svc is already used internally for patron lookup, preference settings etc.
15:21:11 <bensinober> but there is sparse documentation
15:21:20 <ashimema> Jesse's work is certainly rather nice.. though it's basically just a clone of a small aprt of what allot of other frameworks give you out of the box. i.e dancer, mojo etc
15:21:45 <cait> ashimema: what would be your preference? building on jesse's or swtiching it to a framework?
15:21:57 <ashimema> in the medium term I'd like to replace all the current internal use of svc with new rest stuff
15:21:58 <cait> just a little worried about having a framework discussion :)
15:22:00 <khall> ashimema: right. I'm 100% for the rest api being baked in to Koha
15:22:11 <ashimema> I'm all for including Jesse's stuff..
15:22:14 <cait> and i'd like to see something inside koha as kyle says
15:22:36 <cait> Joubu: do you have a preference?
15:22:40 <bensinober> seems to me a good idea to join the work of Jesse w and build out a internal API that could have selected services exposed
15:22:41 <ashimema> if we chose to use a framework it should be all or nothing... or we're just building ourselves into two corners again.
15:22:51 <Joubu> not really
15:23:10 <ashimema> jesse's stuff is nice.. as it take's some of the best bits of the frameworks and effectively backports them to our 'koha' framework.
15:23:51 <tcohen> the question is
15:24:04 <cait> ashimema: is it something we could shift to a framework later and have this as a first step?
15:24:05 <tcohen> does #bywater have a schedule for it?
15:24:18 <ashimema> I 'think' with Jesse's work, if we later wanted to port it to Dancer/mojo it wouldn't be an aweful job.
15:24:40 <ashimema> Jesse's given me the all clear to submit his work thus far tcohen ;)
15:24:47 <cait> yay :)
15:25:02 <tcohen> is there any sample implementation to look at?
15:25:05 <ashimema> What I was going to do was split down his tree into a whole set of bugs.. 1 with the core module in.. then a bug for each svc we port..
15:25:12 <ashimema> he was trying to do it all at once.. hense the hold up.
15:25:22 * cait dislikes all at once things
15:25:39 <tcohen> ashimema: core + one sample endpoint implemented would be a good start
15:25:45 <khall> ashimema: sounds like an excellent plan
15:25:46 <ashimema> https://github.com/pianohacker/koha/commit/40908d6e58c40e6ffaa488266a70ef5233fe9642
15:25:58 <tcohen> it could help eythian on his effort with patron management
15:26:03 <cait> #link https://github.com/pianohacker/koha/commit/40908d6e58c40e6ffaa488266a70ef5233fe9642
15:26:13 <ashimema> I'll be submitting cash management at some point.. and that relies heavily upon it.. showing good practice for three routes at least..
15:26:17 <bensinober> great idea
15:26:19 <khall> I'd say bugs for Core -> New SysPref Servce -> Replace Old SysPref Service with New
15:26:24 <ashimema> and i've also got some other examples I'll be posting along with it..
15:26:40 <ashimema> khall.. defoo.. that's the best plan I reckon
15:27:39 <ashimema> tcohen et al.  were we ok with putting eythians patron api stuff in as is.. with the undertsnading that it'll be deprecated fairly quickly once we have had the restful debate at hackfest..
15:27:54 <khall> I'd be more than happy to help write up some Koha REST api standards
15:27:57 <ashimema> I'm happy doing the work to port it.. seeing as I've already got a half baked one here to play with ;)
15:28:09 <ashimema> khall.. seen the wiki page above?
15:28:19 <ashimema> would certainly apreciate your input on it too..
15:28:20 <cait> can i add actions? :)
15:28:31 <ashimema> eat your heart out cait ;)
15:28:32 <tcohen> ashimema: i don't have any problem with pushing eythian's work on /svc
15:28:36 <cait> #action ashimema to submit patches for the new restful API - core + a sample
15:28:53 * ashimema to fit this all around having baby ;)
15:28:56 <bensinober> got to go, if there are anything to vote on, I'm good with ashimemas plan
15:29:01 <khall> ashimema: yes, I think it's a very good base. Honestly, the more terse we can make it the better it will be followed
15:29:03 <Joubu> maybe should we wait for the discussion at the hackfest before writing anything?
15:29:14 <bensinober> see you in Marseille!
15:29:16 <tcohen> please don't tie the new restful api to a new sysprefs service implementation
15:29:22 <cait> someone else i need to action? :)
15:29:27 <cait> trying to catch up reading
15:30:16 <cait> #action khall volunteers helping out with the RFC and writing up some guidelines
15:30:41 <khall> tcohen: that was just an example, we can find something else as a starter
15:30:52 <tcohen> khall: all good
15:31:03 <tcohen> maybe search ? :-D
15:31:12 <cait> maybe soemthing easy and existing? :)
15:31:17 <cait> adding a record? )
15:31:20 <cait> not sure
15:31:21 <cait> ok
15:31:22 <cait> moving on?
15:31:22 <khall> tcohen: what we really need is to get datatables to play well with a standard api instead of the special stuff it prefers
15:31:36 <tcohen> angular
15:31:38 <khall> angular
15:31:41 <khall> lol
15:31:54 <tcohen> we are all on the same track, moving on :-D
15:32:03 <cait> #topic Zebra / Facet issues
15:32:05 <tcohen> Marseille will be really fun
15:32:16 <cait> hopefully productive fun - but fun i am sure :)
15:32:29 <khall> hackfest++
15:32:43 <cait> I'd like to add an obvervation here about zebra facets
15:32:45 <tcohen> i've collected several stuff about the "zebra facets" feature i'd like to share
15:32:56 <cait> tcohen goes first :)
15:33:30 <tcohen> - they are problematic with the latest Zebra (2.0.59) already present in Testing
15:34:20 <tcohen> 2) their performance is not logaritmic on the amount of records you ask them ti be calculated on
15:34:58 <tcohen> about (1) i'm in talks with indexdata, and will try to have something about it soon, so it doesn't catch us
15:35:34 <tcohen> about (2) the preference facetNumRecs (present in zebra-biblios-dom.xml) is set to 1000 by default
15:36:03 <tcohen> it was a good default, but it seems that large databases (more than 1M records) see some impact on speed.
15:36:25 <tcohen> at UNC we see a gain in speed instead, but our databases are small (90K the bigger)
15:36:38 <Joubu> I have opened a bug report to explain what I have tried 2 days ago (bug 13665)
15:36:38 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13665 major, P5 - low, ---, gmcharlt, NEW , Retrieve facets from zebra is slow
15:36:55 <Joubu> tested on a 1M record DB
15:37:34 <tcohen> i'm experimenting with retrieving all facets at once, whch seems optimal, but need indexdata's feedback on two problems
15:38:26 <tcohen> a) there seems to be a bug that prevents retrieving more than 8 facets at once (they filled a bug ZEB-663 as per my request)
15:39:01 <tcohen> b) there's no current way to change the current behaviour of facet retrieval failing if some facet is not previously populated
15:39:10 <tcohen> i'm working on both
15:39:14 <tcohen> at once, heh
15:39:43 <tcohen> it'd be great to have a sample DB with more than 1M records *with items*
15:39:48 <cait> tcohen++
15:39:49 <tcohen> to play with
15:39:55 <tcohen> I don't have it
15:40:08 <cait> i have done some testing with facets and ran into somethings that confused me a little
15:40:15 <cait> 1) the facets changed with the sorting i chose
15:40:48 <cait> 2) for a result set of 22 records it didn't list all itemtypes as facets that were present in the result set in some 'sort' cases
15:41:07 <cait> if the default is set to 1000... i don#t se why this could happen yet
15:41:22 <cait> it didn't onyl happen for itemtypes but also for other categoreis, just quite obvious there
15:41:35 <cait> would be interested if there is an explanation yet or if people experience similar things in testing
15:41:38 <Joubu> 1: what was the number of result? > 1000?
15:41:44 <cait> 22
15:42:15 <Joubu> weird
15:42:19 <cait> yep
15:42:42 <ashimema> I'm finding datatables really slow
15:42:51 <Joubu> Are the facets sorted by "count" ?
15:43:08 <tcohen> I couldn't reproduce cait's problem FTR
15:43:44 <tcohen> (talking about (2))
15:44:22 <cait> i know - maybe we can just keep it in mind and an eye on it?
15:44:25 <cait> ok movingon?
15:44:30 <tajoli> there is also an other problem on Zebra: 'Zebra hyphen truncating search' on koha-devel
15:44:31 <cait> anything to #info
15:44:41 <tcohen> cait: did u get access to the z39.50 port?
15:44:46 <cait> not yet
15:44:50 <cait> too busy today :(
15:44:53 <cait> will see about it
15:44:56 <tcohen> to try the facet retrieval directly from zebra
15:45:01 <cait> ready to move on?
15:45:06 <tcohen> and spot possible Koha problem?
15:45:51 <cait> i will try to arrange better testing or find samples in my dev database
15:45:56 <cait> #topic Non-XSLT removal
15:45:57 <tcohen> #action people that have issues with zebra facets, contact tcohen who will be looking at those
15:46:03 <cait> :)
15:46:21 <tcohen> Non-XSLT removal
15:46:57 <tcohen> it is already deprecated, since July 2014
15:47:17 <tcohen> #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12561
15:47:17 <huginn> 04Bug 12561: normal, P5 - low, ---, oleonard, NEW , Omnibus: Deprecate non-XSLT detail and result views
15:47:19 <cait> does someone have the actions about this on hand?
15:47:40 <cait> i think i found another - the opac summary field in the itemtype configuration - that's non-xslt only? if used at all still?
15:48:13 <cait> the problem with killing it is that we will have a feature loss for some libraries
15:48:23 <cait> bug 13327 for example
15:48:23 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13327 normal, P5 - low, ---, oleonard, NEW , OPACPopupAuthorsSearch doesn't work with XSLT views
15:48:46 <cait> or bug 11426
15:48:46 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11426 normal, P5 - low, ---, oleonard, NEW , Make HighlightOwnItemsOnOPAC work with XSLT
15:48:51 <cait> khall: woudl you be able to port that to xslt?
15:48:55 <tcohen> are they aware of its deprecation? concerned?
15:49:28 <khall> cait: I think it'll have to be ported
15:50:01 <khall> I'm no xslt wizard though, so I don't know what it will involve
15:50:44 <tcohen> khall: is it just template stuff?
15:51:10 <khall> tcohen: my guess is the hard part is getting the data to the xsl template
15:51:29 <tcohen> specifically?
15:51:58 <tcohen> users-branch?
15:52:11 <khall> I can't give any specifics at the moment, I'll need to reappraise myself of the feature
15:53:13 <cait> i think we maybe need a more comprehensive list - maybe lookint at the prefs on the normal views?
15:53:24 <cait> it's deprecated, but need to decide about features
15:53:28 <tcohen> it's all bloody mixed
15:53:31 <cait> or maybe say they will get removed
15:54:05 <cait> can we set a deadline for next meeting to feed the bug with depending things?
15:54:12 <cait> woudl someone volunteer to look at the code?
15:54:40 <cait> looks like i did volunteer last time ... oops
15:54:43 <oleonard> So we know some things need to get ported, but does that block agreement on the plan to remove the normal view?
15:54:44 <tcohen> i have no objections
15:55:07 <cait> it's something we didn't do so far
15:55:10 <cait> breaking features :)
15:55:12 <cait> but we could
15:55:20 <khall> I also have no objections. Growing pains are inevitable. But the advantage of only one view to update is worth it
15:55:22 <cait> the question is if they will be ported before or after removal
15:55:29 <oleonard> Not on purpose anyway cait
15:55:34 <cait> true
15:55:38 <khall> cait: before would also be preferred, but not required
15:55:51 <cait> #action cait volunteers again to look into creating a better list of features missing from XSLT view
15:56:04 <cait> so can we have a vote
15:56:09 <cait> ?
15:56:12 <tcohen> yes
15:56:30 <cait> please vote on removal - keeping in mind that features might not be ported on time
15:56:41 <barton> I second the movement to vote.
15:56:48 <khall> +1
15:56:50 <oleonard> +1
15:56:59 <barton> +1
15:57:03 <Joubu> 0
15:57:06 <tajoli> 0
15:57:18 <cait> 0
15:57:27 <bag> hmmm  hard one  +1
15:58:27 <cait> there is a second meeting scheduled
15:58:32 <cait> i will add the results as info
15:59:00 <tcohen> +1
15:59:10 <cait> #info voting results on code removal of non-XSLT views: 3x 0, 5x yes
15:59:21 <cait> moving on to another topic, hopefully easier :)
15:59:22 <tcohen> 0 is neutral?
15:59:25 <cait> yeah
15:59:30 <tcohen> ah,ok
15:59:37 <cait> #topic GRS-1 removal
15:59:55 <cait> i thik we still don't have current problems with dom indexing, so this seems safer :)
16:00:02 <cait> any comments before the vote?
16:00:16 <tcohen> I'd like to hear from UNIMARC users
16:00:24 <tcohen> if they are using it, successfully
16:00:45 <Joubu> BibLibre customers still using grs1
16:01:10 <Joubu> I use dom on my dev install, but I don't play with zebra indexes...
16:01:11 <tcohen> have you at least evaluated DOM UNIMARC setups?
16:01:40 <Joubu> tcohen: yes, I think so
16:01:58 <Joubu> I let a note on a bug, don't remember when/where
16:02:28 <Joubu> "I have just install an install with unimarc + dom, it works"
16:02:32 <cait> bug 12641
16:02:32 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12641 enhancement, P5 - low, ---, gmcharlt, NEW , Formally deprecate the GRS-1 indexing mode
16:02:57 <cait> #info bug 12641
16:03:09 <cait> Joubu: would you be ok with having a vote?
16:03:10 <tcohen> it is important to note GRS-1 has been deprecated on July 7 2014
16:03:17 <tcohen> *23
16:03:26 <Joubu> it was bug 9342
16:03:26 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9342 critical, P5 - low, ---, gmcharlt, RESOLVED FIXED, zebra UNIMARC dom indexing does not work
16:03:27 <cait> #info  GRS-1 has been deprecated on July 7 2014
16:03:47 <Joubu> paul_p agreed last meeting, so good to me
16:03:58 <cait> ok
16:04:01 <tcohen> i think we can have a vote
16:04:12 <cait> so please vote on code removal of grs-1 code - making dom the only available option
16:04:17 <tcohen> and UNIMARC users/providers are encouraged to report any issues
16:04:17 <cait> +1
16:04:20 <tajoli> +1
16:04:20 <TGoat> good morning beautiful #koha peeps
16:04:21 <Joubu> +&
16:04:21 <barton> +1
16:04:28 <Joubu> +1
16:04:29 <tcohen> +1
16:04:36 <ablj> +1
16:04:37 <cait> #info UNIMARC and all other users are encouraged to report any issues with DOM indexing
16:04:44 <khall> +1
16:04:53 <oleonard> 0
16:04:54 <tcohen> if there are remaining issues, they should be reported before Marseille's hackfest, so we can solve them
16:05:33 <cait> #voting results on code removel of grs-1: 1x 0, 7x yes
16:05:54 <cait> #info please report before first week in march, so problems can be fixed at the hackfest in marseille
16:05:56 <cait> moving on
16:06:19 <cait> #topic Coding syntax preferences: $a->{b}{c} vs. $a->{b}->{c}
16:06:34 <cait> #info bug 13240 for discussion
16:06:34 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13240 normal, P5 - low, ---, jonathan.druart, Signed Off , advanced_notices.pl contains code obfuscation
16:07:31 <barton> I definitely prefer the second.
16:07:47 <Joubu> I definitely prefer the first :)
16:07:56 <cait> i don't have a preference
16:08:05 <Joubu> But I really don't want to discuss years about that, it's really minor, IMO.
16:08:14 <cait> i kind of agree there :)
16:08:20 <tcohen> 0 for me
16:08:25 <cait> i think we have worse things to battle :)
16:08:26 <khall> agreed, but I also prefer the latter
16:08:41 <cait> the qustion is: is this a qa fail or are we allowing both equally for now?
16:08:52 <barton> I agree with all of the above ;-)
16:08:53 <Joubu> Let's us do like we want? :)
16:09:22 <tcohen> i think we can all adapt to either
16:09:28 <tcohen> we could just vote
16:09:45 <tcohen> what does perlcritic say about this?
16:10:07 <Joubu> I switched from $$a{key}{bar} to $a->{foo}{bar}. It was already a big change :p
16:10:07 <cait> please vote which you prefer: 1) $a->{b}{c}  2) $a->{b}->{c} 3) both shoudl be valid 4) no opinion
16:10:16 <khall> 2
16:10:21 <Joubu> 3
16:10:32 <cait> 4
16:10:39 <tcohen> 4
16:10:41 <barton> 2
16:10:51 <ablj> 2
16:10:52 <Joubu> So we should also vote for $a->{"foo"} or $a->{foo} :)
16:11:05 <tcohen> nah, quotes are forbidden
16:11:07 <tcohen> :-P
16:11:33 <khall> agreed!
16:11:34 <cait> sorry phone
16:11:37 <cait> #chair tcohen
16:11:37 <huginn> Current chairs: cait tcohen
16:11:55 <tcohen> more votes?
16:12:51 <tcohen> #voting results 1) 0 2) 3 3) 1 4) 2
16:13:04 <tcohen> lets see what people say on part 2
16:13:19 <cait> #info voting results 1) 0 2) 3 3) 1 4) 2
16:13:27 <tcohen> :-P
16:13:46 * barton promises not to vote again in the second meeting.
16:13:49 <khall> tcohen: is that in the coding guidelines? I'm not seeing it
16:14:14 <tcohen> shh, will write it without people noticing
16:14:52 <tcohen> i'll put it on next dev-meeting's agenda
16:14:53 <khall> <whisper>sounds good to me</whisper>
16:15:04 <tcohen> cait: moving on?
16:15:13 * tcohen has to leave in 3~4 minutes
16:15:23 <cait> maybe we should put the rest on the next meeting?
16:15:30 <cait> is there something really urgent on the leftover topics?
16:15:35 <tcohen> yes
16:15:46 <Joubu> I would like to talk about the test perf regression
16:15:49 <tajoli> I prefer 3
16:15:59 <Joubu> I will have some time to dedicate on that
16:16:14 <Joubu> + set time for a pre hackfest meeting
16:16:26 <tcohen> i changed my mind, we can leave the rest for the next meeting
16:16:34 <tcohen> could we have one next week?
16:16:37 <cait> ok for me
16:16:42 <cait> i will be travelling the week after next
16:16:43 <tajoli> I try
16:16:55 * tcohen has to leave
16:17:01 <tcohen> later guys
16:17:05 <cait> will yo u send an email tcohen?
16:17:10 <cait> with a date/time?
16:17:45 <tcohen> yes
16:17:45 <cait> shall we just #action him to?
16:17:46 <cait> ah :)
16:17:48 <tcohen> next wednesday
16:17:53 <tcohen> yes, action
16:17:54 <tcohen> please
16:18:09 <cait> #action tcohen to set date and time for next meeting - email to dev list
16:18:15 <cait> #endmeeting