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