14:01:23 #startmeeting Development IRC meeting 13 June 2018 14:01:23 Meeting started Wed Jun 13 14:01:23 2018 UTC. The chair is kidclamp. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:23 The meeting name has been set to 'development_irc_meeting_13_june_2018' 14:01:31 #topic Introductions 14:01:31 #info wahanui, a bot that has become sentient 14:01:39 #info Nick Clemens, ByWater Solutions 14:01:46 #info Jonathan Druart 14:01:49 #info Lee Jamison, Marywood University 14:02:03 #info Owen Leonard, Athens County Public Libraries, USA 14:02:05 #info Josef Moravec, Municipal Library Usti nad Orlici, Czech Republic 14:03:14 #topic Announcements 14:03:18 Anybody 14:03:25 #info Thomas Dukleth, Agogme, New York City 14:03:38 docs will be having a meeting immediately following this dev meeting :) 14:04:32 kidclamp: have there been any 18.11 pushes to master done yet? or still getting set up? 14:04:41 #topic Update from the Release manager (18.11) 14:04:47 we should send a what's on in koha-devel email this month. If you want to contribute, it's there https://annuel2.framapad.org/p/What_s_on_in_koha-devel 14:05:05 still pushing bugs for one more week, then will begin with the queue next friday 14:05:32 #info RM is pushing bugs for one more week, will begin on enhancements next friday 14:05:36 kidclamp: okay thanks..so the docs meeting will be brief :) 14:05:39 thanks Joubu 14:06:05 LeeJ there is a note on the merging deleted tables for docs 14:06:22 bug 20271 14:06:22 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271 major, P1 - high, ---, oha, Passed QA , Merge deleted* tables with their "alive" cousins 14:06:25 kidclamp: hm? 14:06:33 oh dear...alright 14:07:17 * lavamind waves 14:07:22 kidclamp: thanks...I'll have to read it in-depth later 14:07:49 oleonard, is there a write up on the wiki for dev/testing process after SCSS patches are pushed? 14:08:07 if not, can there be? 14:08:14 https://wiki.koha-community.org/wiki/Working_with_staff_client_SCSS 14:08:33 I can add a section specifically for testers 14:08:39 oleonard++ 14:09:02 that's all I have for now, I am going to push all I can to leave time for testing 14:09:45 Mana, ES stuffs, other big things please QA sooner rather than later :-) 14:09:59 #topic Updates from the Release Maintainers 14:10:03 RMaints? 14:10:04 somebody said RMaints was kidclamp (17.11), fridolin (17.05), rangi (16.11) 14:10:20 #info Fridolin Somers, Biblibre, France 14:10:42 wahanui RMaints is ashimema (18.05), fridolin (17.11 and 17.05) 14:10:42 ...but rmaints is kidclamp (17.11), fridolin (17.05), rangi (16.11)... 14:10:49 wahanui RMaints is ashimema (18.05), fridolin (17.11 and 17.05) 14:10:49 ...but rmaints is kidclamp (17.11), fridolin (17.05), rangi (16.11)... 14:10:58 no wahanui, RMaints is ashimema (18.05), fridolin (17.11 and 17.05) 14:10:58 okay, Joubu. 14:11:07 thanks joubu 14:11:16 fridolin? 14:11:16 i guess fridolin is that guy with the great hair 14:11:41 evrything is ok for 17.11.07 release 14:11:45 nothing special 14:12:08 #info Martin Renvoize - PTFS Europe 14:12:25 it has been mentioned we may want to relase 18.05.01 early? ashimema? 14:13:02 iirc Joubu mentioned 18.05 was unfit for prod 14:14:15 I've been waiting for the bugfixes to slow down before making a decision on early release.. felt like there were still bits coming in at more than a tricle pace 14:15:01 as I said.. I'm open to opinions on that but to date I've only had one person suggest a need to get it out sooner than 22nd 14:15:02 there are still some that are not pushed to 18.05.x 14:15:17 indeed 14:15:56 bug 20918, bug 20899 , bug 20832 should be part of 18.05.01 14:15:56 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20918 major, P5 - low, ---, jonathan.druart, Signed Off , left-side navigation broken on the checkout history page 14:15:57 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20899 major, P5 - low, ---, jonathan.druart, Signed Off , Patron name not showing on issuehistory.pl 14:15:58 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20832 critical, P5 - low, ---, josef.moravec, Passed QA , Opac user page crash when there is an overdue fine and not any rental charge for a patron 14:16:06 We'll stick to 22nd as per the norm I think.. get as many solid fixes in as possible rather than setting a precident to release early with some fixes missing 14:16:35 #info 18.05.01 will stick to release on 22nd to get as many fixes as possible 14:16:40 soudns good to me 14:16:46 20832 was one that particular caught my attention ;) 14:17:11 I will push bugs today or tomorrw 14:17:16 to give you time 14:17:29 * ashimema goes on school run to presence will be intermitten for the next 30 mins 14:17:33 :) 14:17:53 moving on 14:17:59 #topic Updates from the QA team 14:18:11 QA team? 14:18:11 QA team is hunting all the bugs! 14:18:16 qa_team? 14:18:17 qa_team is probably alex_a jajm marcelr khall kidclamp tcohen josef_moravec 14:18:31 and few more now 14:19:37 no wahanui qa_teamis jajm marcelr josef_moravec alex_a ashimema tcohen khall Joubu rangi 14:19:41 no wahanui qa_team is jajm marcelr josef_moravec alex_a ashimema tcohen khall Joubu rangi 14:19:41 okay, kidclamp. 14:19:45 I'd like QA on bug 19817 and bug 20287, they should be pushed early in the release cycle 14:19:45 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19817 new feature, P5 - low, ---, jonathan.druart, Needs Signoff , Merge local and online documentations 14:19:46 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20287 enhancement, P5 - low, ---, jonathan.druart, Signed Off , Move AddMember and ModMember to Koha::Patron 14:20:21 bug 20271 is PQA, I think we should get another stamp on it 14:20:21 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271 major, P1 - high, ---, oha, Passed QA , Merge deleted* tables with their "alive" cousins 14:20:28 #info bugs 19817 and 20287, please QA for early pushing to allow thorough testing 14:20:47 and also know if someone is going to work on other tables (issues, reserves, etc.) for this release 14:21:15 Joubu, doesn't it touch them all? 14:21:42 oh, it changed 14:22:01 ha, maybe it has changed since I took a look 14:22:13 no, it was all, then it wasn't again 14:22:42 yes, issues and reserves are the most problematic 14:22:55 I have just looked at the update db entry this morning 14:22:59 and it's scary 14:23:29 INSERT IGNORE INTO items ( 14:23:30 + SELECT *, timestamp AS deleted_on FROM deleteditems 14:23:30 + WHERE biblioitemnumber IN (SELECT biblioitemnumber FROM biblioitems) 14:23:30 + AND homebranch IN (SELECT homebranch FROM branches) 14:23:30 + AND holdingbranch IN (SELECT holdingbranch FROM branches) 14:23:32 + AND biblionumber IN (SELECT biblionumber FROM biblio) 14:23:58 not sure how this will behave on very big DB, that needs to be checked/confirmed before pushed 14:24:26 will test against some dbs before pushing 14:24:56 #info bug 20271 could use a second (or third) pair of eyes as it is a big (but necessary) change 14:25:04 anything else Joubu?> 14:25:12 nope 14:25:31 #topic General development discussion (trends, ideas, ...) 14:25:39 (well, it's no longer a necessary change ;)) 14:25:47 #topic Accounts API: Vote the RFC 14:27:57 I note the question about manager_id vs something more familiar. 14:28:01 #link https://wiki.koha-community.org/wiki/Patrons_account_lines_endpoint_RFC Accountlines endpoint RFC 14:28:17 The accounts RFC looks solid to me. 14:29:02 looks good to me as well 14:29:32 Is the reason for manager_id to use accounting terms as distinct from Koha nomenclature? 14:29:52 thd: I think vote can proceed with note to consider the naming for tcohen 14:29:59 I am not sure why 'manager_id' 14:30:28 kidclamp: heh, I was going to ask the same! 14:30:35 to me it's confusing 14:30:56 What term would you prefer? 14:30:59 It may be the term which proper accountants expect. 14:31:40 and cait asked the same on the wiki page 14:32:02 for the api he specifies 'user_id' which is more in line 14:32:36 so I think he took the comment into account 14:32:47 Staff_id would suit me 14:32:52 Grr, autocorrect 14:33:23 both terms proposed by Katrin are OK for me... 14:33:42 Hmm, user_id feels too generic to me 14:34:21 vote on user_id vs staff_id then vote on rfc with that change? 14:34:28 There are two users in this call.. so having role there makes sense 14:34:37 Yes, actually if it was for accountants then the api term would be manager so manager is still confusing. 14:34:40 user_id vs patron_id 14:35:01 #info Kyle M Hall, ByWater Solutions 14:36:50 going to call a vote for the manager id field 14:36:56 I think we should wait for clarification from the author of the API. 14:37:21 tcohen said he is happy to go with what is wanted 14:37:30 OK 14:38:10 patron_id is a distinct and separate role. 14:38:18 #startvote Should manager_id in the accountlines endpoint be referred to as staff_id, user_id, or manager_id? staff_id, user_id, manager_id 14:38:18 Begin voting on: Should manager_id in the accountlines endpoint be referred to as staff_id, user_id, or manager_id? Valid vote options are staff_id, user_id, manager_id. 14:38:18 Vote using '#vote OPTION'. Only your last vote counts. 14:38:31 #vote user_id 14:38:45 #vote user_id 14:39:07 #vote user_id 14:39:08 https://wiki.koha-community.org/wiki/Acquisitions_funds_endpoint_RFC 14:39:45 #vote staff_id 14:40:17 #vote member_id 14:40:17 Joubu: member_id is not a valid option. Valid options are staff_id, user_id, manager_id. 14:40:21 :D 14:40:29 lol 14:40:32 #vote staff_id 14:40:35 #vote staff_id # for the DB 14:40:35 thd: staff_id # for the DB is not a valid option. Valid options are staff_id, user_id, manager_id. 14:40:53 #vote staff_id 14:40:58 Is the vote about the DB or the API? 14:41:03 the api 14:41:22 i think we are tied, someone around to help us? 14:41:25 #vote staff_id 14:41:31 josef_moravec++ 14:41:33 last call 14:41:49 We can't easily change the db can we? 14:41:51 it's not so important, we just need to stay consistent with other endpoints 14:42:20 The original question was about the DB column manager_id with API key user_id . 14:42:43 #endvote 14:42:43 Voted on "Should manager_id in the accountlines endpoint be referred to as staff_id, user_id, or manager_id?" Results are 14:42:43 staff_id (4): Joubu, ashimema, thd, josef_moravec 14:42:43 user_id (3): kidclamp, LeeJ, khall 14:43:18 #info staff_id is preferred for API access to manager_id in the db 14:43:23 My vote was intended to be for the DB column name. 14:43:58 did you want to change your vote thd? 14:44:26 I am still not clear what the vote is for DB column or API key? 14:44:30 the API 14:44:34 maybe we do not care? 14:44:34 ... or both 14:44:41 really, who *really* cares? 14:44:49 we do not planj to alter the db, is much messier 14:45:16 Is the db column not new? 14:45:24 maybe not. 14:45:37 no, this is just conversing on API endpoints for existing database tables 14:45:53 calling for vote on the RFC 14:46:13 I will leave my vote 14:46:42 #startvote Should we accept the accountlines endpoint RFC with adjustment for manager_id -> staff_id? Yes, No, Abstain 14:46:42 Begin voting on: Should we accept the accountlines endpoint RFC with adjustment for manager_id -> staff_id? Valid vote options are Yes, No, Abstain. 14:46:42 Vote using '#vote OPTION'. Only your last vote counts. 14:46:46 #vote Yes 14:46:57 let's say the RFC is flexible and will be adjusted depending on further needs/discussions? 14:47:39 #info the RFC is flexible and will be adjusted depending on further needs/discussions 14:47:40 #vote Yes 14:47:41 Joubu++ 14:47:45 Joubu++ 14:47:47 #vote Yes 14:47:51 yes, just voting on enough consensus for work to proceed 14:48:06 #vote Yes 14:48:48 I would have preferred to have a rationale from tcohen. 14:49:29 #Yes 14:49:34 #vote Yes 14:49:48 #vote yes 14:49:55 last call 14:50:24 you can still discuss with him later thd 14:50:33 #endvote 14:50:33 Voted on "Should we accept the accountlines endpoint RFC with adjustment for manager_id -> staff_id?" Results are 14:50:33 Yes (6): Joubu, josef_moravec, khall, kidclamp, thd, LeeJ 14:50:48 #info Accountlines RFC endpoint is accepted 14:50:58 #topic Review of coding guidelines 14:51:09 #topic Add a new coding guideline about maintaining the cookie documentation, see: Use of Cookies 14:51:20 #link https://wiki.koha-community.org/wiki/Use_of_Cookies Use of cookies 14:51:56 I meant that I would have preferred a rationale from the author before voting but the suggestion has been that he did not have a strong rationale and as Joubu rightly stated we can revisit the issue if it has a consequence. 14:53:26 s/has been/has been implied indirectly/ 14:54:45 cookies seems to be gdpr consideration? anyone know who added or has opinion? 14:54:45 Okay, so cookies... 14:55:58 kidclamp: should the cookies page be referenced somewhere in the manual considering the gravity of GDPR? 14:56:49 it can't hurt, or can refer to that page 14:57:07 I think asking devs to update docs for cookie expiration time sounds fair 14:57:36 just need someone to word it to vote 14:57:55 sounds good! I'll mark it down for the docs meeting to mention it/create a task 14:58:40 * Joubu thinks Koha should have a page with developper's name and postal address to let librarians send them cookies 14:59:03 * LeeJ agrees with Joubu's idea 14:59:03 that's what the cookie law was about eg 14:59:05 *eh 14:59:11 Joubu++ 14:59:29 Joubu, you added the note, you want to propose a guideline to vote on? or next meeting? 14:59:33 (at 1 hr) 15:00:23 did I?? 15:00:39 I think it was Katrin ;) 15:01:12 Koha Coding Guidelines to be changed to incorporate cookies use and expiration as described in https://wiki.koha-community.org/wiki/Use_of_Cookies with the Koha Manual to incorporate a reference to the same policy as an element in GDPR compliance, Yes or No? 15:01:31 ah, I misread 15:02:22 why do we need to vote on that? Submit a patch and we are done 15:02:40 Joubu++ 15:02:53 the vote is on adding a guideline to ask devs to maintain that page 15:03:10 we need an #info at least. 15:03:22 ho right, so let's vote yes 15:04:12 I'm wondering if there should be a dedicated section in the manual titled something like "GDPR Compliance" if we're going to be continually updating/changing things for compliance purposes 15:04:20 (we need 2 version columns (from-to), if we remove them) 15:04:24 #startvote Should a codign guidline be added to require devs to maintin documentation on cookie use/expiration as required by GDPR and maintained on the wiki page Use of Cookies? Yes, No, Abstain 15:04:24 Begin voting on: Should a codign guidline be added to require devs to maintin documentation on cookie use/expiration as required by GDPR and maintained on the wiki page Use of Cookies? Valid vote options are Yes, No, Abstain. 15:04:24 Vote using '#vote OPTION'. Only your last vote counts. 15:04:40 #vote yes 15:04:42 #vote Yes 15:04:42 #vote yes 15:04:51 #vote Yes 15:04:58 #vote Yes 15:05:05 #vote Yes 15:05:17 last call 15:05:24 it could also be added to the release notes (like syspref, notice templates, permissions, etc.) 15:05:41 Joubu++ 15:05:45 #endvote 15:05:45 Voted on "Should a codign guidline be added to require devs to maintin documentation on cookie use/expiration as required by GDPR and maintained on the wiki page Use of Cookies?" Results are 15:05:45 Yes (6): Joubu, oleonard, khall, kidclamp, thd, LeeJ 15:06:22 #info agred, we shoudl add a coding guideline to maintain cookie documentation 15:06:40 #info Joubu suggests also adding notes about cookies/gdpr to release notes 15:06:55 #action cait, please write a codign guideline for cookies 15:07:37 Next meeting June 27th, 21 UTC? 15:08:03 yes 15:08:45 The more place people may see references to specific elements of GDPR compliance release notes, etc. as Joubu stated the safer people should be at present from any overzealous enforcement. 15:08:59 #info Next meeting: 27 June 2018, 21 UTC 15:09:07 #endmeeting