Time Nick Message 23:01 huginn dcook: The operation succeeded. 23:01 dcook @later tell Joubu yep 26231 is ready for testing. Must've forgotten to switch its status. I do it manually as git bz often crashes if I try it there... 22:25 wshealy hey 22:05 wshealy Hi 19:45 tcohen hahaha 19:41 caroline and of course, there's echo "You're welcome! come! come! come!" 19:40 * oleonard-away shouts 'You're welcome!' as he rides off into the sunset 19:38 tcohen thanks oleonard 19:38 * tcohen didn't know 19:38 tcohen :-D 19:36 oleonard Is "Disable HTTP Cache (when toolbox is open)" set tcohen? 19:36 sf_adam any thought on how I Reset my db (reset_all) 19:32 tcohen it is, but I expect to see cache hits 19:32 oleonard tcohen is it because the developer tools pane is open? 19:24 tcohen is it me or Koha isn't caching anything on the browser? 19:23 sf_adam can someone please explain mor ehow I do these things: Reset your db (reset_all) or drop your db and run the web installer 19:23 sf_adam which has a solution as follows: Before you apply the patch: - Check the "MARC bibliographic framework test" page - Ideally you should see the "wrong tab" mistakes - Reset your db (reset_all) or drop your db and run the web installer - Verify the page no longer points out any issues 19:23 huginn Bug 26018: minor, P5 - low, ---, katrin.fischer, Needs Signoff , Not all subfields for the following tags are in the same tab (or marked 'ignored') 19:23 sf_adam I seem to have the following bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26018 16:38 koha-jenkins Project Koha_Master_U20 build #79: FIXED in 1 hr 17 min: https://jenkins.koha-community.org/job/Koha_Master_U20/79/ 16:38 wahanui Congratulations! 16:38 koha-jenkins Yippee, build fixed! 16:28 koha-jenkins Project Koha_Master_D10 build #334: SUCCESS in 44 min: https://jenkins.koha-community.org/job/Koha_Master_D10/334/ 15:44 koha-jenkins Project Koha_Master_D10 build #333: FIXED in 44 min: https://jenkins.koha-community.org/job/Koha_Master_D10/333/ 15:44 wahanui Congratulations! 15:44 koha-jenkins Yippee, build fixed! 15:31 koha-jenkins Project Koha_Master_D10_Deps build #59: FIXED in 43 min: https://jenkins.koha-community.org/job/Koha_Master_D10_Deps/59/ 15:31 wahanui Congratulations! 15:31 koha-jenkins Yippee, build fixed! 15:13 koha-jenkins Project Koha_Master_U18 build #878: STILL UNSTABLE in 59 min: https://jenkins.koha-community.org/job/Koha_Master_U18/878/ 15:09 reiveune bye 14:59 koha-jenkins Project Koha_Master_D9 build #1415: FIXED in 49 min: https://jenkins.koha-community.org/job/Koha_Master_D9/1415/ 14:59 wahanui Congratulations! 14:59 koha-jenkins Yippee, build fixed! 14:47 koha-jenkins Project Koha_Master_D9_MDB_Latest build #372: FIXED in 46 min: https://jenkins.koha-community.org/job/Koha_Master_D9_MDB_Latest/372/ 14:47 wahanui Congratulations! 14:47 koha-jenkins Yippee, build fixed! 14:41 kohaputti cait, ok 14:41 cait sorry, too many things... and running out, just now to meet for coffee... hopefully it will help :) 14:40 cait this doesn't change any logic, so i left it in signed off 14:40 cait usually we don't require another sign-off for follow ups in QA that are not too bad 14:39 cait and only string changes 14:39 cait the second patch was an rm request 14:39 cait checking the history 14:39 cait probably, sorry 14:37 huginn Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25630 enhancement, P5 - low, ---, katrin.fischer, Signed Off , More capitalization and terminology fixes for system preferences 14:37 kohaputti cait, in similar bug 25630 the patches are from david 14:35 koha-jenkins Project Koha_Master_U20 build #78: FAILURE in 1 hr 16 min: https://jenkins.koha-community.org/job/Koha_Master_U20/78/ 14:33 kohaputti cait, hmm it says your name as the author and there is no sign-off, maybe you are talking about different bug/patch? 14:32 cait i only rebased 14:32 cait the last one is from david not from me 14:32 cait kohaputti: i signed it i think? 14:31 cait Joubu: i'd be happy if you did that 14:26 Joubu that was a /query! 14:26 Joubu lol 14:26 huginn Joubu: The operation succeeded. 14:26 Joubu @later tell oleonard-away Hi Owen, I want to let you know I did something weird on purpose: 14:21 Joubu cait: I can push if you want me too. I test to install in de-DE, if it works I push? 14:14 kohaputti cait, forget the question, I updated the status – I tried to sign-off but it didn't apply anymore 14:14 koha-jenkins Project Koha_Master_U16 build #51: FIXED in 58 min: https://jenkins.koha-community.org/job/Koha_Master_U16/51/ 14:14 wahanui Congratulations! 14:14 koha-jenkins Yippee, build fixed! 14:10 koha-jenkins Project Koha_Master_D9_My8 build #396: STILL UNSTABLE in 52 min: https://jenkins.koha-community.org/job/Koha_Master_D9_My8/396/ 14:10 huginn Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26015 enhancement, P5 - low, ---, katrin.fischer, Signed Off , Terminology: staff interface should be used everywhere 14:09 kohaputti cait, should bug 26015 be Need SO given the last huge patch is not reviewed yet? 14:09 cait not enough German devs and testers... 14:09 cait Joubu: yes, the 2 patches still in NSO 14:00 koha-jenkins Project Koha_Master_D11 build #72: FIXED in 44 min: https://jenkins.koha-community.org/job/Koha_Master_D11/72/ 14:00 wahanui Congratulations! 14:00 koha-jenkins Yippee, build fixed! 13:59 Joubu cait: the de-DE for 20.05? 13:58 cait i love consistency... guess i am boring wahnui 13:58 cait yea good enough for me 13:58 wahanui consistency is boring... 13:58 marcelr consistency ? 13:58 marcelr cait in Koha cancellation wins by far: git grep them both 13:57 cait yes, that is wrong 13:57 marcelr reasion ? 13:57 cait iwth ll and l 13:56 cait marcelr: both are valid... i had looked it up sometime 13:56 wahanui marcelr: Jupiter is aligned with Mars. 13:56 marcelr excuse me 13:56 tcohen WTF 13:56 marcelr cancellation reason please 13:55 cait CORONA? :) 13:55 marcelr spelling ! 13:55 marcelr cancelation reasion HORRIBLE 13:55 cait I really want to talk someone into testing my patches for the existing installer files before we move them :( 13:55 cait Joubu: i will try to catch up later 13:20 huginn Joubu: The operation succeeded. 13:20 Joubu @later tell dcook Is 26231 ready for testing? 13:16 huginn News from kohagit: Bug 25534: Update database <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=f840342c0a5eb39dfe7aa045a85fa55cb660a213> 13:16 huginn News from kohagit: Bug 25534: Add ability to send an email specifying a reason when canceling a hold <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=af0d71b7479432aeaf65dd61225b0d20c84cd360> 13:16 huginn News from kohagit: Bug 25534: Use the cancelation reasion for the 'X' hold cancelation links <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=27c80187ba55e801787a591d0d867921617d8339> 13:16 huginn News from kohagit: Bug 25534: Add reason to pendingreserves.pl <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=0b3f22710a45ccfcde8668494e2073ec8d51cdd8> 13:16 huginn News from kohagit: Bug 25662: Regression tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=9a63cf6dec55c67491e5a2807fe74f9083167ccc> 13:16 huginn News from kohagit: Bug 25662: Make the route for holds restpect maxreserves <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=69bdc94cd4f420094c5706fb2bfc472ba24a5054> 13:16 huginn News from kohagit: Bug 25662: (follow-up) Add tests for the wrong patron_id added behaviour <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=deee485a24df0734cace673dc519f15d41a5b575> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Add missing TT filters <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=61e00246803821dc2680ff740d7702fbef17bb60> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Unit tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=8afa136aee4a07a99d5ef0b46472391c0589f82a> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Add sample notice <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=a6042768ac87794b58b858dab5b52c3252b70cdf> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Add label to reason pulldown <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=563328d3cc37eb64d0eae9c268aa8312f7680e3d> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Add AV category <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=57bbb2861f0c0e2c8eca67d40ec07f46b5a476c8> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Add default values for new AV category <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=ab1d71c53daafb7bd35f84101cdad5402872e0ac> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Add sample notices for translators <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=0a7e3a264e0b3d73cbec51e34bbd9d7b8354c315> 13:16 huginn News from kohagit: Bug 25534: Use build_sample_item in tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=d574597473180006cf7e71679bd2f827245e2de2> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Update Koha::Hold::cancel POD <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=94df210c415dfac39cb778b6b400449461e04b41> 13:16 huginn News from kohagit: Bug 25534: (QA follow-up) Use modal for cancel links, hide reason unless priority... <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=1d19dccbb22b64690a7212708ef9e122276c6049> 13:16 huginn News from kohagit: Bug 25958: (QA follow-up) Implement filter in database query instead of in loop <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=66382458dc46356818473935e8d5546f13f05645> 13:16 huginn News from kohagit: Bug 25958: DBRev 20.06.00.028 <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=385a4cba44c5ac56d334d5ac4f8acd69d17375e9> 13:16 huginn News from kohagit: Bug 25534: DBRev 20.06.00.029 <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=0d64db87d7764855dcb1227eeed46002a02220fc> 13:16 huginn News from kohagit: Bug 25534: DBIC schema changes <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=352bc794d4bda2d39bdc0c9718f9cf3b31c5b070> 13:16 huginn News from kohagit: Bug 26265: add a plan for tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=88f64019536887c094b0178007d3583a048917f2> 13:05 Joubu I am expecting: 1. A geant warning in the log (we have a tiny line from log4perl), and 2. something meaningful on the about page 13:04 Joubu the problem here is that we don't longer have something on the about page 13:04 Joubu kohaputti: we have some code in about.pl to display potential config issues 13:03 kohaputti if there are no issues in this case the postinst script should add those configuratin lines 13:03 Joubu we should not do that manually, ::init should tell us if something is wrong 13:03 tcohen I prefer that, but we should avoid explosion be the default behaviour for an upgrade thousands will do, he 13:02 kohaputti Joubu, e.g. a if check in plack.psgi that those configuration lines in log4perl.conf exists, if not die? 13:00 Joubu k 13:00 Joubu me too 13:00 tcohen I prefer it to explode with meaningful error messages 13:00 Joubu /$/?/ 12:59 Joubu the question is: can we assume they are always in sync (ie. the new version from 16357 for both files will be applied), or should we have a fallback in case the "log components" does not exist/is not valid 12:59 kohaputti the instance specific ones I mean 12:58 kohaputti Joubu, I think plack.psgi should be left for the sysadmin 12:58 Joubu I guess it's because log4perl contains paths, plack.psgi can be copied as it 12:58 Joubu We have something in postinst to keep log4perl in sync, but I was wondering about plack.psgi then 12:57 Joubu from this "morning" :) 12:57 tcohen not lately 12:57 tcohen somehow 12:56 huginn Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16357 normal, P3, ---, dcook, In Discussion , Plack error logs are not time stamped 12:56 Joubu did you follow the discussion on bug 16357? 12:56 tcohen the answer is 'yes, we patch plack.psgi' on update 12:56 tcohen you might be running an instance-specific one I think 12:55 tcohen yes, but 12:55 Joubu tcohen: hola! plack.psgi is getting modified when koha-common is updated, right? 12:51 huginn Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25534 enhancement, P5 - low, ---, kyle, Passed QA , Add ability to send an email specifying a reason and store the reason when canceling a hold 12:51 Joubu cait: can you have a look at the last 2 comments on bug 25534? 12:47 marcelr dont worry 12:46 cait marcelr: so beware of yoru incoming comments? 12:46 cait heh 12:46 marcelr the third rewrite is the best 12:44 tcohen I am really happy with the questions ashimema[m] and Joubu made about the code, that yield this re-rewrite 12:44 marcelr rewriting your own code is a very good process :) 12:43 marcelr no way 12:43 tcohen I rewrote it and am happy with the results 12:42 tcohen he 12:42 tcohen should I? 12:42 marcelr you dont give up on smtp yet 12:42 tcohen hi marcelr 12:42 marcelr hi tcohen 12:20 tcohen morning 12:19 eythian marcelr: I'm always around :) 12:11 cait you too tuxayo ;) 12:09 tuxayo o/ 12:08 cait marcelr: eythian nice to see you around :) 12:07 * cait waves 11:51 eythian Oh, that sentence had no onderwerp, hence my confusion :) No, I also haven't gone far except one trip to Scotland a few weeks back. 11:49 marcelr Didnt mean the rain ;) 11:48 eythian Yeah, there's been a lot of short storm downpours. This looks more like regular rain. 11:47 marcelr Wasnt there quite a bit now 11:47 eythian Yep. Rainy Amsterdam right now. 11:46 marcelr still in a'dam? 11:46 eythian hoi marcelr 11:46 marcelr hallo eythian 11:33 wahanui que tal, eythian 11:33 eythian hi 11:15 kohaputti s/install/upgrade/ 11:14 kohaputti Joubu, ah, I know why it kept working, since the plack.psgi is not updated either during package install 11:12 tuxayo o/ 11:10 marcelr hi #koha 11:08 kohaputti Joubu, I think I was able to reproduce the issue now, let me double check still 11:08 cait kidclamp++ 11:07 cait kohaputti: i try to avoid sign-offs... they get stuck in QA :( 11:04 tuxayo All the tests passed in the 19.05.x, I can move on with the release :D 11:03 kohaputti I will retry 11:02 kohaputti ok, I did that too and for me the warns kept going to plack-error.log 11:02 Joubu yes 11:02 kohaputti Joubu, so you copied the plack.psgi from the bug report and didn't modify log4perl.conf? 11:01 kohaputti hmm, that's how it worked for me 11:01 Joubu kohaputti: it's not what I am seeing 11:01 Joubu so there is no warn to tell something went wrong, no warn on the about page, and the error is lost 11:00 kohaputti Joubu, if you keep the log4perl.conf files the same as they were before it doesn't lose them, it adds them to plack-error.log as it has before 11:00 Joubu the warn 10:59 kohaputti Joubu, what logs this loses? 10:59 wahanui hi oleopard 10:59 Joubu hi oleonard! 10:59 kohaputti Joubu, thanks I saw it, I understand now 10:59 Joubu logs are lost 10:59 Joubu kohaputti: I let a comment 10:59 Joubu no 10:58 oleonard o/ 10:57 kohaputti Joubu, the only real change here is to plack.psgi, and if the koha admin doesn't want to modify the log4perl.conf file things keep working the same as before as far as I can tell. 10:55 kohaputti or what should be separate 10:55 kohaputti adding log4perl? 10:55 Joubu we should not have split into 3 files, it should be a separate bug report 10:54 Joubu kohaputti: I don't understand why we went that far on this bug report 10:49 kohaputti Joubu, hopefully my latest reply also addresses "Or, maybe we should keep log4perl.logger.plack (ie. stderr) as fallback if the logger does not get initiated properly?" 10:35 Joubu yes, actually I was missing the Koha::Logger->get in .psgi.. 10:33 kohaputti "libplack-middleware-logwarn-perl" 10:33 kohaputti Joubu, did you install the new debian package dependency? 10:30 Joubu yes, agreed 10:29 kohaputti just have to make sure %l and %n are valid also in this context 10:28 kohaputti so some extra debugging info, the point of this bug report was to add the date and time which it does now, we could however make a follow-up bug report for adding even more info if wanted 10:27 kohaputti they are described here https://metacpan.org/pod/Log::Log4perl#Log-Layouts 10:23 Joubu there were not there for the existing plack log, but wondering what they mean 10:23 Joubu the %l and %n are not there for plack 10:23 kohaputti ah, that one I didn't notice 10:23 Joubu 63 log4perl.appender.PLACKINTRANET.layout.ConversionPattern=[%d] [%p] %m 10:23 Joubu 30 log4perl.appender.API.layout.ConversionPattern=[%d] [%p] %m %l %n 10:23 kohaputti yes 10:22 Joubu did you notice the difference in the format? 10:22 Joubu kohaputti: must be me, I am double checking the changes I made 10:21 kohaputti hmm 10:21 kohaputti ah, you said you added that too 10:20 kohaputti Joubu, the files are created only if there are warnings 10:19 Joubu wrong copy paste 10:19 Joubu hum 10:19 kohaputti Joubu, did you add a warning message to mainpage.pl manually? 10:19 Joubu Log4perl: Seems like no initialization happened. Forgot to call init()? 10:18 kohaputti hmm 10:18 kohaputti Joubu, have you changed the log4perl configuration / followed the steps in test plan? You need fresh debian package install for them to be set automatically in this new way 10:18 Joubu I edited .psgi and log4perl.conf accordingly, then added the warn, restart_all 10:17 Joubu and so I don't see the warn 10:17 Joubu the log files are not created 10:17 kohaputti Joubu, I tested in koha-testing-docker and build debian package and tested it, what's the issue you are having? 10:16 huginn Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16357 normal, P3, ---, dcook, Passed QA , Plack error logs are not time stamped 10:16 Joubu kohaputti: bug 16357 does not work for me. did you test it in a docker container? 09:32 huginn Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 enhancement, P5 - low, ---, joonas.kylmala, Needs Signoff , Show the parent record's component parts in the detailed views 09:32 kohaputti cait1, hey would you be interested in checking the bug 11175 about component records in biblio view? You mentioned many many years ago you were interested in the feature so I thought to ask xD I fixed some stuff that was requested and I think it is ready for sign-off now. 08:48 Joubu well, we can discuss everything! I don't want to be rude :) 08:48 kohaputti Joubu, given the recent move from C4/Installer/PerlDependencies.pm I think it was not clear. Some documentation somewhere is definitely useful. 08:47 Joubu but we can add something to the wiki if it's not clear 08:47 Joubu there is nothing to discuss, it's an established workflow 08:47 Joubu kohaputti: new dependency => change to cpanfile and eventually to debian/control (must be generated with debian/update-control) 08:46 kohaputti Joubu, let's discuss in the next dev meeting and if everybody agrees add a few words about this to the coding guidelines. 08:40 tuxayo Turns out the test env was somehow broken during the previous hours of usage... 08:40 tuxayo Some news about the 19.05 release: Re running the test whole test suite. I got failures and though many things were broken. 08:39 Joubu no, debian/control is automatically generated by the package manager (see 17084) 08:38 Joubu and debian/control 08:37 Joubu kohaputti: cpanfile (which replaced C4/Installer/PerlDependencies.pm) 08:31 tuxayo ok, very different ^^ 08:30 kohaputti or no patch at all 08:30 kohaputti tuxayo, no, we were discussing earlier here about what patches a developer should sent, just a patch to cpanfile, control.in, etc. 08:29 tuxayo https://wiki.koha-community.org/wiki/Building_Debian_Packages 08:29 tuxayo https://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way 08:29 tuxayo kohaputti: debian packaging instructions in the sense of building them? 08:27 kohaputti I didn't find any appropriate existing page other than https://wiki.koha-community.org/wiki/Coding_Guidelines for the debian packaging instructions but to add it there we need to discuss it in the next development meeting. 07:48 magnuse cait++ 07:47 dolf cait1: Thanks! 07:33 kohaputti cait1, thanks to you for clearing the huge QA backlog, well over 100 bugs you have went through this month! :) 07:30 cait1 kohaputti++ thx :) 07:29 cait1 by default the links go to LOC 07:29 cait1 so you can point it to local fiels that are named with the marc fields or similar 07:29 cait1 you can have your own llink structure there 07:28 cait1 check the system preferences for docs 07:24 dolf Thanks for the ideas. Creating marc help: is that in the docs somewhere? 07:23 cait1 adding tooltips with jquery might be another option 07:23 cait1 but that's maybe a bit much 07:23 cait1 dolf: you could create your own marc help 07:21 lds hi 07:20 dolf Good morning! Is there a way to add examples or descriptions for librarians in cataloging frameworks? I can modify the field headings (e.g. changing "MAIN ENTRY -- PERSONAL NAME" to "AUTHOR" for very simple frameworks), but for more complex fields, like 773$g, I would like to show an example of the desired format on screen. 07:06 * magnuse waves 06:59 cait1 good morning #koha! 06:56 alex_a Bonjour 06:42 reiveune hello 06:32 kohaputti ok, thanks a lot for the help :) 06:32 mtj kohaputti: its ok to leave it there 06:26 kohaputti mtj, one more thing, we should remove now the change to control file since it will be overriden with the update-control run in the pbuilder instance? Or can that be left there now that it is already there? 06:24 mtj ... but its really not needed for a developer when sending a patch, you can manually edit cpanfile and control :) 06:23 mtj the package building process uses update-control in a pristine pbuilder instance, to create a new control file 06:22 kohaputti thanks, I will draft some steps to the wiki page about packaging after finishing reviewing this bug report. 06:20 mtj mostly updating the cpanfile is important, and manually updating the control file (usually not control.in) 06:17 kohaputti What about* 06:16 kohaputti ok, so developer should update cpanfile and control.in, is that right? What running update-control script? 06:15 mtj the ./debian/update-control script uses cpanfile (and control.in) to update the ./debain/control file 06:13 mtj hi kohaputti, i added the patch to the bug 06:06 kohaputti mtj, thanks. I would like to document the process to wiki also. Are you adding the patch separately from this bug or? And what dependencies go now to cpanfile and are some that need to be added to debian/control.in, and then debian/control file is always updated by you? 06:00 mtj kohaputti: i'll add a patch for the control.in file 05:51 dcook Thanks kohaputti :) (and pre-emptively mtj) 05:51 huginn Bug 16357: normal, P3, ---, dcook, Failed QA , Plack error logs are not time stamped 05:51 kohaputti mtj, hey! :) Would you have time to comment on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16357#c65 ? It's about debian/control changes and the cpanfile. 05:31 mtj thanks aleisha, still about? 05:15 aleisha i've just sent an email hopefully clarifying everything! 04:10 tuxayo That's the expected tradeoff for these kind of release to have the thing less exploitable on the short term to let people a bit of time to upgrade. Not sure that it fits Koha but that not a very though of opinion. 04:10 tuxayo rangi: «it also means that no one can check the security fixes» 04:03 aleisha i think two workflows is fine as long as they are both clear - but i dont think that the workflows are that different that we would need two anyway :) 04:01 tuxayo Because two workflow could also cause confusion or inconsistencies in the future. 04:01 tuxayo aleisha: Hopefully have one security workflow (maybe just a small variation inside) for both urgent and non-urgent security releases. 03:59 aleisha that's fair enough :) we should rewrite the wiki with clearer instructions so something like this doesnt happen again. 03:58 tuxayo aleisha: It wasn't clear for me until now that this process had issues. Because I had interpreted things compatible with it. But likely it wasn't what everyone had in mind during the planing of the release. 03:56 aleisha which clearly wasn't applicable for this type of release 03:56 aleisha tuxayo: that was part of the problem, is every time i asked a question i was referred back to the wiki 03:56 aleisha <tuxayo> That wasn't the idea of the security release process: 03:56 rangi exactly 03:56 tuxayo And if we are that paranoid we should not put in the release note the names of security bugs. Because some are self explanatory and the code of the fix can be found back 03:55 rangi not the well we should fix these but its not urgent they can wait until the maintenance release 03:55 rangi but that is for a full on, we have a zero day, need to do a security release now workflow 03:55 rangi it also means that no one can check the security fixes 03:54 tuxayo Which doesn't look a good choice for me. As git install can't use it 03:54 tuxayo «RMaints push the patches from Bugzilla to the protected security repository. They don't push to their normal branches until some time after release. » 03:54 tuxayo https://wiki.koha-community.org/wiki/Release_maintenance#Coordinated_security_releases 03:54 tuxayo That wasn't the idea of the security release process: 03:54 tuxayo rangi: «all needs to be in the normal branch as soon as (or even just before) the release» 03:47 mtj yes, agreed 03:42 rangi before applying it to my koha 03:42 rangi and if i want to audit the code of the security release i can (this is an average sysadmin/user) 03:41 rangi thats the end goal, so there are many ways to do it, but none of them should involve either a rebase of the normal branch, or a force push :) as long as they dont do that, people can continue using the branches, safe in the knowledge that it has everything on it 03:40 rangi i dont care how you get it there, but it all needs to be in the normal branch as soon as (or even just before) the release 03:40 rangi otherwise if i as a user want to look at the logs, i cant 03:39 rangi everything on the normal branch 03:39 rangi basically you need to have at the point of the release 03:38 tuxayo I still cherry-picked security patches from my upstream. And also normal patches (if could continue to work on them) 03:38 tuxayo «this totally breaks the workflow from where 19.11 cherry-picks from 20.05 etc» 03:36 tuxayo (finished, sorry for the mess) 03:35 tuxayo Thanks, it's simple to understand in the case of a dedicated out of cycle security release. 03:35 tuxayo +1 03:35 tuxayo «it does no ci, has no benefit, except for rolling a security release, without disturbing the workflow on the normal branch you just push the security patches as you are about to release» 03:35 tuxayo I'm not sure what everyone had I mind about this phrase but it look very diverse ^^ 03:35 tuxayo That matched how I understood the «RMaints will have security bugs pushed to their security repos (Regular repos will have everything BUT the security bugs)» 03:35 tuxayo And do the release process on the security branch that had all the commits. 03:35 tuxayo My plan if I was able to work enough on Koha as I initially planed was to continue to backport normal patches to the public branch and on release day, rebase the security branch on it. 03:35 tuxayo Here is the clean version 03:34 rangi heh 03:34 tuxayo Oops, draft sent 03:34 * tuxayo sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/PpPyecFLgbEbPZBwoJAVesiC/message.txt > 03:34 mtj rangi: thanks, your description makes sense :) 03:27 rangi its hard to explain in text :) 03:25 rangi you just push the security patches as you are about to release 03:25 rangi you dont even really need to use the security branch, it does no ci, has no benefit, except for rolling a security release, without disturbing the workflow on the normal branch 03:24 rangi yeah in which case you just truck along pushing to your normal branches, except for the security patches, cos you dont want ppl seeing them until the day of the release 03:23 tuxayo That seems to be the case here. 03:23 tuxayo «otherwise its a maintenance release, in the normal cycle, that just happens to have some security patches in it (not urgent enough for a full security release)» 03:23 rangi does that make sense? 03:23 rangi otherwise its a maintenance release, in the normal cycle, that just happens to have some security patches in it (not urgent enough for a full security release) 03:22 rangi because that branch will have the last release + security patches only, which is what a security release should have 03:22 rangi ie out of cycle, release from security branch, merge it in after 03:22 rangi or, if its an actual security release 03:22 rangi merge it in for release 03:21 rangi so basically only security patches on a security branch 03:21 rangi this totally breaks the workflow from where 19.11 cherry-picks from 20.05 etc 03:21 rangi which means you have a month of no changes on the branch, then suddenly a whole montsh worth 03:20 rangi alternatively you branch from main one, push everything to security branch, push that over the main one 03:20 rangi back to the main one 03:20 rangi or you can cherry-pick from there 03:20 rangi you can either merge from your security branch 03:19 rangi that will mess up everyones git checkouts 03:19 tuxayo ouch i misunderstood that 03:19 rangi you cant do a -f push 03:19 tuxayo «where the main commits are on the main branch, the security ones are on the security one» 03:19 tuxayo rangi: «i think the plan that people agreed to originally, on the email » 03:19 rangi yeah but you cant do that, if you have been pushing to the main repo already 03:19 tuxayo It should be the case indeed 03:19 mtj if each rmaint pushes their security branch to the koha.git repo after release... then all the commits and tags are avaiable and correct? 03:19 rangi (when doing one of these weird combined ones) 03:17 mtj rangi: you mentioned before ..."then what happens with the security branch after release, and how does all the stuff get back on to the main branch" 03:01 aleisha okay mtj, so what ill do is make a new branch in the security repo based off of v19.11.08, apply only the security bugs (because i had done that part wrong anyway), and then cherrypick them over to the 19.11.x maintenance branch 02:59 rangi sweet 02:54 mtj so lets follow the plan from the email on the 6th of august 02:48 mtj aah right, i hadnt made that distinction 02:47 rangi thats where this mess is occuring 02:47 rangi the security branches were for doing a security release, not a combined one 02:46 rangi is what has been followed, so it can't change now 02:46 rangi (email on the 6th of august) 02:45 rangi where the main commits are on the main branch, the security ones are on the security one 02:45 rangi i think the plan that people agreed to originally, on the email 02:45 mtj hi rangi.. so that would be a no? :) 02:44 rangi heh 02:44 hayleymapley__ Error: no opening rant tag 02:43 rangi </rant> 02:43 rangi not a maintenance release 02:43 rangi if they are urgent enough to need this level of security they should go out in an actual security release 02:41 rangi and error prone 02:41 rangi because this is way way way overcomplicated 02:41 rangi we just put the security patches on last, and pushed 02:40 rangi this is why we never did it this way 02:38 rangi or worse pointing to a commit that isnt actually the one the package was built from 02:38 rangi or that tag is going to be pointing to a commit no one can reach 02:38 rangi so you cant tag the security one, unless you plan to merge the security one back into the main one 02:38 rangi the tag needs to match the tag on the release 02:37 rangi then what happens with the security branch after release, and how does all the stuff get back on to the main branch? 02:36 mtj i wonder how people feel about setting up a private gitweb and jenkins, for the security repo? 02:32 mtj hmm, i think revert them 02:27 aleisha should i revert those or just leave them? 02:27 aleisha i have pushed the translation patches and increment version commit to the maintenance branch 02:26 mtj aleisha: np, ill be about this arvo if you have some Qs 02:14 aleisha thanks mtj and tuxayo - that stuff was super unclear for me 01:51 mtj so its identical to a regular release, except that rmaints are pushing to a private repo 01:49 mtj ...after the co-ordinated release has happened, the rmaints can finally update their branch on the koha.git repo 01:42 mtj for a security release, rmaints push their stuff to the security.git repo, rather than the koha.git repo 01:41 mtj ..tuxayo's assumptions in his email are correct :) 01:29 mtj hi aleisha, still about? 01:24 mtj hey #koha 00:29 tuxayo Not sure what git choreography would fit the most. 00:28 tuxayo aleisha: Related: you might need to do some messy stuff due to the fact that the public 19.11.x branch has release commits like if there was a parallel release. So without the security patches. 00:23 tuxayo aleisha: Indeed, needs confirmation. And improving the documentation. 00:21 aleisha i think it does help, and it confirms some of the assumptions we were making over here. but the trouble is that they are assumptions and the wiki isn't clear enough, if Joubu or mtj or tcohen can confirm what you've written, it would be awesome if you could update the wiki tuxayo because your explanation was much clearer to me. 00:16 tuxayo aleisha: o/ I hope my response via email will help. This first security release sure is confusing.