[Koha-devel] Country-specific forks?

[Renvoize, Martin]

Hmm, I'm wary of monkey patch like stuff like that... Though it certainly
has its place.  Agree in general that we need to be more pluggable.. Though
when I suggested that the Norwegian stuff should have extended the plugin
system in core then been a plugin I was met with a fair bit of opposition
at the time.
On 11 Feb 2016 12:38 pm, "Jonathan Druart" <
jonathan.druart at bugs.koha-community.org> wrote:

> Yes, it will be a limitation.
> For the signatures, we will have to maintain the plugins and version them.
>
> 2016-02-11 12:30 GMT+00:00 Julian Maurice <julian.maurice at biblibre.com>:
> > Problems that quickly come to mind with this solution:
> > * It will prevent 2 different plugins to redefine the same subroutine
> > * If the subroutine "signature" change, the compatibility with existing
> > plugins will be broken
> >
> >
> > Le 11/02/2016 13:14, Jonathan Druart a écrit :
> >> A really easy solution to implement would be to watch a directory (say
> >> plugins) during the very end of the compilation time.
> >> Using something like Sub::Override
> >> (http://search.cpan.org/~ovid/Sub-Override-0.09/lib/Sub/Override.pm)
> >> would allow the plugin to redefine behaviors.
> >>
> >> 2016-02-11 11:47 GMT+00:00 Kyle Hall <kyle.m.hall at gmail.com>:
> >>> Totally agree with this. All we need to do is imagine where we want
> Koha to
> >>> be pluggable! So far we have the ability create Report/Tool plugins,
> >>> arbitrary file to MARC conversion plugins, and I also have submitted a
> patch
> >>> to make EDIFACT pluggable ( once it gets it ). The first step is to
> know
> >>> what behavior needs to be modified, then make that behavior pluggable.
> It's
> >>> almost a chicken or the egg issue. I suppose what we need to do is
> watch for
> >>> new patches for very region specific features ( such as Norwegian
> patron DB
> >>> ) and suggest a path to plug-ability rather pushing the code itself
> into
> >>> Koha.
> >>>
> >>> Kyle
> >>>
> >>> http://www.kylehall.info
> >>> ByWater Solutions ( http://bywatersolutions.com )
> >>> Meadville Public Library ( http://www.meadvillelibrary.org )
> >>> Crawford County Federated Library System ( http://www.ccfls.org )
> >>> Mill Run Technology Solutions ( http://millruntech.com )
> >>>
> >>> On Thu, Feb 11, 2016 at 5:24 AM, Julian Maurice
> >>> <julian.maurice at biblibre.com> wrote:
> >>>>
> >>>> +1 to "one Koha to rule them all"
> >>>> +1000 to a more powerful plugin system!
> >>>> Having a plugin system to build custom tools and reports is great,
> but I
> >>>> think we could (and should) go further.
> >>>>
> >>>> Le 11/02/2016 10:38, Magnus Enger a écrit :
> >>>>> Dear Community!
> >>>>>
> >>>>> A quote from another thread on koha-devel:
> >>>>>
> >>>>> "I look at the code, and beside wondering why that custom feature
> >>>>> [Norwegian patron DB] is so profoundly imbricated into master Koha, I
> >>>>> was wondering what is not working."
> >>>>>
> >>>>> I think this raises an interesting question. Should we let features
> >>>>> into Koha that are only of interest to libraries in one or a small
> >>>>> number of countries? Or should we confine those features to
> >>>>> country-specific forks?
> >>>>>
> >>>>> The quote above implies (I think) that support for the Norwegian
> >>>>> patron DB should be in a country-specific fork.
> >>>>>
> >>>>> On the other hand, the project implementing Koha for public libraries
> >>>>> in Turkey has been criticized for not integrating their
> customizations
> >>>>> into Koha. To which someone replied that the customizations were not
> >>>>> of much interest to libraries outside Turkey.
> >>>>>
> >>>>> So do we want one Koha to rule them all, including country-specific
> >>>>> features, or do we want one fork per country?
> >>>>>
> >>>>> Personally, I prefer the former. In the case of the Norwegian patron
> >>>>> DB, that is one of the 2-3 "must have" features that all Norwegian
> >>>>> public libraries will be looking for when they are choosing between
> >>>>> Koha or some proprietary system. Should we be telling them "Nope, you
> >>>>> can't use the real Koha, but you can use this fork over here"? That
> >>>>> will not increase their confidence in choosing Koha, I suspect.
> >>>>>
> >>>>> That said, I do think some principles should be applied:
> >>>>>
> >>>>> - Strive to make even the country specific features as general as
> >>>>> possible, so that others can use them as starting points for similar
> >>>>> features.
> >>>>>
> >>>>> - Strive to make the features as unobtrusive as possible.
> >>>>>
> >>>>> And maybe, in time, the plugin system can be made powerful enough
> that
> >>>>> it can handle some or all of the country-specific features?
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Best regards,
> >>>>> Magnus Enger
> >>>>> Libriotech
> >>>>> _______________________________________________
> >>>>> Koha-devel mailing list
> >>>>> Koha-devel at lists.koha-community.org
> >>>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >>>>> website : http://www.koha-community.org/
> >>>>> git : http://git.koha-community.org/
> >>>>> bugs : http://bugs.koha-community.org/
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Julian Maurice <julian.maurice at biblibre.com>
> >>>> BibLibre
> >>>> _______________________________________________
> >>>> Koha-devel mailing list
> >>>> Koha-devel at lists.koha-community.org
> >>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >>>> website : http://www.koha-community.org/
> >>>> git : http://git.koha-community.org/
> >>>> bugs : http://bugs.koha-community.org/
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Koha-devel mailing list
> >>> Koha-devel at lists.koha-community.org
> >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >>> website : http://www.koha-community.org/
> >>> git : http://git.koha-community.org/
> >>> bugs : http://bugs.koha-community.org/
> >
> >
> > --
> > Julian Maurice <julian.maurice at biblibre.com>
> > BibLibre
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160211/fbcb6d03/attachment-0001.html>