20:00:23 #startmeeting Development IRC meeting 24 January 2018 20:00:23 Meeting started Wed Jan 24 20:00:23 2018 UTC. The chair is kidclamp. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:23 The meeting name has been set to 'development_irc_meeting_24_january_2018' 20:00:33 #Topic Introductions 20:00:34 #info wahanui, a bot that has become sentient 20:00:43 #info Nick Clemens, byWater Solutions 20:00:48 #info liz rea, Catalyst IT 20:00:55 #info Aleisha Amohia, Catalyst IT 20:01:20 hi catalyst! 20:02:29 #info Kyle M Hall, ByWater Solutions 20:03:33 hmm..small crowd - forge ahead or reschedule? we can wait a bit too 20:03:54 how many of us are there now? 20:04:10 with you 5 20:04:59 5 is not terrible 20:05:09 I just odn't know if there are people too represent the topics in the agenda 20:05:27 forging ahead :-) 20:05:27 I was just going to raise that. 20:05:39 #Topic Announcements 20:05:44 floor is open 20:06:13 nice work on the "don't store bugzilla passwords in the clear" A+ 20:06:36 #info Thomas Dukleth, Agogme, New York City 20:06:38 yes, +1 20:07:02 Aleisha did you have any comments from academy week, good or bad? 20:07:13 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_24_January_2018 Agenda 20:07:32 #info kudos for work on not storing BZ passwords in plain text 20:08:43 i guess on to 18.05 stuff? 20:09:01 #topic Update from the Release manager (18.05) 20:09:22 Joubu is not here - I think he wants more QA and offers free hugs 20:09:47 oops sorry, Academy was awesome and the community was a huge help 20:09:52 hugs for patches, seems fair trade 20:10:00 #info Joubu could not make meeting, no updates 20:10:10 #topic Updates from the Release Maintainers 20:10:28 #info Academy was awesome and the community was a huge help 20:10:45 #info 17.11.02 and 17.05.08 released today 20:10:51 that's the big news 20:10:59 \o/ 20:11:27 #topic Updates from the QA team 20:11:41 just working where I can 20:12:05 #info every day rhymes with QA day: e.g. Monday is QA day, Tuesday is QA day.... 20:12:27 QA Monday, QA Tuesday etc. if you prefer 20:12:39 #topic General development discussion (trends, ideas, ...) 20:12:59 Bug 17241 20:12:59 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17241 enhancement, P5 - low, ---, kyle, Signed Off , Start using Bower for installing and managing Koha's JavaScript Dependencies 20:13:06 khall? 20:13:06 khall is volunteering to come over and fix it for you, it seems. ;) 20:13:40 ah yes 20:14:02 so, the question is basically: should we use bower for our web dependencies? 20:14:38 I think we maybe need marcel and other with opinions? 20:14:39 just looking for a general yay or nay 20:14:45 or we can just make owen decide 20:14:46 ; ) 20:14:51 ;) 20:15:03 okay to table to next meeting? 20:15:11 unless there are comments?> 20:15:12 i'm a general nay because every time we add on stuff like this it makes it harder to onboard developers. 20:15:20 we don't webpack any of our assets, and even if owen adds webpack, I'm not sure if he's going to add our existing assets 20:15:27 but I recognise that might not be the best reason. 20:15:34 wizzyrea++ 20:15:38 wizzyrea: it actually makes things easier. 20:15:52 well, actually, it doesn't. 20:16:03 right now adding a new dep is a real pain. and for using existing libraries it doesn't affect anything at all 20:16:14 ¯\_(ツ)_/¯ i'm happy to disagree with you 20:16:23 can you explain your thoughts wizzyrea ? 20:16:57 every time you add a new manager, when someone is a new dev, and they want to do work 20:17:00 it's another barrier. 20:17:07 I don't like that. 20:17:11 but 20:17:33 that may not be a good enough reason to not do it. 20:17:34 wizzyrea: do you have experience with bower? 20:17:43 have you had trouble using it in the past? 20:17:48 khall: Would you adress the learning curve? 20:18:08 thd there is no learning curve, seriously 20:18:41 if I were to play devil's advocate, I'd say new developers see the stone age way we handle things and run for the hills ; ) 20:18:59 there is always a learning curve. Always. But as I said, it may not be a good enough reason not to do it. 20:19:15 maybe it would eb helpful to have a 'here's what we do now' versus 'here's waht we do with bower' 20:19:18 wizzyrea: If implementation is trivial and khall writes a one line tutorial for the wiki then I will be for it. :) 20:19:23 I think that is what cait asked for too 20:19:34 we can do that 20:19:40 here it is: bower install 20:19:42 ^ this is fine, but we often end up not getting that 20:19:51 as in: bower install jquery 20:20:17 I'd be happy to write a companion wiki page for bug 17241 20:20:17 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17241 enhancement, P5 - low, ---, kyle, Signed Off , Start using Bower for installing and managing Koha's JavaScript Dependencies 20:20:23 assuming it gets pushed 20:21:29 we already use far more complicated tools for compiling our css, yet we continue to use them and even move forward with better tools ( like scss ) 20:22:36 ¯\_(ツ)_/¯ I can see you feel strongly about it. I really dont. 20:22:40 the academy students were very intimidated by anything css because it's a lil hard to look at, especially the minified stuff 20:23:21 as long as the process is understandable I am generally for it 20:23:24 lol, thanks wizzyrea ; ) 20:23:55 unless a dev is adding a new dependency, they'll never even know it's there 20:23:57 all I'm getting at is, I've watched new developers try to do stuff. The more tools like this they have to learn before they can do work 20:24:03 the less work they do. 20:24:16 the *biggest* positive is also that it makes upgrading packages like jquery much simpler than what we do now 20:24:17 and the more frustrating it is to contribute 20:24:44 wizzyrea: bower is definitely a de-frustrator 20:25:07 ¯\_(ツ)_/¯ 20:25:11 I think owen's opinion or others is necessary, move on? 20:25:11 if you install a library that requires another library, it gets installed automatically 20:25:21 yep onward 20:25:49 ok, can we say that owens decision stands? 20:25:52 I'm fine with that 20:26:06 wizzyrea's point should be well understood, but I am an outlier for avoiding JavaScript as much as I can myself and running noscript. 20:26:17 i am okay with that, but others may have mroe to add 20:26:33 agreed, should wait for more devs to have some input 20:26:44 works for me 20:26:49 #topic REST api 20:26:59 #info Vote: PATCH implementation. Proposal to implement JSON-merge (https://tools.ietf.org/html/rfc7386) as a start. Then implement JSON-patch (http://jsonpatch.com/ https://tools.ietf.org/html/rfc6902). This could be done in two steps taking advantage of Content/Type application/json-patch+json to choose between implementations). 20:27:13 I don't knwo who added this, assuming tomas? 20:27:17 tcohen? 20:27:17 tcohen is obsessed with packages' scripts 20:28:19 #info Lee Jamison, Marywood University 20:28:29 I am gonna say table unless someone can champion this 20:29:08 #info waiting for next meeting and tomas to explain 20:29:09 we needs it 20:29:12 What would be the alternative? 20:29:22 there is no alternative 20:29:30 generally I am for whatever tomas needs for rest 20:29:33 we don't support partial updates in the REST api without PATCH 20:30:24 the alternative is to never allow partial updates and always require the full copy of whatever to put used with PUT 20:30:58 Consequently, this is a mere formality about specifying an unavoidable standard. Do I understand correctly? 20:31:04 for example, if you want to change a persons surname, with PATCH you just send the surname 20:31:10 bascially yes thd 20:31:20 Anybody know where i can find the code behind Email::Valid->address( ) ? I've seen this like in C4/Letters.pm, and Koha/Email.pm seems empty. 20:31:31 notarock: in a minute, it's meeting time :) 20:32:43 I'd propose a vote so tomas can get back to work ; ) 20:33:04 Unless there is some objection we few should vote on the formality. 20:33:55 #vote Shall we implement PATCH using JSON-merge and JSON-patch as described in the agenda? Yes, No, Abstain 20:34:01 #startvote Shall we implement PATCH using JSON-merge and JSON-patch as described in the agenda? Yes, No, Abstain 20:34:01 Begin voting on: Shall we implement PATCH using JSON-merge and JSON-patch as described in the agenda? Valid vote options are Yes, No, Abstain. 20:34:01 Vote using '#vote OPTION'. Only your last vote counts. 20:34:03 Yes 20:34:13 voet yes 20:34:16 vote yes 20:34:21 #vote yes 20:34:30 do it like that ^ 20:34:31 #vote Yes 20:34:51 #vote Yes 20:35:32 #vote Yes 20:35:55 abstain, no opinion. 20:36:47 #vote abstain 20:37:12 last call 20:37:23 #vote abstain 20:38:01 #endvote 20:38:01 Voted on "Shall we implement PATCH using JSON-merge and JSON-patch as described in the agenda?" Results are 20:38:01 Yes (3): kidclamp, thd, khall 20:38:01 Abstain (2): wizzyrea, aleisha 20:38:32 #topic Bug 20086 20:38:32 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20086 major, P5 - low, ---, koha-bugs, NEW , AddRenewal is not executed as a transaction and can results in partial success and doubled fines 20:38:41 I just bring this up for opinions 20:39:07 we have an issue in that if AddRenewal fails partially we are generating doubled fines for patrons 20:39:26 it would be good to use more transactions for things like this, however, it may cause unforeseen issues 20:40:02 with patches there all tests pass, but I think we need more eyes/inputs on how we shold correctly implement multipart updates 20:40:42 * kidclamp has opened the can of worms, that is all 20:40:59 kidclamp: What qualifies as a multipart update? 20:41:32 so for instance - in a renewal we close the fine, then we update the issue, then we update the stats 20:41:34 thd: any time a subroutine updates multiple tables 20:41:40 anytime that one action depends on another 20:43:31 #topic Review of coding guidelines 20:43:47 #info Stop using "type" attribute on