13:06:23 <kidclamp> #startmeeting Development IRC meeting 14 February 2018
13:06:23 <huginn`> Meeting started Wed Feb 14 13:06:23 2018 UTC.  The chair is kidclamp. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:06:23 <huginn`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:06:23 <huginn`> The meeting name has been set to 'development_irc_meeting_14_february_2018'
13:06:29 <kidclamp> #topic introductions
13:06:30 <wahanui> #info wahanui, a bot that has become sentient
13:06:45 <kidclamp> #info Nick Clemens, ByWater Solutions
13:06:48 <oleonard> #info Owen Leonard, Athens County Public Libraries, USA
13:06:49 <tcohen> #info Tomas Cohen Arazi, Theke Solutions
13:07:00 <LibraryClaire> #info Claire Gravely, BSZ, Germany
13:07:18 <cait> #info Katrin Fischer, BSZ, Germany
13:07:30 <m23_KohaCZ> #info Michal Denar, Municipal Library Ceska Trebova, KohaCZ
13:09:27 <petter> #info Petter Åsen, Oslo public library, Norway
13:09:31 <kidclamp> #topic Announcements
13:09:44 <kidclamp> anyone have announcements?
13:09:45 <oleonard> Joubu not here?
13:10:04 <cait> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_14_February_2018 Agenda
13:10:46 <josef_moravec> #info Josef Moravec, Czech Republic
13:10:59 <tuxayo> #info Victor Grousset, BibLibre
13:11:01 <magnuse> #info Magnus Enger, Libriotecf, Noeway
13:11:06 <benjamin> #info Benjamin Rokseth, Oslo Public Library
13:11:11 <magnuse> *Norway
13:11:14 <tuxayo> Hooray for asset versionning? Bug 12904
13:11:14 <huginn`> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 enhancement, P5 - low, ---, kyle, Pushed to Master , Force browser to load new javascript files after upgrade
13:11:23 <kidclamp> indeed
13:11:53 <kidclamp> #info Bug 12904 pushed, some follow ups too, excellent news :-)
13:12:08 <kidclamp> #topic Update from the Release manager (18.05)
13:12:26 <cait> do we need to change something again now with the bug fixes pushed?
13:12:29 <cait> to fix the installations?
13:12:37 <kidclamp> I think he is not here, but read his 'What's on' email - QA stuff, he will push it
13:12:41 <tcohen> cait: yes
13:12:54 <kidclamp> if you pull latest misc4dev and reset_all
13:12:59 <cait> ok
13:13:03 <cait> maybe another email to koha-devel?
13:13:12 <cait> i was not sure if all known bugs are fixed now
13:13:14 <tcohen> there's been two emails
13:13:22 <kidclamp> or run cp_debian_files.pl
13:13:34 * tcohen is running a full kohadevbox creation to test if its fixed
13:14:07 <cait> hm I have only seen one for the first push
13:14:47 <kidclamp> all the blockers are pushed
13:15:07 <kidclamp> bugs 20187 20189 20190
13:15:54 <kidclamp> moving on?
13:16:01 <tcohen> yup
13:16:16 <kidclamp> #topic Updates from the Release Maintainers
13:16:24 <kidclamp> hey, that's me
13:16:39 <kidclamp> will try to catch up on master today/tomorrow, was away for a week so a bit behind
13:16:51 <kidclamp> string freeze tomorrow
13:17:00 <kidclamp> if you need stuff in, let me know
13:17:02 <tcohen> @later tell Joubu sql_mode can be set by the client...
13:17:02 <huginn`> tcohen: The operation succeeded.
13:17:22 <kidclamp> #info kidclamp will be catching up to master - string freeze tomorrow
13:17:28 <kidclamp> fridolin?
13:17:28 <wahanui> i guess fridolin is busy at the moment, I asked him to backport the bug fix
13:17:53 <kidclamp> wahanui forget fridolin
13:17:53 <wahanui> kidclamp: I forgot fridolin
13:18:11 <kidclamp> wahanui fridolin is that guy with the great hair
13:18:11 <wahanui> OK, kidclamp.
13:18:24 <cait> forget fridolin
13:18:24 <wahanui> cait: I forgot fridolin
13:18:27 <cait> Rmaints?
13:18:27 <wahanui> well, Rmaints is kidclamp (17.11), fridolin (17.05), rangi (16.11)
13:19:05 <clrh> hi, just for information, code4lib conference should begin in a few moments, stream available and program https://www.youtube.com/watch?v=MF-B3uVZwkA&feature=youtu.be http://2018.code4lib.org/schedule/day-1/
13:19:15 <cait> fridolin is that guy with the great hair
13:19:18 <cait> fxed.
13:19:43 <kidclamp> #topic Updates from the QA team
13:19:59 <kidclamp> qa_team?
13:19:59 <wahanui> i heard qa_team was alex_a jajm marcelr khall kidclamp tcohen josef_moravec
13:20:16 * kidclamp has been away so v behind, fridays are qa day
13:20:20 <cait> Nothing much new, we still need to do a lot of QA
13:20:26 <kidclamp> but every day rhymes with qa :-)
13:20:27 * tcohen has been away too
13:20:31 <cait> I have started sending weekly emails to the qa team to bug them ;)
13:20:37 <kidclamp> cait++
13:21:01 <kidclamp> khall is away today, so bug him for all the QA, he told me to say that :-
13:21:04 <kidclamp> :-D
13:21:07 <cait> i will
13:21:22 <cait> he also requested a bugging mail update on friday, which I will gladly send :)
13:21:57 <cait> we are stuck around 90 atm, which shoudl be lower, but I am really worried about the NSO queue
13:22:02 <kidclamp> anyone else?
13:22:02 <cait> for when it hits us and for the stuff stuck in there
13:22:35 <kidclamp> if someone wanted to hold a GBSD and drum up support I would give them hugs
13:22:49 <cait> the hackfest in Marseille is soon, but 220 is really a lot
13:23:41 * LibraryClaire would liek to see the NSO queue shrink a bit
13:23:59 * cait too
13:24:05 <oleonard> LibraryClaire++ # for helping shrink the NSO queue
13:24:17 <cait> so... someone GBSD?
13:24:26 <kidclamp> LibraryClaire^^
13:24:34 <LibraryClaire> :P
13:24:46 <LibraryClaire> only if everyone does hte bugs I don't wanna do
13:25:43 <LibraryClaire> the major queue has quite a few in it right now and we have one critical needing sign off too
13:26:09 <tcohen> if its friday, I can guide and SO too
13:26:26 <tcohen> i.e. help you LibraryClaire
13:26:37 <LibraryClaire> tcohen++
13:27:03 <kidclamp> #action LibraryClaire will organize a GBSD in the near future
13:27:30 <kidclamp> moving on
13:27:53 <kidclamp> #topic General development discussion (trends, ideas, ...)
13:28:47 <kidclamp> #info Bug 19474, Convert staff client CSS to SCSS: Should compiled CSS be part of the codebase?
13:28:47 <huginn`> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19474 enhancement, P5 - low, ---, oleonard, In Discussion , Convert staff client CSS to SCSS
13:28:53 <kidclamp> oleonard^
13:29:48 <oleonard> The question is whether there should be a compiled version of staff-global.css (compiled from staff-global.scss) in the codebase or whether it should be compiled during installation
13:30:04 <tcohen> *packaging?
13:30:06 <oleonard> Right now, for instance, in the OPAC the compiled version of the LESS file is tracked.
13:30:33 <oleonard> We ask that people making changes to the OPAC LESS file attach a separate patch for the compiled CSS
13:30:50 <oleonard> Do we want to continue to work that way in the staff client, or change that process somehow?
13:31:22 <oleonard> I don't have a preference either way. I wanted to take the opportunity to ask whether we are doing it the best way.
13:32:01 <cait> hm what are the consequences for the workflows?
13:32:21 <cait> i think package installatons can be fully automated...standard too -  git installations need to run a script?
13:32:38 <tcohen> I think we should do it at packaging time, and have our dev environment generate it for us
13:32:41 <cait> and for testers and sandboxes?
13:32:50 <oleonard> The current practice creates an extra step for patch-submitters but makes it very easy for testers.
13:33:01 <tcohen> and I would also add we should bundle all the perl deps on packaging time too
13:33:14 <kidclamp> what would be required for testers in this scenario?
13:33:18 <oleonard> ...except when testers find that opac.css conflicts every time I guess...
13:34:21 <cait> it seems we don't change the css too often, but staff might be different
13:35:02 <tcohen> in kohadevbox and koha-testing-docker it would be fairly easy to just add a watcher that re-generates the file on each change
13:35:12 <kidclamp> if there is a simple process for sandboxes and dev installs for testing I am for it - I guess is better to place burden on devs - ideal world none of us have to generate it
13:35:21 <mtompset> I've commented on this topic before. Compiling LESS files is technical. We should not introduce technical difficulties to those who wish to participate.
13:35:22 <kidclamp> tcohen what about traditional git
13:35:43 <Freddy_Enrique> Good morning everyone
13:36:13 <tcohen> kidclamp: we are working closely with khall to move the sandboxes into using koha-testing-docker
13:36:14 <josef_moravec> there is about 20 commits per year to staff-global.css, so it is changed relatively often...
13:36:59 <tcohen> in my opinion, this should be a RM task (regenerate) when pushing the patches
13:37:02 <kidclamp> test plans do require things now like 'reindex, run this script, etc' if it is as simple as 'perl compile_css.pl' I think it can be okay for testers
13:37:12 <mtompset> I agreed with tcohen.
13:37:26 <tcohen> in kohadevbox we already have the less-opac alias to do the job
13:37:33 <mtompset> kidclamp, perhaps recompile all the less files as part of restart_all? ;)
13:37:49 <mtompset> Oh... didn't know about that alias.
13:37:52 <mtompset> Sweet.
13:38:06 <cait> so same as schema changes?
13:38:19 <tcohen> mtompset: https://github.com/digibib/kohadevbox#aliases
13:38:19 <cait> hm not quite the same
13:38:34 <Joubu> (oops)
13:38:51 <cait> i think the important part is make it easy for testers
13:38:53 * LibraryClaire waves to Joubu
13:38:53 <mtompset> tcohen, I never pay attention to aliases. :)
13:38:56 <cait> we already talked about hte size of queue
13:38:58 <cait> :)
13:38:59 <kidclamp> with schema we ask devs to include the files to ease testing, could it be the same?
13:40:01 <oleonard> Include a patch with the compiled css but don't push it?
13:40:09 * kidclamp nods
13:40:22 <oleonard> I'm not sure if that's easier, since the patch is always going to conflict.
13:40:26 <Joubu> we will have conflicts all the time
13:40:32 * LibraryClaire hates conflicts
13:40:45 * kidclamp is conflict avoidant
13:42:03 <oleonard> Joubu: What do you think?
13:44:38 <Joubu> what oleonard said
13:45:20 <Joubu> we should provide an easy way to generate the .css file
13:45:25 <Joubu> we could even patch git-bz
13:46:48 <kidclamp> #chair cait
13:46:48 <huginn`> Current chairs: cait kidclamp
13:47:52 <cait> i think we need to make sure testers know waht to do
13:48:00 <cait> and that the solution works for devbox and sandbox
13:48:09 <cait> otherwise i have no preference :)
13:48:23 <kidclamp> oleonard should get what he wants :-)
13:48:25 <Joubu> how can we make sure testers know what do do?
13:48:36 <oleonard> kidclamp: But I didn't express a preference :P
13:49:51 <cait> might be a metter of people willing to help fixing devbox and sandboxes?
13:50:34 <oleonard> I get the impression that's its more typical these days that compiled assets are not tracked in git and it's handled in the packaging process.
13:50:58 <oleonard> Keeping the process the same as it is in the OPAC means that no new work is pushed onto anyone, so maybe that's better.
13:52:31 <cait> could you name the tasks that need to be done to make one or the other work for testers?
13:53:13 <oleonard> Keeping the status quo means testers need to resolve the compiled css conflict every time they test patches with css changes
13:53:38 <oleonard> Updating the workflow means changing devbox, sandboxes, git-bz, packaging process, etc.
13:53:45 <oleonard> ...which sounds like a lot to me!
13:55:17 <oleonard> Anyone want to argue against keeping things the way they are for now?
13:55:51 <kidclamp> well, if we change all that we reduce conflicts and keep ease of testing? pay now for savings later?
13:55:52 <Joubu> nope, just git-bz, or reset_all, that's all
13:56:41 <cait> not everyone wnats to throw their db out all the time :)
13:56:46 <cait> so please nothing that requires a reset_all
13:56:54 <Joubu> it can also be in the test plan, "first step, run this command to update the css file"
13:57:09 * LibraryClaire does not like reset_all after losing her db
13:57:29 <Joubu> so just run the script that will update the css file
13:57:37 <Joubu> or an alias, it's the same
13:57:49 <mtompset> Right, but people write lousy test plans, Joubu.
13:57:56 <Joubu> ok
13:57:59 <mtompset> They aren't likely to remember to add that step.
13:58:02 <Joubu> I am out for this conversatino I think
13:58:11 <LibraryClaire> I think it should be written in the test plan to run the script
13:58:21 <Joubu> people do not read email, do not read test plan, do not want to run alias
13:58:34 <mtompset> Soooo true!
13:59:01 <cait> i think an alias would work after a little get used to
13:59:12 <oleonard> Alright, let's keep things the way they are. I'll revise my patch to include the CSS.
13:59:43 <mtompset> Are we going to add a staff alias for compiling less too?
13:59:57 <oleonard> We should move on before everyone falls asleep.
14:00:12 <cait> any decision to log?
14:00:37 <Joubu> and people do not test anyway
14:00:47 <mtompset> write better test plans which include the command to compile any modified less files? :)
14:00:53 <cait> ok, moving on
14:01:00 <cait> but please still find a solution
14:01:26 <cait> next one is about merging the tables
14:01:28 <cait> petter: ?
14:01:34 <petter> woho!
14:01:37 <petter> this is gonna be fun:)
14:01:46 <petter> So, I guess we first should agree to do it
14:01:50 <petter> The agree on how to do it
14:02:17 <petter> I don't know if I should describe problems of the current db architecture?
14:02:21 <oha> we skip the whys, i guess we agree on that
14:03:05 <cait> it creates massive problems with PKs and the schema? :)
14:03:11 <petter> yes
14:03:12 <petter> https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix
14:03:14 <petter> this i one problem
14:03:23 <petter> is one
14:04:13 <petter> another, is that we are loosing data when moving row from one table to another, when the row is used in a relation to anther table
14:04:34 <petter> example: when we move from items to deleteditems, any old_issue which is refering to the item is set to NULL
14:04:45 <petter> so its no longer possible to find out what that checkout was
14:05:04 <mtompset> oh yuck! Hadn't thought of that one.
14:05:05 <cait> oh ugh
14:05:11 <cait> i didn't know fo that one
14:05:31 <cait> i thought they kept the number an donly nulled for patron
14:05:39 <Joubu> it depends
14:05:53 <oha> depends sounds even worse :)
14:05:59 <Joubu> on the value, but it sucks anyway as the link is not updated it it needs to be
14:06:23 <petter> Anyways, there are many problems, if all agree that we should merge, then we can focus on how to to the merging
14:06:38 <mtompset> Is there anyone opposed to the idea?!
14:06:39 <petter> As far as I could find out, the original reason for splitting the tables was for performace ?
14:06:50 <petter> But I don't think it is a viable argument any more
14:06:55 <petter> With proper indexes
14:07:02 <Joubu> petter: did you read the previous discussions on the list and bug reports?
14:07:04 <petter> millions of rows in issues table should be no problem
14:07:29 <petter> There was some discussion on the recent Recalls in koha bug
14:07:31 <cait> we might have to be careful with the merge - like warn big libraries they need to plan more time for update or so
14:07:39 <cait> we had some issues there with changes on statistics
14:08:04 <cait> my feeling is that we already agreed on doing it multiple times?
14:08:10 <petter> OK good lets do it!
14:08:17 <petter> Shall we vote to do it?
14:08:18 <oha> cait: I guess it will be a problem for custom reports
14:08:19 <cait> like everyone says we shoudl, but noone wants to tackle it
14:08:27 <cait> so was the move of marcxml
14:08:33 <cait> but it hink we got some helpful things from that we coudl use
14:08:40 <cait> like highlighting reports that need work after update
14:08:41 <Joubu> petter: we do not need a vote to do it, it's more: Who/How/When?
14:08:45 <petter> Great
14:08:59 <petter> So we can do some inital work
14:09:03 <oha> I actually did a quick test
14:09:08 <Joubu> and... who is going to update the sql report on the wiki, who is going to write bugfixes when pushed
14:09:25 <Joubu> I am oppose to do it now
14:09:33 <Joubu> I have started already
14:09:51 <oha> Joubu: i have no idea what is the sql report on the wiki
14:10:02 <Joubu> I would like to remove the related C4 modules before, and when the code is moved to Koha we can do it easily
14:10:04 <oha> can you explain?
14:10:17 <oleonard> oha: https://wiki.koha-community.org/wiki/SQL_Reports_Library
14:10:21 <oha> oleonard: ty
14:10:23 <Joubu> https://wiki.koha-community.org/wiki/SQL_Reports_Library
14:10:52 <oha> I guess I will read it _after_ this meeting :)
14:10:58 <oha> unless you want to wait... :o)
14:10:59 <Joubu> after the tables are merged the reports librarians wrote will be broken
14:11:12 <cait> true, but same now for marcxml ones
14:11:21 <cait> we need to document, but I don't think we can prevent it
14:11:34 <LibraryClaire> oha it's a collection of reports which have been written for use in koha
14:11:48 <petter> I understand you want to move C4 to Koha, but that would take years still, don't you think?
14:11:55 <cait> Joubu: wuld it be ok to start with... old_reserves for example after all hold things have been moved?
14:12:00 <Joubu> yes, that's why we have 2 versions for some reports now
14:12:02 <cait> or do you want to finish the whole rewrite before?
14:12:04 <Joubu> "Versions 17.05 and later: "
14:12:28 <petter> I think reports are the least of the challenges with doing the merge
14:12:30 <Joubu> petter: yes it takes years as nobody tests the patches I wrote
14:12:57 <oha> Joubu: I understand the frustration, but isn't this a bit off topic now?
14:13:01 <Joubu> the easier would be the borrowers tables I think
14:13:33 <oleonard> oha: Updating reports is part of the process. It's part of the workload we take on when we take on the change.
14:13:47 <oha> oleonard: i mean, signing joubu patches :)
14:14:04 <petter> I volunter to fix the reports
14:14:13 <cait> i can help with the sql reports
14:14:15 <cait> on the wiki
14:14:16 <wahanui> on the wiki is more information about the packages
14:14:29 <cait> and also with testing, i am already trying to help there
14:14:36 <cait> but it would be cool if got more help there
14:14:55 <cait> i think what we might have to do is agree on a plan
14:15:01 <cait> it feels like we have a lot of unfinished big projects right now
14:15:04 <petter> Yes
14:15:07 <petter> For a start
14:15:14 <petter> Make one bug about each table merge?
14:15:22 <cait> REST API, C4->Koha, etc.
14:15:31 <cait> I think maybe a wiki page even first
14:15:38 <cait> name the tables, the sequence, steps
14:15:46 <cait> and then make the bugs
14:15:48 <oha> anyways, i did a quick test today. I managed to remove deleteditems and have intra working, with the admin reports and apis. it didn't take long and it was 17 files changed, 51 insertions(+), 82 deletions(-)
14:16:12 <oha> I might have missed something, but going around in intra and testing few apis was ok
14:16:34 <oha> but i haven't checked the tests which will surely fails if they mingle with the db
14:19:03 <cait> I am all for it, but I think we need to see that we not only produce new code, but also have a clear plan in place
14:19:09 <cait> as we have problems processing the new code at the moment
14:19:32 <cait> i think a wiki page wth steps etc for next meeting and then really get people to dedicate to do it would be good
14:19:37 <petter> Shall we open a bug for merging items and deleteditems, provida an initial patch and continue discussion there?
14:20:15 <petter> Or we could start with another couple, borrowers + deletedborrowers
14:20:38 <cait> Joubu?
14:20:38 <wahanui> Joubu is probably not sure how to fix that correctly
14:20:40 <LibraryClaire> maye a wiki page for the project
14:20:51 <LibraryClaire> outlining what needs to be done
14:21:38 <Joubu> I have started already borrowers tables I think
14:22:06 <Joubu> oha: start with a wiki page I'd say, link with a bug report, and attach a patch if you have on
14:22:09 <Joubu> e
14:22:12 <oha> I can help you in the next month, but then i'm off for other tasks. so I'm happy to give you patches to test now
14:22:58 <oha> sounds good
14:23:21 <petter> great!
14:23:24 <cait> next meeting is in 2 weeks
14:23:27 <cait> let's see status then?
14:23:31 <petter> I'll make the wiki page and start adding to it
14:23:33 <cait> please make sure it's on the agenda
14:23:44 <cait> moving on ok?
14:23:47 <oleonard> A month probably isn't long enough to see the process through.
14:24:01 <Joubu> and maybe read the previous discussins on the list, I talk about this merge for 2,3y already ;)
14:24:07 <cait> yeah worried about that too, especially as we only have 1.5 left
14:24:11 <cait> hm ok 3
14:24:19 <cait> 3 months until release
14:24:40 <cait> but let's take another look in 2 weeks?
14:25:03 <petter> Yes, sounds good
14:25:10 <cait> I have put another thing on the list - I have learned that we need to document cookies for the data privacy documentation (GDPR etc)
14:25:17 <cait> instead of all of us doing that separately
14:25:28 <cait> I suggest creating a wiki page and collect the information there and maintain it together
14:25:40 <oha> I will do my best to give you something usable, but surely there might be some fine tuning after I'm gone
14:25:48 <cait> we'd need how long a cookie is stored, what is stored, what it's used for
14:25:56 <oha> cait: i think petter volunteered already :)
14:26:13 <cait> for the cookies?
14:26:23 <oha> cait: no, i read to hastly
14:26:26 <oha> ignore me :)
14:26:48 <cait> ok ;)
14:27:05 <cait> and amybe we could make a coding guideline about documenting new cookies added?
14:27:56 <cait> anyone home? :)
14:28:14 <oleonard> I think it's a good idea cait
14:29:14 <cait> ok, so i will start a wiki page
14:29:22 <cait> oleonard: would you be willing to proof read my findings maybe?
14:29:23 <m23_KohaCZ> Wiki page for user data & privacy will be great.
14:29:30 <oleonard> cait: Yes
14:29:40 <m23_KohaCZ> adn coding guidelines for developers too
14:29:45 <cait> #action cait to start a wiki page about cookie use in Koha
14:29:52 <cait> #action oleonard to proof read
14:30:09 <cait> #action cait to suggest a coding guideline for maintaining cookie documentation
14:30:34 <cait> I have also learned me might need to implement one of those cookie banners
14:30:35 <m23_KohaCZ> but GDPR isnt just about cookies, its easy part
14:30:45 <cait> that wanrs you about cookie use...
14:30:52 <cait> i might come back to this another time
14:31:06 <cait> a lot of the data privacy stuff is about documenting
14:31:17 <cait> what do you store, why do you store it, how long do you store it, when do you delete it?
14:32:15 <m23_KohaCZ> if someone want to quit service for some reason, shoul have some waay to delete cookis on their device easy, by click on link for example.
14:33:18 <cait> hm haven't seen that yet
14:33:20 <m23_KohaCZ> GDPR mantra: what user data we store, how we legal reason for it, which (law, agreement...)
14:33:25 <petter> https://wiki.koha-community.org/wiki/MergingOfTables
14:33:28 <cait> but we got a request for taking you data with you in a machine storable format
14:33:30 <cait> §20?
14:33:36 <cait> still have to look into it
14:33:47 <cait> in general, we might have to discuss this at a separate meeting
14:33:55 <cait> ok to move on?
14:34:20 <cait> #topic Review of coding guidelines
14:34:26 <cait> there are no topics listed
14:34:40 <cait> if it's ok, I will jump right to the next topic as we are running late today
14:34:56 <cait> #topic Set time of next meeting
14:35:03 <cait> Joubu: can you help me out?
14:36:07 <cait> February 28, 19 UTC?
14:36:55 <josef_moravec> ok for me
14:37:01 <cait> #info Next meeting: 28 February 2018, 19 UTC
14:37:07 <cait> #endmeeting