19:03:43 <kidclamp> #startmeeting Development IRC meeting 9 November 2016
19:03:43 <huginn> Meeting started Wed Nov  9 19:03:43 2016 UTC.  The chair is kidclamp. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:43 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:43 <huginn> The meeting name has been set to 'development_irc_meeting_9_november_2016'
19:04:02 <kidclamp> #info Nick Clemens, ByWater Solutions
19:04:12 <rangi> #info Chris Cormack, Catalyst IT
19:04:14 <tcohen> #info Tomas Cohen Arazi, Theke Solutions
19:04:26 <tcohen> /#topic introductions
19:04:33 <MKuhn> #info Michael Kuhn, Admin Kuhn GmbH
19:04:46 <josef_moravec> #info Josef Moravec, Municipal Library Usti nad Orlici, Czech Republic
19:05:18 <kidclamp> #info Nick Clemens, ByWater Solutions
19:06:00 <kidclamp> okay
19:06:41 <kidclamp> Anyone have anything?
19:07:14 <rangi> just the manual stuff that people have already seen
19:07:43 <kidclamp> #info rangi is working on updating the manual
19:07:45 <tcohen> #link http://translate.koha-community.org/manual/sphinx-branch/en/html/index.html
19:07:51 <kidclamp> beat me to it
19:08:01 <rangi> i am thinking of maybe shifting it to gitlab, so people can do merge requests easier .. i want the barrier as low as possible, it doesnt need to have near as much stringent QA as the code
19:08:22 <kidclamp> +1
19:08:50 <jirislav> That's nice! Read the docs is the right choice
19:08:53 <rangi> and with the .rst we dont need specific editors, it is human readable .. so that is much easier
19:09:18 <jirislav> ... hi btw :)
19:09:35 <rangi> we can get francesca (one of the koha junior devs here) to do us a koha css theme
19:09:41 <rangi> thats all i have
19:09:55 <kidclamp> cool, next topic if no one else has announcements?
19:10:03 <tcohen> ah yes
19:10:07 <tcohen> I put it at the bottom
19:10:13 <tcohen> but it is really an announcement
19:10:22 <kidclamp> go for it
19:10:24 <tcohen> and I won't be aroudn at the end of the meeting
19:10:42 <tcohen> The community jenkins server started to malfunction a couple weeks ago
19:10:56 <tcohen> i spent a lot of time trying to recover it
19:11:05 <tcohen> only to notice a clean install would just work
19:11:25 <tcohen> as the Biblibre guy in charge of the server is AFK for a couple weeks
19:11:38 <tcohen> I set a temporary (?) server on my own
19:11:47 <tcohen> http://jenkins.theke.io
19:12:06 <tcohen> in which I set the 'master' branch tasks so we have information for the next release
19:12:06 <kidclamp> #info tcohen set a temporary jenkins server until community jenkins is back up
19:12:15 <kidclamp> #link http://jenkins.theke.io
19:12:36 <tcohen> we could just keep it, provided Laurent/Biblibre agrees and we just change the DNS
19:12:51 <tcohen> but I'm evaluating another posibilities
19:12:54 <tcohen> for CI
19:13:12 <tcohen> * Travis-CI * Buildbot * GoCD
19:13:20 <tcohen> they are all valid options
19:13:30 <tcohen> i'm trying to have time to make my mind about them
19:13:41 <kidclamp> do you want to talk with laurent and/or send an emial to devel tcohen?
19:13:43 <tcohen> the plan is to somehow containerize the tasks
19:14:00 <rangi> i think evaluating others is a good idea
19:14:06 <tcohen> so we don't depend on the underlying OS (from the nodes)
19:14:09 <rangi> jenkins works .. but it has always been fragile
19:14:29 <tcohen> and I also plan to re-use the kohadevbox ansible playbook
19:14:39 <tcohen> for generating such environments/containers
19:14:54 <tcohen> yeah, jenkins is fragile, too much
19:15:07 <tcohen> I just had to downgrade the clover plugin
19:15:12 <tcohen> they don't fix it...
19:15:14 <tcohen> anyway
19:15:48 <tcohen> #info If anyone has strong opinions on CI tools, please write to tcohen about it
19:16:13 <tcohen> #info substituting jenkins for something else is a really possible option
19:17:04 <kidclamp> #action tcohen will investigate options for jenkins and coordinate with laurent @ BibLibre
19:17:18 <kidclamp> okay, next topic
19:17:18 <wahanui> i heard next topic was a tricky one...
19:17:38 <kidclamp> #topic Review of coding guidelines
19:17:53 <kidclamp> #info Proposal - REST: Ban id fields in POST/PUT/PATCH bodies
19:18:05 <kidclamp> I am not sure who put this proposal, anyone?
19:18:14 <rangi> not me
19:18:27 <tcohen> Martin / Kyle / Jonathan /Me?
19:18:32 <tcohen> we had that discussion
19:18:48 <tcohen> the RESTful services design is not a closed discussion
19:19:01 <kidclamp> want to add your thoughts? we can postpone vote until more people are around too
19:19:07 <thd> #info Thomas Dukleth, Agogme, New York City
19:19:24 <tcohen> ok, my thought is that we shouldn't include the ID on the object we SEND
19:19:55 <tcohen> when you update/replace an object you usually hit an endpoint that looks like
19:20:05 <tcohen> /endpoint/{ id }
19:20:26 <tcohen> and send the new object (PUT) or attributes (PATCH) on the request body
19:20:42 <bag> #info bag Brendan Gallagher
19:20:43 <tcohen> it is straightforward to just forbid the id to be part of the body
19:20:49 <tcohen> on the other hand
19:20:53 <tcohen> if we allow it
19:20:59 <tcohen> we need to add checks to it
19:21:11 <tcohen> so people don't change the object id!
19:21:28 <tcohen> this is a usual scenario and use case
19:21:42 <jirislav> I thought the object id is immutable
19:21:46 <tcohen> we all agreed it was a good idea, adhering to that design style
19:21:55 <jirislav> #info Jiri Kozlovsky, Brno, Czech Republic
19:22:10 <tcohen> jirislav: it is, but when you code it, you need to take care of that immutability
19:22:23 <rangi> tcohen: it sounds like a good rule to me
19:22:29 <tcohen> the tradeoff
19:22:37 <tcohen> (otherwise there wouldn't be a dsicussion at all)
19:22:39 <kidclamp> and you sent it out on koha-devel - doesn't look like much discussion has come up
19:22:46 <tcohen> is that when you GET an object
19:22:55 <tcohen> it could include the id
19:23:04 <tcohen> yeah
19:23:29 <tcohen> we just wanted to have it formally approved on a meeting
19:23:36 <tcohen> it is the usual way
19:23:37 <rangi> right, you do need to get the id from somewhere
19:23:56 <tcohen> when you hit /endpoint
19:24:01 <tcohen> you get the objects list
19:24:04 <tcohen> they have the id
19:24:15 <kidclamp> I say we can vote and add it, and revisit if needed, but seems reasonable
19:24:30 <rangi> yeah, we can always change rules :)
19:25:01 <kidclamp> lemme see if I do this right ;-)
19:25:35 <kidclamp> #startvote Should we add a coding guideline to ban id fields in post/put/patch bodies for the rest api?
19:25:35 <huginn> Begin voting on: Should we add a coding guideline to ban id fields in post/put/patch bodies for the rest api? Valid vote options are Yes, No.
19:25:35 <huginn> Vote using '#vote OPTION'. Only your last vote counts.
19:25:46 <kidclamp> #vote yes
19:25:50 <thd> #vote yes
19:25:52 <tcohen> #vote yes
19:26:04 <jirislav> #vote yes
19:26:15 <rangi> #vote yes
19:26:18 <josef_moravec> #vote yes
19:26:25 <bag> #vote yes
19:26:39 <kidclamp> last call
19:26:46 <kidclamp> #endvote
19:26:46 <huginn> Voted on "Should we add a coding guideline to ban id fields in post/put/patch bodies for the rest api?" Results are
19:27:05 <bag> [off] wish our elections went like that
19:27:13 <kidclamp> heh
19:27:18 <bag> [off] :P
19:27:27 <tcohen> [off] :-P
19:27:31 <kidclamp> it didn't list results, but passed
19:27:55 <kidclamp> #info vote passed unanimously with 7 yes
19:27:56 <kidclamp> :-)
19:28:09 <kidclamp> #topic Progress on next release (16.11)
19:28:12 <kidclamp> bag?
19:28:12 <wahanui> bag is, like, in Seattle currently
19:28:33 <bag> kyle has shared the release notes
19:28:47 <tcohen> http://jenkins.theke.io/job/Koha_Master_D8/
19:28:53 <bag> looking for comments on it - but no rush - we still have a little bit of time
19:29:10 <bag> besides that we’re moving along
19:29:13 <kidclamp> tomorrow is second draft of release notes (according to deadlines)
19:29:27 <tcohen> Jonathan has been working hard to fix failing tests / bugs
19:29:39 <bag> yeah - that may not be nessicary since we haven’t had any feedback
19:29:50 <bag> but when I say that - I am not sure there is need for feedback yet
19:29:52 <kidclamp> Joubu++
19:29:59 <bag> yes Joubu++
19:30:08 <bag> those patches we’ll push
19:30:40 <bag> that’s about it from me kidclamp
19:30:43 <kidclamp> #info Joubu working on failing tests
19:30:49 <tcohen> we have a weird dependency situation
19:30:57 <tcohen> for smart people to take a look
19:31:04 <tcohen> Undefined subroutine &C4::Circulation::GetItem
19:31:07 <kidclamp> #info bag says things are going well - kyle shared draft 1 of release notes
19:31:14 <tcohen> we get those on several tests
19:31:40 <tcohen> bug 17591 was the wrong attempt to hide the issue (but solve the side effects)
19:31:41 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17591 major, P5 - low, ---, tomascohen, Failed QA , Use fully qualified C4::Items function names in C4::Circulation
19:31:51 <kidclamp> yeah, I have seen that happen once or twice on a customer server randomly
19:31:56 <rangi> hmmm
19:32:12 <rangi> i can try to get time to take a look, but can't promise it
19:32:24 <kidclamp> Joubu posted two poc I think too
19:32:28 <kidclamp> bug 17599
19:32:30 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17599 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , Move C4::Circulation::GetIssuingRule to Koha::IssuingRules->get_effective_issuing_rule
19:32:35 <kidclamp> bug 17600
19:32:36 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17600 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , Standardize the EXPORT
19:32:55 <tcohen> we didn't find the root cause
19:33:34 <kidclamp> #info odd dependency situation causing error: Undefined subroutine &C4::Circulation::GetItem
19:33:43 <kidclamp> #info tcohen, joubu and other investigating
19:34:22 <kidclamp> I think we can move into general dev discussion
19:34:35 <tcohen> item-level_itypes set but no itemtype set for item
19:34:45 <tcohen> lots of tests are raising that waring
19:34:51 <tcohen> because of a patch I wrote :-D
19:35:07 <kidclamp> so you will fix that :-D
19:35:14 <tcohen> shame on me, I wrote several patches for bugs that fix that
19:35:59 <kidclamp> #info Developer documentation (POD) needs to be a QA issue.
19:36:32 <tcohen> #vote yes
19:36:37 <kidclamp> anyone have anything to add on that?
19:36:39 <kidclamp> hah
19:36:42 <kidclamp> I agree
19:37:23 <kidclamp> shoudl it be coding guidelines?
19:37:36 <rangi> yeah, using devel::cover
19:37:44 <rangi> we can test POD coverage
19:38:00 <rangi> or
19:38:02 <tcohen> we could patch the qa script
19:38:04 <rangi> http://search.cpan.org/~neilb/Test-Pod-Coverage-1.10/lib/Test/Pod/Coverage.pm
19:38:04 <thd> Yes, if you want people to do it put it in the guidelines.
19:38:38 <kidclamp> yeah , I think add it to qa script and guidelines
19:38:38 <rangi> if coverage decreases, tests fail .. something like that
19:38:42 <rangi> yep
19:39:55 <kidclamp> #action POD coverage should be in qa script and a coding guideline added
19:40:04 <kidclamp> someone want to volunteer?
19:40:51 <tcohen> i think absent people gain the right to be volunteered
19:40:57 <rangi> heh
19:40:59 <kidclamp> heh
19:41:05 <tcohen> I'd volunteer Joubu, who mainly maintains the qa scripts
19:41:23 <kidclamp> #action Joubu (has been) volunteered to update qa script for pod
19:41:43 <kidclamp> next up is
19:41:49 <kidclamp> #info Highlight easy to test bugs for beginners (follow-up)
19:42:30 <kidclamp> I had brought this up initially, we discussed adding a way to mark bugs as sndbox testable
19:42:34 <kidclamp> etxc
19:42:37 <kidclamp> etc
19:42:51 <kidclamp> but I think we ended at using Academy to tag low hanging fruit
19:43:01 <tcohen> bugs that depend on bug 14598
19:43:02 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14598 major, P5 - low, ---, tomascohen, Pushed to Master , itemtype is not set on statistics by C4::Circulation::AddReturn
19:43:54 <rangi> kidclamp: tagging Academy now is really helpful for me too, any that dont get done before then, we can do at the academy in january
19:44:13 <rangi> there is the wiki page i made a while ago too
19:44:17 <rangi> that needs to be updated
19:44:26 <rangi> lemme find it
19:44:36 <rangi> https://wiki.koha-community.org/wiki/I_want_to_help
19:44:40 <kidclamp> #action please tag simple bugs with 'Academy' tag now and year round to help move them along and get people involved
19:44:49 <kidclamp> #link https://wiki.koha-community.org/wiki/I_want_to_help
19:45:08 <rangi> we've done the  OMGWTFBBQ! one already
19:45:08 <rangi> :)
19:45:13 <kidclamp> ranig++
19:45:16 <kidclamp> rangi++
19:45:52 <rangi> keeping that page up to date would be good i think, then we can point people at it
19:46:43 <kidclamp> #action kidclamp will update the wiki page with academy tag info and link
19:47:12 * kidclamp feels less bad about volunteering Joubu now
19:47:28 <kidclamp> next point
19:47:32 <caboose_> hi all
19:47:40 <kidclamp> #info Bootstrap 3 upgrade (Bug 16239) and relating UI changes
19:47:41 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16239 enhancement, P5 - low, ---, josef.moravec, Failed QA , Upgrade Bootstrap in the staff client
19:47:45 <caboose_> I am new so kind of just lurking at this point
19:47:50 <caboose_> with ByWater
19:48:00 <rangi> caboose_: we are in a meeting at the moment so a good time to lurk
19:48:07 <caboose_> cool!
19:48:16 <tcohen> have to leave
19:48:19 <tcohen> cya!
19:48:21 <kidclamp> bye tcohen
19:48:26 <tcohen> picking Manuel!
19:48:35 <josef_moravec> I started to work on upgrading bootstrap
19:48:36 <rangi> ahh yes, we do need to upgrade bootstrap .. i tried that with the academy 2 years ago, it was too hard/big for the 3 days we had
19:48:43 <caboose_> #info caboose ByWaterSolutions
19:48:45 <bag> welcome caboose_ - it’s the koha-dev meeting currently
19:48:55 <josef_moravec> rangi: as you say ;)
19:49:18 <caboose_> ah...sorry I got an email invite to attend...but I think I was invited accidentally!
19:49:19 <josef_moravec> i have patches and oleonard tested today
19:49:34 <kidclamp> all are welcome caboose, the more the merrier
19:50:03 <kidclamp> anything you need josef_moravec? more testing?
19:50:07 <rangi> caboose_: everyone is welcome :)
19:50:12 <caboose_> nice
19:50:20 <josef_moravec> yes more testing of course...
19:50:44 <josef_moravec> i would like to make it ready when next release cycle starts
19:51:05 <josef_moravec> because i think it's almost imposible to push it without mistakes...
19:51:24 <kidclamp> #info please test bug 16239 to get it ready for early next release cycle to encourage more testing/debugging
19:51:44 <josef_moravec> so would like to have enough time to polish it for 17.05
19:51:51 <kidclamp> agreed - big bugs often go that way
19:52:02 <rangi> josef_moravec: i agree, i think push early and tidy it .. too big to get it right first time
19:52:13 <kidclamp> any highlights of big things it gains us?
19:52:39 <josef_moravec> after this is pushed i would like to investigate to use bootstrap more...
19:52:59 <josef_moravec> and get rid of yui library hopefully...
19:53:06 <kidclamp> I think kyle played with it in his react patches too - bootstrap tables over datatables
19:53:22 <rangi> i thought we had got rid of all yui stuff already?
19:53:38 <josef_moravec> we use grids from yui
19:53:45 <rangi> ahhh
19:54:13 <josef_moravec> and in rancor modals we use gridos from bootstrap
19:54:38 <kidclamp> sounds good, going to keep us moving
19:54:48 <kidclamp> #info REST API - how to solve "conflicts" in endpoints? For example bugs 17007 and 17371
19:54:49 <cait> sorry, I am late
19:54:57 <kidclamp> heh - throwing me to the wolves
19:55:19 <cait> #info Katrin Fischer, BSZ, Germany
19:55:23 <cait> not intentionally :)
19:55:28 <thd> grids, fixed sizes :(
19:55:35 <josef_moravec> these two bugs solves the similer problems, but in a bit different ways...
19:55:42 <rangi> i've been leaving the REST stuff to others so no opinion on that
19:55:50 <josef_moravec> thd: exactly
19:56:18 <kidclamp> yeah, I think we don't have the devs most involved in that here today
19:56:27 <josef_moravec> we just need to decide which one should pick...
19:56:36 <josef_moravec> kidclamp: it looks like...
19:56:38 <cait> bug 17007
19:56:39 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17007 enhancement, P3, ---, mail, Needs Signoff , REST API: add route to get biblio
19:56:42 <cait> bug 17371
19:56:43 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 enhancement, P5 - low, ---, koha-bugs, Needs Signoff , REST API: add CRUD for biblios
19:56:48 <josef_moravec> thanks cait
19:56:59 <kidclamp> or to resolve future conflicts too josef_moravec
19:57:11 <josef_moravec> kidclamp: it would be useful
19:57:40 <josef_moravec> I'm willing to test it.... we really need good REST API
19:58:27 <josef_moravec> we maybe need more detailed guidelines for API...
19:58:49 <kidclamp> tcohen and Joubu proposed a standard at hackfest
19:58:53 <josef_moravec> for CRUD there is nice example of /cities endpoint
19:58:57 <josef_moravec> kidclamp:
19:59:08 <kidclamp> exactly
19:59:19 <bag> yeah cities is the example
19:59:33 <josef_moravec> but it's an example when all is simple...
19:59:40 <josef_moravec> which is not always true...
20:00:22 <josef_moravec> as you can see with these too bugs...
20:00:28 <kidclamp> I don't think there can be a blanket rule though, more when conflicts arise they go into discussion/ out on mailing list/ vote at meeting
20:00:50 <josef_moravec> kidclamp: i agree
20:01:16 <josef_moravec> maybe just more oftem brings these thing to dev meetings...
20:01:32 <josef_moravec> and vote for one or another, as you say
20:01:59 <kidclamp> anyone have differing opinion?
20:01:59 <josef_moravec> it's all from me now ;)
20:02:10 <cait> i think having some guidelines and updating the wiki pages for the api dev would be good
20:02:48 <kidclamp> keep new endpoints up to date in wiki too to avoid conflict?
20:03:11 <cait> hm not sure, might get out of sync too fast
20:03:16 <cait> but if someone wants to try, sure
20:03:20 <cait> #link https://wiki.koha-community.org/wiki/Rest_Api_HowTo
20:03:56 <kidclamp> I think we need input from those who have been working on it too
20:03:59 <josef_moravec> kidclamp: as proposals? because there are many endpoint in patches in bugzilla, but just few in master code...
20:04:10 <jirislav> well, i think bug 17007 and bug 17371 should be merged - they aren't that different
20:04:12 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17007 enhancement, P3, ---, mail, Needs Signoff , REST API: add route to get biblio
20:04:12 <josef_moravec> kidclamp: sure
20:04:13 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 enhancement, P5 - low, ---, koha-bugs, Needs Signoff , REST API: add CRUD for biblios
20:04:18 <kidclamp> yeah, just a thought for proposals
20:04:40 <josef_moravec> jirislav: do you try it?
20:05:57 <kidclamp> #info REST api conflicts should be brough up in bugzilla/posted to koha-devel/discussed at dev meeting
20:06:43 <kidclamp> #action Someone involved in REST api should update 'how to' wiki and note guidelines on conflicts and cities endpoint as base example
20:06:43 <jirislav> i could, but it seems like 17007 is in the subset of 17371, so it could eventually be marked as duplicate (17007)
20:07:23 <kidclamp> yeah, 17371 is all crud, 17001 is just get?
20:07:37 <jirislav> kidclamp: right
20:07:57 <kidclamp> #info 17007 seems to be a subset of 17371 and should be merged
20:08:09 <kidclamp> want to comment on bugs jirislav?
20:08:22 <jirislav> sure thing
20:08:29 <kidclamp> cool, next topic
20:08:37 <kidclamp> #topic Updates from the QA team
20:08:44 <kidclamp> take it away cait :-)
20:09:39 <cait> oh
20:09:54 <cait> there are some problems with failing tests
20:10:27 <cait> so please sign off on those and generally focus on bug fixes for a bit :)
20:10:54 <kidclamp> #info please focus on bug fixes for the next release
20:10:59 <cait> i hope i don't repeat something already said
20:11:08 <cait> testing master, testing updates etc.
20:11:47 <cait> I have the list of critical and blocker bugs linked from the agenda
20:12:00 <cait> #link https://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=dorem&list_id=181688&namedcmd=FIXME%20NOW&remaction=run&sharer_id=1 List of critical and blocker bugs
20:12:00 <kidclamp> #link https://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=FIXME%20NOW&sharer_id=1
20:12:04 <cait> :)
20:12:14 <kidclamp> ah, link name :-)
20:12:40 <cait> 2 blockers especially  - one breaks the OPAC if you allow renewals
20:13:27 <cait> bug 17522
20:13:28 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17522 blocker, P5 - low, ---, kyle, In Discussion , opac-user.pl gives error of OpacRenewalAllowed is enabled
20:13:34 <cait> bug 16430
20:13:35 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16430 blocker, P5 - low, ---, gmcharlt, ASSIGNED , Mainpage.pl dies if library is not set
20:13:36 <rangi> ah yeah that one is nasty
20:14:02 <cait> so yeah, lots to do to make this release shine - please help :)
20:14:37 <jransom> hi all
20:14:39 <kidclamp> #info review critical bugs 17522 and 16340 especially :-)
20:14:40 <cait> that's all from me
20:14:53 <kidclamp> tcohen already mentioned CI updates
20:15:01 <josef_moravec> jransom: hi ;)
20:15:10 <kidclamp> #topic  Koha and Qvarn - http://qvarn.org/
20:15:14 <kidclamp> thanks cait!
20:15:53 <rangi> right, so have people had a chance to have a quick look at Qvarn?
20:16:32 <kidclamp> very briefly looked at site
20:17:09 <rangi> so basically
20:17:22 <rangi> Koha stores a lot of sensitive information
20:17:32 <rangi> about people, and their reading habits
20:18:02 <rangi> the EU has a new act General Data Protection Regulation (which is in transition until the end of the next year)
20:18:24 <rangi> says that anyone deploying systems has to take care that none of this could leak
20:18:31 <rangi> (also its just good to do that in general)
20:18:53 <rangi> Qvan can act as a data store and IDP
20:19:11 <rangi> it has restful https json api
20:19:43 <rangi> so it would allow us to store patron data in qvarn, instead of in raw tables
20:20:11 <rangi> this is all just stuff to think about at this point
20:20:22 <rangi> but I do think it is worth considering
20:20:52 <kidclamp> so, things like borrowers/issues/statistics would move out of native db? what would it mean for reporting?
20:21:35 <jirislav> okay, so if we decide to use qvarn, what would be left in koha database? i mean .. all of the information related to user would have to be accessed via rest api instead of just mysql socket?
20:21:59 <thd> Is there a Qvarn process for particular users to have data removed as should be required by law in EU or even alter and augment it?
20:22:01 <rangi> jirislav: yup
20:22:02 <jirislav> wouldn't that be a preformance issue?
20:22:09 <rangi> potentially
20:22:13 <rangi> or it might be faster
20:22:47 <jirislav> that's right, if it's scaled properly, it could be even faster than SQL
20:22:48 <cait> i think you can keep what can't be linked to a person - if it's anonymous?
20:22:49 <wizzyrea> hi
20:22:49 <wahanui> hola, wizzyrea
20:22:58 <rangi> yep
20:23:01 <wizzyrea> #info Liz Rea, Catalyst NZ
20:23:33 <jirislav> cait: this is just statistics & configuration .. or anything more?
20:23:35 <rangi> like i said, nothing to decide now, but something to research and think about, even if we dont go with qvarn we need to work on making koha more secure around private data
20:23:54 <rangi> liw works at qvarnlabs and would be happy to discuss more i am sure
20:24:06 <kidclamp> I think it is interesting
20:24:17 <josef_moravec> it all sounds interesting....
20:24:19 <rangi> i like the IDP part of it too
20:25:15 <cait> jirislav: not sure exactly, storing a borrowrnumber alone might be ok
20:25:17 <cait> ?
20:25:17 <cait> rangi?
20:25:18 <wahanui> I LIKE ALMONDS! HAVE SOME NUTS!
20:25:19 <kidclamp> maybe liw wants to send out some basic info to listserv, or you rangi?
20:25:45 <josef_moravec> it would be better to use solution like this than write something own...
20:25:48 <kidclamp> wahanui: botsnack
20:25:48 <wahanui> :)
20:25:58 <rangi> kidclamp: yep one of us will
20:26:15 <thd> There should always be some means to change or remove data held in accordance with legal requirements and library policy even if pseudo-anonymised.
20:26:18 <kidclamp> #action rangi or liw will post some qvarn info to listservs
20:26:42 <jirislav> cait: oh, interesting point of view .. borrowernumber actually isn't an identifier which can be treated as an anonymous person
20:26:50 <jirislav> *is an identifier ..
20:27:33 <kidclamp> approaching 90 minutes I think we can keep that discussion going outside of meeting
20:27:42 <jirislav> which means qvarn would only store personal data like name, surname etc ... with connection to bornumber
20:28:16 <thd> Behaviour generally unmasks anonymisation.
20:28:35 <rangi> lets move on :)
20:28:38 <kidclamp> #topic Set time of next meeting
20:28:58 <rangi> theres hours of discussion about privacy :) we can have that another time :)
20:28:59 <kidclamp> do we have a two times set now from survey?
20:29:14 <kidclamp> heh, it's good discussion to have
20:30:31 <kidclamp> it looks like 13 UTC was most popular?
20:31:03 <thd> Very much better than the present time.
20:31:20 <cait> 10 and 19 where the last 2 meetings
20:31:23 <cait> hm were
20:31:39 <kidclamp> 13 works for me
20:31:57 <cait> hm today is 14
20:32:05 <cait> ah sorry, no, that's next general
20:32:18 * cait will be quiet
20:32:42 <thd> 14 is problematic for me where 13 is less so.
20:32:49 <kidclamp> no worries, two weeks out is day after release?
20:32:54 <rangi> just fyi
20:33:02 <rangi> ill never be at a 13 UTC one
20:33:04 <kidclamp> if we want to meet then
20:33:08 <kidclamp> heh
20:33:13 <rangi> not that that should stop you
20:33:27 <rangi> (its 2am nz time)
20:33:38 <kidclamp> so when we stage the revolt, it should be at 13UTC?
20:34:12 <thd> I much prefer morning UTC time.
20:34:55 <kidclamp> alright I am suggesting Dec 14 - 13 UTC?
20:35:55 <cait> ok for me
20:36:03 <kidclamp> #info Next meeting December 14th, 13 UTC
20:36:30 * kidclamp takes that opportunity
20:36:47 <kidclamp> #endmeeting