21:09:54 #startmeeting Development IRC meeting 3 August 2022 21:09:54 Meeting started Wed Aug 3 21:09:54 2022 UTC. The chair is davidnind[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:09:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:09:54 The meeting name has been set to 'development_irc_meeting_3_august_2022' 21:09:58 kia ora! 21:10:18 #topic Introductions 21:10:36 #info David Nind, New Zealand 21:10:45 #info Alex Buckley, Catalyst IT NZ 21:10:47 #info Aleisha Amohia, Catalyst IT NZ 21:10:53 #info Thomas Dukleth, Agogme, New York City 21:10:56 #info Chris Cormack, Catalyst IT NZ 21:11:08 #chair tuxayo 21:11:09 Current chairs: davidnind[m] tuxayo 21:13:53 I'll give it another couple of minutes, not sure where everyone is today... 21:14:03 here 21:14:04 i think katrin is on the way 21:14:11 hehe see 21:15:14 what a coincidence, noone told me to come here 21:15:22 heh 21:15:43 #topic Announcements 21:16:09 Any announcements/events anyone is aware of? 21:16:24 not from me 21:16:52 oh did we info already? 21:17:02 #info Katrin Fischer, BSZ, Germany 21:17:02 we did 21:17:26 #info Closing date for registrations for KohaCon22 is 31 August 2022 21:17:36 #link https://koha-us.org/events/conferences/kohacon22/ 21:18:16 #info Closing date for KohaCon23 proposals is 6 September 2022 (none yet) https://wiki.koha-community.org/wiki/KohaCon23_Proposals 21:18:57 I'll send out a reminder about KohaCon23 proposals this week 21:19:00 #topic Update from the Release manager (22.05) 21:20:06 i need to convince frido to propose tahiti for kohacon23 :) 21:20:18 +1 21:20:54 Not sure whether tcohen is around, so will skip 21:21:18 maybe they all turned up yesterday like I did when i read the time wrong :) 21:22:32 I think we messed up the calendar entry a little 21:22:37 so some migh tnot have seen it 21:22:49 oops - that is probably my fault... 21:23:15 no, I think we missed that the script didn't work right 21:23:26 not your fault at all 21:24:13 I think we should carry on then, anyone got some radical proposals? 🙂 21:24:20 #topic Updates from the Release Maintainers 21:24:42 ... I am trying, but too tired to come up with something 21:25:07 Are any of the release maintainers around, otherwise will skip 21:26:30 #info Maintenance releases were released for all supported versions, was also a security release as well 21:27:08 #topic Updates from the QA team 21:28:03 oh sorry 21:28:21 not much new, just the usual: numbers in the queues are a bit high, but we are working on it an dther ehas been movement 21:28:30 we had some big patches pushed 21:28:44 item bundles, curbside pickups, patrons being able to cancel waiting holds 21:29:10 oh cool 21:29:12 nice! 21:29:23 summer holidays on this half of the globe and Joubu leaving very soon now will mean less QA'ers for quite a while 21:29:36 hope the remaining can step up their game a bit (including me) :) 21:29:51 join the QA team, we have cookies! 21:30:01 (ok... the cookies are jus software cookies... but join anyway!) 21:30:36 🍪 21:30:45 that's it from me, any questions? :) 21:31:24 thanks cait! 21:31:47 you should make a proposal that people have to send the qa team cookies 21:31:51 ill vote for it 21:32:49 :) 21:32:49 #topic Status of roadmap projects 21:33:56 Wiki now restoring in pg_restore with no errors by using Debian 8 for restore and DB migration. 21:34:06 cool 21:34:11 No release manager, so deferred unless anyone has an update on specific items https://annuel.framapad.org/p/koha_22.11_roadmap 21:34:28 thd: is end of August still the goal? 21:34:58 The further from Debian the more errors reported by pg_restore. 21:35:15 We might start migrating next week. 21:35:42 awesome 21:35:52 thd++ 21:36:00 The pg_restore errors were probably false warnings but were scary. 21:36:04 thd++ 21:36:24 https://koha-mw-pg-test02.agogme.com/wiki/Main_Page Postgres restore in Debian 8 pg_restore no errors. 21:36:24 https://koha-mw-my-test02.agogme.com/wiki/Main_Page MySQL migration in Debian 8 21:37:20 https://koha-mw-my-test00-upgr.agogme.com/wiki/Main_Page Upgraded to LTS Debian 10 but not currently built from error free pg_restore. 21:37:55 Sandbox available for ERM module using Vue - https://staff-erm.sandboxes.biblibre.eu/cgi-bin/koha/erm/erm.pl 21:38:07 Debian 10 was easy. Debian 8 was tricky. 21:38:27 aaaaah there is a meeting!!!! 21:38:29 tcohen found a good Docker container to use. 21:38:41 you are just in time 21:38:51 https://github.com/CanastaWiki/Canasta/blob/master/Dockerfile 21:38:55 ohh the ERM module is looking good 21:39:02 plus a nice sneak preview https://bywatersolutions.com/education/monday-minutes-sneak-peek-erm 21:39:06 #info Victor Grousset, Tuxayo IT, France 21:39:53 Joubu said he pushed some more updates/enh just today 21:39:58 so might be worth haveing another look 21:40:00 (ERM) 21:40:12 excellent! 21:40:12 darn tootin' it is. 21:41:30 I haven't had a chance to look at the staff interface redesign recently, but I think good progress is being made - some recent discussion on the mailing list 21:41:49 there also is a sandbox now 21:41:59 dedicated, so everyone can have a look 21:42:01 cool 21:42:08 it looks very cool! 21:42:36 yes very impressive :) 21:42:43 we had some thoughts about the icons in the search bar (i.e. search patrons, check out etc) being a bit ambiguous. it would be cool if the text changed when you hovered on them, rather than just having alt text, otherwise you're required to click 21:42:54 i think the search bar is the most dicussed feature 21:43:02 understandably 21:43:06 there have been accessibility concerns 21:43:20 #info dedicated sandbox to view the staff interface redesign: https://sandboxes.biblibre.eu/ 21:43:21 #link https://staff-bug30952.sandboxes.biblibre.eu/ 21:43:26 and I think it might clash with soem of our 'sysprefed' features that go there 21:43:36 so that is probably the area that needs the most work an dmaybe some ideas still 21:43:39 true true 21:45:55 move on? 21:45:58 so quiet :) 21:46:02 #info Thanks for those reviewing the staff interface redesign, please continue to provide feedback on bug 30952 and can preview at https://staff-bug30952.sandboxes.biblibre.eu/ 21:46:02 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30952 enhancement, P5 - low, ---, julian.maurice, ASSIGNED , New interface for staff client 21:46:13 #topic Actions from last meeting 21:47:15 Extended support/LTS release is the on the agenda for voting, postpone the other items? 21:48:10 ok for me 21:48:20 #action liliputech (deferred from previous meeting) discuss koha CI (docker image built + manual build) hosting on gitlab instance provided by BibLibre's partner AFI. 21:48:24 yes 21:48:35 tuxayo? 21:48:35 tuxayo is on a role 21:48:50 «postpone the other items?» it was about that ^^" 21:48:51 sorry, meant any update on your action point? 21:48:55 ah 21:49:13 i moved it to the coding guidelines section of the agenda 21:49:21 (I just did that ^^") 21:49:26 So we will get to it 21:49:37 thanks! 21:49:50 #topic General development discussion (trends, ideas, ...) 21:50:12 #topic Vote on LTS version 21:50:31 Who would like to summarise the proposal? 21:50:47 Then we can vote, if we think there are enough people here... 21:51:24 it's a little late here, but I can try 21:51:34 I can get stuff from the tickets 21:51:39 thanks cait 21:51:43 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31008#c1 21:51:43 04Bug 31008: new feature, P5 - low, ---, koha-bugs, NEW , Long Term Support (LTS) version of Koha 21:51:52 we have worked out some models for how an LTS could work 21:52:02 the main differences are in overlap time and maintainers required 21:52:08 could someone post the link? 21:52:23 #info graph of LTS proposal https://lite.framacalc.org/29o8a7mlwc-9v57 21:52:32 we ended up mostly agreeing that we will need 4 rmaints, to ensure that the normal versions are ther elong enough, overlap is long enough etc. 21:52:57 yeah 21:53:03 so we should decide what we want - each mode is summarized on the right of the example 21:53:11 mode = model 21:53:37 and then the next question would be to name the first (second if you count 19.11) LTS 21:53:46 I think at the moment it's only a quesiton between 22.05 and 22.11 21:54:17 the older ones are probably too late 21:54:26 tuxayo: anything to add? 21:55:27 Mandate = security + things that are broken (APIs (external), dependencies (such as Elasticsearch), etc) + essential backports only once past oldoldstable 21:55:37 Irregular release - only when something is needed once past oldoldstable 21:56:17 i think irregular release makes sense to me 21:56:24 for an lts 21:57:05 With the last info, most of the proposal should be here and in the table link 21:57:11 I'm just formatting the 2 questions for voting - hope I get it right! 21:57:47 thx davidnind[m] 21:58:04 #startvote Which Koha version will be the first LTS version? 22.05, 22.11 21:58:04 Begin voting on: Which Koha version will be the first LTS version? Valid vote options are 22, 05, 22, 11. 21:58:04 Vote using '#vote OPTION'. Only your last vote counts. 21:58:06 > i think irregular release makes sense to me 21:58:06 That's what makes it doable to find a 4th RMaint otherwise it would be too much of a commitment for limited value. 21:58:11 the idea is to ensure we have a version that can be used by people who don't manage to update that often and still have security patches 21:58:34 i think sticking ot scheudle might be nice as long as you still have bug fixes... but when it dwindles you can skip 21:58:48 up to the rmaint then in the later phase of maintenance 21:58:57 argh, formatted wrong will try again.. 21:59:02 #endvote 21:59:02 Voted on "Which Koha version will be the first LTS version?" Results are 21:59:28 #startvote Which Koha version will be the first LTS version? 22-05, 22-11 21:59:28 Begin voting on: Which Koha version will be the first LTS version? Valid vote options are 22-05, 22-11. 21:59:28 Vote using '#vote OPTION'. Only your last vote counts. 22:00:01 #vote abstain 22:00:01 tuxayo: abstain is not a valid option. Valid options are 22-05, 22-11. 22:00:02 I have no idea what is best 22:00:06 i know! 22:00:10 #vote 22-11 22:00:23 #vote 22-11 22:00:29 #vote 22-11 22:00:49 #vote 22-11 22:00:55 I'll just vote what everyone else voted :P 22:01:00 #vote 22-11 22:01:07 #info Fridolin Somers, Biblibre, Tahiti 22:01:11 tuxayo: the latter option gives more time to approach the issue. 22:01:16 #vote 22-11 22:01:50 sorry, i was too focused did not trick time 22:01:51 Is there any difference on which of XX.05 or XX.11 tends to be most stable when reaching oldstable? 22:01:53 trask 22:01:55 track 22:02:00 yeah, I'd have preferred 22-05 a little, but it's ok as long as we get the ball rolling :) 22:02:17 tuxayo: not really... depends on a lot of things 22:02:22 ok 22:02:43 we use xx-11 at biblibre but it is hazard 22:02:55 from first version 16.11 i bet 22:03:11 i picked 22.11 cos we just have more time to get sorted out :) 22:03:20 :) 22:03:21 fridolin: I don't think so, it's because you are on the north hemisphere and libraries prefer major upgrades in summer. Isn't it that? 22:03:32 ahhh maybe 22:03:35 yeah, it got too late for 22.05 probably 22:03:46 you have one minute to cast/change your vote 22:03:56 using xx.05 woould be too fresh for july in deed 22:04:01 I stand with my vote :) 22:04:11 But for LTS the hemisphere thing doesn't change anything if we choose to have a year of overlap (4 RMaint constantly) 22:05:03 we just need good brain hemispheres ^^ 22:05:12 #endvote 22:05:12 Voted on "Which Koha version will be the first LTS version?" Results are 22:05:12 22-11 (6): cait, rangi[m], fridolin, alexbuckley, davidnind[m], thd 22:05:21 🎉 22:05:29 I love decisions 22:05:32 next! :) 22:05:39 #agreed The first LTS/extended support version will be 22.11 22:05:47 not sure how to phrase the next question - can anyone help 22:05:50 So how many RMaint? 22:06:30 I think maybe... sec 22:07:15 1-3-1, 1.5-3-1, 1.5-3.5-1.5 22:07:29 👀 22:07:39 !bingo 22:07:40 that's regular regular releases, LTS release, overlap of LTS 22:07:58 or...1 2 and 3 from the calc document 22:08:02 but that might go away some day 22:08:13 > but that might go away some day 22:08:13 indeed 22:08:50 Ah I get it 22:10:06 I lean towards the last at the moment 22:10:23 every 4th release is an LTS 22:10:37 1-3-1, 1.5-3-1, 1.5-3.5-1.5 22:10:37 length of support for regular releases - length of support for LTS - duration of LTS overlap(the 1st 6months are when the release is "stable" so not stable enough for migration, subtract 6mo to get the safe overlap) 22:10:40 and you have 1.5 overlap.. which should work with all seasons 22:11:09 do people have an idea what they want? 22:11:48 certainly not 1-3-1 because it's not possible to upgrade every year and choose when to do so. You are forced 22:12:00 4 years is not in the spreadsheet is it? 22:12:27 1.5-3.5-1.5 (the last) works better no matter when they want to upgrade 22:13:05 > 4 years is not in the spreadsheet is it? 22:13:05 Was a 4years proposal made? 22:13:11 sorry 4 releases is not in the spreadsheet. 22:13:35 I meant evey 4th is an lts 22:13:43 what do you mean by 4 releases? 22:13:57 we'll always maintain 4 parallel 22:14:02 Ah ok 22:14:06 1.5-3-1 and 1.5-3.5-1.5 (proposal 2 and 3) have 4 un parallel 22:14:48 So question would be: Use every 4th version as the LTS/extended support version of Koha (see https://lite.framacalc.org/29o8a7mlwc-9v57 for details)? Yes, No 22:15:19 That doesn't discriminate between the 3 proposals 22:15:43 They all work with LTS being one of every 4th release 22:16:06 yes 22:16:15 the difference is the overlap time 22:16:26 in general the mainenance times and such 22:16:30 * fridolin goes to lunch will read the logs 22:16:47 I know i prefer the 3rd 22:16:58 tuxayo persuaded me 22:17:12 and it#s the same amount of maintainers, only difference is that it's always 4 people to the second model 22:17:13 So hard to phrase concisely the proposals 22:17:21 it's why I needed to draw it 22:17:30 We have 3 options - if someone can give me a short description for each one I'll run the vote and then end the meeting 22:18:10 hm I tried :) 22:18:17 How about: What maintenance model will we use for LTS/extended support version of Koha? Option 1, Option 2, Option 3 (every 4th version) 22:18:31 The short description is either 1-3-1, 1.5-3-1, 1.5-3.5-1.5 22:18:36 or what is written next to the tables 22:18:49 for model 3: 4 RMaints 22:18:49 1.5 years maintenance for regular releases 22:18:49 3.5 years maintenance for LTS release 22:18:49 1.5 year overlap 22:19:18 all are every 4th, so I think we can leave that off :) 22:19:27 Format of the proposals: N1-N2-N3 22:19:27 N1: length of support for regular releases - N2: length of support for LTS - N3: duration of LTS overlap (including the first 6 months of lifecycle that aren't well suited for upgrade) 22:19:34 but yes, 1 2 or 3 migh work best 22:20:13 3 RMaints vs 3.75 RMaints vs 4 RMaints 22:21:33 maybe we should just decide between 2 and 3 to make it easier 22:21:47 I tihnk people might agree that having to update every year of they are not on LTS is not enough time 22:22:15 ++ 22:22:27 They can't even do when they want 22:22:49 and the only differnce between 2 and 3 is that we have no cycle where we only need 3 rmaints 22:22:53 we always need 4 22:22:53 2 RMaint for regular releases gives a constraint to do that in winter or summer (depending of when we start) 22:22:57 but we get 1.5 years overlap 22:23:10 so... I think maybe we just vote if 3 is ok :) 22:23:18 ^^ 22:23:35 This would be: 22:23:49 4 RMaints constantly 22:23:49 1.5 years maintenance for regular releases 22:23:49 3.5 years maintenance for LTS release 22:23:49 1.5 year overlap between LTS releases 22:24:18 Nearly there... 22:24:24 ok 22:24:39 proposal 1: keep 3 RMaints and shorten support of regular releases 22:24:39 proposal 2: 4 RMaints (1 out of every 4 cycles, only 3 RMaints) and same support of regular releases. 6 months of effective overlap between LTS 22:24:39 proposal 3: 4 RMaints always and same support of regular releases. 12 months of effective overlap between LTS 22:24:47 Can't make it much sorter 22:25:18 #Info Option 3 for voting = 4 RMaints constantly, 1.5 years maintenance for regular releases, 3.5 years maintenance for LTS release, 1.5 year overlap between LTS releases 22:25:38 #vote Use option 3 as maintenance model for LTS/extended support version of Koha (see https://lite.framacalc.org/29o8a7mlwc-9v57 for details)? Yes, No 22:25:46 #vote Yes 22:25:52 #vote yes 22:25:59 #vote yes 22:26:01 #vote Yes 22:26:07 # vote Yes 22:26:13 #vote Yes 22:26:26 one minute to go.. 22:27:14 #endvote 22:27:18 #vote yes 22:28:24 It was #startvote ! 22:28:26 #agreed To use option 3 (see details in comments) as the maintenance model for the LTS/extended support version of Koha (see https://lite.framacalc.org/29o8a7mlwc-9v57 for details) 22:28:35 anyway we can manually do it 22:28:47 I won't rerun - it was unanimous! 22:28:53 #info All other agenda items deferred to the next meeting 22:28:57 yes and it's soo olate :) 22:28:58 #topic Set time of next meeting 22:29:04 here at least 22:29:17 same time? (for the meeting in 4 weeks) 22:29:35 The one it two week has been decided 2 weeks ago, let me find it 22:30:05 #info see bug 31008 for other details about how the LTS should be handled (scope of what to include, regularity of releases) 22:30:05 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31008 new feature, P5 - low, ---, koha-bugs, NEW , Long Term Support (LTS) version of Koha 22:30:52 #info Next meeting: 17 August 2022, 14 UTC 22:31:10 thanks tixayo 22:31:17 tuxayo even 22:31:21 For meeting in 4 weeks the 31th then? 22:31:22 #endmeeting