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.