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