13:04:01 #startmeeting Development IRC meeting 6 November 2019 13:04:01 Meeting started Wed Nov 6 13:04:01 2019 UTC. The chair is ashimema. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:04:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:04:01 The meeting name has been set to 'development_irc_meeting_6_november_2019' 13:04:03 My timezone is asleep. 13:04:22 #topic Introductions 13:04:26 #info Magnus Enger, Libriotech, Norway 13:04:36 #info Katrin Fischer, BSZ, Germany 13:04:38 #info Marcel de Rooy, Rijksmuseum. Netherlands 13:04:39 #info Martin Renvoize, PTFS Europe 13:04:56 #info Jonathan Druart 13:04:58 #info Thomas Dukleth, Agogme, New York City 13:05:18 #info Fridolin Somers, Biblibre, France 13:05:45 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_6_November_2019 Agenda 13:05:58 thanks cait.. I was just digging that one out :) 13:06:38 #topic Announcements 13:07:09 #info We have now been in Feature Slush for the 19.11 release for a week and will be progressing to Feature Freeze as of this evening (UK time) 13:08:13 #info Feature Freeze means we will only be considering bugfixes for the release past tonight, if you're enhancement isn't already pushed by the end of today it will not be pushed this cycle. 13:08:49 fridolin, did you want to update us on October releases here or as part of rmaint updates? 13:09:01 Binary data storage mode for Koha Wiki database migration from Postgres to MySQL now conquered for building the database structure. Debian old version time machine used. 13:09:30 Currently writing a perl script to run it all. 13:10:29 yep ashimema 13:10:34 #topic Updates from the release manager 13:10:49 oops.. 13:10:52 so you first 13:11:03 i'l tell in RMaint topic 13:11:16 #info The last few weeks the pace has picked up and allot has been pushed 13:11:53 #info I am concentrating on any last straggler enhancements untill the end of the day and then will switch fully to bugs only tomorrow. 13:11:59 #topic Update from the release maintainers 13:12:02 all yours ;) 13:12:26 because of having work load i could not find time to release in end Octobre 13:12:38 so its a bit to late 13:13:03 i will work on a big novembre release 13:13:14 so its well stable before 19.11 13:13:28 maybe its last release for 18.05.x 13:13:41 i noticed there are still quite a few bugs for 18.11 13:14:00 #info Work commitments for our stable branch rmaint have lead to no release during October. 13:14:15 cait: oki dont hesitate to mail Rmaint to list them 13:14:19 I've left notes where I backported fixes to our 18.11 branches 13:14:22 #info Focusing on a well polished November release now instead. 13:14:32 that#s the question - is it enough to leave comment/cc you on the bug or better to email? 13:14:46 have you used any form of keywords cait? 13:14:48 i'd say email is better 13:14:58 bug 23713 was an example 13:14:58 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23713 major, P5 - low, ---, oleonard, Pushed to master , Subscription add form broken for translations 13:15:07 or indeed if bugzilla search makes it 13:15:29 also, I've spotted a few bugs that should perhaps not have been backported recently.. more oldstable and oldoldstable than stable 13:15:33 i will look at all Major/blocker in priority 13:15:39 it's been in master for a month - I assumed you would go through the major ones 13:15:40 fridolin: a big last release could have bugs :) 13:15:55 last big* 13:16:28 fridolin: it's hard to tell where you stopped - I don't want to spam mail you :) 13:16:39 I don't think 18.05 (oldoldstable) will be an especially big release.. it's already pretty stable I believe 13:16:56 oh thought we were talking 19.05 13:17:33 frido is talking 19.05.. but I thought Joubu was talking 18.05 when highlights a fear for bugs in a last release 13:18:01 we speak about all (xxx)stable branches 13:18:38 19.05 wil still be continued Ithink, so just the last relase for frido? 13:18:48 we might all be confusing each other :) 13:18:55 yep for 18.05.x its up to the RMaint, i'd say "as stable as possible" last release ;) 13:18:59 yup 13:19:49 indeed id like to quit Rmaint for next cycle, to be able to focus on other points 13:20:53 speaking of which... we still need rmaints for 19.11 and 18.11 for next cycle 13:21:04 you've done an awesome job as rmaint these last years fridolin.. I'd personally like to thankyou for your support when I stepping in to learn the rmaint process before becoming rm :) 13:21:14 :) 13:21:18 fridolin++ 13:21:42 fridolin++ 13:21:49 oh thanks a lot, it was a pleasure to serve the community :D 13:22:04 << be my guest >> 13:22:09 #info fridolin will be stepping down from the rmaint roles come the 20.05 cycle. I wanted to thank him for his efforts as various rmaint roles the past years and personally thank him for his support onboarding me when I became an rmaint. 13:22:50 #info a big hole to fill, we still need volunteers for rmaint of 19.11 and 18.11 for the 20.05 cycle :) 13:22:55 for next cycle we are talking at biblibre to find someone for 18.11 13:23:13 :) 13:23:56 but if someone/some company could step into 19.11.x it whould be great to have fresh bloud 13:24:10 I worry about 19.11.. the stable rmaint role has it's own additional challenges.. it's good to have someone with a bit more experience in that position I feel 13:24:32 also needs to stay close to give the others time to catch up 13:24:38 I will happily support them of course, whoever it may end up being. 13:25:23 (close to what is pushed to master) 13:25:42 shall we move on.. 13:25:49 #topic Updates from the QA team 13:25:50 i think im ok 13:26:53 may i shortly mention the discussion about Objects->find in list context ? 13:27:02 sure 13:27:05 go ahead 13:27:06 fire away 13:27:23 no just mentioning it, go to the report if interested 13:27:35 maybe Joubu especially 13:27:48 because he added the croak for list context 13:28:14 can we get the bug number or an info? 13:28:17 and for hte logs :) 13:28:18 how about I add it as a topic in the next 'general discussion' section ;) 13:28:40 bug 19809 13:28:40 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19809 enhancement, P5 - low, ---, julian.maurice, Failed QA , Koha::Objects::find calls do not need to be forbidden in list context 13:28:40 Project Koha_Master_D8 build #517: STILL UNSTABLE in 29 min: https://jenkins.koha-community.org/job/Koha_Master_D8/517/ 13:29:08 #info Please take a look at the discussion on bug 19809 about use of Koha::Objects::find calls in list context 13:29:47 and what about the confusion on the check constraint ? sorry ashimema 13:30:19 the check constraints have just been outright removed entirely now 13:30:37 marcelr: answered few minutes ago 13:30:44 I have a topic in the next section to discuss sql etc 13:30:46 Joubu++ so fast 13:31:14 ok ashimema 13:31:14 ashimema is the benevolent dictator 13:31:18 any general qa updates cait? 13:32:33 a lot of the bad bugs have started moving... so that makes me happy, but it's like to see the number go down 13:32:46 if you search in bugzilla, we have logged 120 blocker, major and critical 13:33:13 the dashboard only lists the ones until filed 30 days ago... I'd really like to see people go thorugh those in the bug fixing period to come 13:33:36 maybe not all of them are major, but some triaging would certainly be good 13:34:02 I intend to do a bit of a triage run over the coming days 13:34:06 I can increase this number, but the idea was to increase little by little 13:34:12 yep, hasn't worked :) 13:34:18 but would greatly appreciate help.. that's allot of bugs ;) 13:34:21 not sure more on the dashboard will help, the numbers there have been high this release too 13:34:30 maybe clean up the queue first and see what we end up with 13:35:00 maybe something like: display all blockers and criticals, then display majors for the last 30 days 13:35:14 it's also often missed still the line is a link 13:35:16 maybe it should be green 13:35:16 #info Lots of 'Major' and 'Critical' bugs still in the queue, please focus on those 13:35:18 like the othe rlinks 13:35:24 or have a little arrow at the end 13:35:39 we are waiting for rangi to apply it in production 13:35:48 do we have Major inflation ? 13:35:49 PR has been merged 13:35:54 I did do a patch to make it green.. but when i looked at the code in detail it had deliberately been overriden back to black 13:36:05 Project Koha_Master_U18 build #455: STILL UNSTABLE in 35 min: https://jenkins.koha-community.org/job/Koha_Master_U18/455/ 13:36:11 I think perhaps class it as a button or something to make it clear it's clickable rather than a link 13:36:26 ha, I think it was merged! 13:36:40 the mouse curse changes when you move over it, but I tink people just don't get the idea they can 13:37:11 oops.. well there's still a !important css rule which overrides my css change which i didn't spot when testing locally 13:37:16 indeed 13:37:26 make it an #action? ;) 13:37:49 mouse curse 13:37:51 #info About 120 open bugs for major, critical and blocker on bugzilla - help in review appreciated 13:38:40 #action Update 'Overall bug tracker health' link on the dashboard to be more clearly a link 13:38:49 next topic 13:38:56 #topic General development discussion 13:39:10 #topic Dropping support for Debian Jessie 13:39:37 Right... D8 officially goes end of life come July 2020 13:39:50 but, we're already introducing things that break our support for Jessie 13:40:24 bug 22128 as an example.. it breaks our support already and has been backported a long way.. 13:40:24 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22128 normal, P5 - low, ---, rudolfbyker, RESOLVED FIXED, koha-remove fails mysql ERROR 1133 (42000) at line 2: Can't find any matching row in the user table 13:40:33 thats an implicit drop 13:41:53 I would like to propose that startig with the 20.05 cycle we drop development support for D8, but attampt to continue support in oldoldstable and oldstable (and stable.. any thoughts) untill the release of 20.05 at least 13:41:57 commit msg: "all users should have it by now" .. 13:42:13 then probably drop our support officially entirely at that point (although it should continue to function for a little while) 13:42:32 yeah. we missed the 5.5 beign default in D8 still 13:42:54 maybe we should be more clear about the associated sql versions 13:43:03 I would suggest reverting that bug in current oldoldstable and even oldstable.. 13:43:13 that was going to be my next point 13:43:43 mysql and mariadb are certainly diverging at an increased rate.. the check constraints handling raised that, but this bug also highlights it 13:44:14 The change should definitely be explicit rather than implicit. 13:44:15 I do not understand, you are suggesting to revert bug 22128 in 18.05 and 18.11? 13:44:18 currently we just say 'mariadb and mysql supported' (I actually don't know where we say that.. but that's generally the concensus I've got from people).. 13:44:34 debian moved to mariadb 13:44:35 and so drop support of debian stable for our oldstable branches? 13:44:42 but that lack of clarity leads to issues in support 13:45:08 well.. perhaps we need to write two code paths if we want to support D8 and D9 13:45:18 I dunno.. looking for peoples thoughts 13:45:35 it's 6 months in reality.. 13:45:37 a small patch could be rewritten for 5.5 ? 13:45:40 I would hope the majority of pople are on D9 already 13:46:36 we at Biblibre will to upgrades to D9 this summer, but we are really the late 13:46:46 we would need to identify the mysql/mariadb versions and then run a different sql syntax for each 13:46:49 i mean summer 2020 13:46:54 fridolin: D10 ? 13:46:54 somebody said D10 was certainly a work in progress.. 13:47:11 we've been in the process of upgrading all our customers for some time now.. not many left 13:47:15 wahanui: forget D10 13:47:15 Joubu: I forgot d10 13:47:24 D10 isn't well supported at all yet 13:47:31 yep 13:47:45 but we will try to anticipate this time 13:47:48 packages will not install without allot of manual intervention 13:48:04 our servers will go Bionic so its for outise servers 13:48:05 we have testing setup to run against it.. but whilst it doesn't even build none of the tests can run 13:48:11 so we are only fully supporting D9 13:48:25 and Bionic ? 13:48:40 and U18 yes 13:48:44 D9 and U18 13:48:55 fridolin: werent you containerizing ? 13:49:05 and we don't have tests that highlight our existing D8 issues. 13:49:31 As long as the statement of change is clear and widely posted, people should have already been expecting to migrate to current Debian old stable as the previous old stable is retired. 13:49:37 I would like to go further and suggest we set OS and SQL versions we officially support.. 13:49:58 ashimema++ 13:49:58 marcelr: we are : bionic container on a bionic hypervisor 13:50:06 right now one can install latest MySQL or MariaDB and just expect it to work.. we're not testing those so we really should make it clear we don't officially support them yet 13:50:34 +1 for explicit verisons 13:50:58 there is a patch of release notes dedicated to that but its actually frozen 13:51:00 makes sense to me - support what is in the OS we support, right? 13:51:08 qa needs something to not slip stuff in from higher db versions 13:51:18 it soulhd contain : OS, DB server, ES server, Perl ... 13:51:38 I've already improved the situation a little the past couple of weeks by adding SQL versions to test against.. but we're still only actually testing mysql5.5 and mariadb10.1 13:51:38 ES server would be good, Perl I think we do list 13:52:02 I know some people are running mysql5.7, mysql8, mariadb10.3 and beyond 13:52:13 we do but it needs work to tell D9 and U18, they have diff version 13:52:17 it's what caused the massive mess with the Check constraints stuff. 13:52:36 it proved useful too 13:52:42 we plan to upgrade to MariaDB 10.4 + U18 13:52:57 indeed.. 13:53:23 is release notes the right place ? 13:53:40 do we wish to continue to support both mysql and mariadb as they diverge.. if we do we need to work out a way forward.. 13:53:50 their syntaxes are diverging 13:54:05 but only for checks or in other areas as well? 13:54:06 probably a good idea to have that in the release notes yeah.. 13:54:21 +1 for release notes - it's the mostl likely place for people to check requirements 13:54:29 at least as a starting place 13:54:32 patch release generator then 13:54:34 in other area's too cait 13:54:40 hense the bug in koha-remove 13:54:49 debian moves to maria 13:55:02 I think already has 13:55:07 moved 13:55:09 Project Koha_Master_D9 build #985: STILL UNSTABLE in 57 min: https://jenkins.koha-community.org/job/Koha_Master_D9/985/ 13:55:11 so should we ? 13:55:15 with the debian updates (we are on it too) ours are on mariadb now in part 13:55:21 stick to default ? 13:55:26 so far I've only identified such disparities in table manipulations.. alter table, alter constraint, add user, drop user type stuff 13:55:51 how are other projects handling this? 13:55:58 i think it probably doesn't only affect us 13:55:59 good Q 13:56:10 indeed.. you have to work hard to install mysql on debian now.. maria is the default 13:56:22 no idea if that's the same on ubuntu 13:56:40 I don't know how many other projects actually are db agnostic cait 13:57:07 there's really only two options.. stick to one DB or write code to work out what DB you're attached to and write different code for each. 13:57:08 i think mysql/mariadb should have come to a lot like us rather naturally 13:57:27 yup 13:57:39 Projects with more resources at least have a better history of document the database version requirements and expected changes explicitly. 13:57:57 and it's only really with the major version number jump that the two start to diverge more widely I think.. 13:58:03 db agnostic was the long term goal of postgres support 13:58:09 we should boost bug 23914 ;) 13:58:09 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23914 enhancement, P5 - low, ---, chris, NEW , Hea - share the DBMS (name and version) 13:58:17 I don't think Debian or Ubuntu stables have made that version jump yet 13:58:17 but i think we are not moving any closer to that 13:58:27 as long as debian has maria, choosing mysql is not handy ? 13:58:42 we still have a lot of people running koha from tarball out there... 13:58:47 yup.. that's why I wanted bug 23914 ;) 13:58:47 oh of course, HEA 13:58:58 so being explicit is good, but forcing them short term to switch dbms might cause bigger problems 13:59:06 if you call mysql-server to install you get mariadb-server instead at he moment 13:59:20 you have to work around it if you actually want mysql installed 13:59:26 so its all about OS too 13:59:27 i have no issue with Hea - but it still represents only a small part 13:59:35 the ones we probably not catching are the small self hosted ones 13:59:38 I'm not suggesting an overnight change 13:59:46 some use remote DB server 13:59:49 so far we only have the DROP USER IF EXISTS syntax that is not supported by MySQL5.5 (and so D8) 13:59:50 Why does MariaDB seem to have chosen syntax changes which break compatibility? 13:59:51 but suggesting we start planning for it 13:59:52 ;) 13:59:53 that may not be a Debian ... 13:59:54 so it can be an indicator... but we should not put all decisions on what it tells us 13:59:55 which is only used in 1 script, koha-remove 14:00:13 it's the other way around thd 14:00:22 to support D8 we could post a workaround on the wiki to explain you can replace this script by this contain 14:00:26 what we shoudl totally do right now is make a page lsiting the differences 14:00:32 and the versions 14:00:39 mariadb followed the syntax that postgres set years ago.. then mysql cuaght up and added the feature but chose to use a different syntax 14:00:42 have that info stored somewhere, because it gets confusing pretty fast now 14:01:20 (me hates DB servers) 14:01:23 that.. and start running tests against a broader range of DB's so we start spotting issues before they hit users cait 14:01:32 Joubu: i'd prefer an in-built thing.. rememver how many times we got asked aout the PK problem on lists and chat :( 14:01:37 with koha-testing-docker it's getting easier to do that.. 14:02:13 #action Document differences between MySQL and MariaDB syntaxes, versions etc. on the wiki 14:02:14 if its only in koha-remove, a if/else looks fine 14:02:15 cait: I just wanted to tell it's super minor so far 14:02:30 I tried to install mysql 5.5 on D9 this morning, to provide a patch, but failed 14:02:34 Joubu: yeah, but if it stops you from installing, that's not so minor :) 14:02:40 failed to install it 14:02:42 not for the non-technical people that may encounter it 14:02:59 stops you from removing.. doesn't prevent installs 14:03:02 cait: it's koha-remove, so it will not stop people from installing Koha 14:03:05 ah good 14:03:14 koha cant be removed 14:03:16 sorry, missed that bit 14:03:23 i bet nobody ever removes a Koha ;) 14:03:23 which is good :) 14:03:28 try it and love it 14:03:30 no really, it's minor 14:03:35 but still... not super good - could we display a note or something? when you try to remove? 14:03:47 it's only affects a koha-remove of an instance which is called as part of an apt purge or if you just want to remove a single instance 14:03:47 it should be rewritten 14:03:50 so it's fairly minor in reality 14:03:52 fridolin: and never ever leave? ;) 14:03:52 I just walked the person through hacking a fix when it came up a few days ago 14:03:55 I assume that you can install anything with chroot but I built a Debian old version time machine for what I needed. 14:04:06 he was only removing it so he could add it back fresh 14:04:06 and have many children ;) 14:04:08 :) 14:04:14 somebody with a D8 runnning somewhere could provide a patch :) 14:04:31 so let's note it on the wiki at least to keep on top of things 14:04:42 when you are not around, it#s nice to have something to point people at 14:04:54 indeed 14:05:44 #action Add a note somewhere that koha-remove does not work on D8 with MySQL5.5 right now and likely won't unless we find a developer who is still running D8 14:06:15 #action Check release note generator for supported versions list and update accordingly for SQL servers 14:06:50 #action Continue the deprecation of D8 conversation on the lists and come up with a clear plan 14:07:11 #action Continue work on supporting D10 14:07:35 sound sreasonable 14:07:49 #action Further the work to test against more DB server versions in our CI process. 14:08:25 #action Promote bug 23914 more so we can get a better idea of what's actually in use in our userbase 14:08:25 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23914 enhancement, P5 - low, ---, chris, NEW , Hea - share the DBMS (name and version) 14:09:13 I'm tempted to move that bug into a new bug.. the conversation got hugely off topic.. the idea was to start recording that data.. not promote a massive opinionated discussion on history and database agnostisism. 14:09:23 moving one.. 14:09:34 was there any more you wanted to say on the find in list context bug marcelr? 14:09:39 sorry for that 14:09:51 no 14:10:13 julianm can continue 14:10:24 jajm 14:10:24 okies. 14:10:34 better note on the bug i think 14:10:46 its there cait 14:10:54 he'll understand 14:10:54 #topic Objects->find - Bug 23914 14:11:23 oops.. wrong bug 14:11:33 #link https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19809 bug 19809 14:11:33 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19809 enhancement, P5 - low, ---, julian.maurice, Failed QA , Koha::Objects::find calls do not need to be forbidden in list context 14:11:34 04Bug 19809: enhancement, P5 - low, ---, julian.maurice, Failed QA , Koha::Objects::find calls do not need to be forbidden in list context 14:11:42 moving on 14:12:01 #topic Review of coding guidlines 14:12:01 nothing from me to raise.. anyone else? 14:12:30 maybe later - db stuff 14:12:49 I mean we might want to add some new things when we figure out the db support - to help qa 14:13:08 agreed.. we need more detail before we can work out more guidlines. 14:13:22 agreed 14:13:36 so 14:13:42 #topic Set time of next meeting 14:14:12 I'm thinking it's the busy period and we're talking to each other lots already (and there's the docs meeting and general meeting next week anyway).. 14:14:24 so.. shall we skip a fortnight and call the next one in a month, after release? 14:14:47 say, 4th December ? 14:16:04 The fortnight may also be very close to a major US holiday. 14:16:42 so a second good reason to skip 14:16:52 any issue's with 4th Dec? 14:16:58 or advancements 14:18:08 ooh.. 14:18:18 4th is bad for me.. I'll be at our company meeting dinner 14:18:19 lol 14:18:47 my system is running very slowly at the moment :0 14:19:13 it's December.. it's going to likely be a very quiet meeting whenever we do it isn't it.. 14:19:32 11th works well for me 14:19:43 Why do you think a dev meeting just before the release is bad? 14:19:52 s/bad/not useful 14:20:28 not bad as such.. just perhaps unrequired 14:20:40 The fortnight is actually not close to the US holiday. 14:20:41 I'm happy to have one if you guys feel it's useful 14:21:06 The US holiday is the week following the fortnight. 14:21:20 ok, 20th then 14:21:27 s/week/end of week/ 14:22:09 evenining one 14:22:31 so `20 November 2019, 20:00 UTC` sound ok 14:22:49 +1 14:23:41 #info Next meeting: 20 November 2019, 20:00 UTC 14:23:56 #endmeeting