22:04:44 #startmeeting Developer IRC meeting 24 June 2015 - part 2 22:04:44 Meeting started Wed Jun 24 22:04:44 2015 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:04:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:04:44 The meeting name has been set to 'developer_irc_meeting_24_june_2015___part_2' 22:04:48 #topic Introductions 22:04:49 #info wahanui, a bot that has become sentient 22:04:53 please introduce yourself with #info 22:05:12 #info Indranil Das Gupta 22:05:13 #info Mirko Tietgen, one eye still open 22:05:18 sorry, got a couple of issues to deal with my apologies 22:05:21 #info Robin Sheat, Catalyst IT, Wellington 22:05:30 dont add any more frameworks while im away 22:05:34 lol 22:05:40 #info Katrin Fischer, BSZ Germany 22:06:08 ok, moving on :) 22:06:09 #info Nick Clemens, VOKAL Consortium, Vermont 22:06:14 pauses 22:06:31 today's agenda is: 22:06:34 #link http://wiki.koha-community.org/wiki/Development_IRC_meeting_24_June_2015 22:06:40 let's move on 22:06:51 #topic RM 3.22 comments 22:06:55 tcohen isn't here :) 22:07:05 he complained that we keep him pretty busy pushing things 22:07:08 # info Mason James, NZ 22:07:13 that's what i remember ;) 22:07:57 he also pointed out the good work on the security releases 22:08:24 he is trying to get through the bigger ones, but they take a bit longer 22:08:35 #info the RM considers 'normal' for patches on the PQA list to stay there for more than 2 weeks, if you think something needs to be pushed faster, please contact the RM personally 22:09:00 nengard has been working on the help files updates and is mostly done - patches should go into master and 3.20 22:09:11 anything else? 22:10:05 i am going to move on 22:10:13 #topic RESTful API implementation 22:10:18 things got a bit wild there 22:10:41 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920 22:10:42 04Bug 13920: new feature, P5 - low, ---, julian.maurice, Needs Signoff , API authentication system - proposal 22:10:51 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 22:10:52 04Bug 13799: new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 22:11:13 kivilahtio_: wrote up some comments about the first meeting on the rfc page 22:11:19 #link http://wiki.koha-community.org/wiki/New_REST_API_RFC 22:11:35 does anyone talk about something specifically? 22:11:36 awesome info ^ 22:12:53 ok, one of the points discussed was the inclusion of the Swagger UI in the base patch 22:12:54 #info brendan gallagher bywater 22:13:07 "Swagger UI After a heated debate in the IRC meeting, we decided to let go of Swagger UI as a part of the Koha git history, and instead move it to a new bug which helps people deploy API inspectors, other than just Swagger UI." 22:13:38 yeah, i'd like to suggest a wiki page instead linked to bugs 22:14:06 bugzilla can get a bit complicated for documenting setup steps quite quickly 22:14:24 but generally moving it out of the patch seems like a good idea 22:14:24 yes, indeed 22:15:00 another thing discussed was the way of documenting 22:15:18 i thik the conclusion was that the documentation is in the code itself - in the swagger specs 22:15:29 Olli mentioned using 'redmine' for documenting, in last meeting 22:15:44 redmine is a full scale project management / bug tracking system 22:15:53 someone would have to set up and maintain it 22:16:02 aah, sounds heavy 22:16:05 Yeah, discouraging the use of 50 different things that all do a similar job would be good. 22:16:06 we are using it at work, but I am not sure it gives us something that bugzilla doesn't have 22:16:39 trello could be a good tool, for that? 22:16:50 mtj: it's proprietary, remember. 22:16:55 there are lots of good tools 22:17:00 s/trello/taiga|libreboard/ 22:17:08 aah, i didnt know eythian_ 22:17:23 but people need to use them :) 22:17:26 the thing to remember is that we have a really active .. one of the more active opensource projects in the world 22:17:35 with one of the lowest barriers to becoming a dev 22:17:39 cait: no they don't 22:17:44 what we have now works really well 22:17:53 wizzyrea was going to have a go at setting up taiga, but has probably been too busy. 22:17:54 improving it is always good 22:18:12 but i dont think we want to forget the workflow we have no actually works really well 22:18:17 now even 22:18:24 yep 22:18:35 and having something very similar than bugzilla parallel... sounds a bit nightmarish 22:18:46 i can see having something for the devs to use 22:18:50 sorry, i took the convo a bit offtrack there ^ 22:18:51 i think they agreed to have the rfc api wiki page updated for now 22:18:56 to coordinate big tasks 22:19:10 but i dont think you want to get people having to report things in 2 places etc 22:19:17 * rangi goes back to doing translation updates 22:19:48 #idea think about ways for devs to coordinate big tasks better 22:20:11 aonther longer discussion was had about the topic authentication 22:20:19 it seems we have 2 implementations right now 22:20:28 i gota bit lost there, so recommend reading the logs for more detailled information 22:20:37 one thing that was pointed out was that it should suppord our current cookie 22:20:40 is there a link to the previous meeting logs anywhere? 22:20:43 so we can use the api inside of koha i think 22:20:55 i will put one on the agenda after th emeeting 22:21:00 but of curse everything is in the logs 22:21:33 #info links to logs: http://irc.koha-community.org/koha/2015-06-24#i_1693798 22:21:50 ta 22:22:25 i hope the wiki page gets cleaned up a little - please put questions and notes there too! 22:22:52 i also requested that the api has to be easy to setup and test 22:22:56 does mojo have a perl 5.20 requirement? 22:23:11 to avoid the problems we have for example with getting sip patches integrated - the harder it is to use, the harder it is to get in 22:23:30 mtj: I don't know - eythian maybe? 22:24:10 not sure 22:24:31 ahh.. ' which are currently 5.20.x and 5.18.x. ' 22:24:32 mtj: coudl you put that on the wiki maybe? 22:24:46 mtj: what are you quoting there? 22:24:59 http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#Which-versions-of-Perl-are-supported-by-Mojolicious 22:25:08 we currently announce that we support poerl 5.10+, so mojo would be quite a shift. 22:25:25 ok, what can i put in the mintues? 22:25:53 #info Question: what are the perl requirements of mojolicious? 22:26:02 I think deciding if we're OK bumping the minimum supported version needs to be a discussion (another time.) 22:26:09 #link http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#Which-versions-of-Perl-are-supported-by-Mojolicious 22:26:32 i think maybe soon - because we'd need to switch soon if we don't agree 22:26:57 i still need to be convinced that we actually gain anything by introducing mojo 22:27:08 and dont give me its easier for developers .. i dont really care about that 22:27:15 i wasn't going to ;) 22:27:24 if it makes koha harder for users to install, for no gain to them 22:27:27 then meh 22:27:34 i think the impression of most is now we agreed on it - which could make it a bit difficult to change direction now 22:27:49 who's this we :-) 22:28:02 i am just trying to summarize 22:28:42 (also, the discussion about mojo causing breaking changes a lot concerns me, we must be able to support multiple versions.) 22:28:53 the flip is.. why not bump the minimum perl version? 22:28:56 i think those are all good points 22:29:03 as i said - it hink the easier we make it 22:29:09 to test and use 22:29:20 the better 22:29:20 it has been said that the better is "take cover." :) 22:29:45 i also think we need to make sure that we keep things tightly locked up 22:29:51 so authentication working well is a big point for me 22:30:58 I'm of the opinion that auth needs to be redesigned from the ground up, but that's a big Jobâ„¢ 22:31:03 hmm, i see squeeze has perl 5.10, and wheezy perl 5.14 - so thats a problem :/ 22:31:22 mtj, eythian: could you bring that up on wiki/mailing list/bugzilla? 22:31:43 yep, will do cait 22:31:59 good news... jessie has perl 5.20 22:32:08 fwiw, backporting the mojo module to wheezy didn't lead to tests failing, so that's hopeful. 22:32:44 so, koha with mojo/swagger would only run on debian.8? 22:32:51 14.04 is april 2019 22:32:56 #action mtj to bring perl version question to the mailing list 22:33:33 something else about the api we should think of? 22:33:46 but yeah, even without the perl issue, wtf does mojo even give us 22:34:00 thats what no one has explained to me yet 22:34:17 i feel like its moose all over again 22:34:25 i thnk the main excitement seems to be the swagger plugin for it 22:34:34 hum, i assumed swagger needed mojo.. but no? 22:34:39 i think so 22:34:59 but... the technical bits are hard for me here - so please check what i say :) 22:35:40 no, aiui they're two different things that can be connected. 22:36:04 ok 22:36:33 https://metacpan.org/pod/Swagger2 22:37:16 hmm, it does look like the mojo stuff is optional? 22:37:17 yes thats one implementation of swagger for perl 22:37:18 "This distribution comes with a Mojolicious plugin, Mojolicious::Plugin::Swagger2, which can set up routes and perform input and output validation." 22:37:19 do you want me to add somethong to the minutes? 22:37:26 thats not swagger tho 22:37:39 thats a mojolicious implementation of swagger 22:38:06 yep, understood 22:39:02 #info Question: what do we gain by using Mojolicious - are there other ways we could make use of Swagger? 22:39:21 anything else i can add? 22:39:52 #info Question: can swagger be used without mojo? 22:40:06 does it take infos rom non-chairs? 22:40:11 i am never sure if i need to repeat 22:40:34 i think yes cait 22:41:06 #info Question: can swagger be used without mojo? 22:41:11 just to make sure :) 22:41:14 ok, ready to move on? 22:42:34 #topic Koha Naming standards 22:42:48 where is a new wiki page where we gathered the terms used in the gui 22:42:58 http://wiki.koha-community.org/wiki/Terminology 22:43:17 the question came up naming the new routes but also how to nam modules in the new namespace 22:43:27 patron / borrower / member / user 22:43:32 there is a lot of variation 22:43:47 but all the UIs I see use "reserve" and "member" and so on :) 22:43:58 we are kind of standardized in the gui right now 22:44:07 eythian which do you mean? 22:44:16 all of them 22:44:18 ah en_nz? 22:44:19 all the GUIs 22:44:26 well yeah, the standard language 22:44:35 well yes... there is a translation issue there 22:44:43 but i'd vote for at least having consistency - also makes translating easier 22:44:53 and maybe not use all options in naming stuff :) 22:45:02 (that said, as much as patron is an old-timey, out-of-date sounding word, consistency is probably a better benefit no matter if it does sound weird.) 22:45:45 im still puzzled how we got to en_NZ not being the standard seeings it started here ... but since we are standardising (or standardizing) on americanese patron is the word we should use 22:46:01 i think that predated my involvement on koha :) 22:46:06 it was all very patron when is tarted 22:46:14 another thing you can blame on liblime actually 22:46:19 probably 22:46:20 somebody said probably was not, but i do not know another way 22:46:35 from a translation point of view - consistency is nice 22:46:40 we probably have more users not using en_US though, if you count India :) 22:46:42 because it helps to settle on the same term in the translations as well 22:47:23 I say we silently edit it to say that all words should use real English ;) 22:47:35 just do while i am on vacation please :) 22:47:50 so let's get some quick opinion thing 22:48:15 are we in favour of using the gui terminology (en_US) on the coding side of things as well (thinking namespaces and the like)? 22:48:45 en_SIMPLE, you mean? ;) 22:49:06 #chair eythian 22:49:06 Current chairs: cait eythian 22:49:15 there, you get to help now with this meeting 22:49:18 yeah makes sense to match the code 22:49:37 +1 from me (consistency helps generally) 22:49:39 http://i.imgur.com/kn488mY.jpg <-- that's the image I was thinking of 22:49:42 however please for the love of toasted cheesus .. don't go refactoring code 22:49:51 just to align the terminology 22:49:54 i think it was moslty a queston of the new namespace for now :) 22:50:04 new is ok 22:50:16 yeah, consistency is good 22:50:43 #agreed consistency is good - meeting participants in favour of aligning new code terminology with the gui terminology 22:50:50 hope ig ot that about right :) 22:50:51 ok, moving on? 22:51:04 +1 22:51:09 #topic Big stuff we are working on 22:51:18 i think eveyone wants to know... eythian - elastic search? 22:52:16 it's coming along. I discovered a whole new search API the other day (yay!), implemented support for it and am now refactoring the bits that refer to it. 22:52:39 oh what is it? 22:52:50 C4::Search::SimpleSearch, from memory. 22:53:22 I'm hoping that when this is done, that'll be all the searching in the whole system using ES. 22:53:31 which means it'll be ready for production ;) 22:53:34 (not really) 22:53:55 ah another one in Koha 22:54:01 yeah 22:54:12 but after that is all the bitsy things like making sure indexing works properly, and so forth. 22:54:16 amazing stuff eythian_ ^ 22:54:26 i.e. when you update a record, it's reindexed 22:54:37 that would be good yes :) 22:54:58 we have great difficulties with the facets... i am really hoping your code will make things better 22:55:06 and it should all work with zebra too, just by flicking the switch 22:55:17 cait: well, it uses ES to generate the facets, so that's hopefully better 22:55:25 mostly people are really confused we don't take into account the whole result set - displaying the important facets... and all as an option etc. 22:55:42 this one does take into account all the result set, I think. 22:55:53 there are a few bugs there, like the "more" link doesn't work. 22:55:53 like 'why do more itemtypes turn up when i limit the search, but haven't been shown initially' 22:56:15 yeah 22:56:23 I'd love to see those things gone from my complaints list :) 22:56:28 that probably shouldn't happen in this case, at least nearly so much. 22:56:42 eythian - will you send an email to the list again when we can start testing more? 22:56:51 I'm not sure how far ES looks into the data. 22:57:03 sure. 22:57:16 I'll finish off this API stuff and then update my test server. 22:57:25 #action eythian to send an email to the list to call for testing when ready 22:57:34 hm should have included elastic search there... 22:57:46 smething else big? 22:57:53 or something you want to announce/mention? 22:58:10 not me :) 22:58:30 #info ElasticSearch is coming along 22:58:39 #topic GBSD 22:59:01 we talked about having another gbsd - maybe coupled with a qa sprint 22:59:10 but they don't seem to have a lot of impact 22:59:18 not more people actually testing etc 22:59:29 the idea was to gather some ideas what we could do to revive them 23:00:59 no ideas? 23:01:30 if it's any consolation, the last debian-perl equivalent got forgotten about even by the organiser :) 23:01:35 #info Needed: ideas on how to make gbsds more fun and more attractive 23:01:45 not really heh 23:02:17 cait: gbsd with dubstep 23:03:18 nobody likes dubstep, mtj ;) 23:03:24 other than that, i dont have any great ideas on GBSD 23:03:45 #topic specific bugs that need feedback 23:03:51 i put bug 7710 there 23:03:52 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7710 new feature, P5 - low, ---, alex.arnaud, In Discussion , multiple holds per title 23:03:55 we had some discussion how it should behave 23:03:59 and where the configuration should happen 23:04:21 for example: should we allow record level holds in combination with item level holds 23:04:32 re: gbsd - perhaps we start working towards a definite testing setup, like kohadevbox? 23:04:41 i'd like to encourage people to add a note with thir ideas on the bug report 23:05:31 maybe we ould runa kohadevbox tutorial on a gbsd 23:05:36 to make it easier to get started? 23:05:52 yeah, thats what i mean cait :) 23:06:18 #info Looking for opinions on bug 7710 - confiuration and behavoiur of multiple holds per title 23:06:28 #idea run a kohadevbox tutorial on gbsd 23:06:38 that's a good idea, I think 23:06:43 i'd attend :) 23:06:56 a gbsd newbie guide, from installing kohadevbox to signing-off a patch 23:07:03 i am too tired to look up the actions form last meeting 23:07:09 i am fully trusting people to have done their part 23:07:29 #idea gbsd newbie guide - from installing kohadevbox to sign-off 23:07:57 ok, i'd like to moveon :) 23:08:02 #topic Set time of next meeting 23:08:21 #action tcohen to set date and time for next meeting - a shift to 14 UTC was suggested 23:08:27 last chance? 23:08:28 :) 23:08:31 +1 23:08:50 #endmeeting