14:01:23 <kidclamp> #startmeeting Development IRC meeting 13 June 2018
14:01:23 <huginn`> 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 <huginn`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:23 <huginn`> The meeting name has been set to 'development_irc_meeting_13_june_2018'
14:01:31 <kidclamp> #topic Introductions
14:01:31 <wahanui> #info wahanui, a bot that has become sentient
14:01:39 <kidclamp> #info Nick Clemens, ByWater Solutions
14:01:46 <Joubu> #info Jonathan Druart
14:01:49 <LeeJ> #info Lee Jamison, Marywood University
14:02:03 <oleonard> #info Owen Leonard, Athens County Public Libraries, USA
14:02:05 <josef_moravec> #info Josef Moravec, Municipal Library Usti nad Orlici, Czech Republic
14:03:14 <kidclamp> #topic Announcements
14:03:18 <kidclamp> Anybody
14:03:25 <thd> #info Thomas Dukleth, Agogme, New York City
14:03:38 <LeeJ> docs will be having a meeting immediately following this dev meeting :)
14:04:32 <LeeJ> kidclamp: have there been any 18.11 pushes to master done yet? or still getting set up?
14:04:41 <kidclamp> #topic Update from the Release manager (18.11)
14:04:47 <Joubu> 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 <kidclamp> still pushing bugs for one more week, then will begin with the queue next friday
14:05:32 <kidclamp> #info RM is pushing bugs for one more week, will begin on enhancements next friday
14:05:36 <LeeJ> kidclamp: okay thanks..so the docs meeting will be brief :)
14:05:39 <kidclamp> thanks Joubu
14:06:05 <kidclamp> LeeJ there is a note on the merging deleted tables for docs
14:06:22 <kidclamp> bug 20271
14:06:22 <huginn`> 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 <LeeJ> kidclamp: hm?
14:06:33 <LeeJ> oh dear...alright
14:07:17 * lavamind waves
14:07:22 <LeeJ> kidclamp: thanks...I'll have to read it in-depth later
14:07:49 <kidclamp> oleonard, is there a write up on the wiki for dev/testing process after SCSS patches are pushed?
14:08:07 <kidclamp> if not, can there be?
14:08:14 <oleonard> https://wiki.koha-community.org/wiki/Working_with_staff_client_SCSS
14:08:33 <oleonard> I can add a section specifically for testers
14:08:39 <kidclamp> oleonard++
14:09:02 <kidclamp> that's all I have for now, I am going to push all I can to leave time for testing
14:09:45 <kidclamp> Mana, ES stuffs, other big things please QA sooner rather than later :-)
14:09:59 <kidclamp> #topic Updates from the Release Maintainers
14:10:03 <kidclamp> RMaints?
14:10:04 <wahanui> somebody said RMaints was kidclamp (17.11), fridolin (17.05), rangi (16.11)
14:10:20 <fridolin> #info Fridolin Somers, Biblibre, France
14:10:42 <kidclamp> wahanui RMaints is ashimema (18.05), fridolin (17.11 and 17.05)
14:10:42 <wahanui> ...but rmaints is kidclamp (17.11), fridolin (17.05), rangi (16.11)...
14:10:49 <kidclamp> wahanui RMaints is ashimema (18.05), fridolin (17.11 and 17.05)
14:10:49 <wahanui> ...but rmaints is kidclamp (17.11), fridolin (17.05), rangi (16.11)...
14:10:58 <Joubu> no wahanui, RMaints is ashimema (18.05), fridolin (17.11 and 17.05)
14:10:58 <wahanui> okay, Joubu.
14:11:07 <kidclamp> thanks joubu
14:11:16 <kidclamp> fridolin?
14:11:16 <wahanui> i guess fridolin is that guy with the great hair
14:11:41 <fridolin> evrything is ok for 17.11.07 release
14:11:45 <fridolin> nothing special
14:12:08 <ashimema> #info Martin Renvoize - PTFS Europe
14:12:25 <kidclamp> it has been mentioned we may want to relase 18.05.01 early? ashimema?
14:13:02 <lavamind> iirc Joubu mentioned 18.05 was unfit for prod
14:14:15 <ashimema> 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 <ashimema> 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 <Joubu> there are still some that are not pushed to 18.05.x
14:15:17 <ashimema> indeed
14:15:56 <Joubu> bug 20918, bug 20899 , bug 20832 should be part of 18.05.01
14:15:56 <huginn`> 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 <huginn`> 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 <huginn`> 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 <ashimema> 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 <kidclamp> #info 18.05.01 will stick to release on 22nd to get as many fixes as possible
14:16:40 <kidclamp> soudns good to me
14:16:46 <ashimema> 20832 was one that particular caught my attention ;)
14:17:11 <kidclamp> I will push bugs today or tomorrw
14:17:16 <kidclamp> 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 <ashimema> :)
14:17:53 <kidclamp> moving on
14:17:59 <kidclamp> #topic Updates from the QA team
14:18:11 <kidclamp> QA team?
14:18:11 <wahanui> QA team is hunting all the bugs!
14:18:16 <Joubu> qa_team?
14:18:17 <wahanui> qa_team is probably alex_a jajm marcelr khall kidclamp tcohen josef_moravec
14:18:31 <Joubu> and few more now
14:19:37 <kidclamp> no wahanui qa_teamis jajm marcelr josef_moravec alex_a ashimema tcohen khall Joubu rangi
14:19:41 <kidclamp> no wahanui qa_team is jajm marcelr josef_moravec alex_a ashimema tcohen khall Joubu rangi
14:19:41 <wahanui> okay, kidclamp.
14:19:45 <Joubu> I'd like QA on bug 19817 and bug 20287, they should be pushed early in the release cycle
14:19:45 <huginn`> 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 <huginn`> 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 <Joubu> bug 20271 is PQA, I think we should get another stamp on it
14:20:21 <huginn`> 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 <kidclamp> #info bugs 19817 and 20287, please QA for early pushing to allow thorough testing
14:20:47 <Joubu> and also know if someone is going to work on other tables (issues, reserves, etc.) for this release
14:21:15 <kidclamp> Joubu, doesn't it touch them all?
14:21:42 <kidclamp> oh, it changed
14:22:01 <Joubu> ha, maybe it has changed since I took a look
14:22:13 <kidclamp> no, it was all, then it wasn't again
14:22:42 <kidclamp> yes, issues and reserves are the most problematic
14:22:55 <Joubu> I have just looked at the update db entry this morning
14:22:59 <Joubu> and it's scary
14:23:29 <Joubu> INSERT IGNORE INTO items (
14:23:30 <Joubu> +            SELECT *, timestamp AS deleted_on FROM deleteditems
14:23:30 <Joubu> +            WHERE biblioitemnumber IN (SELECT biblioitemnumber FROM biblioitems)
14:23:30 <Joubu> +            AND homebranch IN (SELECT homebranch FROM branches)
14:23:30 <Joubu> +            AND holdingbranch IN (SELECT holdingbranch FROM branches)
14:23:32 <Joubu> +            AND biblionumber IN (SELECT biblionumber FROM biblio)
14:23:58 <Joubu> not sure how this will behave on very big DB, that needs to be checked/confirmed before pushed
14:24:26 <kidclamp> will test against some dbs before pushing
14:24:56 <kidclamp> #info bug 20271 could use a second (or third) pair of eyes as it is a big (but necessary) change
14:25:04 <kidclamp> anything else Joubu?>
14:25:12 <Joubu> nope
14:25:31 <kidclamp> #topic General development discussion (trends, ideas, ...)
14:25:39 <Joubu> (well, it's no longer a necessary change ;))
14:25:47 <kidclamp> #topic Accounts API: Vote the RFC
14:27:57 <thd> I note the question about manager_id vs something more familiar.
14:28:01 <kidclamp> #link https://wiki.koha-community.org/wiki/Patrons_account_lines_endpoint_RFC Accountlines endpoint RFC
14:28:17 <ashimema> The accounts RFC looks solid to me.
14:29:02 <LeeJ> looks good to me as well
14:29:32 <thd> Is the reason for manager_id to use accounting terms as distinct from Koha nomenclature?
14:29:52 <kidclamp> thd: I think vote can proceed with note to consider the naming for tcohen
14:29:59 <kidclamp> I am not sure why 'manager_id'
14:30:28 <Joubu> kidclamp: heh, I was going to ask the same!
14:30:35 <Joubu> to me it's confusing
14:30:56 <ashimema> What term would you prefer?
14:30:59 <thd> It may be the term which proper accountants expect.
14:31:40 <Joubu> and cait asked the same on the wiki page
14:32:02 <kidclamp> for the api he specifies 'user_id' which is more in line
14:32:36 <kidclamp> so I think he took the comment into account
14:32:47 <ashimema> Staff_id would suit me
14:32:52 <ashimema> Grr, autocorrect
14:33:23 <josef_moravec> both terms proposed by Katrin are OK for me...
14:33:42 <ashimema> Hmm, user_id feels too generic to me
14:34:21 <kidclamp> vote on user_id vs staff_id then vote on rfc with that change?
14:34:28 <ashimema> There are two users in this call.. so having role there makes sense
14:34:37 <thd> Yes, actually if it was for accountants then the api term would be manager so manager is still confusing.
14:34:40 <kidclamp> user_id vs patron_id
14:35:01 <khall> #info Kyle M Hall, ByWater Solutions
14:36:50 <kidclamp> going to call a vote for the manager id field
14:36:56 <thd> I think we should wait for clarification from the author of the API.
14:37:21 <kidclamp> tcohen said he is happy to go with what is wanted
14:37:30 <thd> OK
14:38:10 <thd> patron_id is a distinct and separate role.
14:38:18 <kidclamp> #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 <huginn`> 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 <huginn`> Vote using '#vote OPTION'. Only your last vote counts.
14:38:31 <kidclamp> #vote user_id
14:38:45 <LeeJ> #vote user_id
14:39:07 <khall> #vote user_id
14:39:08 <Joubu> https://wiki.koha-community.org/wiki/Acquisitions_funds_endpoint_RFC
14:39:45 <thd> #vote staff_id
14:40:17 <Joubu> #vote member_id
14:40:17 <huginn`> Joubu: member_id is not a valid option. Valid options are staff_id, user_id, manager_id.
14:40:21 <Joubu> :D
14:40:29 <LeeJ> lol
14:40:32 <ashimema> #vote staff_id
14:40:35 <thd> #vote staff_id # for the DB
14:40:35 <huginn`> thd: staff_id # for the DB is not a valid option. Valid options are staff_id, user_id, manager_id.
14:40:53 <Joubu> #vote staff_id
14:40:58 <thd> Is the vote about the DB or the API?
14:41:03 <kidclamp> the api
14:41:22 <kidclamp> i think we are tied, someone around to help us?
14:41:25 <josef_moravec> #vote staff_id
14:41:31 <kidclamp> josef_moravec++
14:41:33 <kidclamp> last call
14:41:49 <ashimema> We can't easily change the db can we?
14:41:51 <Joubu> it's not so important, we just need to stay consistent with other endpoints
14:42:20 <thd> The original question was about the DB column manager_id with API key user_id .
14:42:43 <kidclamp> #endvote
14:42:43 <huginn`> 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 <huginn`> staff_id (4): Joubu, ashimema, thd, josef_moravec
14:42:43 <huginn`> user_id (3): kidclamp, LeeJ, khall
14:43:18 <kidclamp> #info staff_id is preferred for API access to manager_id in the db
14:43:23 <thd> My vote was intended to be for the DB column name.
14:43:58 <kidclamp> did you want to change your vote thd?
14:44:26 <thd> I am still not clear what the vote is for DB column or API key?
14:44:30 <kidclamp> the API
14:44:34 <Joubu> maybe we do not care?
14:44:34 <thd> ... or both
14:44:41 <Joubu> really, who *really* cares?
14:44:49 <kidclamp> we do not planj to alter the db, is much messier
14:45:16 <thd> Is the db column not new?
14:45:24 <thd> maybe not.
14:45:37 <kidclamp> no, this is just conversing on API endpoints for existing database tables
14:45:53 <kidclamp> calling for vote on the RFC
14:46:13 <thd> I will leave my vote
14:46:42 <kidclamp> #startvote Should we accept the accountlines endpoint RFC with adjustment for manager_id -> staff_id? Yes, No, Abstain
14:46:42 <huginn`> 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 <huginn`> Vote using '#vote OPTION'. Only your last vote counts.
14:46:46 <kidclamp> #vote Yes
14:46:57 <Joubu> let's say the RFC is flexible and will be adjusted depending on further needs/discussions?
14:47:39 <kidclamp> #info  the RFC is flexible and will be adjusted depending on further needs/discussions
14:47:40 <josef_moravec> #vote Yes
14:47:41 <thd> Joubu++
14:47:45 <josef_moravec> Joubu++
14:47:47 <thd> #vote Yes
14:47:51 <kidclamp> yes, just voting on enough consensus for work to proceed
14:48:06 <LeeJ> #vote Yes
14:48:48 <thd> I would have preferred to have a rationale from tcohen.
14:49:29 <khall> #Yes
14:49:34 <khall> #vote Yes
14:49:48 <Joubu> #vote yes
14:49:55 <kidclamp> last call
14:50:24 <kidclamp> you can still discuss with him later thd
14:50:33 <kidclamp> #endvote
14:50:33 <huginn`> Voted on "Should we accept the accountlines endpoint RFC with adjustment for manager_id -> staff_id?" Results are
14:50:33 <huginn`> Yes (6): Joubu, josef_moravec, khall, kidclamp, thd, LeeJ
14:50:48 <kidclamp> #info Accountlines RFC endpoint is accepted
14:50:58 <kidclamp> #topic Review of coding guidelines
14:51:09 <kidclamp> #topic Add a new coding guideline about maintaining the cookie documentation, see: Use of Cookies
14:51:20 <kidclamp> #link https://wiki.koha-community.org/wiki/Use_of_Cookies Use of cookies
14:51:56 <thd> 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 <thd> s/has been/has been implied indirectly/
14:54:45 <kidclamp> cookies seems to be gdpr consideration? anyone know who added or has opinion?
14:54:45 <oleonard> Okay, so cookies...
14:55:58 <LeeJ> kidclamp: should the cookies page be referenced somewhere in the manual considering the gravity of GDPR?
14:56:49 <kidclamp> it can't hurt, or can refer to that page
14:57:07 <kidclamp> I think asking devs to update docs for cookie expiration time sounds fair
14:57:36 <kidclamp> just need someone to word it to vote
14:57:55 <LeeJ> 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 <eythian> that's what the cookie law was about eg
14:59:05 <eythian> *eh
14:59:11 <kidclamp> Joubu++
14:59:29 <kidclamp> Joubu, you added the note, you want to propose a guideline to vote on? or next meeting?
14:59:33 <kidclamp> (at 1 hr)
15:00:23 <Joubu> did I??
15:00:39 <josef_moravec> I think it was Katrin ;)
15:01:12 <thd> 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 <kidclamp> ah, I misread
15:02:22 <Joubu> why do we need to vote on that? Submit a patch and we are done
15:02:40 <thd> Joubu++
15:02:53 <kidclamp> the vote is on adding a guideline to ask devs to maintain that page
15:03:10 <thd> we need an #info at least.
15:03:22 <Joubu> ho right, so let's vote yes
15:04:12 <LeeJ> 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 <Joubu> (we need 2 version columns (from-to), if we remove them)
15:04:24 <kidclamp> #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 <huginn`> 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 <huginn`> Vote using '#vote OPTION'. Only your last vote counts.
15:04:40 <Joubu> #vote yes
15:04:42 <kidclamp> #vote Yes
15:04:42 <oleonard> #vote yes
15:04:51 <khall> #vote Yes
15:04:58 <thd> #vote Yes
15:05:05 <LeeJ> #vote Yes
15:05:17 <kidclamp> last call
15:05:24 <Joubu> it could also be added to the release notes (like syspref, notice templates, permissions, etc.)
15:05:41 <thd> Joubu++
15:05:45 <kidclamp> #endvote
15:05:45 <huginn`> 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 <huginn`> Yes (6): Joubu, oleonard, khall, kidclamp, thd, LeeJ
15:06:22 <kidclamp> #info agred, we shoudl add a coding guideline to maintain cookie documentation
15:06:40 <kidclamp> #info Joubu suggests also adding notes about cookies/gdpr to release notes
15:06:55 <kidclamp> #action cait, please write a codign guideline for cookies
15:07:37 <kidclamp> Next meeting June 27th, 21 UTC?
15:08:03 <Joubu> yes
15:08:45 <thd> 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 <kidclamp> #info Next meeting: 27 June 2018, 21 UTC
15:09:07 <kidclamp> #endmeeting