20:00:23 <kidclamp> #startmeeting Development IRC meeting 24 January 2018
20:00:23 <huginn> 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 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:23 <huginn> The meeting name has been set to 'development_irc_meeting_24_january_2018'
20:00:33 <kidclamp> #Topic Introductions
20:00:34 <wahanui> #info wahanui, a bot that has become sentient
20:00:43 <kidclamp> #info Nick Clemens, byWater Solutions
20:00:48 <wizzyrea> #info liz rea, Catalyst IT
20:00:55 <aleisha> #info Aleisha Amohia, Catalyst IT
20:01:20 <kidclamp> hi catalyst!
20:02:29 <khall> #info Kyle M Hall, ByWater Solutions
20:03:33 <kidclamp> hmm..small crowd - forge ahead or reschedule? we can wait a bit too
20:03:54 <thd> how many of us are there now?
20:04:10 <kidclamp> with you 5
20:04:59 <thd> 5 is not terrible
20:05:09 <kidclamp> I just odn't know if there are people too represent the topics in the agenda
20:05:27 <kidclamp> forging ahead :-)
20:05:27 <thd> I was just going to raise that.
20:05:39 <kidclamp> #Topic Announcements
20:05:44 <kidclamp> floor is open
20:06:13 <wizzyrea> nice work on the "don't store bugzilla passwords in the clear" A+
20:06:36 <thd> #info Thomas Dukleth, Agogme, New York City
20:06:38 <kidclamp> yes, +1
20:07:02 <wizzyrea> Aleisha did you have any comments from academy week, good or bad?
20:07:13 <kidclamp> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_24_January_2018 Agenda
20:07:32 <kidclamp> #info kudos for work on not storing BZ passwords in plain text
20:08:43 <wizzyrea> i guess on to 18.05 stuff?
20:09:01 <kidclamp> #topic Update from the Release manager (18.05)
20:09:22 <kidclamp> Joubu is not here - I think he wants more QA and offers free hugs
20:09:47 <aleisha> oops sorry, Academy was awesome and the community was a huge help
20:09:52 <wizzyrea> hugs for patches, seems fair trade
20:10:00 <kidclamp> #info Joubu could not make meeting, no updates
20:10:10 <kidclamp> #topic Updates from the Release Maintainers
20:10:28 <kidclamp> #info Academy was awesome and the community was a huge help
20:10:45 <kidclamp> #info 17.11.02 and 17.05.08 released today
20:10:51 <kidclamp> that's the big news
20:10:59 <wizzyrea> \o/
20:11:27 <kidclamp> #topic Updates from the QA team
20:11:41 <kidclamp> just working where I can
20:12:05 <kidclamp> #info every day rhymes with QA day: e.g. Monday is QA day, Tuesday is QA day....
20:12:27 <kidclamp> QA Monday, QA Tuesday etc. if you prefer
20:12:39 <kidclamp> #topic General development discussion (trends, ideas, ...)
20:12:59 <kidclamp> Bug 17241
20:12:59 <huginn> 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 <kidclamp> khall?
20:13:06 <wahanui> khall is volunteering to come over and fix it for you, it seems. ;)
20:13:40 <khall> ah yes
20:14:02 <khall> so, the question is basically: should we use bower for our web dependencies?
20:14:38 <kidclamp> I think we maybe need marcel and other with opinions?
20:14:39 <khall> just looking for a general yay or nay
20:14:45 <khall> or we can just make owen decide
20:14:46 <khall> ; )
20:14:51 <thd> ;)
20:15:03 <kidclamp> okay to table to next meeting?
20:15:11 <kidclamp> unless there are comments?>
20:15:12 <wizzyrea> i'm a general nay because every time we add on stuff like this it makes it harder to onboard developers.
20:15:20 <khall> 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 <wizzyrea> but I recognise that might not be the best reason.
20:15:34 <thd> wizzyrea++
20:15:38 <khall> wizzyrea: it actually makes things easier.
20:15:52 <wizzyrea> well, actually, it doesn't.
20:16:03 <khall> 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 <wizzyrea> ¯\_(ツ)_/¯ i'm happy to disagree with you
20:16:23 <khall> can you explain your thoughts wizzyrea ?
20:16:57 <wizzyrea> every time you add a new manager, when someone is a new dev, and they want to do work
20:17:00 <wizzyrea> it's another barrier.
20:17:07 <wizzyrea> I don't like that.
20:17:11 <wizzyrea> but
20:17:33 <wizzyrea> that may not be a good enough reason to not do it.
20:17:34 <khall> wizzyrea: do you have experience with bower?
20:17:43 <khall> have you had trouble using it in the past?
20:17:48 <thd> khall: Would you adress the learning curve?
20:18:08 <khall> thd there is no learning curve, seriously
20:18:41 <khall> 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 <wizzyrea> 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 <kidclamp> 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 <thd> wizzyrea: If implementation is trivial and khall writes a one line tutorial for the wiki then I will be for it. :)
20:19:23 <kidclamp> I think that is what cait asked for too
20:19:34 <khall> we can do that
20:19:40 <khall> here it is: bower install <package>
20:19:42 <wizzyrea> ^ this is fine, but we often end up not getting that
20:19:51 <khall> as in: bower install jquery
20:20:17 <khall> I'd be happy to write a companion wiki page for bug 17241
20:20:17 <huginn> 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 <khall> assuming it gets pushed
20:21:29 <khall> 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 <wizzyrea> ¯\_(ツ)_/¯ I can see you feel strongly about it. I really dont.
20:22:40 <aleisha> 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 <kidclamp> as long as the process is understandable I am generally for it
20:23:24 <khall> lol, thanks wizzyrea ; )
20:23:55 <khall> unless a dev is adding a new dependency, they'll never even know it's there
20:23:57 <wizzyrea> 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 <wizzyrea> the less work they do.
20:24:16 <khall> the *biggest* positive is also that it makes upgrading packages like jquery much simpler than what we do now
20:24:17 <wizzyrea> and the more frustrating it is to contribute
20:24:44 <khall> wizzyrea: bower is definitely a de-frustrator
20:25:07 <wizzyrea> ¯\_(ツ)_/¯
20:25:11 <kidclamp> I think owen's opinion or others is necessary, move on?
20:25:11 <khall> if you install a library that requires another library, it gets installed automatically
20:25:21 <wizzyrea> yep onward
20:25:49 <khall> ok, can we say that owens decision stands?
20:25:52 <khall> I'm fine with that
20:26:06 <thd> 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 <kidclamp> i am okay with that, but others may have mroe to add
20:26:33 <aleisha> agreed, should wait for more devs to have some input
20:26:44 <khall> works for me
20:26:49 <kidclamp> #topic REST api
20:26:59 <kidclamp> #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 <kidclamp> I don't knwo who added this, assuming tomas?
20:27:17 <kidclamp> tcohen?
20:27:17 <wahanui> tcohen is obsessed with packages' scripts
20:28:19 <LeeJ> #info Lee Jamison, Marywood University
20:28:29 <kidclamp> I am gonna say table unless someone can champion this
20:29:08 <kidclamp> #info waiting for next meeting and tomas to explain
20:29:09 <khall> we needs it
20:29:12 <thd> What would be the alternative?
20:29:22 <khall> there is no alternative
20:29:30 <kidclamp> generally I am for whatever tomas needs for rest
20:29:33 <khall> we don't support partial updates in the REST api without PATCH
20:30:24 <khall> the alternative is to never allow partial updates and always require the full copy of whatever to put used with PUT
20:30:58 <thd> Consequently, this is a mere formality about specifying an unavoidable standard.  Do I understand correctly?
20:31:04 <khall> for example, if you want to change a persons surname, with PATCH you just send the surname
20:31:10 <khall> bascially yes thd
20:31:20 <notarock> 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 <wizzyrea> notarock: in a minute, it's meeting time :)
20:32:43 <khall> I'd propose a vote so tomas can get back to work ; )
20:33:04 <thd> Unless there is some objection we few should vote on the formality.
20:33:55 <kidclamp> #vote Shall we implement PATCH  using JSON-merge and JSON-patch as described in the agenda? Yes, No, Abstain
20:34:01 <kidclamp> #startvote Shall we implement PATCH  using JSON-merge and JSON-patch as described in the agenda? Yes, No, Abstain
20:34:01 <huginn> 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 <huginn> Vote using '#vote OPTION'. Only your last vote counts.
20:34:03 <kidclamp> Yes
20:34:13 <kidclamp> voet yes
20:34:16 <kidclamp> vote yes
20:34:21 <kidclamp> #vote yes
20:34:30 <kidclamp> do it like that ^
20:34:31 <thd> #vote Yes
20:34:51 <kidclamp> #vote Yes
20:35:32 <khall> #vote Yes
20:35:55 <wizzyrea> abstain, no opinion.
20:36:47 <wizzyrea> #vote abstain
20:37:12 <kidclamp> last call
20:37:23 <aleisha> #vote abstain
20:38:01 <kidclamp> #endvote
20:38:01 <huginn> Voted on "Shall we implement PATCH  using JSON-merge and JSON-patch as described in the agenda?" Results are
20:38:01 <huginn> Yes (3): kidclamp, thd, khall
20:38:01 <huginn> Abstain (2): wizzyrea, aleisha
20:38:32 <kidclamp> #topic Bug 20086
20:38:32 <huginn> 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 <kidclamp> I just bring this up for opinions
20:39:07 <kidclamp> we have an issue in that if AddRenewal fails partially we are generating doubled fines for patrons
20:39:26 <kidclamp> it would be good to use more transactions for things like this, however, it may cause unforeseen issues
20:40:02 <kidclamp> 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 <thd> kidclamp: What qualifies as a multipart update?
20:41:32 <kidclamp> so for instance - in a renewal we close the fine, then we update the issue, then we update the stats
20:41:34 <khall> thd: any time a subroutine updates multiple tables
20:41:40 <kidclamp> anytime that one action depends on another
20:43:31 <kidclamp> #topic Review of coding guidelines
20:43:47 <kidclamp> #info Stop using "type" attribute on <script> and <style> tags. See Bug 20053 and Bug 20054
20:43:47 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20053 normal, P5 - low, ---, indradg, Signed Off , Drop type attribute "text/javascript" for <script> elements used in OPAC templates
20:43:48 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20054 normal, P5 - low, ---, oleonard, Signed Off , Remove attribute "text/css" for <style> element used in the OPAC templates
20:44:06 <thd> The issue seems to be that if one part of the multipart update fails we may need to roll back the others wich succeeded.  Do I understand correctly?
20:44:12 <kidclamp> yes thd
20:46:06 <kidclamp> I think this one makes sense, but needs to be written as a guidleine
20:46:33 * LeeJ nods
20:46:46 <kidclamp> #action indradg please write up a guideline for submission for removing 'type' attributes
20:47:01 <kidclamp> #info New rule Coding_Guidelines#SQL12: Booleans (DRAFT)
20:47:31 <kidclamp> Thi smakes sense to me, standardizing is always noce
20:47:39 <kidclamp> any discussion?
20:48:20 <LeeJ> kidclamp: if removing type resolves multiple bugs then it stands to reason the same situation would re-appear in the future
20:48:39 <LeeJ> so I agree it makes sense to standardize the practice in favor of removing it
20:49:04 <kidclamp> oh, I meant for the next topic :-) I think the type thing is good, just needs to be written up
20:49:27 <LeeJ> :P
20:50:14 <kidclamp> #startvote Should we adopt SQL12 as drafted in the coding guidelines? Yes, No, Abstain
20:50:14 <huginn> Begin voting on: Should we adopt SQL12 as drafted in the coding guidelines? Valid vote options are Yes, No, Abstain.
20:50:14 <huginn> Vote using '#vote OPTION'. Only your last vote counts.
20:50:20 <kidclamp> #vote Yes
20:51:04 <wizzyrea> #vote yes
20:52:58 <LeeJ> #vote Yes
20:53:05 <kidclamp> last call
20:53:37 <thd> #vote Yes
20:53:48 <kidclamp> #endvote
20:53:48 <huginn> Voted on "Should we adopt SQL12 as drafted in the coding guidelines?" Results are
20:53:48 <huginn> Yes (4): kidclamp, wizzyrea, LeeJ, thd
20:55:05 <kidclamp> #action tomas please finalize SQL12
20:55:12 <kidclamp> #Topic Set time of next meeting
20:55:51 <kidclamp> two weeks out would be february 7th
20:56:11 <kidclamp> but is alos gneeral meeting
20:56:42 <kidclamp> so I suggest 2018-02-14 13 UTC?
20:58:21 <kidclamp> #info Next meeting: 14 February 2018, 13 UTC
20:58:25 <kidclamp> #endmeeting