14:08:13 <cait> #startmeeting Development IRC meeting 13 July 2016
14:08:13 <huginn> Meeting started Wed Jul 13 14:08:13 2016 UTC.  The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:13 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:08:13 <huginn> The meeting name has been set to 'development_irc_meeting_13_july_2016'
14:08:17 <cait> #topic Introductions
14:08:17 <wahanui> #info wahanui, a bot that has become sentient
14:08:27 <cait> please introduce yourself following wahanui's example
14:08:34 <Joubu> #info Jonathan Druart
14:08:52 <cait> #info Katrin Fischer, BSZ, Germany
14:09:00 <cait> today's agenda is at
14:09:10 <cait> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_13_July_2016
14:09:36 <khall> #info Kyle M Hall, ByWater Solutions
14:09:57 <drojf> #info Mirko Tietgen, koha.abunchofthings.net
14:10:08 <druthb> #info Ruth Bavousett, nobody important.
14:10:10 <oleonard> #info Owen Leonard, Athens County Public Libraries
14:10:33 <cait> moving onto next topic in a moment
14:11:46 <cait> #topic announcements
14:11:50 <cait> #chair drojf
14:11:50 <huginn> Current chairs: cait drojf
14:11:54 <cait> backup - as I am at work :)
14:12:08 <cait> any announcements?
14:12:36 <drojf> not a useful backup today, only here with one eye .)
14:12:44 <cait> are you a pirate now?
14:12:51 <cait> ok
14:12:54 <drojf> heh
14:12:54 <cait> moving on to the next one
14:13:02 <cait> #topic Review of coding guidelines
14:13:28 <cait> Someone has put up a question for discussion:
14:13:28 <cait> #info Should cache-only bugs require benchmarks to prove confirm speed improvements?
14:14:06 <Joubu> It seems that khall did
14:14:13 <Joubu> khall: what's the context?
14:14:13 <wahanui> the context is everything?
14:14:14 <cait> khall: can you explain a bit about the context please?
14:14:44 <Joubu> I think I provide benchmarks for these kind of changes
14:14:49 <khall> yes. The idea being that if a patch is only about speed improvements, should the author be required to post data proving there is a speed increase
14:15:19 <khall> Joubu does, so we should probably just put it in the guidelines
14:15:27 <marcelr> #info Marcel
14:16:23 <Joubu> khall: I'd it's like unit tests for method/subroutine changes, if you think your patch adds speed improvements, you must prove it :)
14:16:31 <Joubu> say*
14:16:52 <khall> Joubu: it sounds like your in favor of it then?
14:17:01 <Joubu> yep
14:17:03 <cait> hm I must say it sounds logical to me for this kind of patches
14:17:22 <cait> I think it's also likely to speed thing up if people see there is somethign to gain
14:17:32 <khall> agreed
14:17:42 <marcelr> some other patches could use benchmarks too ?
14:17:46 <Joubu> we could provide a bunch of lines testing the cache speed
14:19:36 <cait> i think we once agreed that if we have doubts about a patch - like if we are afraid it will slow down things significantly, that qa can ask for benchmarks
14:20:12 <cait> checking the coding guidelines one sec
14:20:37 <cait> hm nothing for speed, benchmark or performance in there...
14:20:59 <Joubu> khall: What's the context? Did you ask for a specific patchset?
14:21:32 <khall> Joubu: I don't really recall to be honest.
14:22:18 <khall> I think if we are going to be able to ask for benchmarks on non-cache patches, the bar should be set fairly high.
14:22:31 <marcelr> wouldn't hurt to have a general rule to ask for benchmarks where we doubt
14:22:56 <marcelr> but yes, not to quick
14:22:57 <khall> Yes, but it's also another hurdle that developers have to jump.
14:23:20 <khall> It makes sense for performance patches, but I think we've got plenty of hoops to jump through already ; )
14:23:40 <Joubu> I will check if I can add some benchmarks in the qa tools (optional) for QA
14:24:06 <Joubu> That could launch a series of tests before and after the patches applied
14:24:14 <Joubu> and compare the diff
14:24:17 <khall> Joubu: that would be very useful!
14:24:29 <khall> that would definitely lower the bar. Thanks!
14:24:31 <cait> cool
14:24:37 <cait> i will log an action for that :)
14:24:48 <Joubu> yes please do :)
14:25:03 <marcelr> lots of success :)
14:25:04 <cait> #action Joubu is going to check if some performance testing can be included in the qa scripts (launch a series of tests and compare diff)
14:25:16 <cait> so shoudl we just add one rule for now?
14:25:26 <cait> performance patches should improve performance gain?
14:25:47 <marcelr> or: patches should not dramatically impact performance ?
14:25:47 <khall> I think so. Should we do a vote?
14:26:01 <cait> marcelr: would be nice if that was a given heh :)
14:26:13 <khall> marcelr: I think that's a slippery slope ; )
14:26:37 <marcelr> whats in a drama
14:27:00 <cait> #startvote new coding guideline: performance and chache related patches should include benchmarks of some sort to prove their effects. Question? (yes,no)
14:27:00 <huginn> Begin voting on: new coding guideline: performance and chache related patches should include benchmarks of some sort to prove their effects. Question? Valid vote options are , yes, no, .
14:27:00 <huginn> Vote using '#vote OPTION'. Only your last vote counts.
14:27:00 <khall> ?
14:27:13 <khall> #vote yes
14:27:17 <marcelr> #vote yes
14:27:21 <Joubu> #vote yes
14:27:22 <cait> i have to add a question mark somewhere... so it works
14:27:26 <cait> #vote yes
14:27:36 <druthb> #vote yes
14:27:45 <drojf> #vote yes
14:28:08 <oleonard> #vote yes
14:28:17 <cait> #endvote
14:28:17 <huginn> Voted on "new coding guideline: performance and chache related patches should include benchmarks of some sort to prove their effects. Question?" Results are
14:28:17 <huginn> yes (7): Joubu, cait, oleonard, marcelr, druthb, khall, drojf
14:28:17 <cait> #agreed new coding guideline: performance and chache related patches should include benchmarks of some sort to prove their effects.
14:28:24 <khall> @later tell oleonard this looks interesting https://nosir.github.io/cleave.js/
14:28:24 <huginn> khall: The operation succeeded.
14:28:24 <cait> who is going to add it?
14:28:33 <khall> cait: I will
14:28:48 <cait> #action khall to add new benchmark rule to the coding guidelines
14:29:01 <cait> do we have a page about benchmarking/tools? might be good to link if we have - to give some hints
14:29:17 <cait> moving on to next topic
14:29:26 <cait> #topic Bugs in discussion
14:29:48 <cait> #info Topic: Koha::Patrons::Import (bug 12598) vs Koha::Exporter::Record (bug 14722)
14:29:50 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12598 enhancement, P5 - low, ---, kyle, Failed QA , New misc/import_borrowers.pl command line tool
14:29:51 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14722 enhancement, P5 - low, ---, jonathan.druart, Pushed to Master , Refactor the catalogue export tool (command-line tools/export.pl does not work anymore. Use misc/export_records.pl instead)
14:30:02 <cait> again, i need some help here about the context please
14:30:11 <Joubu> It's just about the name/structure of the import/export new modules we are going to add
14:30:31 <Joubu> I have added Koha::Exporter::Record in 14722
14:30:46 <Joubu> and 12598 adds a Koha::Patrons::Import
14:30:54 <Joubu> that does not make sense to have both
14:31:27 <Joubu> we should have either Koha::Exporter::Record(s?) and Koha::Exporter::Patron(s?)
14:31:48 <marcelr> consistency++
14:31:51 <Joubu> of Koha::Patrons::Export|Import and Koha::Records::Export|Import
14:32:30 <cait> i am all for concistency... but I don't have a strong prefrence there
14:32:39 <Joubu> My opinion is that having Koha::Exporter|Importer::Stuffs will add the ability to have a Koha::Exporter::Importer to group export/import methods, if we have to
14:32:45 <cait> exporter sounds a little odd to me - so from language.. maybe i'd look under patrons first
14:34:06 <khall> personally, I like how Koha::Object::Export and Koha::Object::Import read, it really revolves around the object, and not the "Exporter" which is a thing that doesn't exist
14:34:50 <Joubu> can be Koha::Import|Export::Objects instead
14:35:32 <khall> yep, I don't think either one is really "better" than the other
14:35:41 <Joubu> anyone else?
14:36:25 <cait> hm
14:36:25 <Joubu> khall: no, but it's bad if they both exist :)
14:36:46 <cait> i think we have no inheritance, is that right? as kyle said, there is no exporter object?
14:36:59 <Joubu> We will want to export in csv, odt, pdf, etc.
14:37:08 <khall> Joubu: yes, I agree with that. We should pick one or the other
14:37:17 <Joubu> and we will want to centralise some of these functions under the same namespace
14:37:24 <khall> Koha::Patron::Export::CSV
14:37:25 <khall> vs
14:37:32 <khall> Koha::Export::CSV::Patron?
14:37:51 <khall> I think the former makes more sense
14:37:54 <Joubu> or Koha::Export::Patron::CSV
14:38:20 <khall> that's not bad either
14:38:41 <Joubu> ok I will ask on the mailing list...
14:38:44 <khall> ok, I think we need to just have a majority rule vote. We're bikeshedding ; )
14:38:53 <cait> yeah, ask so they pick one
14:38:56 <cait> and state it clearly
14:39:05 <Joubu> just thought dev meeting would be appropriate to get feedbacks
14:39:08 <khall> Joubu: why not just decide now? It's like we're arguing over what color to paint the house ; )
14:39:44 <cait> not sure we will have a clear vote
14:39:44 <Joubu> as we will get this color for ages, I'd prefer not to  have my house pink
14:39:52 <cait> i woudl abstain i think - not sure either way
14:39:58 <marcelr> it depends on the focus of the code
14:40:06 <cait> but... pink is pretty!
14:40:12 <khall> I would probably abstain as well
14:40:18 <oleonard_> Yeah, not enough opinionated voters here today I think
14:40:22 <marcelr> is the focus export first or patron first ?
14:40:23 <khall> cait: you'd like florida then ; )
14:40:30 <cait> :)
14:40:42 <drojf> not that it matters in any way, but catmandu has Catmandu::Exporter::CSV
14:40:46 <cait> i'd say,... ask on the mailing list and count that out after a week or so
14:40:48 * drojf contributes random information
14:40:58 * nengard is confused about what we're voting on
14:41:02 <cait> ah they have exporter
14:41:20 <Joubu> drojf: thanks, I will have a look at their code then
14:41:24 <khall> I think drojf brings up a good thought though, I think Koha::Patron::Export::CSV is more "CPAN-like"
14:42:06 <khall> but again, I don't think the choice is that important, the consistency is
14:42:31 <cait> #action Joubu to ask on the mailing list about which namespace scheme should be used for the 'export things'
14:42:39 <Joubu> I have plenty of other questions for devs, so I will shoot all of them in an email to koha-devel
14:42:41 <drojf> so we don't have a lot of opinions, but rather none in particular?
14:43:04 <khall> now if we built a system where we could import and export arbitrary objects ( patrons, libraries, etc ) then Koha::Export::Patron::CSV would make a lot more sense
14:43:22 <Joubu> that was the idea
14:43:31 <khall> drojf: I think that's the case. I think Joubu is championing Koha::Export::Patron::CSV
14:43:49 <khall> Joubu: ok, I'll through my hat in your ring ; )
14:43:50 <oleonard_> It's hard to plan for what we think we /might/ do in the future.
14:44:00 <khall> indeed
14:44:28 <khall> so I'm now in favor of Joubu's choice if that matters ; )
14:44:37 <drojf> +1 for consistency is my only opinion
14:44:43 <Joubu> we have at least patron and record (biblio+auth) and we could add reports, etc.
14:44:47 <drojf> so if we have 2 people agreeing on something, i am all for that
14:44:55 <cait> ok
14:44:58 <cait> so we do vote
14:45:04 <cait> #action ... delete last action
14:45:05 <marcelr> i vote for mailing list
14:45:11 <vfernandes> hi #koha
14:45:17 <cait> marcelr: 2 seconds earlier...
14:45:35 <drojf> marcelr: do you expect new input on the topic? or just postpone it to "not now"?
14:45:38 <Joubu> I will abstain :D
14:45:48 <marcelr> more info
14:46:02 <cait> so mailing list? or vote this, that, ml? heh
14:46:10 <cait> i think it's not super urgent - but shoudl be resolved
14:46:14 <cait> so i think mailing list would be ok
14:46:25 <khall> agreed
14:46:26 <cait> if there is no conclusion, we will have a vote next meeting
14:46:36 <drojf> ok
14:46:36 <cait> #action ... and action item is in effect again
14:46:38 <vfernandes> there is any easy way or any report to verify which records have repeated authorities?
14:46:40 <cait> moving on
14:46:48 <oleonard_> vfernandes: we are in a meeting right now
14:46:49 <drojf> vfernandes: we are in a meeting
14:46:58 <cait> #info Topic:  Allow Koha::Objects to be used as hashrefs ( Bug 15759 )
14:46:59 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15759 enhancement, P5 - low, ---, kyle, RESOLVED WONTFIX, Allow Koha::Object derived objects to be used as hashrefs
14:46:59 <Joubu> well, we have 2 big patches waiting for QA, so it's not so urgent but...
14:47:09 <cait> ah
14:47:18 <Joubu> I think authors (me included) would prefer not to rebase them for 1 year :)
14:47:27 <Joubu> but I will ask on the ML
14:47:30 <cait> thx
14:47:30 <drojf> Joubu: you wanted to abstain :P
14:47:30 <vfernandes> sorry!
14:47:38 <cait> i hope the opinions will be one onse side or the other
14:47:43 <cait> so a vote won't be necessary then
14:48:10 <cait> so for the next topic there has been some discussion and also on the mailing list
14:49:25 <cait> do we need more discussion or are we ready for a vote?
14:49:46 <Joubu> khall closed the bug
14:49:53 * oleonard_ gets a stiff neck from watching all the discussions go over his head
14:50:12 <khall> I'd still be open to discussion if anyone is interested
14:50:24 <Joubu> so I don't really know if it's stilll valid
14:50:35 <khall> I'm be willing to reopen it
14:50:39 <Joubu> :)
14:51:51 <khall> does everyone here know about bug 15759?
14:52:39 <cait> i think i lean more onto not doing it
14:52:43 * Joubu whispers yes
14:53:04 <khall> I think it would give us a *huge* leap on improving our code
14:53:08 <cait> for the reasons alex and other stated
14:53:19 <khall> the argument against it is "we should be rewriting all that code instead"
14:53:27 <khall> but, I must ask, who is going to volunteer to do that?
14:55:35 <Joubu> I do!
14:55:46 <Joubu> I have plenty of patches waiting for signoff and QA
14:55:55 <Joubu> moving code from C4 to Koha
14:56:07 <cait> true :)
14:56:19 <Joubu> and it will help to manipulate objects and only objects
14:56:27 <Joubu> instead of mixing objects and hashrefs
14:56:35 <khall> ok, put that in the actions ; )
14:57:11 <Joubu> If these patches could be pushed in an easier/quicker way, I could continue the same job for other modules
14:57:29 <khall> I think the writing is on the wall for 15759. I thought it was clever and interesting at least.
14:58:01 <khall> Joubu: I think we need a special ops team. You to write, someone to sign off, and someone to qa
14:58:09 <khall> I'd volunteer for the qa part
14:58:38 <khall> if you can find someone for sign-offs, we could add focus and speed to your project
14:58:54 <cait> sounds good
14:59:01 <cait> I think some are in the signed off state already
14:59:10 <cait> I was focusing on the 'bugs' the last 2 days, trying to get back into things
14:59:36 <khall> Joubu wil get me the bug numbers and I'll take a look!
14:59:47 <khall> we're wandering off topic
14:59:51 <khall> shall we move on?
15:00:20 <cait> #action khall volunteers to focus on rewrite patches for QA
15:00:38 <cait> #action Jobuu to provide a list of bug numbers waiting for QA in that area atm
15:00:42 <cait> ok
15:00:57 <cait> #topic  Deprecate support for Debian Wheezy?
15:01:02 <cait> drojf: ?
15:01:09 <drojf> i think we agreed that if we want to abandon wheezy at some point, we would have to announce we deprecate support for it before.
15:01:19 <drojf> AFAIK, we add more things that won't work in wheezy. like plack out of the box (and all other apache 2.4 related things that may come) and elasticsearch (unless i'm mistaken here)
15:01:35 <drojf> so we do not fully support wheezy any longer. do we want to "support" it at all, or just label it deprecated? like, announce it now, drop support for 16.11
15:01:41 <drojf> related quetion: are there a lot of people still using wheezy, and for what reasons?
15:01:45 <drojf> *question
15:02:54 <khall> I think we should just go ahead and deprecate it, and drop support for 16.11
15:03:19 <cait> 16.11?
15:03:40 <khall> that is, drop official wheezy support in 16.11
15:03:55 <cait> aah
15:03:57 <khall> too many important things don't work in wheezy
15:03:59 <cait> sorry, got confused
15:04:06 <khall> np ; )
15:04:07 <drojf> 16.11 may be the "ES in koha" release (don't know the status), so i think it would make sense to have the cut then
15:04:09 <cait> do we have a kind of list?
15:04:24 <drojf> list of what?
15:04:27 <cait> so that we coudl say... due to this that and so... it will be deprecated
15:04:31 <khall> cait: well, plack and elastic
15:04:34 <cait> ok
15:04:37 <cait> good list :)
15:04:42 <drojf> and apache 2.4 in general
15:04:46 <cait> shall we vote on that?
15:04:55 <cait> what woudl be the consequences? a note in the release notes
15:04:59 <khall> drojf: indeed!
15:05:02 <cait> not fixing bugs related only to wheezy?
15:05:21 <drojf> not backporting whatever things. from the packaging side
15:05:27 <drojf> because those might get a lot
15:05:36 <cait> ok
15:06:16 <oleonard> Does it have the potential to exclude Koha users because they are unable to upgrade for some reason?
15:06:18 <drojf> it will probably work for a while, apart from some things. don#t know. i would not mind backporting security stuff for a little longer. but not all of catmandu and things like that
15:06:26 <cait> #info Deprecating Wheezy because of problems with ES, Plack, Apache 2.4 - will mean: note in release notes, not fixing bugs specific to wheezy, not backporting from packaging side
15:06:54 <drojf> oleonard: i don't know and i don't know how we could find out about it
15:07:17 <cait> probably they shoudl be using a supported current OS
15:07:17 <drojf> what is a valid reason not to uprade your server operating system?
15:07:18 <cait> ?
15:07:42 <cait> shoudl we vote?
15:07:45 <khall> drojf: I don't think there is one ; )
15:07:51 <khall> cait: yes, I think we should vote
15:08:04 <cait> #startvote Should we officially deprecate Debian Wheezy? (yes,no,abstain)
15:08:04 <huginn> Begin voting on: Should we officially deprecate Debian Wheezy? Valid vote options are , yes, no, abstain, .
15:08:04 <huginn> Vote using '#vote OPTION'. Only your last vote counts.
15:08:10 <eythian> if you vote no, you are offering to support it :)
15:08:18 <khall> #vote yes
15:08:20 <drojf> #vote yes
15:08:22 <cait> #vote yes
15:08:24 <drojf> lol eythian
15:08:25 <Joubu> #vote yes
15:08:56 <cait> done?
15:09:10 <cait> #endvote
15:09:10 <huginn> Voted on "Should we officially deprecate Debian Wheezy?" Results are
15:09:10 <huginn> yes (4): Joubu, cait, drojf, khall
15:09:21 <cait> #agreed Wheezy is officially deprecated
15:09:30 <cait> #action bag to add a note to the next release notes
15:09:39 <bag> woot
15:09:41 <cait> ok?
15:09:45 <drojf> so long, wheezy
15:09:51 <cait> moving on
15:09:56 <cait> and hi bag ;)
15:10:01 <cait> #topic General development discussion (trends, ideas, ...)
15:10:03 <bag> hola
15:10:10 <cait> ther is nothing listed under this topic
15:10:16 <cait> does someone have something he/she wants to add?
15:10:42 <Joubu> 4 votes for deprecating wheezy...
15:10:49 <khall> I'm interested in thoughts on Angular vs React
15:11:04 <khall> I think the nature of Koha would make React better suited
15:11:17 <cait> React seems to be somewhat... hotter? right now - but I don't have any technical knowledge/views :(
15:11:21 <drojf> Joubu: none against it :P
15:11:23 <Joubu> (The rewrite work is on https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=15449, but I have already paste this number thousands of times)
15:11:30 <cait> but maybe... pick only one please
15:11:41 <khall> cait: exactly
15:11:51 <cait> Joubu: if someone wants to fight the decision... they always can next meeting :)
15:11:56 <khall> I think React is a better fit because:
15:12:20 <cait> #info Topic: thoughts on Angular vs React
15:12:22 <khall> a) we already have a code base, Angular is more happy being the app, it doesn't share well ; )
15:12:40 <khall> b) React is all about create "widgets" which we could re-use from page to page
15:13:04 <khall> so it would greatly simplify our code if we used react
15:13:26 <khall> Consider the patron info sidebar, that could be converted to a React widget that could be used across multiple pages
15:13:35 <khall> or the checkouts table, or the holds table
15:13:49 <khall> we just tell the widget "show the data for this patron" and it does it's thing
15:14:08 <khall> I'm sure it's possible with Angular as well, but Angular is much "heavier"
15:14:29 <khall> I think we need to pick just one
15:14:42 <drojf> i'm happy to learn a little of one of them. after you decide what you want to use ;) not qualified to pick one
15:15:01 <Joubu> kivilahtio presented the diff between these 2 frameworks and his conclusion was the same as yours: React is better
15:15:08 <khall> React is also easier to learn
15:15:08 <wahanui> okay, khall.
15:15:12 <Joubu> I dont remember the details, but he had a big list of pros/cons
15:15:17 <drojf> i like easier to learn
15:15:36 <khall> excellent! Just looking for input, I don't want to code myself into a corner ; )
15:16:12 <oleonard> khall: Are you interested enough in it to put together a proof of concept?
15:16:30 <Joubu> what I was going to ask for
15:16:31 <cait> would it make sense to ask kivilahtio for his list?
15:16:32 <khall> oleonard: yes, that's the plan! I'm going to start with something small
15:16:40 <cait> can i action that?
15:16:43 <cait> :)
15:16:49 <khall> I wrote the item messages feature using Angular, I'll rewrite it using React
15:16:58 <khall> cait: sure!
15:17:00 <oleonard> Yes, coordinating with kivilahtio sounds sensible
15:17:01 <Joubu> khall: does it make sense to use React to call the rest api?
15:17:09 <cait> #action khall to provide a proof of concept for using React in Koha
15:17:26 <khall> Joubu: yes, I think that should absolutely be done
15:17:35 <cait> #info more information in chat log about this - not easy to info all :)
15:17:35 <khall> *but* first we need to get the API enabled by default
15:17:38 <Joubu> in that case, I am waiting for an example on bug 14974 for month
15:17:39 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14974 enhancement, P5 - low, ---, gmcharlt, Patch doesn't apply , Use the REST API for cities
15:17:42 <Joubu> :)
15:17:45 <khall> also a good reason to move on from wheezy to jessie
15:18:15 <cait> i'd be happy if we could do a little api tutorial sometime
15:18:31 <cait> one of the things I didn't achieve at the hackfest... missed out on that
15:18:36 <khall> cait: I think that's an excellent idea!
15:18:39 <cait> how to activate, how to test, how to validate... whatever comes to mind
15:18:47 <khall> I volunteer Julian ; )
15:19:20 <khall> let's vote on that since he's not here : ) =
15:19:42 <oleonard> I hate to see any major changes to our JavaScript infrastructure before we get a front-end build tool in place.
15:19:57 <khall> oleonard: how's that going?
15:20:13 <khall> what do we want to use? Gulp and Bower?
15:21:34 <oleonard> We never reached a consensus, although pianohacker volunteered to build custom packages for something like Gulp if that would move it forward.
15:22:14 <oleonard> I'm not really familiar with Bower
15:22:43 <khall> I think Gulp is the way to go. Bower is great for js deps. We could manage all our libraries using Bower. jQuery and such
15:22:43 <cait> #info cait would be interested in an online api tutorial - how to set it up, test, validate etc.
15:23:10 <khall> oleonard: it's like apt-get but for javascript libraries
15:23:52 <cait> shudl we put this as a topic on the next agenda?
15:23:58 <cait> or maybe ask for ideas on the mailing list?
15:24:06 <khall> both I think
15:24:33 <khall> oleonard: would you be willing to start a mailing list thread?
15:24:47 <cait> #action khall to add react/angular and frontend build to to next agenda ;)
15:25:07 <cait> oleonard? :)
15:25:24 <oleonard> Yes
15:25:30 <khall> thanks!
15:26:32 <oleonard> gro
15:26:44 <oleonard> whoops, focus!
15:28:54 <cait> #action oleonard to start a mailing list thread about the frontend build tool
15:28:58 <cait> ok sorry
15:29:01 <cait> moving on
15:29:06 <Joubu> I have a question, if we have finished with the this topic
15:29:12 <cait> ah ok
15:29:16 <cait> go for it :)
15:29:23 <Joubu> How can we motivate other devs to attempt dev meetings?
15:29:25 <Joubu> :D
15:29:45 <drojf> by deprecating stuff when they are not looking
15:29:46 <Joubu> just kidding, you can move on something else
15:29:57 <cait> hehe yes
15:29:59 <cait> ok
15:29:59 <morgane> bye !
15:30:25 <cait> #topic Updates from the QA team
15:30:27 <khall> ha!
15:31:02 <cait> first... sorry for the absence - I hope to improve on that
15:31:09 <cait> and a thank you to Joubu for his summaries
15:31:20 <cait> i think they contain a lot of good info
15:31:31 <cait> Joubu: do you have something for QA?
15:31:54 <cait> ah... I had wanted to compile a list about mysql 5.x bugs - but I didn't get to it
15:32:03 <Joubu> The last 2 months I have sent a "what's on in koha-devel" email
15:32:03 <cait> I'd like to get some focus on them if possible
15:32:12 <cait> we have a lto of people ignoring the warning in the release notes or not reading it
15:32:31 <Joubu> to summarise what's happen on bugzilla and koha-devel ML
15:33:00 <Joubu> like that devs won't have excuse not to follow/know what is going on
15:33:33 <Joubu> I have started the move of C4::Members to Koha::Patrons
15:33:33 <cait> Joubu++
15:33:55 <Joubu> see bug 16846 and related
15:33:56 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16846 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , Move patron related code to Koha::Patron
15:34:03 <cait> #info read Joubu's summary emails "what's on in koha-devel"! :)
15:34:16 <cait> #info Joubu started move of C4::Members to Koha::Patrons
15:34:26 <Joubu> and the others on the graph I paste earlier
15:35:01 <cait> are we ready to se tthe date for the next meeting?
15:36:02 <cait> #topic Set time of next meeting
15:36:07 <reiveune> bye
15:36:18 <cait> the next general meeting is august 3
15:36:21 <cait> maybe a week after?
15:36:30 <cait> august 10?
15:36:45 <Joubu> k
15:36:51 <cait> which time?
15:36:52 <wahanui> it has been said that which time is better for my area? 10:00+0000 or 22:00+0000?
15:36:57 <cait> 21 utc ?
15:36:57 <wahanui> somebody said 21 utc was fine and might be better for local time adjustments.
15:37:08 <cait> rather late in europe... better in other places
15:37:09 <Joubu> wow, not ok :)
15:37:31 <cait> 19 utc?
15:37:31 <wahanui> somebody said 19 utc was fine by me.
15:37:51 <Joubu> I don't know, I let you decide
15:38:17 <Joubu> still late for me, but if it can help to get other devs, it's ok for me (who?)
15:38:22 <cait> let's try
15:38:45 <cait> trying to see what that is in nz but failing
15:39:00 <cait> hm 7 am
15:39:17 <cait> #agreed next meeting will take place on august 10 at 19 UTC
15:39:26 <cait> if it doesn't work out, we will set another date close
15:39:29 <cait> #endmeeting