<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 14653 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 192, Issue 4<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Re: custom core patches management (Philippe Blouin)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 4 Nov 2021 08:12:29 -0400<br>From: Philippe Blouin <philippe.blouin@inlibro.com><br>To: dcook@prosentient.com.au, "'Michael Hafen (TECH)'"<br> <michael.hafen@washk12.org><br>Cc: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] custom core patches management<br>Message-ID: <472cb0c1-bdf0-8257-4b16-06f0ed3210cb@inlibro.com><br>Content-Type: text/plain; charset="utf-8"; Format="flowed"<br><br>I'm happy to hear someone else raising the issue about koha-perldeps <br>going wild on OS updates. Every perl package suddenly become suggested <br>for autoremove. I experience that on most updates on every server.<br><br>Regarding you request for info, David, we also are git-based <br>deployment. Each of our customers have personnalized branches so every <br>update require personnalized attention, but we have code in the main <br>branch to help. Since they require (and get) their requirements <br>"quickly", this approach is very fast. Major updates (19.05 to 20.05 <br>for example) have to be planned carefully, though. I don't see us <br>moving to a different method unless we could standardize our code base.<br><br><br><br>Philippe Blouin,<br>Directeur de la technologie<br><br>Tél. : (833) 465-4276, poste 230<br>philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com><br><br>inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com><br>On 2021-11-03 6:39 p.m., dcook@prosentient.com.au wrote:<br>><br>> I would actually be a bit more interested in git based deployments if <br>> we fixed up the directory layout for the Koha codebase.<br>><br>> One downside to the git approach is that you’ll also need to manually <br>> update generated configuration files. Not a big problem for small <br>> scale deployments, but not something you really want to be doing when <br>> you’re updating 100 Koha instances across 15 servers across 3 <br>> continents at the same time (which is still small scale by some <br>> measures haha). I think the git-based installation makes it easier to <br>> wind up with a broken Koha by accident.<br>><br>> Software deployment is a bit of a passion of mine, so really curious <br>> to hear from more people. I’m quite interested in using Carton to <br>> handle Koha’s Perl dependencies instead of using OS-based Perl <br>> dependencies. I’m planning to move that way for a different project, <br>> although I’m actually still using OS packages for deploying my app. <br>> Actually, that’s another reason to consider going with package-based <br>> deployments: dependency management. (That said, I have noticed an <br>> issue where Koha gets uninstalled when updating the OS. Something I <br>> still need to investigate. Think it is Zebra related.)<br>><br>> At some point, I’d like to move to Docker-based deployments, but <br>> there’s still more work to do on that front. It’s very doable, but <br>> without a critical mass of Koha community members wanting to do it, I <br>> think it would be a waste of my time to invest too much in it. There’s <br>> a saying that you go faster alone but farther together, and I think <br>> that’s something worth keeping in mind.<br>><br>> David Cook<br>><br>> Senior Software Engineer<br>><br>> Prosentient Systems<br>><br>> Suite 7.03<br>><br>> 6a Glen St<br>><br>> Milsons Point NSW 2061<br>><br>> Australia<br>><br>> Office: 02 9212 0899<br>><br>> Online: 02 8005 0595<br>><br>> *From:*Michael Hafen (TECH) <michael.hafen@washk12.org><br>> *Sent:* Thursday, 4 November 2021 3:37 AM<br>> *To:* dcook@prosentient.com.au<br>> *Cc:* David Schmidt <mail@davidschmidt.at>; <br>> koha-devel@lists.koha-community.org<br>> *Subject:* Re: [Koha-devel] custom core patches management<br>><br>> This is exactly how I manage my Koha installs, with the exception that <br>> instead of using the packages I run my production servers from a dev <br>> install. When I have changes ready I just `git fetch; git reset --hard <br>> origin/my_release_branch` to apply those changes, but then I have to <br>> manually go through koha-upgrade-schema and koha-plack --restart for <br>> each instance (I have 3 active instances). So I have traded building <br>> and distributing debian packages for manually doing the post upgrade <br>> work that the packages would do for me.<br>><br>> On Tue, Nov 2, 2021 at 7:00 PM <dcook@prosentient.com.au <br>> <mailto:dcook@prosentient.com.au>> wrote:<br>><br>> Hi David,<br>><br>> I won’t make a comment on good vs bad strategies, as those are<br>> just subjective judgements, and ultimately it really all depends<br>> on your context.<br>><br>> However, it sounds like you’re making a lot of work for yourself<br>> with those files. Using git commands, you could extract<br>> equivalents of those .orig, .changed, and .patched files.<br>><br>> Also, by patching prod files like that, you don’t necessarily know<br>> exactly what your application state is at any particular time. I<br>> suppose you could probably do a git-based manual patching<br>> deployment system using git hashes to represent versions, but I’ve<br>> found in practice that those cause more headaches than they solve.<br>><br>> Most Koha support providers (like the one I work for) will fork<br>> the branch(es) they want to customize, and then generate Debian<br>> packages which they distribute around the world as necessary. As<br>> soon as you’re running more than 1 Koha server, you really want a<br>> way to easily and quickly deploy changes across multiple machines.<br>> Koha is large and complex, so I think you’ll find that leveraging<br>> the work the community has done to build robust Debian packages is<br>> your best bet.<br>><br>> Carrying customizations forward through time takes work, so it’s<br>> best to upstream everything you can, but I think we all know<br>> that’s not always feasible. Again git commands can help you show<br>> the changes you’ve made between different versions, and then you<br>> can make periodic efforts to review your customizations and port<br>> over anything you need to when a new version comes out.<br>><br>> I hope that you find that helpful.<br>><br>> David Cook<br>><br>> Senior Software Engineer<br>><br>> Prosentient Systems<br>><br>> Suite 7.03<br>><br>> 6a Glen St<br>><br>> Milsons Point NSW 2061<br>><br>> Australia<br>><br>> Office: 02 9212 0899<br>><br>> Online: 02 8005 0595<br>><br>> *From:*Koha-devel <koha-devel-bounces@lists.koha-community.org<br>> <mailto:koha-devel-bounces@lists.koha-community.org>> *On Behalf<br>> Of *David Schmidt<br>> *Sent:* Tuesday, 2 November 2021 9:01 PM<br>> *To:* Koha-devel@lists.koha-community.org<br>> <mailto:Koha-devel@lists.koha-community.org><br>> *Subject:* [Koha-devel] custom core patches management<br>><br>> Hello koha community,<br>><br>> We made some changes to our Koha instance and are now looking for<br>> a mechanism to apply them to a new installation.<br>><br>> - some of the changes are simply new files, thats easy.<br>><br>> - some changes were possible to put into plugins or use existing<br>> hooks.<br>><br>> but how do you deal with changes to the koha sourcecode?<br>><br>> this is our strategy:<br>><br>> 1) we have a git repo with our koha source code.<br>><br>> 2) if we change code in Foobar.pm we create 3 files.<br>><br>> Foobar.pm.orig<br>><br>> Foobar.pm.changed<br>><br>> Foobar.pm.patch<br>><br>> 3) on a new koha instance next we have a script `install.sh` that<br>> compares Foobar.pm.orig with the installed file. if they match,<br>> the patch is applied.<br>><br>> Does that sound like a good idea?<br>><br>> How do YOU manage core changes that do not go upstream?<br>><br>> cheers,<br>><br>> david<br>><br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> <mailto:Koha-devel@lists.koha-community.org><br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> <https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel><br>> website : https://www.koha-community.org/<br>> <https://www.koha-community.org/><br>> git : https://git.koha-community.org/<br>> <https://git.koha-community.org/><br>> bugs : https://bugs.koha-community.org/<br>> <https://bugs.koha-community.org/><br>><br>><br>><br>> -- <br>><br>> Michael Hafen<br>><br>> Washington County School District Technology Department<br>><br>> Systems Analyst<br>><br>><br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211104/95e4a7e9/attachment.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 192, Issue 4<br>******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>