15:01:08 #startmeeting Development IRC meeting 4 November 2020 15:01:08 Meeting started Wed Nov 4 15:01:08 2020 UTC. The chair is Joubu. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:08 The meeting name has been set to 'development_irc_meeting_4_november_2020' 15:01:17 #topic Introductions 15:01:26 #info Jonathan Druart 15:01:28 qa_team? 15:01:28 somebody said qa_team was cait Joubu marcelr kohaputti josef_moravec tcohen kidclamp khall ashimema alex_a jajm matts 15:01:29 rmaints? 15:01:29 somebody said rmaints was lukeG, aleisha, and tuxayo, I SUMMON THEE!!⚡⚡ 15:01:44 #link https://wiki.koha-community.org/wiki/General_IRC_meeting_4_November_2020 15:01:48 * tuxayo emerges 15:01:49 \o/ 15:02:17 #info tuxayo/Victor Grousset, France 15:02:53 #info Agustin Moyano, Theke Solutions 15:03:20 #info Owen Leonard, Athens County Public Libraries, Ohio, The Bad Place 15:03:33 LOL 15:03:37 hehe 15:03:46 #info Tomas Cohen Arazi, Theke Solutions 15:04:10 oleonard++ # keeping it up 15:04:46 #info Martin Renvoize, PTFS Europe 15:04:47 #info Thomas Dukleth, Agogme, New York City 15:04:48 made it.. just 15:04:59 #topic Announcements 15:05:03 Anyone have something? 15:05:41 #info Election of 21.05 release team is "tonight"! 20 UTC 15:05:58 Finally an election I can enjoy 15:06:05 #info Katrin Fischer, BSZ, Konstanz 15:06:21 :) 15:06:42 #info Lucas Gass, ByWater Solutions 15:06:56 #topic Update from the Release Manager (20.11) 15:06:58 Job offer: Release Maintainer for Koha. Salary: a lot of magical internet points 15:07:12 One candidate is needed 15:07:13 back from vacation, lot of things has been PQAed, great job QA team! 15:07:22 what brach is missing a candidate? 15:07:29 at least those who QAed ;) 15:07:34 2 15:07:44 20.05 and 19.11 15:07:44 39.16 15:08:02 Patience, wahanui 15:08:02 rumour has it Patience is a virtue.. some of the updates are slow be nessecity 15:08:04 oldstable (20.05) 15:08:05 tuxayo has been great on oldoldstable 15:08:15 everybody should run master anyway 15:08:21 +1 15:08:46 19.11: I candated, unless aleisha wants to continue it 15:08:55 we should ping someone at Catalyst 15:08:55 *candidated 15:09:03 to know if they want to continue 15:09:05 I volunteer for 20.05 15:09:08 what about lukeG? 15:09:16 tcohen++ 15:10:01 Joubu: I would like to have a break from Rmaint, I've done 4 cycles now 15:10:01 I would prefer to give new members the chance 15:10:07 I can back you up if you want to share at all tcohen.. can't commit full time but happy to share the load 15:10:13 yeah.. would be nice to have new blood though. 15:10:15 hehe lukeG, yes, fair enough! 15:10:17 cool 15:10:22 ashimema++ 15:10:28 I will sign for 20.05 15:11:05 tcohen++ 15:11:06 kidclamp: ES topic expert? 15:11:20 matts: CAS/Shib topic expert? 15:11:44 then we are good, great team once again 15:11:46 I would say those ones are 'nice to have', not as vital though.. 15:12:12 :) 15:12:16 Joubu, okay for me ! 15:12:21 so, I was saying, lot of things have been PQA, I am processing them all and hopefully will be "done" (pushed or not) before end of the week 15:12:46 no new enhancement will be pushed after this week 15:13:04 I hope we will manage to fix all the bugs next week! 15:13:08 i expect quite a bit of conflicts 15:13:11 and maybe needed follow-ups 15:13:21 is there some room we could give devs there? 15:13:37 Then, please add the release notes to your bugs. I will add the bz tags next week 15:13:57 We will also need to generate the technical release notes. I will ask you for help about that as well 15:14:17 next is the packages, we must continue the discussion we had on the dev list 2 weeks ago 15:14:36 tcohen: there is a term for people accumulating roles :) 15:15:05 he 15:15:07 cait: it will depend on the size of the patch set. I am pushing a lot of things and I am afraid of the time we will need to stabilize all that 15:15:17 some of the bigger stuff is currently sitting 15:15:25 I aim to lend a hand on release notes and swatting bugs the next few weeks.. at least a couple of hours a day 15:15:36 sending ILL emails for example 15:15:56 I am spending 90% of my work time on the PQA bugs 15:16:03 cannot do more 15:16:49 I am doing my best to give everybody the necessary feedback to have their bugs pushed to master ASAP 15:16:56 Joubu++ 15:16:58 any questions? 15:16:59 Joubu++ You're doing great.. it was a BIG queue 15:17:00 cait I don't like doing it, actually 15:17:07 Joubu++ 15:17:09 i know, i was just wondering if there might be a way to add a little room/time as i thnk it will be a close call 15:17:10 Project Koha_Master_U2010 build #39: STILL UNSTABLE in 45 min: https://jenkins.koha-community.org/job/Koha_Master_U2010/39/ 15:17:38 cait: yes, it won't be strict for the things PQA already 15:17:41 sorry, if that came out wrong 15:18:04 nope :) 15:18:14 #topic Updates from the Release Maintainers 15:18:20 maybe have people check their stuff for rebasing 15:18:26 could help remove some extra work/time lost 15:19:04 #info 19.05: last security release was without issue 15:19:05 #info If you have PQA bugs that have been FQA or needs a rebase, provide feedback ASAP to have them reach 20.11! 15:20:17 ho, I forget, D11 is completely broken, see bug 26893, must not be used! 15:20:17 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26893 blocker, P5 - low, ---, koha-bugs, NEW , New version of JSON::Validator (D11) break our REST API routes 15:20:47 #info Koha under Debian 11 is broken, it must not be used until bug 26893 is fixed! 15:20:54 we need this fixed for 20.11 15:21:25 #topic Updates from the QA team 15:21:38 #info about RMaint I did a first pass on the release maintenance wiki page to complete and fix the security process. Needs a second one and proofreading from aleisha and lukeG 15:22:09 tuxayo: i'll have a look later today 15:22:36 lukeG: thanks, I'll try also to do the 2nd pass 15:22:49 cait: something to add for the QA team topic? 15:22:58 yes 15:23:29 I am close to 1.000 QA in one year and it's not a reason for celebration 15:23:34 I can't keep this up 15:23:38 :o 15:23:48 and I need everyone on the QA team signing up to step up some more next cycle 15:23:58 cait++ 15:24:00 at the moment the load is mostly on ashimema and me 15:24:01 team-- 15:24:03 ashimema++ 15:24:06 and we need to fix that 15:24:29 I agree.. we need to spread the load more next release.. it's unsustainable as it is. 15:25:03 I know queue looks good right now, but as soon as 2 people step off for a day or 2 numbers are rising really fast 15:25:37 cait: do you get feedback when you ask for in your weekly email? 15:25:50 most of the time I don't 15:26:14 I think that's the mail problem. People should show up when we need them 15:26:22 i will still keep sending htem as i got positive feedback in general 15:26:40 I read the weekly mails and try to attack those as a high priority.. but often I find I'm locked out of at least some of them 15:26:47 it#s very time consuming to ask individual members to do things 15:26:55 I find the qa emails really helpful personally 15:26:59 i know it's human... and that it works 15:27:41 so maybe we need new ideas 15:28:13 best solution would be more time and people 15:28:32 perhaps we could mentor some new QA people? 15:29:08 I was just writing that I'm feeling conformable to try QA now ^^ 15:29:08 I would be interested in helping/learning 15:29:09 if there's anyone out there at all interested in doing QA.. or anyone anyone here thinks might be good at QA then feel free to apply and I'd be happy to guide on the process/mentor people 15:29:10 The best solution for most things is more available time. 15:29:10 we have 2 new members for 21.05 15:29:12 which is good 15:29:28 agreed 15:29:40 yes, but we started out quite well number wise this cycle, it's hard to predict 15:29:48 I am fine if people don't have many hours to spend 15:29:48 alex_a: not candidate to be a QA member for 21.05? 15:30:01 but having some idea when they are available and some kind of consistency would be great 15:30:02 also.. the QA queue is often full of easy starter bugs.. one's that don't take hours.. you can be on the QA team and be picky about what you choose to QA.. it's a good way to start 15:30:15 for sure 15:30:20 and it free's up other QA team members to look at some of the more narly and difficult to QA patches 15:30:25 * cait recommends oleonard's for starters 15:30:28 :) 15:30:30 ashimema: alright, sound good for me :) 15:30:35 I'd love to see someone nick all the easy patches and overtake me on the leaderboards ;P 15:30:38 to be honest, the main problem right now is the NSO queue.. 15:30:50 we have a general flow issue 15:30:51 That is also true 15:31:21 I ran a youtube 'live coding' session just before this meeting.. first half was about how to pick bugs to SO and then how to SO them using sandboxes.. 15:31:21 and a lot of the thigs gettings stuck are stuck because they are not easy to test for people with sandboxes or require dev knowledge 15:31:37 so a good topic for dev meeting - we need devs on this queue too 15:31:39 I'd be happy to run similar things regularly if it would help onboard people 15:32:08 since I won't be Rmaint'ing I hope to dedicate much more time to NSO 15:32:13 I hope this doesn't come off as too negative, but if we don't talk about... we can't change it 15:32:30 lukeG++ 15:32:42 totally a worthwhile thing to discuss cait 15:33:16 lukeG: sounds great :) 15:33:22 as for sandboxes (* OK, they're broken right now but I'm working on that).. if there's something you can't test on them yet let me know and I can work on that 15:33:36 mail testing does work for example.. that's a recent addition 15:33:43 but perhaps we need to guide people on how 15:33:52 I don't know if it is really problem that stuff is stuck in NSO queue, if things are important to more than just person then people will sign-off, not every feature needs to get in my opinion, and giving feedback on all features suggested always might not be time well spent 15:34:24 kohaputti: maybe true for a part of the queue, but there are also bug fixes and things that just aren't easy to test 15:34:38 kohaputti: I agree, but having the queue "clean" makes things easier to pick 15:34:49 yeah, I beleive that too 15:34:55 a not so daunting queue will be more inviting 15:35:18 ashimema: «I ran a youtube 'live coding' session» Do you mean you recorded it for publication? 15:35:32 I would hope bugwranglers can help with keeping the queue clean.. a certain amount of that role is not to test, but to just take a look at the bugs and comment on whether they're valid, a good idea, need more thought etc 15:35:41 yup 15:36:12 https://www.youtube.com/watch?v=0Q0KrFv_YnU 15:36:22 we need to edit it a little still.. but it's there 15:36:44 just need to cut off the first 5 minutes of us getting ourselves set up 15:36:44 #info QA team - The project is having a long standing issue about the QA queue. We should have more people involved in the process. It will especially help if you are kind of expert in a given area, let us know! 15:36:48 something like that..? 15:36:53 +1 15:37:01 ashimema++ will watch, might learn a few things :D 15:37:47 all very informal.. but hopefully that also means it's a bit less scary for people.. shows we're all human 15:38:20 brill Joubu 15:38:25 so basically, I have nothing to suggest, cait, sorry. But hopefully amoyano and dcook will bring some fresh air :) 15:38:35 ashimema: I liked all the deliberate mistakes :) 15:38:43 # #action amoyano QA all the things! 15:38:50 thx 15:38:51 haha.. only one was actually deliberate ;) 15:38:54 # #action dcook QA all the things! 15:38:56 he, I'll try 15:39:03 the others were me being human 15:39:07 ashimema: it looked planned to me .) 15:39:26 moving on? 15:39:36 ok 15:39:39 :) 15:39:44 #topic Actions from last meeting 15:39:52 #topic amoyano Will try to provide a Vue alternative to bug 15522 15:39:52 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 enhancement, P5 - low, ---, jonathan.druart, Patch doesn't apply , New interface for revamped circulation rules 15:39:57 you did it! 15:40:02 amoyano++ 15:40:04 yep! 15:40:04 amoyano++ 15:40:12 amoyano++ 15:40:14 amoyano++ 15:40:15 amoyano: can you tell us something about it? 15:40:29 What's the next step? Should we ask the list for feedback? 15:40:59 If you checked it out, it's not exactly a copy of the proposal made with react 15:41:06 * ashimema is testing it.. but it's slightly behind keeping on top of the bugs bug queue at the moment.. and rebasing code for Joubu... I hope to do allot more testing and review first thing next cycle 15:41:22 there's a UX change 15:41:29 so.. thanks for submitting amoyano.. apologies I've not fed back yet 15:41:31 sorry if that mess things up, but I though it was a good time to introduce that change 15:42:10 amoyano: that's relevant no worries 15:42:25 I believe it's simple to read.. 15:42:33 #info amoyano wrote an alternative for the new circulation rules interface - code is available on bug 15522 15:42:38 so.. next step I think is to probably wait a couple of weeks (whilst we're all super busy with release), then go on a drive to find testers.. thinking mailing list, pre-setup sandboxes etc 15:42:43 vue packages modules in a single file, (.vue files) 15:42:57 #info feedback is needed on the code and UX changes 15:43:14 code does look clean to me.. in what I have managed to read so far 15:44:11 #action amoyano advertise 15522 and ask the list for feedback [after 20.11 is released], setup a sandbox, etc. 15:44:45 I'll have to watch achimema's video to setup a sandbox, he! 15:45:25 amoyano: nope, you will need to catch him to set it up for you and have it "eternal" 15:45:31 or it will be erase after X days 15:45:33 haha.. I can help with that.. it may be one of those bugs that needs a little more behind the scenes to get it working on a sandbox 15:45:35 d 15:45:45 indeed 15:45:48 next topic was about the same things 15:45:54 #topic ashimema Setup a sandbox with lot of circ rules (ideally from production data) to test 15522. Then ask the list for feedback. 15:46:01 so skipping this one 15:46:06 I did.. then I broke the sandboxes :( 15:46:15 so I'm back to square one and need to do it again 15:46:21 :o 15:46:21 but yes.. wait for next cycle now 15:46:21 I am postponing the 2 next ones, David is working on them 15:46:31 #action davidnind Find and update relevant places to record Perl version required, including release notes, manual and wiki (one source of the truth) (still working on this) 15:46:41 i thin having both versions testable (GUI wise) woudl be great 15:46:44 hum, only one actually 15:46:44 and advertise that 15:47:08 yes, definitelly, we may need to pick a bit of both 15:47:15 #topic davidnind to add information about what to backport to the release maintainers role page (as a starting point for further notes and guidance) (initial information added - see Release maintenance page) 15:47:24 #link https://wiki.koha-community.org/wiki/Release_maintenance#Deciding_on_what_to_back_port 15:48:25 davidnind++ this is great! 15:48:33 davidnind++ 15:48:38 good call 15:49:14 davidnind++ 15:49:27 #info davidnind wrote a wiki page to list the general principle for backporting - https://wiki.koha-community.org/wiki/Release_maintenance#Deciding_on_what_to_back_port 15:49:35 @later tell davidnind thanks David! 15:49:35 Joubu: The operation succeeded. 15:49:53 #topic ashimema to write a guideline to forbidding the use of type "number" 15:49:54 davidnind++ 15:49:57 #link https://wiki.koha-community.org/wiki/Coding_Guidelines#ACC2:_Input_type_.22number.22_should_be_avoided 15:49:58 done :) 15:50:02 yup 15:50:16 feel free to point out amendments if anyone wants to :) 15:50:25 but hopefully it's fairly clear and concise 15:50:46 ashimema++ 15:50:56 hm should we create an omnibus bug to check/fix codebase? 15:51:04 and we have the QA test: https://gitlab.com/koha-community/qa-test-tools/-/merge_requests/28 15:51:09 not a bad idea cait 15:51:11 so we can consider this done 15:51:14 thanks ashimema 15:51:15 ashimema++ 15:51:21 didn't knew about inputmode 15:51:23 lots of academy bug potential there 15:51:50 and lots of things i no longer will have to change locally :) 15:52:05 #info New coding guideline - Input type "number" is now forbidden, use inputmode=numeric instead. See https://wiki.koha-community.org/wiki/Coding_Guidelines#ACC2:_Input_type_.22number.22_should_be_avoided 15:52:21 I can take that action.. to create the omnibus bug 15:53:01 #action ashimema Open an omnibus bug to fix the existing occurrences of input type "number" 15:53:01 #action ashimema to add an omnibus bug to retroactively fix inputs for ACC2 coding guideline 15:53:04 :) 15:53:15 #topic General development discussion (trends, ideas, ...) 15:53:21 #topic Discuss Bug 20410, Remove OpacGroupResults system preference and feature -- oleonard 15:53:21 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20410 enhancement, P5 - low, ---, koha-bugs, NEW , Remove OpacGroupResults system preference and feature 15:53:41 So... Does anyone know if this feature is still used? 15:54:03 I haven't heard of a working implementation in quite a long while 15:54:15 and never seen a production one 15:54:29 do we have it on hea? 15:54:38 Every time the OPAC gets a big update I dutifully make a best effort to update opac-results-grouped.tt but I'd like to not do that anymore :) 15:54:44 yes, 9 occurrences for 1/yes 15:55:08 i thin we should announce deprecation 15:55:15 The 0 value means yes? :o 15:55:17 and remove in 21.05 15:55:26 there are 9 with 1 :) 15:55:59 oleonard: go for it! 15:56:26 #action oleonard ask the list if someone use OpacGroupResults somewhere... 15:56:40 I don't remember the last time we announced the deprecation of a feature. Does anyone? 15:56:51 zebra? 15:56:51 hmmm... zebra is running? 15:56:55 I did it once 15:56:55 (lol) 15:57:00 can't remember what 15:57:02 lol 15:57:07 we did it few time 15:57:15 non xslt view 15:57:16 ashimema, you deprecated some C4 function 15:57:23 maybe couple years ago 15:57:30 I wouldn't "ask if anyone is using it".. I would "Announce wwe intend to remove it" and then see if anyone complains ;) 15:57:41 yep 15:57:46 I suppose dead external services don't count? 15:58:16 we are reaching 1h, moving on 15:58:21 #topic Sign off and tests failing - question: Recently I've had several cases where the tests pass before and after the patches are applied. However, if system preferences are changed as part of the test plan and tests are run at the end then they fail. If the developer says this is fine (for whatever reason), should we accept that when signing off and then leave to QA to critique their work? Example (not 15:58:29 picking on this one in particular, it's the only one I can remember): Bug 22690. --davidnind 15:58:29 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22690 normal, P5 - low, ---, ere.maijala, Failed QA , Merging records with many items too slow (Elasticsearch) 15:58:36 I've used https://metacpan.org/pod/Mojo::Util#deprecated in a few places to deprecate routines 15:58:42 manualcredit was one I think 15:59:01 The short answer is "it depends" 15:59:45 ideally tests should pass in whichever situation 15:59:46 it's a hard call.. in the best case all unit tests should be idempotent and do all their own setup 16:00:09 and mock "everything". Like: if you need this specific pref to be set to have the test pass, then mock the pref's value 16:00:10 if I hit such a situation during QA I tend to have a go at fixing it 16:00:11 I'm under the impression if you remove like some default branches, etc. then maany tests will fail 16:00:17 exactly 16:00:28 correct kohaputti 16:00:29 but we use to accept tests if they pass on top of the sample data / default value 16:00:38 but for new tests it's important we try to be better ;) 16:00:53 > do all their own setup 16:00:53 Here, does is "just" mean that the test lacks setting the syspref in it's setup? 16:00:59 kohaputti: I don't think so, we took care of that 16:01:11 we do not longer use hardcoded data 16:01:17 like "branchcode=CPL" 16:01:40 ok 16:01:43 the problem is more about the default values IMO, and so the syspref 16:01:45 s 16:01:50 also things like counting rows before and after the test.. rather than hard coding a number of rows we expect from the test data 16:01:55 that's a pattern now 16:01:56 at least for new tests this might be a good idea 16:02:12 also: don't delete the data before the tests! 16:02:15 indeed... hense it being a judement call :) 16:02:19 but existing tests, I don't know, could be potentially many many hours of work to get some bug fix, etc. in 16:02:25 most of the time it's the wrong way :) 16:02:48 yup.. QA team use your judement a bit basically ;) 16:02:53 should we have some notes about good pattersn in unit testing writing somewhere? 16:02:55 it comes with practice 16:02:57 The current koha unit tests sound more like integration tests to me :D 16:03:05 if we intend to improve them, better make sure new people have some guidance 16:03:09 agree :( 16:03:19 kohaputti: yes, they are a bit of everything 16:03:24 well.. they're a real jumbled mix really 16:03:27 haha.. snap 16:04:03 ha but wait 16:04:15 Is David's question about searchengine? 16:04:19 yes it is 16:04:26 so 16:04:30 bug 26250 16:04:30 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26250 major, P5 - low, ---, jonathan.druart, Pushed to master , Test suite does not pass if Elastic is used as search engine 16:04:43 the test suite must pass with searchengine set to ES 16:05:13 We did not setup the new job on Jenkins already 16:05:21 (or make it the default) 16:05:45 ok but it doesn't, is it the job of the patch writer to fix it that touches some unrelated test in the same file that has the bug currently? 16:06:11 after 26250 the whole test suite must pass with ES set 16:06:15 if it's not, it's a bug 16:06:27 open a separate bug report and link it with 26250 16:06:59 talk about it later if needed, moving on 16:07:03 #topic Review of coding guidelines 16:07:16 #topic Proposal for uniform response code for duplicate errors on the API (vote) 16:07:30 tcohen: ? Is that you? 16:09:01 we cannot vote on that without someone explaining it 16:09:33 pity.. seemed interesting 16:09:41 "When a create operation fails due to duplicate object, it must return 409." 16:10:22 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409 16:10:25 hmm 16:10:27 The HTTP 409 Conflict response status code indicates a request conflict with current state of the target resource. 16:10:30 Conflicts are most likely to occur in response to a PUT request. For example, you may get a 409 response when uploading a file which is older than the one already on the server resulting in a version control conflict. 16:10:34 not exactly the same 16:11:37 well, if it's the code to return, let's return it 16:11:42 not sure we should vote for that 16:11:51 indeed 16:12:11 so more of a mention to make sure QA catch it 16:12:22 #topic Proposal for related object ids on the API (vote) 16:12:36 "Fields containing a key for a related object should be named related_id where related is the related object name and if called via embed should be replaced by just the related object name. " 16:13:08 and this one makes sense, go for it tcohen! 16:13:17 not sure that applies in every case 16:13:28 example? 16:13:51 if you've got more than one FK to another table you couldn't do it 16:14:15 yes 16:14:24 for instance suggestion, manager, suggester, etc. 16:14:30 but then it's manager_id, suggester_id 16:15:00 is then the rule wrong? 16:15:10 ok, then that's ok.. I thought it ment to place the _id 16:15:11 "related object name" is "patron" 16:15:31 I think it reads good 16:15:46 although it not always 'Object' name either 16:15:51 it's more the 'relation' name 16:15:56 In my understanding the suggestion.managed_by will become manager_id, not patron_id 16:16:13 so 'manager_id' and 'manager' is the relation name.. the final object is a Koha::Patron 16:16:14 yes, that's it 16:16:30 correct 16:16:31 can you update the guideline please? 16:16:34 that's my understanding too 16:16:39 yup 16:16:43 maybe with the example 16:16:53 great.. scratch from records everything I said, please :) 16:17:03 good catch amoyano 16:17:21 very good catch amoyano 16:17:25 hehe 16:17:30 thanks 16:17:36 it brings the guidline directly above into the mix to make sure they agree with each other 16:17:50 #topic Set time of next meeting 16:17:59 I think we agree on the approach so I'll update it to be clear 16:18:52 #info Next meeting: 18 November 2020, 15 UTC 16:19:05 don't forget a carrot cake for oleonard 16:19:17 and, peel the carrot, peel it hard 16:19:25 #endmeeting