14:00:16 #startmeeting Development IRC meeting 29 September 2021 14:00:16 Meeting started Wed Sep 29 14:00:16 2021 UTC. The chair is Joubu. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:16 The meeting name has been set to 'development_irc_meeting_29_september_2021' 14:00:26 #topic Introductions 14:00:42 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_29_September_2021 14:00:46 #info Jonathan Druart 14:00:53 #info Marcel de Rooy, Rijksmuseum, The Netherlands 14:01:36 #info Thomas Dukleth, Agogme, New York City 14:01:49 #info Martin Renvoize, PTFS Europe 14:02:13 #info Nick Clemens, ByWater Solutions 14:02:20 #info Victor Grousset, Tuxayo Global Services Inc., France 14:02:23 #info Henry Bolshaw, House of Lords Library, UK 14:03:09 #info Kyle M Hall, ByWater Solutions 14:03:20 #topic Announcements 14:03:27 Anyone have something? 14:04:00 not i 14:04:29 #topic Update from the Release Manager (21.11) 14:04:37 Back from a break, I will be around full speed until the release. 14:04:51 First, you must upgrade your Koha instances in production. Last releases contain important security bug fixes. 14:05:07 Then, devs should `docker pull` to pull the latest koha-testing-docker images. A new dependency has been pushed this morning. 14:05:14 A workaround is to install it via apt (libemail-address-perl). 14:05:39 About 21.11: 14:05:52 There is only one month left before the feature freeze, there is still some time for big things to get in but we need to speed up. 14:06:10 I would like devs to list their priorities for 21.11. We need to help each others and focus on helping everyone's priorities. 14:06:25 If you have things from the roadmap that need test or review, let me know and I will put them on top of my list. 14:06:42 +1 14:06:54 My priorities are flagged with the RM_priorities bugzilla keyword, and are still the same since the beginning of the release cycle (as very few have been pushed). 14:07:14 https://frama.link/koha_bz_RM_priority 14:07:27 Here is my top 5: 14:07:35 bug 28445 (additional work is stuck because of that one) 14:07:35 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28445 enhancement, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Use the task queue for the batch delete and update items tool 14:07:38 bug 27829 14:07:38 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27829 enhancement, P5 - low, ---, koha-bugs, NEW , [OMNIBUS] Remove specific LANG installer data 14:07:42 bug 3142, 14:07:42 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3142 normal, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Standardize how OPAC and staff determine requestability 14:07:47 bug 28413 14:07:47 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28413 enhancement, P5 - low, ---, jonathan.druart+koha, Signed Off , background job worker is running with all the modules in RAM 14:08:02 and the accessibility bugs (see bz kw 'accessibility', there are currently 6 waiting for SO). 14:08:15 I will send an email to koha-devel later this week about that. 14:08:38 Ha, and there is also the Flatpickr move. oleonard, do we have an omnibus for them? 14:09:03 https://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=Flatpickr&list_id=385606 14:09:06 should be that list 14:09:22 oleonard: Left a note that he would not be available for this meeting. 14:09:27 we need the move completed for 21.11 or we will have to maintain 2 plugins 14:09:37 thd: indeed 14:09:48 that's all for me, any questions? 14:10:53 Not a question but I will SO some of the accessibility bugs today or tomorrow 14:11:04 thanks! 14:11:20 #topic Updates from the Release Maintainers 14:11:20 flatpickr is near the top of my list 14:11:38 I've unblocked the hard one now and intend to QA the rest this afternoon :) 14:12:03 magnuse should reply to the normarc deletion patches 14:12:20 marcelr: he agreed to remove NORMARC support for 21.11 14:12:56 #info security release went out, thanks Joubu and mtj for the specific work there. 14:13:23 release_team++ 14:13:26 it was a tricky one 14:13:35 we identified some flaws in our workflow 14:13:40 Is flatpickr only on staff client? 14:13:48 for now 14:13:50 we should improve how we deal with security release to make things easier for everybody, it's on my list 14:14:24 it would be nice to see if a secu patch is on the move to being backported or just passed qa 14:14:48 marcelr: what would you suggest? A comment from the RM? 14:15:10 that might help already; now it is probably only a mail or so 14:16:04 the biggest of our problem is that we don't have CI for the security repo 14:16:34 indeed ^^ 14:16:49 we should also try and provide patches for older versions, but we also have troubles with the 4 we support 14:17:07 another idea would be to have a LTS version 14:17:25 I will be working on a proposal during the next month 14:17:35 moving on? 14:18:09 :) 14:18:25 #topic Updates from the QA team 14:18:58 70 / 15 = 4,5 ? 14:19:42 70/15 14:19:45 70/15? 14:19:45 4.66666666666667 14:19:48 almost 14:19:50 why 15? 14:19:59 o maybe 14 (qa team size) 14:20:07 70/13? 14:20:08 5.38461538461539 14:20:20 70 is the SO queue now 14:20:21 so yes, 6 each and we are done 14:21:23 something else? 14:21:42 bug 28883 14:21:42 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28883 normal, P5 - low, ---, tomascohen, In Discussion , Koha::Objects->_new_from_dbic doesn't work correctly in list context 14:21:58 we touch this discussion in other reports too 14:23:24 to me we should remove wantarray, it will make sense easier 14:23:37 and we won't need the scalar trick in the template anymore 14:24:01 yes we need people to be more aware of the danger of chaining methods in templates 14:24:03 but it seems that others prefer the reverse 14:24:57 > danger of chaining methods in templates 14:24:58 what are these dangers? 14:25:01 the low number of occurrences of scalar in .tt shows that we don't chain much 14:25:08 the reverse means that you need to put scalar everywhere in the templates 14:25:25 I've just found a case in the wild... 14:25:26 everywhere you chain :) 14:26:01 well, a case in which a dev thought _new_from_dbic honoured list context 14:26:03 it's not even using scalar, it's using it in a weird way. You have to split the calls, like you discovered it in one of the comments of the bug 14:26:08 tuxayo: have a look at the report 14:26:47 object.method1.method2 is in TT somethings else than in perl 14:27:28 TT is calling in list context, it's in the doc, nothing wrong :) 14:27:43 hmm i think that was a bad choice in TT 14:27:45 My opinion is that, currently, we don't have people available to work on such big tasks. 14:27:55 we do 14:28:02 both solutions are time consuming 14:28:21 i agree that it is hard to go that road now but we are somewhere in the middle 14:28:35 or on 0.25 ? 14:28:38 we have been in the middle for years, nothing new 14:28:45 lol 14:29:05 ok I see: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28883#c47 14:29:05 04Bug 28883: normal, P5 - low, ---, tomascohen, In Discussion , Koha::Objects->_new_from_dbic doesn't work correctly in list context 14:29:12 we need to move on, several topics left. But let's continue after the meeting or on the bug 14:29:45 #topic Actions from last meeting. 14:29:50 nothing here 14:29:59 #topic Informal feedback & highlights from koha-US conference 14:30:04 Who added that? 14:30:30 tuxayo: ? 14:30:53 was a bit dark there? 14:30:57 no highlights 14:31:02 LOL 14:31:17 oh it was me, in case someone who was there wanted to mention stuff to get other to check it out 14:31:30 (i didn't check if there was recordings) 14:31:55 kidclamp maybe? 14:32:25 https://koha-us.org/conference2021/#recordings 14:32:34 :D 14:32:45 everything is there 14:32:57 give us the highlights tuxayo :) 14:33:12 action tuxayo what the koha-us conference and write a summary 14:33:15 watch 14:33:21 I didn't attend sorry 14:33:24 lol 14:33:34 For some portion of everything perhaps :) 14:33:58 nope, if I want to get rid of some big stuff so I can get back to SO and QA 14:34:13 #topic Roles for 22.05 14:34:30 I will create the page and send the link to the list, right after the meeting 14:34:52 #topic General development discussion (trends, ideas, ...) 14:35:19 marcelr, tcohen: would like to continue the list/scalar context discussion now? 14:35:34 yes 14:35:36 not necessarily 14:35:47 #info Magnus Enger, Libriotech, Norway 14:35:47 trade offs 14:35:50 raising awareness 14:36:02 #info Tomás Cohen Arazi 14:36:24 I think it is one of those things that are worth, once sorted, things are clearer for devs 14:36:48 right now they will need to identify methods that rely on _new_from_dbic from those calling ->search 14:37:13 yeah but the templating side is no improvement 14:38:07 the scalar. builtin module didn't work, right? 14:38:14 lets build a wrapper around TT, haha 14:38:23 yes it needs stash 14:38:34 since we have a as_list method, I don't understand why we wouldn't help ourself having everything return an iterator, and let callers *explicitely* ask for a list when they need it 14:38:36 I'm not sure 14:38:49 I got condused between the options honestly 14:39:02 Joubu: that would mean changing the ->search behavior as well? 14:39:15 for consistency yes 14:39:17 yes, remove wantarray 14:39:19 that is a TT scalar plugin.. there is our own Scalar plugin and there is also TT::Stash::Context or something 14:39:23 from everywhere 14:39:50 maybe we should add sub hatearaay 14:39:53 hatearray 14:40:22 if we go that route, we should certainly think of raising an exception in list context 14:40:38 theoretically i would prefer the list context but the tt is a large drawback 14:40:45 ah no, that would break all templates, nm 14:41:51 you cannot return an array, because most of the time you want an iterator 14:42:03 you can get an array from an iterator (ofc not the reverse) 14:42:08 was there never any request for TT to use scalar context in chaining ? 14:42:25 it should not be that hard ?? 14:42:53 marcelr: Joubu solved it, in a non-elegant way, but technically solved it 14:43:10 https://metacpan.org/pod/Template::Stash::Context 14:44:31 One can always test for some data type and transform the data into whatever data type is expected when the data is returned in some unexpected type. 14:44:57 adding .scalar is not the solution i was thinking of ashimema 14:45:19 I like explicitly addinig .scalar 14:45:26 obejct.method1.method2 should mean method1 is scalar context 14:45:33 tcohen: Is there an elegant solution? 14:46:13 I would prefer a dotted chaining solution to Scalar( object, method ) 14:46:23 me too 14:46:35 tcohen .scalar is ugly too 14:46:38 frankly I just find it confusing that TT always calls in list context 14:46:43 yup 14:46:46 it didn't work when I tried 14:46:56 no you need stash module 14:47:18 and I guess that's why I wrote our own TT plugin 14:47:28 which works like a charm 14:47:37 but we cannot do that everywhere 14:47:42 no 14:47:53 remember that problem in an AR patch about the Biblio plugin ? 14:48:01 where do you need it? 14:48:02 charm is not my word haha 14:48:05 what's the root of the problem? 14:48:17 so far we have Context.Scalar called in 2 files 14:48:52 i wont change scope further .. 14:48:53 and they are include files (that's why it was ugly to have the code duplicated in the controller and easier to pass the orders iterator) 14:49:53 dbic has 'force scalar' for all relation accessors built in btw 14:49:58 that's how they get around it 14:50:01 Are there obtables the handle all the data preparation in the .pl files ? To not need logic in the .tt (other than loops and conditions on data immediately available, no dot calls) 14:50:19 there are _rs versions of every relation that dbic adds 14:50:26 tuxayo: yes, code duplication 14:50:27 but that would be a bit of a pain to add to koha objects 14:50:59 obtables ? 14:51:10 *obstacles 14:51:14 or only disallow chaining them ? 14:51:33 > code duplication 14:51:33 indeed,it can be tricky 14:51:42 but hard to parse probably 14:51:43 * tcohen is not that worried about code duplication 14:51:48 lol 14:51:49 I am 14:52:19 when we need info for the toolbars, we have code duplicated in all the controllers of the module (say acquisition) 14:52:30 that's why I am fighting 14:52:30 I prefer to calculate more things in the controllers, and wait for TT 10 to handle scalar context 14:52:31 haha 14:52:44 Joubu use a module haha 14:53:20 can you remind me the problem with explicitely call ->as_list when we need an array? 14:53:39 inconsistent behavior 14:53:40 as it solves the different problems we are having, what's the real problem with that? 14:53:52 not if you implement it everywhere and remove wantarray, as I am suggesting 14:54:13 you still need to track all the uses in list context 14:54:31 do our templates now also expect lists from ->items e.g. 14:54:36 yes, but a change in whatever direction will be painful 14:55:03 i know the answer already :) 14:55:53 both paths are painful 14:56:04 what is the biggest one ? 14:56:12 and the one Joubu proposes implies not needing todo weird stuff in all templates 14:56:30 and the other one feels more consistent with what we currently do in the codebase 14:56:35 what requires the most changes ? 14:56:50 I don't think it is a matter of how many 14:56:57 the biggest (but not the hardest) is to remove wantarray. Not too hard as you can identify them with the @ 14:57:08 tracking all templates is painful per-se 14:57:18 the templates are the problem 14:57:28 exactly, Joubu is right about that 14:57:52 Are there no occasions when we need an array or should need an array to properly represent the meaning of the data where multiple sub-elements are individually associated? 14:58:16 I maintain my position however, we don't have people available to work on that (at least now, 1 month before the ft freeze). 14:58:25 I don't see that as a high priority move 14:58:44 we leave with that for years, with 3 "problematic" occurrences in the codebase 14:58:53 s/sub-elements/data components/ 14:59:39 it means that anyone is doing the things his own way 15:00:29 It means that we can think about it during the next month. Investigate the different options, come with proposal, and discuss again later :D 15:00:36 we are kind of stuck anyway 15:00:37 sure 15:01:26 I don't think we can come with a vote/solution now 15:01:29 I agree, but then those bugs shouldn't block devs into master 15:01:40 why not using Scalar? 15:02:10 you will be stuck if you are waiting for one of the solution to be implemented 15:02:44 the advantage of scalaring a scalar 15:03:52 tcohen: there are no bugs linked with this bug 15:04:06 oh, did we remove them already 15:04:20 all bugs have been solved tcohen 15:04:58 #topic Set time of next meeting 15:05:16 #info Next meeting: 13 October 2021, 14 UTC 15:05:20 #endmeeting