Re: [Koha-devel] RFC: Retiring of the koha-patches mailing list

> Does anyone have any strong objections to shutting down the mailing list? +1 to shutting down the patches mailing list. I haven't heard any objections yet, so let's move forward on it. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org ___

Re: [Koha-devel] RFC: Retiring of the koha-patches mailing list

+1 El mar., 12 jul. 2016 a las 9:34, Owen Leonard () escribió: > > Does anyone have any strong objections to shutting down the mailing list? > > +1 to shutting down the patches mailing list. > > I haven't heard any objections yet, so let's move forward on it. > > -- Owen > > -- > Web Developer

Re: [Koha-devel] RFC: Retiring of the koha-patches mailing list

+1 Van: koha-devel-boun...@lists.koha-community.org namens Tomas Cohen Arazi Verzonden: dinsdag 12 juli 2016 14:45:21 Aan: Owen Leonard; koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] RFC: Retiring of the koha-patches mailing list +1 El mar.,

[Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE performance issue !

Hi all, Those days, we're working on a pretty large DB ( >1M biblio), for a customer that want to do many statistics on some fields. We discovered that something "simple" like: SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY publicationyear; was giving *no result in

Re: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE performance issue !

I agree 100%, but I'd go for a metadata_record table with schema, (id), biblionumber, format and metadata columns to start supporting more and more schemas. Example: | id | format | schema | metadata | 1 | marcxml | marc21 | ... | 2 | usmarc | unimarc | ... | 3 | mij | marc21 |

Re: [Koha-devel] RFC: Retiring of the koha-patches mailing list

Already +1'ed this some time ago :) Who can make it happen? Am 12.07.2016 um 15:00 schrieb Marcel de Rooy: > +1 > > > *Van:* koha-devel-boun...@lists.koha-community.org > namens Tomas Cohen Arazi > > *Verzonden:* dinsdag

Re: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE performance issue !

2016-07-12 17:43 GMT+01:00 Paul Poulain : > Hi all, Hi Paul, > Those days, we're working on a pretty large DB ( >1M biblio), for a customer > that want to do many statistics on some fields. > We discovered that something "simple" like: > SELECT publicationyear, count(publicationyear) FROM biblioi

[Koha-devel] Reminder: Koha Developer IRC Meeting - 13 July 2016, 14 UTC

Hi all, just sending a quick meeting reminder: https://wiki.koha-community.org/wiki/Development_IRC_meeting_13_July_2016 Please take a look at the agenda and add any topics that you want to discuss in advance of the meeting. See you there! Katrin ___

Re: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE performance issue !

+1 from me On 13 July 2016 5:11:36 AM NZST, Tomas Cohen Arazi wrote: >I agree 100%, but I'd go for a metadata_record table with schema, (id), >biblionumber, format and metadata columns to start supporting more and >more >schemas. Example: > >| id | format | schema | metadata >| 1 | marcxml |

Re: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE performance issue !

+1 from me too It’ll hopefully go a long way to moving away from MARC in the long-term too… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-boun...@lists.koha-community.org [mailto

[Koha-devel] Permissions for /var/spool/koha/instance and possible path changes

Hi all, I was just reviewing the Filesystem Hierarchy Standard, and it's led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha. Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html I say

Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes

opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html code in /opt/koha and data in /var/opt/koha We've been using this pattern at the place I just left (not for Koha but other things) and it makes it very easy and (for us at least was--your mileage will vary) intuitive. -- side note-- /va

Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes

That’s an option for folk doing tarball installs, but I’m thinking for the Debian packages, which already have a set way of doing things (like code in /usr/share/koha, etc). To be honest, I’ve been thinking a bit about making RPM packages for Koha and thinking about where I’d put all the fil

Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes

P.S. In general, I quite like /opt/X for code. I’ve been working more on Redhat lately, and I’ve noticed that Redhat uses /opt for their Redhat Software Collection packages. Not sure how common it is to use in the packaging world though. David Cook Systems Librarian Prosentient Systems

Re: [Koha-devel] Using the file upload feature for more customization

In regards to XSLTs, I’d love some sort of registry where you could add XSLTs and then reference them elsewhere from a dropdown. As for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648, I’m curious why we’d ha

Re: [Koha-devel] Using the file upload feature for more customization

On Jul 12, 2016 11:47 PM, "David Cook" wrote: > > In regards to XSLTs, I’d love some sort of registry where you could add XSLTs and then reference them elsewhere from a dropdown. > > > > As for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648, I’m curious why we’d have XSLTs publicl

Re: [Koha-devel] Using the file upload feature for more customization

Hi Barton, You’re referring to your local Bywater practice, yes? By default, users would be using the XSLTs installed with their Koha (Deb packages or source install), so the default XSLTs would be registered using the filepath on the local server, I reckon. I suppose if you were to use H

[Koha-devel] mailing list creation for greek koha community

dear developers list a month ago, I sent the following mail to mail...@lists.koha-community.org. - -Dear administrators - -as we are trying to establish the Greek Koha Users Group, we would also like to create the Greek koha users mailing list. I understand that we -need a "List creator's (au