14:02:34 <tuxayo> #startmeeting Development IRC meeting 22 June 2022 14:02:34 <huginn> Meeting started Wed Jun 22 14:02:34 2022 UTC. The chair is tuxayo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:34 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:34 <huginn> The meeting name has been set to 'development_irc_meeting_22_june_2022' 14:02:54 <tuxayo> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_22_June_2022 Today's agenda 14:03:07 <tuxayo> #topic Introductions 14:03:08 <nugged> o/ 14:03:09 <ashimema> #info Martin Renvoize, PTFS Europe, UK 14:03:14 <oleonard> #info Owen Leonard, Athens County Public Libraries, Ohio, USA 14:03:20 <liliputech> #info Arthur Suzuki, BibLibre, France 14:03:31 <tcohen> #info Tomás Cohen Arazi, Theke Solutions, Argentina 14:03:40 <nugged> #info Andrii Nugged, National Library of Finland, Helsinki, FI 14:03:54 <thd> #info Thomas Dukleth, Agogme, New York City 14:04:05 <tuxayo> #info Victor Grousset, Tuxayo VZW, France 14:04:32 <kidclamp> #info Nick Clemens, ByWater Solutions 14:06:15 <ashimema> shall we move on? 14:06:55 <ashimema> unlikely to get davidnind right.. he put something on the agenda but it's poor timing for him 14:07:03 <tcohen> yes 14:07:30 <tuxayo> #topic Announcements 14:07:51 <tuxayo> Anything to announce that doesn't fit better the other topics? 14:07:53 <koha-jenkins> Project Koha_Master_U22 build #101: SUCCESS in 1 hr 5 min: https://jenkins.koha-community.org/job/Koha_Master_U22/101/ 14:08:28 <cait1> #info Katrin Fischer, BSZ, Germany 14:08:44 <tuxayo> #topic Update from the Release Manager (22.05) 14:08:54 <tuxayo> tcohen: 🎙️ 14:09:47 <tcohen> hi 14:10:21 <tcohen> We have passed string freeze for the stable releases, and several bugfixes have been pushed for 22.05 14:10:34 <tcohen> I will start integrating enhancements and new features soon 14:10:46 <tcohen> will try to not touch sensible areas that have outstanding bugs 14:10:52 <tcohen> on the first weeks 14:11:47 <ashimema> long live the new rm 14:11:50 <tcohen> Devs should looks at the roadmap and add the things they want to work on 14:12:13 <tcohen> I'm open to chat/video call with people willing to engage team work 14:12:15 <lukeg> #info Lucas Gass, ByWater Solutions 14:12:17 <tcohen> if required 14:12:31 <cait1> tcohen++ 14:12:51 <liliputech> tcohen++ 14:13:15 <ashimema> tcohen++ 14:14:21 <tuxayo> Anything else tcohen ? 14:15:19 <tcohen> I would like to mention the new 'ktd' command in KTD 14:15:21 <nugged> wow 14:15:25 <tcohen> will send an email about it 14:15:42 <tcohen> would like testers to try it before we tweak the docs 14:16:12 <nugged> tcohen+=3; from all our FI team (I can represent, yes) 14:16:25 <tcohen> https://gitlab.com/koha-community/koha-testing-docker/-/issues/300 14:16:36 <tcohen> it is already merged and can be used 14:17:06 <tuxayo> tcohen++ 14:17:48 <cait1> what does ktd do? 14:17:48 <tuxayo> #info Testers needed for new koha-testing-docker management script. See https://gitlab.com/koha-community/koha-testing-docker/-/issues/300 14:18:32 <tcohen> cait1: it replaces the aliases 14:18:42 <tcohen> or aliases could be rewritten in terms of it 14:18:56 <tcohen> the issue describes a usability problem we have for daily stuffs 14:20:07 <tuxayo> When using various images (for es versions for example) one had to manually pick the right docker-compose.yml files to update the images. 14:20:13 <koha-jenkins> Project Koha_Master_U20 build #446: UNSTABLE in 36 min: https://jenkins.koha-community.org/job/Koha_Master_U20/446/ 14:20:34 <cait1> just please write easy to read docs :) 14:20:39 <cait1> I'll read those then 14:21:00 <tcohen> the README will get hughly simplified 14:21:05 <tuxayo> ++ 14:21:08 <cait1> +1 14:21:13 <cait1> don't let me hold up things 14:21:15 <cait1> move on? 14:21:38 <tuxayo> If there is something else, we can come back later 14:21:39 <tuxayo> #topic Updates from the Release Maintainers 14:21:43 <tuxayo> rmaints? 14:21:43 <wahanui> rmaints are lukeg, liliputech and tuxayo 14:22:51 <liliputech> as of the release maintenance of 21.11, I'm almost ready to release the 21.11.07, just missing access to community wordpress and download site to push to. 14:22:54 <tuxayo> 1sts commits pushed so I have the rights on the branch and will be able to release on friday 14:25:00 <liliputech> i didn't pick bug30733 yet because it changes a lot the templates and i didn't feel very secure to add it this close to the release (lots of templates changes), but I'll work on it for 21.11.08 (be nice with translators). 14:25:08 <tuxayo> I need to investigate some some failures on Ubuntu 16.04 that I inherited otherwise, that's all 14:25:34 <tuxayo> liliputech: you need to contact gmcharlt rangi or Liz Rea according to https://wiki.koha-community.org/wiki/Website_Administration#download.koha-community.org 14:25:43 <tuxayo> for download 14:25:48 <cait1> bug 30733 14:25:48 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30733 enhancement, P5 - low, ---, victor, Pushed to stable , Simplify translatable strings 14:25:54 <liliputech> sent an email to liz just minutes ago :) 14:25:56 <cait1> i think I wouldn't push that one 14:25:56 <ashimema> is it actualyl worthwhile backporting 30733 any further.. ? 14:26:12 <ashimema> ha.. great minds 14:26:14 <cait1> it creates a lot of work for translators 14:26:21 <tuxayo> ashimema totally not 14:26:24 <cait1> and the later the version the more unlikley people keep up 14:26:25 <tuxayo> It's a mess ^^ 14:26:30 <liliputech> if it's not i can manage not to work on it ;) 14:26:32 <ashimema> I don't think we should.. it would do the oposite of what it tries to do.. get translators to re-translate a lot 14:26:37 <tuxayo> 30733 was only for 22.05 14:26:48 <cait1> yep, I think it's good there 14:26:49 <liliputech> ok, then i will resolve-fix that one :) thx! 14:26:56 <ashimema> it's great for the case where they've not already translated much.. but that your points in the cycle it should be left out. 14:26:57 <ashimema> coolios 14:26:58 <cait1> but it took me a few hours to go through 14:27:09 <tuxayo> For earlier versions it would be bad for translators to have so much work so late in the life cycle 14:27:18 <tuxayo> cait++ 14:27:23 * liliputech applause 14:27:25 <ashimema> brill 14:27:33 <cait1> so we all agree, less work for liliputech :) 14:27:39 <liliputech> \o/ 14:28:35 <tuxayo> liliputech: for other patches, if it meets the backport criteria in the RMaint doc but it conflicts, just let a message that if someone needs it they should provide a backport. 14:29:19 <tuxayo> liliputech: I think you said you had issues with bug 30717 so just write that in the ticket 14:29:19 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30717 major, P5 - low, ---, jonathan.druart+koha, Pushed to master , Dates displayed in ISO format when editing items 14:29:42 <tuxayo> moving on? 14:29:47 <ashimema> ++ 14:29:47 <tcohen> +1 14:29:49 <liliputech> tuxayo: when it's small conflicts, i tend to fix them, but yes, sometime i just cannot guess what is the "proper" way to fix, then I would ask for help :) 14:29:50 <tuxayo> #topic Updates from the QA Team 14:30:02 <tuxayo> qa_team? 14:30:02 <wahanui> i heard qa_team was cait, marcelr, khall, kidclamp, kohaputti, lukeg, aleisha, fridolin, ashimema, tuxayo, nugged, petrova and Joubu 14:30:36 * ashimema is a little behind this month.. lots of meetings.. 14:30:51 <tuxayo> > small conflicts, i tend to fix them, but yes, sometime i just cannot guess what is the "proper" way to fix, then I would ask for help :) 14:30:51 <tuxayo> That's the way, ask for help and then forget about it, just don't miss your bugzilla notification in case someone steps up 14:31:04 <ashimema> * 65 submissions in the queue, 24 of them bugs 14:31:21 <cait1> yep, PLEASE QA! 14:31:35 <koha-jenkins> Project Koha_Master_D11_MDB_Latest build #967: SUCCESS in 43 min: https://jenkins.koha-community.org/job/Koha_Master_D11_MDB_Latest/967/ 14:31:44 <ashimema> be nice to get that first number back down under 50.. and we should strive to keep the bugs number lower 14:31:56 <cait1> I highlighted bad bugs in the Monday email, there is still quite a few 14:31:58 <ashimema> I think I'm locked out of a number of the bugs.. 14:32:06 <cait1> new ones, not the old ones.... 14:32:45 <cait1> also some bad bugs in Needs Signoff to grab for everyone and help us processing them 14:33:32 <ashimema> bug 29325 in particular would be good to get some eyes on. 14:33:32 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29325 critical, P5 - low, ---, nick, Signed Off , commit_file.pl error 'Already in a transaction' 14:33:41 <cait1> yes, please! 14:34:28 <cait1> and please also check the security project - they don't show up on dashboards - they will be visible in the saved lists and have permission/are logged in 14:34:37 <ashimema> also bug 30889 (or help moving the alternative Joubu suggested forward.. that one's on my list) 14:34:37 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30889 major, P5 - low, ---, martin.renvoize, Signed Off , Background jobs lead to wrong/missing info in logs 14:34:37 <cait1> all QA team members have access to anything security by default 14:35:24 <tuxayo> Not QA specifically but signoffs: I'm launching SO sessions with french speaking librarians (and will do in english if that works well) Does anyone have contacts with Koha users in Africa? 14:35:25 <tuxayo> Because most french speakers are actually there and it would be a good way to strengthen the librarian community. 14:35:54 <ashimema> Great initiative tuxayo 14:37:48 <cait1> tuxayo++ 14:37:52 <cait1> maybe you could ask rangi 14:38:00 <tuxayo> #info anyone who have contacts of Koha users in french speaking Africa contact victor AT tuxayo DoT net so we can make patch testing session with librarians 14:38:17 <tuxayo> cait1: good idea 14:38:26 <tuxayo> #topic Status of roadmap projects 14:38:39 <tuxayo> #info https://annuel.framapad.org/p/koha_22.11_roadmap 14:39:41 <thd> I have not yet added wiki db migration and update to the new roadmap. 14:39:50 <tcohen> please do thd 14:40:03 <thd> I updated https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23073 14:40:03 <huginn> 04Bug 23073: normal, P2, ---, td-koha-bugs, NEW , wiki.koha-community.org needs updating to a later version 14:40:11 <tcohen> do you have help from other community members? 14:40:24 <tcohen> I know some volunteered to help in past meetings 14:41:06 <ashimema> lots of us waiting and wanting to help 14:41:09 <thd> Yes, mtj is working on automated validation that the data migrated without errors was actually migrated without errors and not dropped somewhere. 14:41:29 <cait1> I'll try to have a look at the testing site tomorrow 14:41:29 <tcohen> do we have a timeframe? 14:41:45 <cait1> but maybe others could help too? we had discussed this earlier on IRC this morning 14:42:02 <thd> git://test01.agogme.com/koha-migrate-mwiki-db-and-upgrade-test.git is now up. 14:42:51 <cait1> thd++ mtj++ 14:43:10 <thd> That may be a message of the sort one sees for several days after reinstallation while some processes run gradually. 14:43:19 <thd> oops 14:43:47 <koha-jenkins> Yippee, build fixed! 14:43:48 <koha-jenkins> Project Koha_Master build #2070: FIXED in 1 hr 9 min: https://jenkins.koha-community.org/job/Koha_Master/2070/ 14:43:48 <wahanui> Congratulations! 14:44:20 <thd> Reinstalled test instance of the Koha Wiki using Postgres at https://koha-mw-pg-test01.agogme.com/ . 14:44:21 <thd> Koha test wiki migrated to MySQL at https://koha-mw-my-test01.agogme.com/ . 14:44:21 <thd> Koha MySQL test wiki upgraded to MediaWiki 1.35 LTS at https://koha-mw-my-test01-upgr.agogme.com/ . 14:45:08 <thd> Be mindful that various work will take those down and regenerate or slow them down at times. 14:45:35 <tcohen> thd: have you pondered a dockerized setup? 14:45:41 <thd> Those test instances have been mostly up for over a year. 14:45:51 <tcohen> we have a big server that is only serving koha-api-docs right now 14:45:57 <tcohen> and I can arrange you access to it 14:46:49 <thd> I have never learned enough of docker to actually use it for anything. 14:47:26 <tcohen> ok, but if we managed to set a running MediaWiki instance there 14:47:41 <cait1> I think we shoudl not change the process too much now 14:47:41 <tcohen> it would be a matter of copying the files and loading the DB, right? 14:47:46 <cait1> let's finish it and then move to docker? 14:47:59 <ashimema> +1 14:48:19 <ashimema> did you bring across user acounts into your test? 14:48:20 <tcohen> agreed 14:48:24 <thd> It is somewhat more than copying the files and loading the DB. 14:48:25 <tcohen> sorry for the noise 14:48:27 <cait1> ashimema: i coudl log in 14:48:40 <ashimema> ok 14:48:41 <thd> I brought over everything. 14:48:57 <cait1> so let's say mtj declares the migration is good 14:49:07 <cait1> and we don't find anything too troublesome 14:49:16 <tuxayo> thd: looks great, what is missing? 14:49:25 <thd> There is no mail server running on my VPS so you cannot change your password but everything works. 14:49:29 <cait1> do we define a 'cut off' date then and can we set the wiki to read only whiel we move? 14:49:38 <thd> Automated testing would be nice. 14:50:37 <thd> mtj said that he was working on automated testing since we discussed what was needed last meeting. 14:50:56 <tuxayo> Testing what? 14:50:56 <wahanui> i guess Testing is important :) 14:51:54 <cait1> yes, wahanui 14:51:54 <wahanui> yes is something different :) 14:51:58 <thd> Testing that the migration from Postgres to MySQL did not drop anything consequential other than cached values or indexes. 14:52:00 <tuxayo> XD 14:52:18 <thd> Nothing appears to be different. 14:52:29 <tuxayo> > Testing that the migration from Postgres to MySQL did not drop anything consequential other than cached values or indexes. 14:52:29 <tuxayo> Ah I see so to avoid subtle issues 14:53:08 <thd> There is an unpleasant warning when reloading the database from Postgres. 14:53:57 <thd> Yet my investigation finds no actual problem. 14:54:39 <tuxayo> Considering all looks great don't hesitate to drop the automated check if it turns out to be too hard. IHMO 14:54:52 <ashimema> +1 14:54:58 <ashimema> done with some minor bugs we didn't spot and can fix later is better than not done at all 14:55:04 <cait1> I am looking forward to clean up categories some 14:55:11 <ashimema> it's been ongoing since early 2019 from memory 14:55:35 <thd> Yes, the pandemic has wrecked my schedule. 14:55:36 <cait1> the new(?) editor for categories seems to work well (tested earlier) 14:56:12 <tuxayo> moving on? 14:56:20 <ashimema> was about to say that 14:56:26 <thd> I have a small fraction of the time I had before the pandemic. 14:56:39 <tuxayo> Thanks for the great news about the wiki thd++ 14:56:43 <tuxayo> #topic Actions from the last meeting 14:56:51 <tuxayo> « tuxayo add requesting access for ssh access for download.koha-community.org in Initial_setup of rmaint doc » 14:56:51 <tuxayo> done 14:56:55 <tuxayo> « davidnind to create bug to summarise discussions and next steps for LTS version of Koha » 14:56:57 <ashimema> lol.. we missed the whole of the existing roadmap stuff 14:57:00 <ashimema> no worries 14:57:28 <tuxayo> existing roadmap stuff? 14:57:35 <tuxayo> Ok I'll back to that in the general part 14:57:47 <tuxayo> david created bug 31008 14:57:47 <huginn> 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 14:57:47 <ashimema> no worries.. it can wait for next time 14:58:11 <cait1> I haven't read the bug yet 14:58:20 <cait1> but the idea was to label 21.11 LTS 14:58:22 <koha-jenkins> Project Koha_Master_D10 build #693: SUCCESS in 38 min: https://jenkins.koha-community.org/job/Koha_Master_D10/693/ 14:58:31 <cait1> with a promise to support it for... 2.5 years I think? 14:58:49 <cait1> Paul raised a question on the ML but not sure if ti's an issue 14:59:06 <cait1> I think someone running LTS Koha might also be more likely to go LTS on the OS? 14:59:47 <cait1> I don't think too many issues shoudl be expected there in terms of dependency issues? 15:00:14 <tuxayo> Looks okay when I see for oldoldstable since 2 years 15:00:56 <tuxayo> I never had issues to switch a big depence 15:00:58 <reiveune> bye 15:01:03 <tuxayo> *dependence 15:01:16 <cait1> yes, I think we should just go with it 15:01:34 <cait1> the "test" wth 19.11 didn't bring up anything like it 15:01:42 <tuxayo> right! 15:01:42 <ashimema> yowsers.. is it not like 3am where you are davidnind 15:01:56 <tuxayo> yowsers? 15:02:11 <cait1> 5 am i think 15:02:14 <davidnind[m]> Apologies for only doing the bug/email yesterday... 15:02:18 <ashimema> it will heavily rely on volunteers from an already small pool supporting it 15:02:26 <tuxayo> davidnind++ 15:02:28 <cait1> thx for doing it davidnind++ 15:02:30 <davidnind[m]> 3am 😄 15:02:33 <ashimema> how do we pick which bersions become LTS 15:02:33 <tuxayo> thanks for the summary ^^ 15:02:56 * ashimema goes quiet as he's not read the details for ages and can't remember 15:03:01 <cait1> ah... 10 the other way 15:03:25 <cait1> ashimema: what we discussed last time was using oldstable 15:03:40 <ashimema> we can't always use 'oldstable' 15:03:44 <cait1> 2 years... jump to current oldstable 15:03:53 <cait1> no not always 15:03:55 <ashimema> ok 15:03:59 <cait1> there will be gaps of course 15:04:14 <ashimema> so once every two years we drop one LTS and replace it with whatever oldstable currently is 15:04:16 <ashimema> I see 15:04:25 <cait1> taht was the idea discussed 15:04:31 <ashimema> we'd certainly need to publish that clearly.. 15:04:41 <cait1> we are in the process :) 15:04:59 <ashimema> and make sure the RM overseeing that particular release when it first comes out is very much aware 15:05:23 <cait1> hm why? 15:05:29 <ashimema> I think it needs up front commitment at development time.. for it to be a really good LTS it likely needs a 6 month polish before release 15:05:33 <cait1> we get about 6 maint releases in 15:05:35 <tuxayo> By the time it because oldstable it should be polished 15:05:41 <ashimema> because LTS is always meant to be much more stable and reliable.. from day one 15:05:45 <cait1> that was the idea yes 15:06:02 <cait1> that's why we wanted to pick .6 15:06:02 <ashimema> in general an LTS release is LTS announced as LTS at release time 15:06:14 <tuxayo> > much more stable and reliable.. from day one 15:06:14 <tuxayo> If it not advertised as LTS on day one then we don't need that 15:06:32 <cait1> I don't think that's doable to be honest 15:06:44 <cait1> it will be the .6 release when it' announced 15:07:01 <cait1> or the .7 ... might be off by a month not sure 15:07:02 <ashimema> OK.. well.. if there are people wanting to take it on.. fine with me. 15:07:35 <ashimema> I would say we're not doing LTS.. we're doing a random Extended support 15:07:42 <cait1> I just think with manpower we have a super careful release is probably not on the map atm... people want new things etc, I understand the argument, but trying to find some middle ground 15:07:45 <ashimema> but hey.. that's just semantics 15:07:54 <cait1> we coudl also call it extended support 15:07:57 <cait1> but it won't be random 15:08:06 <cait1> goal is to put this into a schedule 15:08:48 <tuxayo> It's not convenient for people to have to upgrade from the LTS-1 to the new LTS a few months after their install but having a .00 labelled LTS would give worse results. 15:09:45 <cait1> if we make it predictable, that will give people the option 15:09:49 <tuxayo> wait, it's not and issue 15:10:07 * tcohen needs to leave to feed the kids 15:10:24 <tuxayo> Because when the LTS is oldstable and oldoldstable, it's maintained by the usual RMaint 15:10:38 <tuxayo> So the real LTS-1 is still maintained 15:11:06 <tuxayo> So there is not the issue to have to do a major upgrade a few months after installing an LTS 15:11:44 <cait1> we might need to do a graphic 15:11:46 <cait1> my head hurts 15:11:55 <cait1> but I think extended support is a realyl great idea 15:12:21 <cait1> we do have some difficulty keeping up with the current schedule 15:12:22 <tuxayo> extended support is a good term also. 15:12:30 <cait1> yes, happy witht hat 15:12:38 <tuxayo> > keeping up with the current schedule 15:12:38 <tuxayo> What do you mean? 15:12:56 <cait1> [off] that we tend to get stuck on EOL versions 15:13:27 <tuxayo> Great, that confirms the need for an extended support/LTS version 15:13:41 <ashimema> so LTS gets 18month support 15:13:44 <tuxayo> #info consider naming extended support instead of LTS 15:13:51 <ashimema> as it only become LTS after 6 months of release 15:13:53 <cait1> the idea was 2 years to 2.5 actually 15:13:53 <koha-jenkins> Project Koha_Master_D12 build #174: STILL UNSTABLE in 1 hr 5 min: https://jenkins.koha-community.org/job/Koha_Master_D12/174/ 15:13:54 <ashimema> right? 15:13:59 <tuxayo> > 18month support 15:13:59 <tuxayo> That's the normal thing. 15:14:23 <cait1> I will try to draw it 15:14:26 <ashimema> so 2 years would mean maintaining it for 2.5 years right 15:14:36 <cait1> for the 21.11 example 15:14:42 <ashimema> because it's only LTS after the first 6 months of maint 15:14:57 <cait1> yeah you coudl phrase it like that 15:14:59 <cait1> i think 15:15:11 <tuxayo> > it's only LTS after the first 6 months of maint 15:15:11 <tuxayo> It's actually LTS only after 18 months of RMaint, that when the LTS RMaint take over 15:15:12 <ashimema> so by the end of LTS support someone would be running a feature stable software written 2.5 years before 15:15:20 <ashimema> ok.. I can sorta understand theat.. 15:15:27 <koha-jenkins> Yippee, build fixed! 15:15:27 <koha-jenkins> Project Koha_Master_U20 build #447: FIXED in 43 min: https://jenkins.koha-community.org/job/Koha_Master_U20/447/ 15:15:27 <wahanui> Congratulations! 15:15:33 <ashimema> and they need to upgrade every 2 years 15:15:46 <ashimema> nah 15:15:55 <ashimema> it's LTS the moment it's deemed to be the LTS we're going to support 15:16:11 <tuxayo> #action cait try to draw how extended support/LTS would work 15:16:14 <cait1> maybe calling it extended support we could call it that from day one? 15:16:18 <cait1> heh 15:16:20 <cait1> thx 15:16:22 <ashimema> if it's only LTS when they maint takes it on then it's actually only 6 months or whatever 15:16:44 <cait1> let's postpone and think it over? 15:16:56 <tuxayo> ashimema: the LTS RMaint add more than 6 months 15:16:58 <cait1> i think another 2 weeks is not going to kill it 15:17:07 * ashimema would still have prefered to see effort go into stabalising code earlier, more CI and creating a rolling release 15:17:49 <ashimema> lets move on 15:17:53 <tuxayo> > call it that from day one? 15:17:53 <tuxayo> Wouldn't it be a less good experience if people needing an extended support install a .00 ? 15:18:46 <tuxayo> > ashimema would still have prefered to see effort go into stabalising code earlier, more CI and creating a rolling release 15:18:46 <tuxayo> You can throw brainpower here: https://wiki.koha-community.org/wiki/LTS_workflow_proposal 15:18:46 <tuxayo> Warning, it's draining ^^ 15:19:03 <tuxayo> « davidnind request feedback for the above on the mailing list with next dev meeting (two weeks from now) as a deadline » 15:19:04 <tuxayo> done 15:19:10 <tuxayo> on koha-devel 15:19:21 <tuxayo> « liliputech discuss koha CI (docker image built + manuall build) hosting on gitlab instance provided by BibLibre's partner AFI. » 15:20:55 <tuxayo> #action liliputech discuss koha CI (docker image built + manuall build) hosting on gitlab instance provided by BibLibre's partner AFI. 15:21:04 <tuxayo> #topic General development discussion (trends, ideas, ...) 15:21:06 <liliputech> tuxayo: about this, people at AFI said it might be OK to host a mirror on our gitlab instance, I just got a warning about ressource use (do we have any estimation for CPU/memory use?) 15:21:40 <tuxayo> > host a mirror 15:21:40 <tuxayo> not needed IIUC 15:21:55 <tuxayo> It's about CI runners 15:22:20 <tuxayo> liliputech++ thanks for asking 15:22:42 <liliputech> i need more info about ressource usage to move on, and some clues about how to build a runner. 15:23:22 <liliputech> would it need people external to biblibre to have an account on our gitlab? 15:23:32 <liliputech> (like push access?) 15:23:37 <ashimema> I don't believe so 15:23:53 <tuxayo> My guess is that you can note to ask tcohen and mtj about ressources. 15:23:59 <ashimema> I'm confused.. not sure who asked for what 15:24:30 <ashimema> My understanding is we're struggling for CI resource for some of the bigger builds basically.. so it's s docker runner 15:24:39 <ashimema> the code is hosted fine where it is 15:24:49 <tuxayo> Yes, code is fine 15:25:29 * ashimema needs to disappear soon.. kids duties 15:25:40 <liliputech> ok. I will ask tcohen. we've build a runner for other use (other than koha) not so long ago, we could do it once more, but I guess there are tokens or other stuff we need. 15:25:57 <Joubu> it's a 5min job 15:26:05 <tuxayo> One solution would be to host a portainer node on AFI/BibLibre infrastructure and then we can put any docker container there. tcohen manages the portainer thing. 15:26:37 <tuxayo> moving on? 15:27:12 <tuxayo> «New status for development work flow and dashboard - 'Needs documenting' (see bug 30998) » 15:27:12 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30998 enhancement, P1 - high, ---, david, ASSIGNED , [DOCS] Managing documentation tasks - simplify processes and integrate more with the development process 15:28:14 <ashimema> Basically.. have a look at the proposal on the bug.. we're already trialling some of it.. 15:29:06 <cait1> sorry, I have to leave, have a nice 'day' everyone :) 15:29:06 <ashimema> there's a new status on bugzilla, 'Needs documenting' akin to 'Needs signoff' that sits after 'Pushed to X' and before 'Resolved'.. that status is being used to populate a todo list and status list on the dashboard so far 15:29:32 <tuxayo> Great, I see RMaints are mentioned so homework is to read the ticket 15:29:34 <tuxayo> rmaints? 15:29:34 <wahanui> rmaints are lukeg, liliputech and tuxayo 15:29:36 <tuxayo> ↑ 15:30:06 <tuxayo> (Great was about things being trialled) 15:30:33 <ashimema> it's to give docs people a clear list of bugs to work through... and to help spread the load keeping on top of it... so rather than the docs manager having to maintain out of band lists and look at every bug.. docs team can work through the list and get 'points' be submitting docs or making the decision that a particular bug doesn't need any docs changes and so can just be marked resolved 15:31:15 <ashimema> for Rmains the main change is 'use "Needs documenting" where you would have used 'Resolved Fixed' in the past. 15:31:30 <tuxayo> ok 15:31:40 <ashimema> lucasg is already on board with it and the majority of these will hit him first 15:32:38 <liliputech> most of the thing I'll put on my branch are already documented isn't it? 15:32:47 <ashimema> what I'm still not sure about is the docs team side bits.. whether we should track submission + pushed states somehow in bz side.. to build more lists on the dashboard 15:32:48 <liliputech> (mine being 21.11) 15:32:57 <ashimema> well.. they 'should be' liliputech 😜 15:33:09 <liliputech> hum ^^ 15:33:47 <ashimema> keep doing what your doing.. if a bug hits you that you push.. use 'Pushed to X'.. if a bug hits you that you decide not to backport use 'Needs documenting'.. then the docs team will come along and make the final step to 'Resolved fixed'.. 15:33:52 <tuxayo> liliputech: IIUC So it's when not backporting due to issues or not important enough, we use "Needs documenting" instead of "Resolved Fixed" 15:34:07 <liliputech> I also work on another software, documentation is part of the workflow for proposing an enhancement. that means, no dev can reach code-base without documentation. 15:34:13 <ashimema> it puts it on them to check if there's a new syspref or change of behavour that aught to be documented 😜 15:34:24 <ashimema> yeah.. I tried that 15:34:33 <tuxayo> > no dev can reach code-base without documentation 15:34:33 <tuxayo> Not the case in Koha 15:34:36 <ashimema> didn't get much support 15:35:03 <ashimema> devs don't like documenting and we already have a really long lead time for code to get in with our SO + QA queues.. 15:35:19 <ashimema> adding in 'Failed QA, no docs' was seen to put people off more.. 15:35:24 <ashimema> which is a shame 15:35:33 <liliputech> but, whose at the best place for documenting than the dev who provides the code? 15:35:40 <tuxayo> Indeed 15:35:50 <ashimema> true 15:35:53 <liliputech> s/whose/who is/ 15:35:56 <liliputech> . 15:36:10 <ashimema> feel free to propose that alternative 15:36:17 <liliputech> in the bz? 15:36:37 <ashimema> I have a hard enough time persuading people to upstream code 😜 15:36:40 <ashimema> yeah.. it's as good a place 15:38:58 <davidnind[m]> this would at least make it a more visible part of the process - pushed to x, then needs documenting 15:39:20 <tuxayo> maybe we could have a status "Failed QA, missing documentation" which the documentation team could also unblock for the oldest ones. 15:39:20 <tuxayo> I can add that to the ticket also. 15:39:42 <ashimema> our process also means that often the feature changes allot between initial submission and pqa.. when that's the case you really need to document at the end else it's just another thing to constantly be adapting throughout the process.. but if you submit it at the end and the code isn't pushed once it's PQA it adds another burden to the dev to also keep rebasing the code and likely another QA run when the rebases aren't trivial.. 15:40:01 <ashimema> we've often seen code pushed that's pretty functionally broken because of a lag between PQA and actual Push 15:40:19 <tuxayo> > and the code isn't pushed once it's PQA it adds another burden to the dev to also keep rebasing the code and likely another QA run when the rebases aren't trivial.. 15:40:19 <tuxayo> right >_< 15:40:33 <liliputech> added my 2 cents on the bz 15:40:45 <ashimema> I did propose a requirement for docs submissions alongside dev submissions back when I was RM 😜 15:40:55 <davidnind[m]> I don't think we would want to be a blocker for changes getting into Koha 15:40:59 <tuxayo> liliputech++ 15:41:01 <ashimema> so I do like the idea liliputech.. just explaining why my proposal failed when it did back then 15:41:24 <ashimema> wow.. me being RM feels like a long time ago now 15:41:31 <tuxayo> moving on? 15:41:38 <ashimema> yup 15:41:52 <tuxayo> ashimema: you had something I skipped earlier 15:41:57 <tuxayo> I can note for next meeting 15:41:58 <davidnind[m]> ashimema++ 15:42:03 <liliputech> hu. ashimema it fails because there is too much lag between submission and push :( 15:42:11 <tuxayo> it was about roadmap 15:42:16 <liliputech> but I get the point 15:42:38 <ashimema> Mmm 15:42:46 <liliputech> and everyone's doing one's best already 15:43:08 <ashimema> Koha does move fast really.. but as a Dev it can feel glacial at times 15:43:10 <tuxayo> liliputech: adding documentation step will ensure that there is a lag between PQA and push. Which might be too bad. 15:43:57 <liliputech> humm. maybe doc could be done after pqa? 15:44:24 <tuxayo> ashimema: «we missed the whole of the existing roadmap stuff» 15:44:31 <liliputech> (still needed for a push to master) 15:44:42 <ashimema> Lol.. that's basically what this proposal does 15:44:49 <ashimema> Hmm. 15:44:57 <liliputech> \o/ 15:45:01 <tuxayo> No because liliputech propose that it's still the dev that does it IIUC 15:45:04 <ashimema> No, the lag between pqa and push is part of the problem 15:45:25 <ashimema> A dev can do docs certainly.. and I often try to 15:45:36 <ashimema> Often during Dev as a test plan as such 15:45:50 <ashimema> But their also rather different skill sets 15:45:55 <liliputech> never worked on new features in koha... 15:46:07 <tuxayo> There is no strong obligation for the dev to do so since the code is merged. But some will do it and if it drags for too long the documentation team take over. 15:46:09 <ashimema> Sphinx etc 15:46:26 <ashimema> It's not just new features.. every change submitted might affect docs.. 15:46:48 <liliputech> but if i had to : its not so more job to write the doc, than to explain your code to someone who's going to write the doc for u. 15:46:53 <ashimema> There's are often subtle but meaningful changes of behaviour that may need clarifying in docs when bugfixes are pushed 15:47:03 <liliputech> true 15:47:06 <ashimema> New sysprefs introduced etc 15:48:36 <tuxayo> Anything else on any topic? (we might note them for next meeting) 15:49:33 <davidnind[m]> please add any comments you have to the bug or email me, or discuss on IRC 15:49:59 <thd> Yes ... 15:50:39 <tuxayo> go on thd 🎙️ 15:51:03 <thd> If anyone has deep insight into a pgrestore warning WARNING: ftell mismatch with expected position . 15:52:09 <thd> please let me know. That is the only concerning thing in my logs but silent errors could be possible. 15:52:15 <davidnind[m]> #info Add any comments and feedback on the "Needs documenting" status and work flow to bug 30998 15:52:15 <huginn> 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30998 enhancement, P1 - high, ---, david, ASSIGNED , [DOCS] Managing documentation tasks - simplify processes and integrate more with the development process 15:52:47 <tuxayo> #info contact thd if you can help with the wiki upgrade which hits this warning: "WARNING: ftell mismatch with expected position" 15:54:12 <tuxayo> #topic Set time of next meeting 15:54:47 <thd> That is before any upgrade and merely on restoring the Postgres dump to Postgres . 15:55:04 <tuxayo> #info Next meeting: 6 July 2022, 21 UTC 15:55:23 <tuxayo> That was what was discussed on last Oceania + Americas meeting 15:55:46 <tuxayo> For the next Americas + Europe meeting, same hour? 15:56:16 <tuxayo> The 20th of July it would be 15:56:31 <tuxayo> Let's say that for now. reach out if a change is needed 15:56:36 <tuxayo> #endmeeting