15:01:31 <tuxayo> #startmeeting Development IRC meeting 19 January 2022
15:01:31 <huginn> Meeting started Wed Jan 19 15:01:31 2022 UTC.  The chair is tuxayo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:31 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:31 <huginn> The meeting name has been set to 'development_irc_meeting_19_january_2022'
15:01:40 <tuxayo> #topic Introductions
15:01:51 <tuxayo> rmaints?
15:02:01 <oleonard> #info Owen Leonard, Athens County Public Libraries, Ohio, USA
15:02:02 <tuxayo> i heard rmaints was khall, AndrewFH, wainui and tuxayo
15:02:08 <tuxayo> qa_team?
15:02:22 <tuxayo> well, qa_team is cait, joubu, tuxayo, marcelr, kidclamp, khall, tcohen, ashimema, nugged, kohaputti, petrova
15:02:35 <tuxayo> #info Victor Grousset, Tuxayo Group Holding Limited, France
15:02:37 <ashimema> #info Martin Renvoize, PTFS Europe, UK
15:02:59 <nugged> #info Andrew Nugged, National Library of Finland, HELSINKI
15:03:17 <tuxayo> Apologies from Fridolin: «Sorry, children sick at home. Feel free to postpone the points I have noted. Email me for any question. »
15:03:58 <nugged> 🍇 🫖 and 💪 for Fridolin!
15:04:17 <Joubu> #info Jonathan Druart
15:04:30 <tuxayo> i'll relay ^^
15:05:03 <tuxayo> #topic Announcements
15:05:08 <marcelr> #info Marcel de Rooy
15:05:18 <tuxayo> Any announcement that doesn't fit in another topic?
15:05:34 <thd> #info Thomas Dukleth, Agogme, New York City, recent COVID capital, testing negative from last week and after effects of severe congestion, fatigue, etc. have greatly.  I do not recommend it but very contagious despite vaccination and other precautions.
15:05:46 <oleonard> There was a meeting yesterday of interested parties regarding a redesign of the staff interface
15:06:02 <oleonard> I will send a brief report to koha-devel today
15:06:27 <ashimema> oleonard++
15:06:32 <ashimema> I look forward to reading the report
15:06:51 <tuxayo> best wishes for remission thd
15:07:00 <tuxayo> great news oleonard
15:07:09 <thd> s/greatly/greatly diminished/
15:07:58 <tuxayo> #topic Update from the Release manager (22.05)
15:08:20 <tuxayo> «How do we manage review of Bug 19532 Recalls ?»
15:08:20 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19532 new feature, P1 - high, ---, aleisha, ASSIGNED , Recalls for Koha
15:08:59 <marcelr> we made plans for that already
15:09:07 <marcelr> in earlier dev meetings
15:09:59 <marcelr> i asked for more specific timing but got no specific replies
15:10:26 <tuxayo> In a previous meeting or in the ticket?
15:10:53 <marcelr> depends on what you exactly mean
15:11:28 <tuxayo> I missed the previous message. Ok about timing.
15:12:18 <tuxayo> @ Fridolin for later: The latest news are in the ticket. IIUC it's feature frozen and a rebase in needed to review and test as is.
15:12:19 <huginn> tuxayo: I'll give you the answer as soon as RDA is ready
15:12:56 <tuxayo> can't use the at sign at all without huginn noticing ^^
15:13:48 * ashimema still struggles with recalls.. is it still nearly a clone of holds code from many years ago?
15:13:50 <Joubu> use later tell
15:14:08 <marcelr> ashimema: you are backtracking the discussion now?
15:14:29 <ashimema> ok.. I'll stay quiet
15:15:02 <kidclamp> #info Nick Clemens, ByWater Solutions
15:15:23 <khall_> #info Kyle M Hall, ByWater Solutions
15:15:54 <tuxayo> next point from Fridolin: « There are links to gitweb in https://koha-community.org/get-involved/for-developers/ »
15:17:03 <tuxayo> I might have the right to edit this page where is the repo for documentation now?
15:17:47 <oleonard> That could be added as bug in Bugzilla
15:18:15 <tuxayo> Indeed
15:18:45 <tuxayo> #action tuxayo open ticket and update https://koha-community.org/get-involved/for-developers/ with the URL of the current git repo (Gitea)
15:19:08 <tuxayo> next point from Fridolin: « Add new Bugzilla component for Koha as Mojo App ? »
15:19:43 <Joubu> No need to ticket + blabla too long for an update of the website
15:19:45 <tuxayo> Are there so many tickets about that an omnibus ticket doesn't do the trick?
15:19:47 <Joubu> ping me and I will do it
15:19:51 <tuxayo> ok
15:19:52 <Joubu> that seems easier for everybody
15:22:22 <tuxayo> #action tuxayo postpone «Add new Bugzilla component for Koha as Mojo App ?» and ask for more details
15:22:28 <tuxayo> #topic Updates from the Release Maintainers
15:22:44 <tuxayo> rmaints?
15:22:52 <tuxayo> i heard rmaints was khall, AndrewFH, wainui and tuxayo
15:23:09 <khall_> steady as she goes :)
15:23:26 <tuxayo> nothing to report about 20.11
15:23:49 <tuxayo> moving on then
15:23:50 <tuxayo> #topic Updates from the QA team
15:23:57 <tuxayo> qa_team?
15:24:07 <tuxayo> well, qa_team is cait, joubu, tuxayo, marcelr, kidclamp, khall, tcohen, ashimema, nugged, kohaputti, petrova
15:24:26 <oleonard> No cait1 at the moment?
15:24:34 <ashimema> I've been behind on QA so far this cycle personally.. other pressing commitments
15:24:43 <ashimema> but I am starting to pick up pace again now
15:24:51 <marcelr> ashimema++
15:25:12 <ashimema> we still need more hands.. for the small/trivial bugs there's still a serious lag.. many of them only take a couple of minutes to QA
15:25:26 <ashimema> grab it, check it, run the qa scripts..
15:25:53 <ashimema> if more people grabbed one of those a day we'd keep the queue numbers down.. and have more time to concentrate on the bigger things
15:26:34 <cait1> oh yes sorry
15:27:09 <cait1> what ashimema said
15:27:14 <cait1> we need more hands and more QA time overall
15:27:34 <Joubu> yes, I am trying to send a short email with a list of easy bugs that should go asap
15:27:36 <ashimema> [off] I mooted the topic of trying to put some money up for a 'pipelines' position in the community.. someone actually paid to help keep things moving.. chasing for signoffs and qa's
15:27:44 <cait1> i'd love to see the average 'time in queue' reduced... but it won't be possible with more resources
15:27:51 <Joubu> will continue doing it for the next weeks and see if they get attention
15:28:04 <ashimema> I've done 12 QA's today.. in a half hour gap I had between meetings 😉
15:28:15 <marcelr> hmm
15:28:20 <ashimema> it's not impossible to keep on top of things.. there's just a disitnct lack of apetite
15:28:28 <ashimema> most of those were one line string fixes 😉
15:28:29 <cait1> at the moment wefocus on the bad and ugly mostly
15:28:39 <marcelr> too fast qa's is just postponing trouble
15:28:46 <ashimema> I agree
15:28:47 <thd> :)
15:28:57 <ashimema> but typo and string fixes really do only take a few minutes
15:28:58 <Joubu> but having the list full of easy but ugly tiny things does not help to see what's exactly in the list
15:29:03 <cait1> not talking about fast... but more time overall and prioritizing
15:29:15 <ashimema> exactly
15:29:16 <cait1> so yes, if you have stuff waiting, consider to join the team ;)
15:29:23 <ashimema> if we can tackle those quickly.. it focuses the eye on the other one's more
15:29:54 <cait1> i think doing QA 'right' also saves time in the long run
15:29:58 <marcelr> only focusing on small stuff, will not get the other ones in
15:30:01 <cait1> bugs fixing issues missed also take time
15:30:18 <cait1> I'd be ok if we mostly did a mix
15:30:38 <cait1> if everyone grabbed the oldest in queue... and 1-3 easy ones constantly, we'd get stuff moving already
15:30:57 <cait1> like strting with the worst/oldest everytime you get to do QA or at least try to
15:31:05 <marcelr> yeah some kind of balance
15:31:38 <ashimema> my point isn't to say "don't do the hard one".. it was to say.. if you have half an hour between meetings.. pick off a simple QA or two
15:31:49 <cait1> yep
15:32:06 <ashimema> don't wait for yourself to have a multi-hour period you may never get so you can attack one hard one 😉
15:32:12 <cait1> the balance... is the key, discussing it is a good step already
15:32:18 <ashimema> but yeah.. we just need more flow as a whole
15:32:58 <cait1> maybe to add for the logs, we have also been talking to Aleisha about the recalls bug (marcelr++ aleisha*++) and hope to have that one moving soon
15:33:17 <cait1> but overall... more resources would help a great deal
15:34:47 <tuxayo> #topic Status of roadmap projects
15:35:05 <Joubu> roadmap?
15:35:19 <tuxayo> Is there actually an equivalent this cycle?
15:35:40 <cait1> not sure, is frido around?
15:35:45 <oleonard> No
15:36:01 <ashimema> there was an intention.. but I don't know that it came to fruition
15:36:03 <tuxayo> There might a confusion, the old roadmap document has seed some edits this cycle ^^
15:36:03 <tuxayo> https://annuel.framapad.org/p/koha_21.11_roadmap
15:36:12 <oleonard> "todo: Make a roadmap" :)
15:36:13 * ashimema really has dropped the ball on this cycle so far.. sorry peeps
15:36:51 <cait1> #info Katrin Fischer, BSZ, Germany
15:37:05 <marcelr> Joubu asked for feedback in a mail on dev list
15:37:16 <cait1> ashimema: it happens, we need to be able to deal with people having other projects and stuff
15:37:48 <cait1> shoudl we postpone thre roadmap question and check in with frido on this?
15:37:50 <thd> I have fixed image directories missed from rsync when relocating files in the wiki.  I can concentrate for the hours required now without risking bronchitis.
15:37:52 <cait1> or assume we'll move them to a new one
15:38:07 <ashimema> [off] ptfs-e are advertising for a new developer in the next few days.. so things are looking up for time I can spend on Koha again in the medium term future
15:38:44 <tuxayo> #action tuxayo postpone roadmap topic and check in with frido on this
15:39:16 <tuxayo> #topic Actions from last meeting
15:40:22 <tuxayo> « fridolin announces timeframe extension (end of feb) and for this one allow proposals outside eligible continents, keeping priority to actual ones »
15:40:24 <tuxayo> done
15:41:04 <marcelr> thats kohacon?
15:41:10 <tuxayo> yes
15:42:15 <tuxayo> #action postpone or ask about the 2 other actions of fridolin. And
15:42:35 <tuxayo> « tuxayo check if xt/perltidyrc is used to see if we currently rely on it's values »
15:42:39 <tuxayo> it doesn't
15:43:06 <tuxayo> it doesn't influence the tests at all. So do we still need it?
15:43:32 <ashimema> interesting
15:43:34 <cait1> if we don't need it... removing it seems logical
15:43:37 <tuxayo> After emptying it or removing or setting the max line lenght to 40 char no error pops
15:43:48 <ashimema> not doing anything.. lets get rid of it.
15:43:52 <cait1> and if we don't enforce/use it either
15:44:02 <marcelr> just open a report on Bugzilla :)
15:44:16 <tuxayo> ok, who to open the ticket?
15:44:45 <marcelr> i dont know how
15:44:53 <tuxayo> #action tuxayo open a ticket about the removal of xt/perltidyrc which is not used
15:45:32 <thd> Was it ever used?
15:45:50 <tuxayo> maybe a long time ago
15:46:10 <tuxayo> «tuxayo postpone "Avoid formatting single words within sentences to ease translation (example: Bug 29589)" to wait for test results »
15:46:10 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29589 minor, P5 - low, ---, jonathan.druart+koha, Failed QA , Translation issue with formatting in MARC overlay rules page
15:46:48 <tuxayo> I suppose  it's about this https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29589#c6
15:46:48 <huginn> 04Bug 29589: minor, P5 - low, ---, jonathan.druart+koha, Failed QA , Translation issue with formatting in MARC overlay rules page
15:47:17 <tuxayo> Anyone has seen the new ticket ?
15:48:18 <Joubu> bug 29853
15:48:18 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29853 normal, P5 - low, ---, fridolin.somers, Needs Signoff , Text needs HTML filter before KohaSpan filter
15:48:21 <Joubu> I guess
15:48:27 <ashimema> not one I've looked at yet
15:48:48 <tuxayo> thank for the find Joubu, so done
15:48:54 <tuxayo> « tuxayo Update coding guideline JS5 to removed everything from DEPRECATED to the end of JS5. »
15:48:55 <tuxayo> donne
15:49:07 <tuxayo> #topic General development discussion (trends, ideas, ...)
15:49:54 <tuxayo> « LTS discussion »
15:49:54 <tuxayo> Shall we postpone for when fridolin is there and we have more time?
15:50:17 <ashimema> yup
15:50:28 <marcelr> postponing++
15:50:30 <Joubu> what's the discussion about?
15:50:36 <Joubu> we postponed it 3 times already
15:50:48 <thd> LTS
15:50:49 <ashimema> true
15:50:51 <marcelr> thats tells you something at least
15:50:57 <cait1> i think we need to agreeon the time we support
15:51:05 <cait1> and maybe discuss about regularly dropping rleeases in between
15:51:06 <ashimema> to have some formal idea of what our LTS support means
15:51:13 <Joubu> it's LTS maintainer to decide
15:51:15 <cait1> and.. write it down somewhere
15:51:25 <tuxayo> yes, do we start a formal LTS and advertise it
15:51:27 <Joubu> or someone somewhere to decide they will have someone to deal with that
15:51:30 * nugged going behind the talk but ...
15:51:31 <nugged> > removal of xt/perltidyrc which is not used
15:51:31 <nugged> but do we have some recommended perltidyrc which is "proper-iest" one?
15:51:31 <Joubu> so a support company
15:51:32 <cait1> an LTS doesn't work wihtout a "promise" of support time
15:51:35 <ashimema> how long, how many versions should we actually be supporting.. should we drop some versions and take up a rolling version
15:51:51 <Joubu> it's not our job to do that, what if we decide 4 years and next year nobody is willing to support it?
15:52:01 <marcelr> we dont have the people to do it
15:52:08 <cait1> well then we can't have an LTS at all
15:52:08 <ashimema> something being called LTS means as a community we have committed
15:52:23 <ashimema> we need to know what LTS actually means and publish that
15:52:29 <cait1> I agree
15:52:34 <thd> ashimema++
15:52:40 <Joubu> drop rangi an email then
15:54:02 <tuxayo> > what if we decide 4 years and next year nobody is willing to support it?
15:54:02 <tuxayo> We can be confident to always have 3 RMaints and that would mean oldoldstable could be dropped when a 4th RMaint isn't found. This seems a doable promise in general.
15:54:19 <cait1> yes, it would have to take priority
15:54:29 <ashimema> personally.. I think we're an already rather stretched team of people ;).. I'd love to see us drop some support and move to a more fluid model for some support
15:54:48 <marcelr> just stick to 3 versions ?
15:54:49 <ashimema> but also.. if we say we'll do LTS.. what goes into decided that a particular version becomes the next LTS?
15:55:06 <cait1> I was wondering that too
15:55:15 <cait1> after 19.11... what woudl be the next one to become an LTS release
15:55:22 <marcelr> 20.11
15:55:22 <cait1> i think we were talking about 2-3 years last time
15:55:31 <cait1> supporting
15:55:43 <cait1> marcelr: can you explain?
15:55:55 <Joubu> it should be 3y minimum
15:55:55 <marcelr> it is a good release :)
15:55:55 <ashimema> https://koha-community.org/about/release-schedule/ will need updating
15:55:57 <tuxayo> > just stick to 3 versions ?
15:55:57 <tuxayo> Worst case. In the exemple workflow that would be very similar to the current one
15:56:29 <marcelr> i think that we want too much
15:56:49 <Joubu> it's actually easier than suporting 3 versions
15:57:13 <Joubu> we just need to support an old version for those who does not care abotu the new features
15:57:20 <Joubu> and to provide them security backport
15:57:30 <Joubu> it's the main purpose, security patches
15:57:35 <cait1> yes
15:57:41 <marcelr> thats just additional work on top of 3 versions
15:57:43 <cait1> and that's the way we should do it
15:57:52 <tuxayo> So it would be stable and LTS so 2.
15:57:54 <cait1> i think that's why ashimema was suggesting to drop one
15:58:03 <ashimema> exactly
15:58:20 <cait1> or drop oldoldstable?
15:58:29 <cait1> same versions than now... but bigger gap
15:58:29 * ashimema would actually like LTS, Stable and Rolling.. as the three
15:58:32 <tuxayo> In this case we would drop oldoldstable and oldstable IIUC
15:58:37 <ashimema> with rolling meaning a feature release every month
15:58:51 <tuxayo> > LTS, Stable and Rolling.. as the three
15:58:51 <tuxayo> That could work very well
15:58:52 <ashimema> and stable meaning feature stable for 6 months..
15:58:52 <thd> marcelr: Are you really saying that there is a need for the 3 versions in any case because of supporting customers or something?
15:59:06 <ashimema> so more of a drop oldstable and oldoldstable
15:59:18 <cait1> i think maybe smaller steps... establish LTS first
15:59:26 <cait1> let the others run out slowly...
15:59:31 <cait1> and maybe do an oldstable
15:59:35 <cait1> people need to jump on LTS first too
15:59:50 <ashimema> or stable becomes a 1 year rather than 6 month feature cadence
16:00:01 <ashimema> the point is to reduce the number of rmaints required
16:00:17 <ashimema> and generally try to make our 'dev' branch more stable to begin with for rolling
16:00:31 <tuxayo> > or stable becomes a 1 year rather than 6 month feature cadence
16:00:31 <tuxayo> ++ that's a possibility
16:00:34 <cait1> i am not sure we can do more stable
16:00:42 <cait1> there will always be big patches with possible side effects
16:00:53 <cait1> and communitcating those riskier releases seems a nightmare
16:01:06 <cait1> it might also be confusing to libraries to have even more releases and release notes to check
16:01:09 <marcelr> when 21.11 came out, i went to 20.11
16:01:20 <marcelr> so that would not be possible anymore already
16:01:45 <cait1> yes, I think we need to think about the implications for people on different versions now
16:01:58 <ashimema> yup
16:02:18 <ashimema> all this stuff needs formalising and discussing... just suddently saying we're having an LTS overnight was the problem in my book
16:02:35 <cait1> I think it's good to have a fact and then we can work from there .)
16:02:50 <cait1> but we have only talked about it here... nothing writen up etc
16:02:57 <cait1> we need to now do that
16:03:06 <ashimema> yup.. so first step is to just document what we mean by LTS and make it a community commitment
16:03:13 <tuxayo> > just suddently saying we're having an LTS overnight
16:03:13 <tuxayo> 19.11 it's just a version with long support. There was never a promise for support time so there is no issue
16:04:12 <tuxayo> And can we know in advance if an LTS will be followed enough to be worth it?
16:04:12 <cait1> ok - what about... we start an lts wiki page
16:04:20 <tuxayo> Are many instances doing minor upgrades?
16:04:21 <cait1> add the queestions and our answers and go from there next time?
16:04:24 <tuxayo> https://hea.koha-community.org/systempreferences
16:04:30 <tuxayo> There are some instances that are on the latests 20.05.x and 19.11.x so it would benefit them to have a long support. Which it the case for 19.11.x
16:04:35 <tuxayo> But it's dwarfed by a factor of 15 for 20.05.x and more than 30 for 19.11.x by the instances on versions older than the last 3.
16:04:39 <cait1> tuxayo: we would only do it when necessary (bad bug fixed) but can't tell about others
16:04:40 <thd> What would the mechanism be to ensure support?  Ensure that someone would be available for maintenance for the duration of the period?
16:05:14 <cait1> I don't think it needs to be for the whole duration, others can take over
16:05:15 <ashimema> I'd be interested to see if there are any stats from the deb repos that could give us an idea of how many people actually track the verious releases and don't pin.
16:05:18 <cait1> we alrady do that curently
16:05:55 <marcelr> tuxayo hea figures? if so, be careful with older numbers
16:05:56 <ashimema> right now we kinda pressurise people into taking on the existing rmaint roles
16:05:59 <tuxayo> cait1: I'm not worried about provider involved in the community.
16:06:00 <ashimema> it's a given they're needed
16:06:06 <ashimema> so people step in
16:06:34 <tuxayo> thd: «  Ensure that someone would be available for maintenance for the duration of the period?» If we have a workflow that works with 3 RMaints we shouldn't have an issue
16:07:06 <cait1> yes, keeping it at 3 versions shoudl work, we'd just have a wider gap between lts and others
16:07:22 <cait1> I don't think we'll come to results today
16:08:32 <tuxayo> marcelr: I don't why I didn't look 20.11. But for 21.05 it's too recent to see if people upgrade it. Since it was the latest version not long ago
16:08:37 <ashimema> indeed
16:09:22 <marcelr> just warning because older data is not removed at fixed time
16:10:04 <tuxayo> When an instance sent again data, it replace the old one right?
16:10:14 <tuxayo> There is an ID for each Koha
16:10:27 <marcelr> i guess, but when they leave, the records stays
16:10:38 <marcelr> so the picture is not clear anymore
16:10:49 <thd> I presume there would be people for maintenance as long as support companies have sufficient demand for such a version which depends significantly on what libraries actually want.
16:11:26 <tuxayo> > i guess, but when they leave, the records stays
16:11:27 <tuxayo> Indeed, but that should only blur thing for older releases right?
16:13:08 <marcelr> well we got out of scope a bit
16:13:13 <ashimema> it's not just rmaint burden either.. I've often found myself having to write patches for multiple versions.. sometimes they differ rally quite a lot.. the less parallel versions we support the more reliable we can get I feel
16:13:19 <ashimema> but yeah.. lets move on.
16:14:07 <tuxayo> What's the next step to plan about the topic?
16:14:29 <marcelr> a proposal on the wiki?
16:14:32 <tuxayo> So it doesn't stay in limbo
16:14:42 <cait1> +1
16:15:23 <tuxayo> Who to draft one or several workflow proposals on the wiki?
16:15:39 <tuxayo> I can participate
16:16:10 <thd> ashimema writes a definition of LTS along which includes a path from some current or forthcoming release.
16:16:24 <marcelr> [off] htg
16:17:43 <ashimema> I can try to knock something together.. or at least ask rangi or someone what their intentions were
16:18:02 <cait1> i thik we just need a starting point
16:18:19 <ashimema> I think, as a company, we're unlikely to actually use the LTS notion.. customers aren't keen on software that ages that much
16:18:24 <cait1> once you start writing it gets a little easier
16:18:31 <ashimema> ok.. i'll draft something
16:18:57 <thd> ashimema: If customers are not keen, how will it really be supported properly?
16:19:20 <cait1> i think thre are just different use cases
16:19:23 <tuxayo> There are multiple involved actor here
16:19:26 <cait1> a self supported library might be keen on an LTS
16:19:41 <ashimema> well ptfs-e is unlikely to be lending a hand.. doesn't mean other companies may not take a different stance/cadence
16:19:41 <cait1> or more i think they will be
16:19:45 <ashimema> indeed
16:19:47 <cait1> and we will probably consider it at least
16:19:55 <reiveune> bye
16:20:02 <ashimema> yup.. there are certainly people out there
16:20:34 <ashimema> we generally have been trying to move to annual feature upgrades
16:20:37 <thd> I understand the rationale for the self supported, but they need strong advocacy.
16:21:06 <cait1> we know they are there... and for smaller support proivders it cuold also well be an option
16:21:13 <ashimema> so an LTS of 3 years or something wouldn't sit well with customers.. many already don't like having to wait for their sponsored features
16:21:20 <cait1> it really depends on your environment, resources etc.
16:21:34 <ashimema> indeed
16:21:37 <ashimema> I'm totally not against it
16:21:42 <cait1> not toally? ;)
16:21:51 <ashimema> lol
16:21:55 <ashimema> right.. moving on..
16:21:59 <cait1> it is a chance to talk about how we do things too of course
16:22:00 <ashimema> what's next tuxayo?
16:22:14 <tuxayo> >  there are certainly people out there
16:22:14 <tuxayo> Yes, like Catalyst that support 19.11 even if they aren't using it and I support oldoldstable without providing it too. So no worries as long as it requires 3 RMaint
16:22:51 <tuxayo> #action ashimema drafts an LTS proposal. (tuxayo can help!)
16:22:58 <tuxayo> #topic  Set time of next meeting
16:23:56 <tuxayo> It would be the 2 february then
16:24:02 <tuxayo> same time I supose
16:24:57 <ashimema> lol.. I started to try and get a discussion going about this in 2019: https://wiki.koha-community.org/wiki/Koha_Versioning_-_Next
16:25:09 <tuxayo> lol
16:25:11 <tuxayo> #info Next meeting: 2 February 2022, 15:00 UTC
16:25:22 <tuxayo> #endmeeting