[Koha-devel] custom core patches management

Michael Hafen (TECH) michael.hafen at washk12.org
Wed Nov 3 17:36:49 CET 2021


This is exactly how I manage my Koha installs, with the exception that
instead of using the packages I run my production servers from a dev
install.  When I have changes ready I just `git fetch; git reset --hard
origin/my_release_branch` to apply those changes, but then I have to
manually go through koha-upgrade-schema and koha-plack --restart for each
instance (I have 3 active instances).  So I have traded building and
distributing debian packages for manually doing the post upgrade work that
the packages would do for me.

On Tue, Nov 2, 2021 at 7:00 PM <dcook at prosentient.com.au> wrote:

> Hi David,
>
>
>
> I won’t make a comment on good vs bad strategies, as those are just
> subjective judgements, and ultimately it really all depends on your context.
>
>
>
> However, it sounds like you’re making a lot of work for yourself with
> those files. Using git commands, you could extract equivalents of those
> .orig, .changed, and .patched files.
>
>
>
> Also, by patching prod files like that, you don’t necessarily know exactly
> what your application state is at any particular time. I suppose you could
> probably do a git-based manual patching deployment system using git hashes
> to represent versions, but I’ve found in practice that those cause more
> headaches than they solve.
>
>
>
> Most Koha support providers (like the one I work for) will fork the
> branch(es) they want to customize, and then generate Debian packages which
> they distribute around the world as necessary. As soon as you’re running
> more than 1 Koha server, you really want a way to easily and quickly deploy
> changes across multiple machines. Koha is large and complex, so I think
> you’ll find that leveraging the work the community has done to build robust
> Debian packages is your best bet.
>
>
>
> Carrying customizations forward through time takes work, so it’s best to
> upstream everything you can, but I think we all know that’s not always
> feasible. Again git commands can help you show the changes you’ve made
> between different versions, and then you can make periodic efforts to
> review your customizations and port over anything you need to when a new
> version comes out.
>
>
>
> I hope that you find that helpful.
>
>
>
> David Cook
>
> Senior Software Engineer
>
> Prosentient Systems
>
> Suite 7.03
>
> 6a Glen St
>
> Milsons Point NSW 2061
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
>
> *From:* Koha-devel <koha-devel-bounces at lists.koha-community.org> *On
> Behalf Of *David Schmidt
> *Sent:* Tuesday, 2 November 2021 9:01 PM
> *To:* Koha-devel at lists.koha-community.org
> *Subject:* [Koha-devel] custom core patches management
>
>
>
> Hello koha community,
>
>
>
> We made some changes to our Koha instance and are now looking for a
> mechanism to apply them to a new installation.
>
>
>
> - some of the changes are simply new files, thats easy.
>
> - some changes were possible to put into plugins or use existing hooks.
>
>
>
> but how do you deal with changes to the koha sourcecode?
>
>
>
> this is our strategy:
>
>
>
> 1) we have a git repo with our koha source code.
>
> 2) if we change code in Foobar.pm we create 3 files.
>
> Foobar.pm.orig
>
> Foobar.pm.changed
>
> Foobar.pm.patch
>
> 3) on a new koha instance next we have a script `install.sh` that compares
> Foobar.pm.orig with the installed file. if they match, the patch is applied.
>
>
>
> Does that sound like a good idea?
>
> How do YOU manage core changes that do not go upstream?
>
>
>
> cheers,
>
> david
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>


-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211103/2912827d/attachment.htm>


More information about the Koha-devel mailing list