14:01:37 #startmeeting Development IRC meeting 11 April 2018 14:01:37 Meeting started Wed Apr 11 14:01:37 2018 UTC. The chair is Joubu. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:37 The meeting name has been set to 'development_irc_meeting_11_april_2018' 14:01:45 #topic Introductions 14:01:46 #info wahanui, a bot that has become sentient 14:02:01 #info Owen Leonard, Athens County Public Libraries, USA 14:02:02 #info Jonathan Druart 14:02:05 #info Marcel de Rooy, Rijksmuseum, NL 14:02:10 #info Thomas Dukleth, Agogme, New York City 14:02:16 #info Andreas Hedström Mace, Stockholm University Library 14:02:20 #info Julian Maurice, BibLibre 14:02:24 #info Josef Moravec, Municipal Library Ústí nad Orlicí, Czech Republic 14:02:26 #info Colin Campbell, PTFS-Europe 14:02:30 #chair kidclamp 14:02:30 Current chairs: Joubu kidclamp 14:02:48 #info Nick Clemens, ByWater Solutions 14:03:40 in another meeting, may be slow 14:03:53 nobody else? 14:03:59 #topic Announcements 14:04:04 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_11_April_2018 14:04:09 ^ this is the agenda 14:04:33 #info wiki page for the 18.11 roles is created - https://wiki.koha-community.org/wiki/Roles_for_18.11 14:04:52 anyone has something to announce? 14:05:14 #info Katrin Fischer, BSZ, Germany 14:05:23 #info Claire Gravely, Germany 14:05:27 sorry to be a little late 14:05:39 no worries, do you have something to announce? 14:06:11 only the roles page 14:06:14 #topic Update from the Release Manager (18.05) 14:06:14 you already did I think 14:06:21 reading back quickly now 14:06:41 I have announced several things at the last general meeting. Everybody reads the minutes so I do not need to repeat everything 14:07:02 nothing new since last week 14:07:13 #topic Updates from the Release Maintainers 14:07:20 rmaints? 14:07:20 i guess rmaints is kidclamp (17.11), fridolin (17.05), rangi (16.11) 14:07:31 yep 14:07:55 I continue Rmaint 17.05 after 18.05 release 14:08:04 i will go to 17.05.18 max 14:08:14 just trying to catch up and push things 14:08:47 #topic Updates from the QA team 14:09:04 hard feature freeze is planned for 20th 14:09:06 so we are busy 14:09:34 we'll try to take car eof as many things as possible, but at the moment the queue is still around 70 14:09:45 please rebase/follow-up really quickly if needed 14:10:07 yes, please 14:10:30 I am also dealing with 40 patches to push but waiting for answers on some of the reports 14:10:30 okay, Joubu. 14:10:32 if something doesn't apply I will fail it - because there is not much time to work on follow-ups myself 14:10:37 don't take it personal :) 14:10:50 yes, check your outstanding bugs for comments 14:11:17 it's disappointing to spend time on reviewing and not hear back, especially with the deadline so close 14:11:33 but lots of progress too right now, it's just a lot of things 14:11:59 anyone else from QA? 14:12:16 you said it all 14:12:22 #topic General development discussion (trends, ideas, ...) 14:12:45 #topic REST api 14:13:47 Does anyone disagree with one of the 4 RDF? 14:13:50 RFC 14:14:07 there are: 14:14:07 https://wiki.koha-community.org/wiki/Acquisitions_orders_endpoint_RFC 14:14:08 There is an open issue in the wiki descriptionl. 14:14:12 https://wiki.koha-community.org/wiki/Acquisitions_funds_endpoint_RFC 14:14:14 I've left commetns on each 14:14:15 https://wiki.koha-community.org/wiki/Acquisitions_vendors_endpoint_RFC 14:14:19 https://wiki.koha-community.org/wiki/Biblios_endpoint_RFC 14:14:27 some small things about names etc, butnothing big 14:14:34 so 3 about ACQ and 1 for the bibliographic record endpoint 14:14:36 like use tax instead of gst (like the gui does already) 14:14:50 users vs patrons for acquisition funds which obviously do not apply to patrons. 14:15:09 but you still use a patron_id i think? 14:15:13 if we stick with terminology 14:15:31 i am not sure we shoud mix, if it's all the same 14:16:09 in koha you always link to a patrons record, staff is not separate, either use one term or the other 14:16:28 we should keep it consistant I think 14:16:48 I understand the underlying problem is the original specification for Koha. 14:16:59 #info Kyle M Hall, ByWater Solutions 14:17:00 Every user is a patron. 14:17:06 +1 for consistency 14:17:06 i think +1 for consistency is drojf's only opinion 14:17:30 I merely identify that there are open questions in what is proposed for voting. 14:17:57 from the page "Note: it would be correct to pick users over patrons in this case. This should be voted, though." 14:18:12 so I guess Tomas expected the discussion here and get a decision 14:18:56 I presume that we take the examples as they are and issues such as users vs patrons are for some future prospect of reconsideration. 14:19:06 #info Brendan Gallagher, ByWater 14:19:48 any other concerns about these RFC? 14:19:52 something that could be blocker? 14:19:57 Having noted the outstanding issues, I am ready to vote on the proposed form as they stand in the wiki today. 14:20:09 +1 on thd comment 14:20:47 #info Jon Knight, Loughborough University 14:20:49 start vote? 14:20:56 #chair cait 14:20:56 Current chairs: Joubu cait kidclamp 14:21:27 We can revisit the outstanding issues in future as the opportunity arises. 14:21:39 all in one or separate? 14:21:57 all in one (imo) 14:22:00 All in one without objection. 14:22:01 ok 14:22:21 the hardest part is always phrasing the question 14:22:56 #startvote To vote: RFC endpoints for orders, funds and vendors in acq, biblios. Do you agree with the RFCs and comments as they are? (yes,no,abstain) 14:22:56 Begin voting on: To vote: RFC endpoints for orders, funds and vendors in acq, biblios. Do you agree with the RFCs and comments as they are? Valid vote options are , yes, no, abstain, . 14:22:56 Vote using '#vote OPTION'. Only your last vote counts. 14:23:11 #vote yes 14:23:18 #vote abstain 14:23:27 #vote yes 14:23:30 #vote yes 14:23:38 #vote abstain 14:23:45 #vote yes 14:23:46 #vote abstain 14:23:58 #vote abstain 14:24:17 giving it a few more seconds 14:24:29 #endvote 14:24:29 Voted on "To vote: RFC endpoints for orders, funds and vendors in acq, biblios. Do you agree with the RFCs and comments as they are?" Results are 14:24:29 yes (4): greenjimll, cait, bag, thd 14:24:29 abstain (4): Joubu, oleonard, cc_, jajm 14:24:29 #vote yes 14:24:32 #vote yes 14:24:35 #vote yes 14:24:36 toooo late guys 14:24:43 haha 14:24:44 #vote yes 14:24:45 people, pay attention 14:24:59 :)\ 14:25:22 #agreed RFCs for funds, vendors, orders and biblios have been agreed upon, no blocker concerns, write the code and then we adjust. 14:25:29 my concerns, not about the RFC: REST API endpoints must be written with already moved code 14:25:43 and ACQ code is not moved at all (even not started) 14:25:44 #info 4 yes, 4 lates yes and 4 abstains 14:25:53 Joubu++ 14:25:59 Joubu: i see the conflict, but we need the apis for acq 14:26:15 to me it will be very difficult to write orders (order lines) end points with the code we have in C4::Acq 14:26:23 maybe it could be a separate discussion 14:26:26 which is very shitty 14:26:31 (I know I wrote big part of it) 14:26:31 how to tackel them exactly 14:27:03 shoudl we also vote patrons vs users? 14:27:14 yes lots of underlying issues in acq design 14:27:23 would be good to vote on that cait 14:27:41 can you help me phrase the question? 14:27:53 cait: what is the link for that one ? 14:27:56 i think at the moment it's if we shoudl use it on funds 14:28:02 comment here: https://wiki.koha-community.org/wiki/Acquisitions_funds_endpoint_RFC 14:28:12 Note: it would be correct to pick users over patrons in this case. This should be voted, though. 14:28:20 funds can be linked to 1-many users that can 'use ' them 14:28:38 yeah fund user sounds better than fund patron 14:28:50 you still will link it to a patron record 14:28:57 i thnk mixing might get difficult, but ready to abstain 14:29:39 so cait you think having users in acqs and then having patrons on other areas of Koha - is too confusing? 14:29:42 #startvote Should we use users instead of patron in the case of the funds RFC (users /patrons able to use a specific fund for odering)? (yes,no,abstain) 14:29:42 Begin voting on: Should we use users instead of patron in the case of the funds RFC (users /patrons able to use a specific fund for odering)? Valid vote options are , yes, no, abstain, . 14:29:42 Vote using '#vote OPTION'. Only your last vote counts. 14:29:53 #vote yes 14:29:56 #vote yes 14:29:58 there is also the owner, so "users" and "owner" make perfect sense 14:29:59 bag: it will still be patron_id I think 14:30:01 #vote yes 14:30:01 #vote yes 14:30:12 right 14:30:17 #vote yes 14:30:25 #vote yes 14:30:26 #vote abstain 14:30:29 #vote yes 14:30:32 #vote yes (turned by the argument of owners) 14:30:32 cait: yes (turned by the argument of owners) is not a valid option. Valid options are , yes, no, abstain, . 14:30:33 #vote abstain 14:30:36 #vote yes 14:30:38 #vote yes 14:30:46 #vote yes 14:30:48 * ashimema catches up 14:30:52 few more seconds 14:30:55 people concentrate! 14:30:57 #vote yes 14:31:00 :) 14:31:05 #endvote 14:31:05 Voted on "Should we use users instead of patron in the case of the funds RFC (users /patrons able to use a specific fund for odering)?" Results are 14:31:05 yes (11): Joubu, greenjimll, cc_, cait, kidclamp, oleonard, ashimema, jajm, marcelr, bag, thd 14:31:05 abstain (2): andreashm, josef_moravec 14:31:24 #agreed We will users in the case of the funds RFC (11 yes, 2 abstain) 14:31:31 done 14:31:37 can someoen help with oauth? 14:31:40 moving ong? 14:31:48 #topic REST API Authentication 14:31:56 jajm: ? 14:32:02 * ashimema thinks we should say 'users everywhere in the api' as apposed to 'in this case' 14:32:37 ashimema: that woudl mean changing already voted on rfcs which I'd wanted to avoid in this case 14:32:38 i think we need to discuss what to do with oauth2, scopes, and patron's permissions 14:32:45 ashimema: something we can discuss later again 14:32:53 is the api versioned yet 14:33:06 jajm: how does the proposal work? i create an api-key for an existing patron, the permission the patron has will be used? 14:33:12 * ashimema will refrain from asking questions now and have a catch up session with cait/tomas or someone later 14:33:14 because that would sound ok for e right nwo 14:33:48 As RM I'd like to know if we can expect to see this REST API auth work into 18.05 or if it is too late 14:33:54 With OAuth2, are we talking client-confidential flows? Using JWT tokens? 14:33:56 the code in bug 20402 only allow to define "API clients" in koha-conf.xml, not linked to any koha patron 14:33:56 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20402 enhancement, P5 - low, ---, julian.maurice, Failed QA , Implement OAuth2 authentication for REST API 14:34:14 greenjimll, client crendentials yes, no jwt tokens 14:34:26 jajm: but how do you figure what they are allowed todo? 14:34:39 * ashimema will read that code before commenting 14:35:21 maybe that's the best approach to comment on the bug itself? 14:35:22 cait, as an example the code allow to define scopes for each API client (ex. "patrons.read"), the scopes needed to access a specific resource is defined in the swagger schema 14:35:23 jajm: The reason for not having JWT tokens? They're in common use (eg Google REST APIs) 14:36:03 greenjimll, i just wanted a minimal working implementation 14:36:15 i think one of the basic questions is if we can finish something or 18.05 14:36:23 my impression was that we haven't defined scopes yet, is that right? 14:36:34 cait, you're right 14:36:38 Isn't 18.05 freeze in 9 days? That's tight! 14:36:43 yep 14:36:46 too late.. 14:36:52 so is there something reasonable that we can do for 18.05 14:37:11 i think people voiced a need for this in order to continue with implementing links with Coral 14:37:27 which would be a good argument for me to provide something earlier than later, but not sure how doable it is 14:37:39 links with anything outside of Koha itself, in fact 14:37:52 Something that works better than cookies is needed. But other than that, I have no opinion on how it is built 14:38:09 i think the only thing we can do before feature freeze is to remove the "scopes" stuff, and tie an API client with an existing Koha patron, so that we can use the permissions the patron 14:38:27 starting simple seems viable to me. doing something for 18.05 seems tight though. 14:38:38 If it is doable for 18.05 I am for it 14:38:43 +1 14:38:47 +1 14:38:52 Do we allow backporting after release? 14:38:57 +1 i think we need to offer something now 14:39:22 who's working on bug 20402? 14:39:22 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20402 enhancement, P5 - low, ---, julian.maurice, Failed QA , Implement OAuth2 authentication for REST API 14:39:41 jajm: do you have time to work on it? 14:39:49 i think maybe also tomas, for qa we#d have to check then 14:40:01 Joubu, I will, if everyone agree 14:40:25 josef_moravec: maybe you for qa? feasable? 14:42:28 * oleonard watches everyone disappear 14:44:09 hiya oleonard 14:45:10 * oleonard wonders if half of the meeting is now taking place in an alternate dimension 14:46:03 Was there another earthquake wherever OFTC houses its servers? 14:47:19 i think the question was about how not to force everyone to discover the smae things :) 14:47:19 like put a warning somewher that a specific database update needs a lot of time 14:47:19 so you can plan ahead and are not surprised by it 14:47:20 it's 2 meetings in a row with IRC explosion... 14:47:24 release notes? 14:47:24 release notes are in misc/release_notes 14:47:46 they are already created when those things appear in part 14:47:51 i think tht was tuxayo's point at least 14:47:54 We meeting HARD, get used to it oftc 14:47:57 Is this warnings that we know about before release, or that become apparent afterwards? 14:48:13 i think appratent afterwards was the issue 14:48:21 but we shoul try to put all the important things int he release notes 14:48:36 (resending some messages for the minutes) 14:48:46 #action ashimema will read code of bug 20402 and give feedback on the bug report 14:48:46 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20402 enhancement, P5 - low, ---, julian.maurice, Failed QA , Implement OAuth2 authentication for REST API 14:48:53 #action jajm will work on linking to existing patrons, tcohen and josef_moravec will test/qa 14:49:16 #info jajm will take a look at the existing Mojolicious plugin (instead of using Net::OAuth2::.. directly) 14:49:45 we got another dev meeting before release 14:49:47 postpone this? 14:49:47 About the updates - just assume than updates can be problematic, and test them on a test/pre-prod server 14:50:03 +1 14:50:19 but yes, we could highlight them in the release notes as well 14:50:30 I think collect on a wiki page if it happens 14:50:41 wiki page per release 14:50:43 If a db update is likely to take hours then that's certainly something we can predict and put in the release notes I would say 14:50:44 that problems/notes make sense after release 14:50:50 yep 14:51:14 set time and date of next meeting? 14:51:24 it's very easy to know if it will be problmatic, just by reading the SQL queries in updatedb.pl 14:51:27 #info try to already note long running db updates in the release notes properly 14:51:30 * ashimema actually reads the wiki page of release note/upgrade path notes for Mojolicious versions.. something similar would certainly be helpful. 14:51:34 I was thinking more that if we knew something might take a long time up front, a warning could be included as part of the update process? 14:51:38 if there is items/biblioitems, etc. it will certainly take ages 14:51:41 Joubu: not everyone will understand them the way we do 14:51:53 think a sysadmin that ususally not works on Koha or with sQL 14:51:58 i know what tuxayo means 14:52:22 a warning inlines in the updates won't help I think.. 14:52:42 I am just worried about the decisions/discussions we have in the meetings ;) 14:52:50 - Hey, this thing we're about to do is going to take a while.. but we're not going to give you an option to postpone it 14:52:59 not helpfull really is it ;) 14:53:07 they are usually lost in blockholes 14:53:08 More helpful than silence. 14:53:12 blackholes 14:53:22 mm 14:53:24 let's move on? 14:53:34 1sec 14:53:50 we talked about moving the print line of the updateDB *before* the execution 14:54:01 that could give information on what is going on 14:54:09 that would be nice 14:54:18 (no idea if someone opened a bug report) 14:54:45 or just occassionally print a extra line 14:54:45 #topic Set time of next meeting 14:55:00 April 25th? 14:55:29 Next meeting: 25 April 2018, 20 UTC? 14:55:40 will be travelling 14:55:43 +1 14:55:43 me too 14:55:52 Next meeting: 25 April 2018, 21 UTC? 14:56:12 yes 14:56:14 #info Next meeting: 25 April 2018, 21 UTC 14:56:22 3 14:56:23 Yes 14:56:23 2 14:56:25 1 14:56:27 #endmeeting