From paul.poulain at biblibre.com Wed Feb 1 16:59:14 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 01 Feb 2012 16:59:14 +0100 Subject: [Koha-devel] Coding guidelines Message-ID: <4F296152.9040206@biblibre.com> Hello, I just updated the coding guideline page on the wiki (http://wiki.koha-community.org/wiki/Coding_Guidelines) To add numbers to each rule. That will be helpfull/faster when QAing to say "this patch break PERL5 or HTML2 rule". -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Thu Feb 2 18:01:46 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 02 Feb 2012 18:01:46 +0100 Subject: [Koha-devel] tips and tricks wiki page Message-ID: <4F2AC17A.60407@biblibre.com> Hello, I just have added a page called http://wiki.koha-community.org/wiki/Tips_and_tricks I made a mistake today, pushing a patch that had a file not compiling. The patch had been submitted, sign-offed, QAed and pushed, and none of us saw the problem. Why ? Because none of us had a git hook to check ! Go to read the wiki page, and you'll learn how to avoid forever submitting/testing/QAing that has a syntax error ! That's so easy ! I love git ! PS: if you want to improve the testing script proposed, don't hesitate even a second ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From skushner at mplmain.mtpl.org Fri Feb 3 22:37:00 2012 From: skushner at mplmain.mtpl.org (Scott Kushner) Date: Fri, 3 Feb 2012 16:37:00 -0500 Subject: [Koha-devel] Translating a template file. Message-ID: <135996400018D3448DFF998E536286EF2A57BB@exchange.mplmain.mtpl.org> I want to translate one .tmpl to template toolkit .tt file. Does anyone know the command for this? I have a git install. Do not have /koha/tt dir.... Just want to translate the one template file. Thanks, Scott Kushner Systems Librarian Middletown Public Library 55 New Monmouth Rd Middletown, NJ 07748 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at aandc.org Sat Feb 4 19:17:29 2012 From: paul.a at aandc.org (Paul) Date: Sat, 04 Feb 2012 13:17:29 -0500 Subject: [Koha-devel] Bug 5677 Message-ID: <5.2.1.1.2.20120204125227.0518c928@stormy.ca> Not sure if it's possible to re-open a "resolved" bug (or even if mine is germane) having just looked at . We have some items that are showing up as "lost" despite having a correct "library" and "shelf location". e.g.: from OPAC: "Books NMA box_rr169 Reference REFE-UNKN-57 (Browse Shelf) Item lost" -- it's a book at the NMA, in box_rr169, [call# correct], LOST. In the staff interface (same "lost" labeling), editing "item", the "lost status" is given as 5 but our "authorized values" are default and 5 does not exist. I have edited the framework to attempt to be able to edit/modify this (952$1), but the drop down box "1 - Lost status" only appears for *new* items, and while the line is there, there is no dropdown to edit existing records. Bug 5677 suggests that it was an OPAC problem, not showing in the staff interface -- whereas mine is showing in both. Can anyone assist me, please? As background, we are not a lending library, have no "patrons" in the Koha sense, and have never even tried to declare an item as "lost" which if I understand correctly is a management tool for unreturned books. tnx - paul From mtj at kohaaloha.com Mon Feb 6 09:16:12 2012 From: mtj at kohaaloha.com (Mason James) Date: Mon, 6 Feb 2012 21:16:12 +1300 Subject: [Koha-devel] Bug 5677 In-Reply-To: <5.2.1.1.2.20120204125227.0518c928@stormy.ca> References: <5.2.1.1.2.20120204125227.0518c928@stormy.ca> Message-ID: On 2012-02-5, at 7:17 AM, Paul wrote: > Not sure if it's possible to re-open a "resolved" bug (or even if mine is germane) having just looked at . > > We have some items that are showing up as "lost" despite having a correct "library" and "shelf location". e.g.: from OPAC: "Books NMA box_rr169 Reference REFE-UNKN-57 (Browse Shelf) Item lost" -- it's a book at the NMA, in box_rr169, [call# correct], LOST. > > In the staff interface (same "lost" labeling), editing "item", the "lost status" is given as 5 but our "authorized values" are default and 5 does not exist. > > I have edited the framework to attempt to be able to edit/modify this (952$1), but the drop down box "1 - Lost status" only appears for *new* items, and while the line is there, there is no dropdown to edit existing records. > > Bug 5677 suggests that it was an OPAC problem, not showing in the staff interface -- whereas mine is showing in both. > > Can anyone assist me, please? > > As background, we are not a lending library, have no "patrons" in the Koha sense, and have never even tried to declare an item as "lost" which if I understand correctly is a management tool for unreturned books. > > tnx - paul > my hunch is... its a different bug than 5677 perhaps you had a LOST auth_value with a value of 5, that was deleted... what would that have been....? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From paul.poulain at biblibre.com Mon Feb 6 09:27:44 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 06 Feb 2012 09:27:44 +0100 Subject: [Koha-devel] [Koha] Translating a template file. In-Reply-To: <135996400018D3448DFF998E536286EF2A57BB@exchange.mplmain.mtpl.org> References: <135996400018D3448DFF998E536286EF2A57BB@exchange.mplmain.mtpl.org> Message-ID: <4F2F8F00.5070409@biblibre.com> Le 03/02/2012 22:37, Scott Kushner a ?crit : Hi Scott, > I want to translate one .tmpl to template toolkit .tt file. > Does anyone know the command for this? I have a git install. Isn't this page of the wiki what' you're looking for: http://wiki.koha-community.org/wiki/Htp-to-tt-conversion ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Mon Feb 6 22:23:25 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 06 Feb 2012 22:23:25 +0100 Subject: [Koha-devel] Call for help, testing sandboxes system Message-ID: <4F3044CD.7070404@biblibre.com> Hello koha-devel, In my Release Manager Application, there was something about setting sandbox testing servers. I wrote some scripts to deal with this system. With them, you can easily test patches. I think the system is ready to be deployed and announced widely. But before doing that, i'd like to have some feedback from a small group like users of this list. So my request is: * got to the wiki page http://wiki.koha-community.org/wiki/Sandboxes, it should be self-explanatory, otherwise I must improve the page and please report it here * test some patches to see if everything is working well 2 more informations: * the MARC21 sample database is really a tiny one. If someone has a bigger one, he's welcomed to send it to me, i'll update the sandbox * only test1 (unimarc) and test5 (marc21) are deployed for instance. Don't try to user other testX server, it won't work. Thanks for the time you'll dedicate on this task, it really hope this system will be usefull to lower the number of patches needing signoff by lowering the technical level needed to test it. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From magnus at enger.priv.no Tue Feb 7 10:44:20 2012 From: magnus at enger.priv.no (Magnus Enger) Date: Tue, 7 Feb 2012 10:44:20 +0100 Subject: [Koha-devel] 2012-02-08 Global bug squashing day #9 - you can help! Message-ID: Dear Community, In just 15 minutes, it's that time again (at least in Kiribati): http://wiki.koha-community.org/wiki/2012-02-08_Global_bug_squashing_day Just as an example of work that needs to be done, there are currently 89 bugs that need signing off - that's too many! And to put things in perspective, on 2012-02-08 it's just 2 months and 2 weeks until 2012-04-22 is upon us! (If you're wondering why that is significant, it's the date dictated by tradition for the next version of Koha - 3.8. (The actual date is of course dictated by Paul P. ;-)) Happy hunting, folks! Magnus From paul.poulain at biblibre.com Tue Feb 7 18:27:57 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 07 Feb 2012 18:27:57 +0100 Subject: [Koha-devel] "in discussion" bugs, proposed workflow Message-ID: <4F315F1D.9070007@biblibre.com> Hello all, i've added to the IRC agenda some details about the "in discussion" bugs. We must setup a workflow to be sure there is a discussion and we exit from this discussion in a given time, with a clear decision. You can find a proposition for a workflow on the IRC agenda wiki page and i'd like to discuss of this workflow during the IRC. Look at : http://wiki.koha-community.org/wiki/General_IRC_Meeting,_8_February_2012#Agenda for more details. I plan to be at the meeting, but it's 3AM for me, so apologize if I shoot my radio when she awake me ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From tomascohen at gmail.com Wed Feb 8 16:42:26 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 8 Feb 2012 12:42:26 -0300 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha Message-ID: Hi, I'm just starting a thread to discuss this topic so we make some decisions and we can continue improving Koha in this aspect. As far as I can remember there are a few issues with this: 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration. I introduced the use of ENV (from Apache vhost definition) for storing memcached servers configuration data on Bug 6193. This was done for being able to cache the koha-conf.xml configuration variables (prior to that, memcached info was saved in koha-conf.xml itself and thus not-cacheable). When coding that I realized that memcached was being initialized everywhere we needed it. And namespaces where not always consistent (KOHA and koha alternatively, this might not be a problem if this happens to be case insensitive, anyway, it looked bad to me). I then exported the object memcached and the ismemcached variable in C4::Context. This first patch (koha-conf.xml in memcache, and memcached object available for every other lib that includes C4::Context) has been pushed. Then there's a second patch, that removes several memcached configuration validation and initialization code from the rest of the libs, and reuses that variables from C4::Context. I tested it to work flawlessly, but things around it halted when other proposals raised. I like mi approach. I like how the resulting code looked, I wont hide it. But I don't need it to be accepted at all, maybe the other proposals are far better. The only thing I missed on this cache thing was more feedback. Back to the ENV use I think we must make a desicion: - Do we want to cache koha-conf.xml ? If the answer is no, then we can revert that patch. And we are done. If the answer is yes, we can deal with it is storing the settings in the database, but this will make it difficult to memoize the function reading. Or leave it as it is now. I don't agree it is a problem to move those settings to the vhost definition, it could be even moved into a separate file with an include sentence in the vhost definition for convenience (/etc/koha/memcached.conf and Include in vhost definition...) 2) Memoization in Koha Do we plan to use memoization in the mid/long-term? Or are we thinking of a more abstract set of 'cache' utilities which provide an interface to memcached? Using memoization is nice, clean and simple. It has the disadvantage that caching is done in an implicit way, and there are hidden problems (read side-effects) that have to be taken into account. For example, someone writes a method, other memoizes it, but doesn't know that a third method relies on data returned by the first mehotd being 'online'. As-is, memoize_memcached doesn't provide a proper way of invalidating data automatically. As said in a previous email: we will end up hooking all the data writing methods so they invalidate all the memcached store, or those methods the writer knows have to do with the current. Almost like making it explicit, but just for writers. In which case it is better to implement the second option, making everything explicit: The second approach means we have to hook every function to handle its caching, and cache invalidation. Its advantage is that being explicit, but requieres a lot of work and we will end up having business logic mixed with cache handling code, which is not a problem per-se. Just thinking. If we are planning to go on with memoization, I made a proposal on IRC (which had zero responses) to add memoize_memcached an array of references to data invalidation methods, so we don't have to hook every method. The Memoize::Memcached dev told me to take over the lib as he isn't maintaining it nor working on perl anymore. I'd like to do that, but I halted my work on that until it is more clear that it is not a waste of time. Ok. I'd like to re-read this words I wrote, but I'm just back from holidays and my bosses need a lot of answers for a lot of stuff I didn't finish last year, right now, so... Regards To+ From paul.a at aandc.org Wed Feb 8 20:37:12 2012 From: paul.a at aandc.org (Paul) Date: Wed, 08 Feb 2012 14:37:12 -0500 Subject: [Koha-devel] "Damaged" values Message-ID: <5.2.1.1.2.20120208143210.0196a030@stormy.ca> In our "Authorized values" > "Damaged", we have added a term "Normal wear" to the Koha defaults 0, 1 and 2: 0 Not damaged Not damaged 1 Damaged Some damage noted 2 Unknown Condition not stated 3 Normal wear Normal wear However, in both staff interface and OPAC, "normal wear" items are appearing as damaged I assume (maybe incorrectly) that the value of "damaged" is read by detail.pl starting line 196: if ($item->{damaged}) { $item->{itemdamagedloop} = GetAuthorisedValues($authvalcode_items_damaged, $item->{damaged}) if $authvalcode_items_damaged; } and then passed to detail.tt start line 310: [% IF ( itemloo.damaged ) %] [% IF ( itemloo.itemdamagedloop ) %] [% FOREACH itemdamagedloo IN itemloo.itemdamagedloop %] [% IF ( itemdamagedloo.selected ) %] [% itemdamagedloo.lib %] [% END %] [% END %] [% ELSE %] Damaged [% END %] [% END %] I have no experience with this type of 'loo' and 'loop' coding, but it seems to me that "normal wear" is not being picked up, and therefore the ELSE default "Damaged" is being used. Could some kind person please point me to the logic of these loops? Either a brief explanation here (preferred) or a pointer to a tutorial (I have googled with no success.) Or is there something more intrinsic|relevant to the use of authorized values for "damaged"? Bugs [3637] and 5797 may be germane. Many thanks, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. , and From robin at catalyst.net.nz Wed Feb 8 22:59:43 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 09 Feb 2012 10:59:43 +1300 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: References: Message-ID: <1328738383.26658.11.camel@zarathud> Tomas Cohen Arazi schreef op wo 08-02-2012 om 12:42 [-0300]: > 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store > memcached configuration. My 2? here is that we should use ENV. The main logic behind this is that it means the only thing you can't cache is the ENV vars, which no one does anyway. As for cache invalidation and memoisation, it's something best approached very slowly and carefully as it's a Hard Problem. I don't really have any concrete suggestions on that front though. ?There are only two hard things in Computer Science: cache invalidation and naming things?. ? Tim Bray quoting Phil Karlton -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From robin at catalyst.net.nz Wed Feb 8 23:08:18 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 09 Feb 2012 11:08:18 +1300 Subject: [Koha-devel] "Damaged" values In-Reply-To: <5.2.1.1.2.20120208143210.0196a030@stormy.ca> References: <5.2.1.1.2.20120208143210.0196a030@stormy.ca> Message-ID: <1328738898.26658.14.camel@zarathud> Paul schreef op wo 08-02-2012 om 14:37 [-0500]: > 0 Not damaged Not damaged > 3 Normal wear Normal wear > However, in both staff interface and OPAC, "normal wear" items are > appearing as damaged > I assume (maybe incorrectly) that the value of "damaged" is read by > detail.pl starting line 196: > > if ($item->{damaged}) { So the nutshell version of what's going on: The Perl line above says essentially "if the damaged value != 0, then..." So by having "normal wear" at 3, it thinks its damaged. My suggestion to change this would perhaps to be to change that line so that it's if ($item->{damaged} > 0) { and then you could set 'normal wear' to -1 and it wouldn't show as damaged. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jcamins at cpbibliography.com Thu Feb 9 00:03:45 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 8 Feb 2012 18:03:45 -0500 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <1328738383.26658.11.camel@zarathud> References: <1328738383.26658.11.camel@zarathud> Message-ID: 2012/2/8 Robin Sheat > Tomas Cohen Arazi schreef op wo 08-02-2012 om 12:42 [-0300]: > > 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store > > memcached configuration. > > My 2? here is that we should use ENV. The main logic behind this is that > it means the only thing you can't cache is the ENV vars, which no one > does anyway. > Personally, I feel that everything that is configurable should be configurable from the interface (i.e. sysprefs), but that seems like a valid reason to use ENV, so I withdraw my objections. Let's get Koha caching! Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjr at phonecoop.coop Thu Feb 9 11:18:51 2012 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 09 Feb 2012 10:18:51 +0000 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: Message-ID: Tomas Cohen Arazi > Back to the ENV use I think we must make a desicion: > - Do we want to cache koha-conf.xml ? Yes, I think so. We were burning time on every request reloading it, weren't we? [...] > 2) Memoization in Koha > Do we plan to use memoization in the mid/long-term? Or are we thinking > of a more abstract set of 'cache' utilities which provide an interface > to memcached? > > Using memoization is nice, clean and simple. It has the disadvantage > that caching is done in an implicit way, and there are hidden problems > (read side-effects) that have to be taken into account. For example, Is there a good list of the example disadvantages somewhere? Have other projects made this decision faced with similar circumstances, and can we see their reasoning? Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From paul.a at aandc.org Thu Feb 9 15:35:47 2012 From: paul.a at aandc.org (Paul) Date: Thu, 09 Feb 2012 09:35:47 -0500 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: References: Message-ID: <5.2.1.1.2.20120209090249.044260c0@localhost> At 10:18 AM 2/9/2012 +0000, MJ Ray wrote: >Tomas Cohen Arazi [snip] > > 2) Memoization in Koha > > Do we plan to use memoization in the mid/long-term? Or are we thinking > > of a more abstract set of 'cache' utilities which provide an interface > > to memcached? > > > > Using memoization is nice, clean and simple. It has the disadvantage > > that caching is done in an implicit way, and there are hidden problems > > (read side-effects) that have to be taken into account. For example, > >Is there a good list of the example disadvantages somewhere? > >Have other projects made this decision faced with similar circumstances, >and can we see their reasoning? Disclaimer: my knowledge of memoization dates back to FORTRAN (fluid dynamics, harmonics and orbital calcs and was mostly used in conjunction with polynomial functions.) Is there enough repetitive math in Koha to justify memoization? I've been looking at caching (specifically memcached 1.4.13) for faster access to "text" (as opposed to calculated numeric values) in the general sense of page rendering and search results which I see as the bulk of what is returned (and therefore time cost) by a client request. The biggest problem that I appear to be facing at this point is coordinating the zebra cronjob with a discreet cache. The more static Koha files (pl, tt, inc) have not [yet] posed difficulties. I retained caching for the sql content again based on "text" versus "math results", as most examples of memoization appear to be primarily used for math functions (see for example ) If I'm way off-track from what you folks have been working on, please point me in the right direction. I'd be more than happy to look into an example of a specific case where you have felt that memoization might be advantageous. Best regards - Paul From tomascohen at gmail.com Thu Feb 9 16:29:19 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 9 Feb 2012 12:29:19 -0300 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <5.2.1.1.2.20120209090249.044260c0@localhost> References: <5.2.1.1.2.20120209090249.044260c0@localhost> Message-ID: On Thu, Feb 9, 2012 at 11:35 AM, Paul wrote: > At 10:18 AM 2/9/2012 +0000, MJ Ray wrote: >> >> Tomas Cohen Arazi > > [snip] > >> > 2) Memoization in Koha >> > Do we plan to use memoization in the mid/long-term? Or are we thinking >> > of a more abstract set of 'cache' utilities which provide an interface >> > to memcached? >> > >> > Using memoization is nice, clean and simple. It has the disadvantage >> > that caching is done in an implicit way, and there are hidden problems >> > (read side-effects) that have to be taken into account. For example, >> >> Is there a good list of the example disadvantages somewhere? >> >> Have other projects made this decision faced with similar circumstances, >> and can we see their reasoning? > > > Disclaimer: my knowledge of memoization dates back to FORTRAN (fluid > dynamics, harmonics and orbital calcs and was mostly used in conjunction > with polynomial functions.) > > Is there enough repetitive math in Koha to justify memoization? ?I've been > looking at caching (specifically memcached 1.4.13) for faster access to > "text" (as opposed to calculated numeric values) in the general sense of > page rendering and search results which I see as the bulk of what is > returned (and therefore time cost) by a client request. ?The biggest problem > that I appear to be facing at this point is coordinating the zebra cronjob > with a discreet cache. ?The more static Koha files (pl, tt, inc) have not > [yet] posed difficulties. > > I retained caching for the sql content again based on "text" versus "math > results", as most examples of memoization appear to be primarily used for > math functions (see for example > ) > > If I'm way off-track from what you folks have been working on, please point > me in the right direction. ?I'd be more than happy to look into an example > of a specific case where you have felt that memoization might be > advantageous. You are right on asking for clarification as Koha is using Memoization in a different way as usual. Memoization is normally used to trade space (in the stack) for computing time (doing the math). This ussually happens trough the life of the main loop of the app. In this case, Koha has been using memoization libs that have a persistent storage (memcached) that lives until they reach their TTL that caches the results of function calls as a way to avoid coding the cache stuff: the Memoize lib does a trick that creates a wrapper around your functions so you don't need to worry about that stuff. Hence, we are using memoization libs, to make the implementation of caching easier. Regards To+ From robin at catalyst.net.nz Thu Feb 9 20:43:55 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 10 Feb 2012 08:43:55 +1300 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <5.2.1.1.2.20120209090249.044260c0@localhost> References: <5.2.1.1.2.20120209090249.044260c0@localhost> Message-ID: <4F3421FB.8080403@catalyst.net.nz> Op 10-02-12 03:35, Paul schreef: > Is there enough repetitive math in Koha to justify memoization? I've > been looking at caching (specifically memcached 1.4.13) for faster > access to "text" (as opposed to calculated numeric values) Generalise "math" to "functions that take input and produce output based just on that", and that's a large amount of most programs. In the case of Koha, a lot of them are relatively slow operations: talking to zebra, talking to a database, and so on. Robin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From paul.a at aandc.org Fri Feb 10 01:21:30 2012 From: paul.a at aandc.org (Paul) Date: Thu, 09 Feb 2012 19:21:30 -0500 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <4F3421FB.8080403@catalyst.net.nz> References: <5.2.1.1.2.20120209090249.044260c0@localhost> <5.2.1.1.2.20120209090249.044260c0@localhost> Message-ID: <5.2.1.1.2.20120209181814.06193670@localhost> At 08:43 AM 2/10/2012 +1300, Robin Sheat wrote: >Op 10-02-12 03:35, Paul schreef: > > Is there enough repetitive math in Koha to justify memoization? I've > > been looking at caching (specifically memcached 1.4.13) for faster > > access to "text" (as opposed to calculated numeric values) > >Generalise "math" to "functions that take input and produce output based >just on that", and that's a large amount of most programs. In the case >of Koha, a lot of them are relatively slow operations: talking to zebra, >talking to a database, and so on. Thanks Robin. But I'm afraid you've lost me to a great extent. Queries to a database (be it zebra or mysql) are "one-offs" dependant on client input; and yes they are the slow point (high server time cost) and need to operate from memory rather than a HD read, hence "caching" in some form or another. But how does memoization improve on the concept that all functions are|can be cached in a more "classic" manner (as can be mysql and possibly zebra.) The concept of memoization is to eliminate *repetitivity* (classic case; memoize 17! and calculating either 15! or 19! reduces to 2 operations.) Could you give a specific Koha scenario where you feel memoization could be advantageous? I'm not trying to be "contrary" -- quite the opposite, I've been spending some effort on improving server response time and would be more than happy to go the extra mile to improve matters (and happy to spend some time in the sandbox.) Best regards - Paul From robin at catalyst.net.nz Fri Feb 10 02:08:38 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 10 Feb 2012 14:08:38 +1300 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <5.2.1.1.2.20120209181814.06193670@localhost> References: <5.2.1.1.2.20120209090249.044260c0@localhost> <5.2.1.1.2.20120209090249.044260c0@localhost> <5.2.1.1.2.20120209181814.06193670@localhost> Message-ID: <1328836118.6034.12.camel@zarathud> Paul schreef op do 09-02-2012 om 19:21 [-0500]: > But how does memoization improve on the concept that all functions > are|can > be cached in a more "classic" manner (as can be mysql and possibly > zebra.) The concept of memoization is to eliminate *repetitivity* > (classic > case; memoize 17! and calculating either 15! or 19! reduces to 2 > operations.) Well, the definition is slightly different but closely related. More or less, it can be used as a fancy way of saying "caching function results." Assume that every request for a syspref goes to the database, if we replace that with something that does it once and caches it, then that's giving us something that will speed up every operation requiring that syspref (and while composing many pages, I expect that the same syspref is hit a good number of times.) However, in the Perl world anyway, it's made quite invisible. This is a Perl module commonly used for this: http://perldoc.perl.org/Memoize.html and it actually uses recursive maths functions as examples, but the approach can generalise to other things. Mostly to speed up slow, repetitive data accesses. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From paul.poulain at biblibre.com Fri Feb 10 09:49:29 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 09:49:29 +0100 Subject: [Koha-devel] T::T caching (was Re: Speed improvement & T::T) In-Reply-To: <4EE21796.6050703@biblibre.com> References: <4EE21796.6050703@biblibre.com> Message-ID: <4F34DA19.8050803@biblibre.com> Le 09/12/2011 15:13, Paul Poulain a ?crit : > Hello Koha-devel, > I've digged into Template::Toolkit, and here > http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/Config.pod#Caching_and_Compiling_Options > I've found 2 options that look promizing : COMPILE_EXT and COMPILE_DIR I finally made some tests, and a 2 lines patch changes so many things !!! Look at bug 7511 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7511) The result is really great ! (PS: this caching type is not related to the "cache handling in Koha" thread, it's an internal T::T feature) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Fri Feb 10 10:41:33 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 10:41:33 +0100 Subject: [Koha-devel] IRC meeting decision about "discussion" Message-ID: <4F34E64D.3050805@biblibre.com> Hi all, (Koha general mailing list reader: this mail is also for you, please read it's an opportunity to participate to Koha, even if you don't have technical skills !) Tomas was faster than me to start a discussion, I planned to send a mail about the results of our discussion during the last IRC session. The question was : "how to deal with patches that are 'in discussion'". I made a proposal, that has been a little bit amended during the discussion, here is the final result: * when a patch is rejected or is conflicting with another one (not a technical conflict, but a "strategic" conflict), the bug status can be set to "In Discussion" * Someone (I volunteered to do it, but feel free to do it yourself if you're concerned= - start a wiki page with describing the problem - send a mail to koha-devel and koha pointing to the wiki page, and calling for comments. * the delay for discussion is "until next IRC meeting, not less than 1 week" * at the next IRC meeting, - if the discussion (on the wiki or koha-devel) result in a general agreement, nothing specific need to be made (no vote needed) - if the discussion result in a balanced situation, organize a vote. About the vote (this has not been discussed on last IRC meeting, thinking of it and proposing it now): as some of us are always sleeping during IRC meetings, it's unfair to vote only on the IRC channel during the meeting. I propose that ppl could also express their preference/vote on the wiki itself (and have a specific section for that on the page). Those votes would be added to the IRC vote. I've started the general discussion wiki page: http://wiki.koha-community.org/wiki/Bug_and_Enhancement_Discussion -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Fri Feb 10 11:33:52 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 11:33:52 +0100 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <1328738383.26658.11.camel@zarathud> References: <1328738383.26658.11.camel@zarathud> Message-ID: <4F34F290.9020803@biblibre.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08/02/2012 22:59, Robin Sheat a ?crit : > Tomas Cohen Arazi schreef op wo 08-02-2012 om 12:42 [-0300]: I've started the wiki page for this discussion http://wiki.koha-community.org/wiki/Cache_handling_in_Koha >> 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to >> store memcached configuration. > > My 2? here is that we should use ENV. The main logic behind this is > that it means the only thing you can't cache is the ENV vars, which > no one does anyway. I fully agree, and vote ENV as well ! > As for cache invalidation and memoisation, it's something best > approached very slowly and carefully as it's a Hard Problem. I > don't really have any concrete suggestions on that front though. I've discarded the 2nd part of this mail about the memoization on the wiki page, I think it's another topic (that I agree must be investigated) - -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPNPKQAAoJEK81SonuhyGosTMH/16+eq4TuSgJ54bzZnrE9hqg HFcHjCEDQ+oGNMgU+9DiIgZZ5JLwaqZEqBxX4wBzQrJjUkqKgkT2i/f4pBau8yX4 GiKcdDfg8+4cfUEsrLr8ySWaaca2TciVQI32zsPG/3KBfByuDOB+kJmB2Lpzbdrg dKzOE7ZxXJUqcm+x0wzIPXN3zym0SDOHRaMRPRcQZ6Qb0lzmaS1OyRBXGtYXJGfc 6RCaxL54uDC98XrmxRy8bTI1G8G5cV79pEgt649CFZeFey/bkzL9bjMcpCSaL9UV t99fE90GK4mmZRHDjQDyn1t9Und/reu93z8CnFRCgs+pVUzuI1JY8RWDkY4riZw= =4m/z -----END PGP SIGNATURE----- From paul.poulain at biblibre.com Fri Feb 10 11:44:34 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 11:44:34 +0100 Subject: [Koha-devel] [Discussion tech] database table naming Message-ID: <4F34F512.5010707@biblibre.com> Continuing with open discussion for the future of Koha: On the page http://wiki.koha-community.org/wiki/DB_schema_bugs, we have referenced some inconsistencies on the database. One of them is about table naming : acquisition related tables all start by aq, other tables don't have any prefix. OTOH, Julian has submitted a bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5339 that adds an "invoice" table, related to acquisitions, but don't has a aq prefix. The possible options are on http://wiki.koha-community.org/wiki/Table_naming, let's start the discussion ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From marc at msys.ch Fri Feb 10 12:14:45 2012 From: marc at msys.ch (Marc Balmer) Date: Fri, 10 Feb 2012 12:14:45 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F34F512.5010707@biblibre.com> References: <4F34F512.5010707@biblibre.com> Message-ID: <4F34FC25.7000506@msys.ch> Am 10.02.12 11:44, schrieb Paul Poulain: > Continuing with open discussion for the future of Koha: > > On the page http://wiki.koha-community.org/wiki/DB_schema_bugs, we have > referenced some inconsistencies on the database. > One of them is about table naming : acquisition related tables all start > by aq, other tables don't have any prefix. > > OTOH, Julian has submitted a bug > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5339 that adds > an "invoice" table, related to acquisitions, but don't has a aq prefix. > > The possible options are on > http://wiki.koha-community.org/wiki/Table_naming, let's start the > discussion ! A better (imo) move than prefixes would be to use DB schemas. This way related tables can be grouped in a schema, and default security can be defined at the schema level (at least on PostgreSQL). afaik, both MySQL and PostgreSQL support schemas. From paul.poulain at biblibre.com Fri Feb 10 12:24:42 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 12:24:42 +0100 Subject: [Koha-devel] [Discussion tech] Generalise the use Template Toolkit plugins Message-ID: <4F34FE7A.7000905@biblibre.com> I've started another discussion page: http://wiki.koha-community.org/wiki/Generalise_the_use_Template_Toolkit_plugins Chris_c recently has added a plugin to manage the display of dates into Koha (see http://wiki.koha-community.org/wiki/Coding_Guidelines#Displaying_dates), that is very interesting. Do we want to generalise this mechanism ? When do we want to use it ? For example, the patch for bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 could nicely use this mechanism let's start the discussion ! (reading the page and the possible solutions, you'll see I made 2, but am not happy with them. Probably need others ideas...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From abesottedphoenix at yahoo.com Fri Feb 10 12:55:59 2012 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Fri, 10 Feb 2012 03:55:59 -0800 (PST) Subject: [Koha-devel] IRC meeting decision about "discussion" In-Reply-To: <4F34E64D.3050805@biblibre.com> References: <4F34E64D.3050805@biblibre.com> Message-ID: <1328874959.76683.YahooMailNeo@web114707.mail.gq1.yahoo.com> Salvete! > (Koha general mailing list reader: this mail is also for you, please > read it's an opportunity to participate to Koha, even if you don't have > technical skills !) > ??? +1 > * the delay for discussion is "until next IRC meeting, not less than 1 > week" ??? I think that should probably read "window" in the stead of "delay". If you have something to talk about, don't delay. :D > About the vote (this has not been discussed on last IRC meeting, > thinking of it and proposing it now): as some of us are always sleeping > during IRC meetings, it's unfair to vote only on the IRC channel during > the meeting. I propose that ppl could also express their preference/vote > on the wiki itself (and have a specific section for that on the page). > Those votes would be added to the IRC vote. ??? This is very yucky on its face. For a long time now, the bar of involvement has been if you really are that keen to change things, show up at the General Meeting. This used to suck more before we rotated meeting times and folks could be screwed out of a meeting for literally months at a time. ??? While it's nice to have spam protection on the wiki, there are roadblocks to signing up. Do you really want a maths test when you're in a hurry to vote on something before work? How about a long wait for authorisation that might cost you the ability to vote on something you care about? ??? I think this erodes a lot of the impetus for using IRC. I've noticed that there are less folks on there in general, though. Separate problem, but how do we get to know one another now and make new folks feel welcomed, preferably in a realish time way. Identica mebbe? ??? Even if everyone wanted to do it this way, and I turn out to be very much in the minority, how are you going to accurately tabulate this many proxy votes? Deduplicating this as chair gets to be a bit of a bear, but it would be manageable at one issue per meeting. I certainly don't mind it as much for stuff like Conference. However this just doesn't seem right for deeper issues, that there are probably many of since this whole thing started to address a bug backlog. ??? I'm willing to give over on this if we can get 50 replies to this message that say "I wanna do it Paul's way." AND you have a bot or summat that will crawl the wiki for a given issue, tabulate proxy votes and then check against active IRC meeting participants. (But that seems like programming time that could be better spent on fixing barcodes or performance or whatnot.) Cheers, Brooke From oleonard at myacpl.org Fri Feb 10 14:24:50 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 10 Feb 2012 08:24:50 -0500 Subject: [Koha-devel] IRC meeting decision about "discussion" In-Reply-To: <1328874959.76683.YahooMailNeo@web114707.mail.gq1.yahoo.com> References: <4F34E64D.3050805@biblibre.com> <1328874959.76683.YahooMailNeo@web114707.mail.gq1.yahoo.com> Message-ID: > For a long time now, the bar of involvement has been if you really are that keen to change things, > show up at the General Meeting. I think this is a valid point. The meeting agendas are posted well in advance, so it should be possible to arrange to be present for a vote. We've already demonstrated that for larger issues (like the Koha non-profit question) we can use alternate methods to vote. I say we should keep the smaller stuff (especially developer-centric stuff) to the IRC meetings. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Fri Feb 10 15:09:40 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 15:09:40 +0100 Subject: [Koha-devel] IRC meeting decision about "discussion" In-Reply-To: References: <4F34E64D.3050805@biblibre.com> <1328874959.76683.YahooMailNeo@web114707.mail.gq1.yahoo.com> Message-ID: <4F352524.2040000@biblibre.com> Le 10/02/2012 14:24, Owen Leonard a ?crit : >> For a long time now, the bar of involvement has been if you really are that keen to change things, >> show up at the General Meeting. > > I think this is a valid point. The meeting agendas are posted well in > advance, so it should be possible to arrange to be present for a vote. Well, with time shifting, don't expect ppl from the "it's 2AM" timezone to be here, so I strongly think we should adress this issue. > We've already demonstrated that for larger issues (like the Koha > non-profit question) we can use alternate methods to vote. I say we > should keep the smaller stuff (especially developer-centric stuff) to > the IRC meetings. So maybe we should say: * discussion votes are made on the mailing list / on the wiki, and not on IRC if you think we should not have 2 places to vote ? Note that i've nothing against more than one method to vote. In France, if you're not present the day of the vote, you can do a "vote par procuration" (proxy vote says gg translate). It would be the same kind of voting. To answer Brooke concern: I also think the "you must register on the wiki" is not a big deal. If you want to be involved in Koha, registering on the wiki & bugzilla will be hard to avoid... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Fri Feb 10 17:50:49 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 17:50:49 +0100 Subject: [Koha-devel] Automatic detection of "does not apply" patch Message-ID: <4F354AE9.30500@biblibre.com> Hello, I wrote a small script that automatically retrieve all patches that "Needs signoff" and try to apply them on master. If it's not possible, the script can also update the status on the bug. I'll push the script on misc/devel/ directory (that will be created) I was wondering what to do with this script. The script can be run regularly, and automatically change the status of the bug, adding a comment saying "The script misc/devel/testbugzillapatches.pl has detected that this patch does not apply anymore:" with the git error message. I ran the script, with the update of bugzilla commented, and can already say the following patches don't apply: 3571, 4032, 5166, 5786, 5787, 5788, 5877, 5911, 6296, 6334, 6504, 7411, 7430 (13 patches on 77 waiting for being signed-off) My proposition is: * to push this patch into Koha, to let everybody know how it works * run it myself regularly, something like every friday. In some weeks/months, once i'm sure there are no hidden problems with the script, run it cronly, from jenkins PS: I also could easily check for signed off patches, just in case some of them don't apply anymore before being QAed PS2: the only problem i've found is when a patch depends on another one. My script won't be able to detect that and will mark "does not apply". I think it's an uncommon situation that we can deal with, but switching back to "need signoff" when the initial patch is pushed. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Fri Feb 10 17:57:18 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Feb 2012 17:57:18 +0100 Subject: [Koha-devel] Automatic detection of "does not apply" patch In-Reply-To: <4F354AE9.30500@biblibre.com> References: <4F354AE9.30500@biblibre.com> Message-ID: <4F354C6E.8090005@biblibre.com> Le 10/02/2012 17:50, Paul Poulain a ?crit : > * to push this patch into Koha, to let everybody know how it works s/this patch/this script/, of course -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From kyle.m.hall at gmail.com Fri Feb 10 19:05:24 2012 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 10 Feb 2012 13:05:24 -0500 Subject: [Koha-devel] Automatic detection of "does not apply" patch In-Reply-To: <4F354C6E.8090005@biblibre.com> References: <4F354AE9.30500@biblibre.com> <4F354C6E.8090005@biblibre.com> Message-ID: That sounds pretty awesome! Paul++ Kyle http://www.kylehall.info Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org ) On Fri, Feb 10, 2012 at 11:57 AM, Paul Poulain wrote: > Le 10/02/2012 17:50, Paul Poulain a ?crit : >> * to push this patch into Koha, to let everybody know how it works > s/this patch/this script/, of course > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > 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/ From abesottedphoenix at yahoo.com Fri Feb 10 20:01:17 2012 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Fri, 10 Feb 2012 11:01:17 -0800 (PST) Subject: [Koha-devel] IRC meeting decision about "discussion" In-Reply-To: <4F352524.2040000@biblibre.com> References: <4F34E64D.3050805@biblibre.com> <1328874959.76683.YahooMailNeo@web114707.mail.gq1.yahoo.com> <4F352524.2040000@biblibre.com> Message-ID: <1328900477.4588.YahooMailNeo@web114715.mail.gq1.yahoo.com> Salvete! >> I think this is a valid point. The meeting agendas are posted well in >> advance, so it should be possible to arrange to be present for a vote. > Well, with time shifting, don't expect ppl from the "it's 2AM" > timezone > to be here, so I strongly think we should adress this issue. > ??? How? I don't think anyone expects people from the crummy timezone to be present. The best we can do is slate a time that works for a good chunk of the geographic world, as we do now. It's always going to be a reality of life for real time meetings when we have a global project that part of the project is disenfranchised part of the time. If we come together as we have and say that "Okay, this is a large issue, let's invoke a special procedure" that's fine. It's basically a motion to suspend the rules as far as I'm concerned. Those are in order some of the time in special cases. Making a special case a day to day reality is why I'm starting to dig in. I don't want to overpromise myself here. >> We've already demonstrated that for larger issues (like the Koha >> non-profit question) we can use alternate methods to vote. I say we >> should keep the smaller stuff (especially developer-centric stuff) to >> the IRC meetings. > So maybe we should say: > * discussion votes are made on the mailing list / on the wiki, and not > on IRC if you think we should not have 2 places to vote ? Note that i've > nothing against more than one method to vote. In France, if you're not > present the day of the vote, you can do a "vote par procuration" > (proxy > vote says gg translate). It would be the same kind of voting. > ??? All of this is a matter of frequency. Voting in France is not monthly on multiple small issues. Furthermore, there's infrastructure at work that I don't have at my disposal. I am not even an arrondisement, Paul. If we really want this, then we'd need a committee of volunteers that would show to count proxies _every_ month. That's a lot of man hours that I'd frankly prefer to dedicate elsewhere. ??? If we decided on this for roles *maybe*. I'd be inclined to say certainly if we went to a 9 or 12 month release cycle. Conference to me works well: it's a once a year occurrence.? We're lucky to have Nicole helping there and tabulating things. ??? Hashing things out on the mailing list first certainly works. I still like formalising it at the meeting so that there's a logical end to discussion. I don't think anyone wants to miss a discussion, which is why the one week window before the meeting for things labeled discussion works. I think it's going to be tricky to ensure that we don't fall back to things discussed over the list and MUNG in IRC. We'll see though. > To answer Brooke concern: > I also think the "you must register on the wiki" is not a big deal. If > you want to be involved in Koha, registering on the wiki & bugzilla will > be hard to avoid... > ??? It's not a big deal with plenty of lead time. If the wiki is down, then it becomes a big deal. Bugzilla is not particularly hard to avoid for non devs. ??? We need a nice participation flow from listserv, IRC, wiki to harder things like sandboxing, bugzilla, and proper developing. Cheers, Brooke From marc at msys.ch Fri Feb 10 23:36:03 2012 From: marc at msys.ch (Marc Balmer) Date: Fri, 10 Feb 2012 23:36:03 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> Message-ID: <4F359BD3.2000303@msys.ch> Am 10.02.12 23:15, schrieb David Schuster: > Where you the one working on getting Koha to work with postgres SQL? Yes. > The School district I work for wants to see about making Koha work with > SequelSQL(Microsoft)... A bad choice. Consider PostgreSQL. > > What have you found in your journey that we should be aware of and > thinking about to make Koha database agnostic? Some shim layer in Perl will be needed to make Koha DB agnostic. I plan to work on this during the Marseille hackathon, > > We did work with Moodle to make it agnostic in regards to DB storage. > > On Fri, Feb 10, 2012 at 5:14 AM, Marc Balmer > wrote: > > Am 10.02.12 11:44, schrieb Paul Poulain: > > Continuing with open discussion for the future of Koha: > > > > On the page http://wiki.koha-community.org/wiki/DB_schema_bugs, we > have > > referenced some inconsistencies on the database. > > One of them is about table naming : acquisition related tables all > start > > by aq, other tables don't have any prefix. > > > > OTOH, Julian has submitted a bug > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5339 that > adds > > an "invoice" table, related to acquisitions, but don't has a aq > prefix. > > > > The possible options are on > > http://wiki.koha-community.org/wiki/Table_naming, let's start the > > discussion ! > > A better (imo) move than prefixes would be to use DB schemas. This way > related tables can be grouped in a schema, and default security can be > defined at the schema level (at least on PostgreSQL). > > afaik, both MySQL and PostgreSQL support schemas. > > _______________________________________________ > 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/ > > > > > -- > David Schuster > Plano ISD > Library Technology Coordinator From robin at catalyst.net.nz Sun Feb 12 03:17:12 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Sun, 12 Feb 2012 15:17:12 +1300 Subject: [Koha-devel] Replacing dependency on Date::ICal Message-ID: <1329013032.6034.26.camel@zarathud> Date::ICal is no longer really maintained, and is being dropped by Debian at least: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653301 I haven't looked to see how we use it, but we should probably consider replacing it with DateTime::Format::ICal. Oh, grep has finished: $ grep -ri 'Date::ical' * C4/Installer/PerlDependencies.pm: 'Date::ICal' => { INSTALL.fedora7:Date::ICal opac/opac-ics.pl:use Date::ICal; opac/opac-ics.pl: my $datestart = Date::ICal->new( opac/opac-ics.pl: my $dateend = Date::ICal->new( I've created http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7532 to change this, just want to know if anyone has any issues with doing this. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bob at calyx.net.au Sun Feb 12 08:02:54 2012 From: bob at calyx.net.au (Bob Birchall) Date: Sun, 12 Feb 2012 18:02:54 +1100 Subject: [Koha-devel] IRC meeting decision about "discussion" In-Reply-To: References: <4F34E64D.3050805@biblibre.com> <1328874959.76683.YahooMailNeo@web114707.mail.gq1.yahoo.com> Message-ID: <4F37641E.6040002@calyx.net.au> On 11/02/12 00:24, Owen Leonard wrote: >> For a long time now, the bar of involvement has been if you really are that keen to change things, >> show up at the General Meeting. > I think this is a valid point. The meeting agendas are posted well in > advance, so it should be possible to arrange to be present for a vote. > We've already demonstrated that for larger issues (like the Koha > non-profit question) we can use alternate methods to vote. I say we > should keep the smaller stuff (especially developer-centric stuff) to > the IRC meetings. > > -- Owen > The usual method of voting where you can't turn up in person is to send a 'proxy' vote. I see no reason why (known and experienced) people shouldn't be able to send a vote to the chair prior to the meeting, or even to ask someone else to exercise their vote at the meeting. This needs trust and good sense which both exist most of the time (whilst formalism is to be avoided if possible). Just a thought. Bob From M.de.Rooy at rijksmuseum.nl Mon Feb 13 08:11:31 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 13 Feb 2012 07:11:31 +0000 Subject: [Koha-devel] [Discussion tech] Generalise the use Template Toolkit plugins In-Reply-To: <4F34FE7A.7000905@biblibre.com> References: <4F34FE7A.7000905@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31044A8E4B@S-MAIL-1B.rijksmuseum.intra> I would say here that a general rule is hard to make. Even disapproving a patch only for the reason of not using a plugin is "discussionable". Current Koha does a lot of things in a lot of ways. Standardizing with routines and plugins is a continuous educational project.. ________________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Paul Poulain [paul.poulain at biblibre.com] Verzonden: vrijdag 10 februari 2012 12:24 To: koha-devel at lists.koha-community.org; Koha-Mailinglist Onderwerp: [Koha-devel] [Discussion tech] Generalise the use Template Toolkit plugins I've started another discussion page: http://wiki.koha-community.org/wiki/Generalise_the_use_Template_Toolkit_plugins Chris_c recently has added a plugin to manage the display of dates into Koha (see http://wiki.koha-community.org/wiki/Coding_Guidelines#Displaying_dates), that is very interesting. Do we want to generalise this mechanism ? When do we want to use it ? For example, the patch for bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 could nicely use this mechanism let's start the discussion ! (reading the page and the possible solutions, you'll see I made 2, but am not happy with them. Probably need others ideas...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ 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/ From chris at bigballofwax.co.nz Mon Feb 13 08:12:41 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 13 Feb 2012 20:12:41 +1300 Subject: [Koha-devel] [Discussion tech] Generalise the use Template Toolkit plugins In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31044A8E4B@S-MAIL-1B.rijksmuseum.intra> References: <4F34FE7A.7000905@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA31044A8E4B@S-MAIL-1B.rijksmuseum.intra> Message-ID: On 13 February 2012 20:11, Marcel de Rooy wrote: > I would say here that a general rule is hard to make. Even disapproving a patch only for the reason of not using a plugin is "discussionable". ?Current Koha does a lot of things in a lot of ways. Standardizing with routines and plugins is a continuous educational project.. > +1 ! I agree completely. Chris From mjr at phonecoop.coop Mon Feb 13 17:44:16 2012 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 13 Feb 2012 16:44:16 +0000 Subject: [Koha-devel] Replacing dependency on Date::ICal In-Reply-To: <1329013032.6034.26.camel@zarathud> Message-ID: Robin Sheat > I've created > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7532 to change > this, just want to know if anyone has any issues with doing this. No. I've marked the earlier bug 7393 as a duplicate of it. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From paul.poulain at biblibre.com Tue Feb 14 10:59:23 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 14 Feb 2012 10:59:23 +0100 Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records In-Reply-To: <5.2.1.1.2.20120127131446.06f198f0@localhost> References: <5.2.1.1.2.20120106161856.00bea980@localhost> <5.2.1.1.2.20120106151732.00bea128@localhost> <5.2.1.1.2.20120106111952.00bea128@stormy.ca> <5.2.1.1.2.20120106151732.00bea128@localhost> <5.2.1.1.2.20120106161856.00bea980@localhost> <5.2.1.1.2.20120127131446.06f198f0@localhost> Message-ID: <4F3A307B.2050703@biblibre.com> Le 27/01/2012 19:41, Paul a ?crit : > At 04:07 PM 1/27/2012 +0100, Paul Poulain wrote: > - I installed Apache as worker + fastcgi rather than prefork I'm highly interested by more information for this topic. Could you give me/us some details about your Apache configuration file ? how did you setup fastcgi ? Did it work for both staff & opac ? Thanks for your feedback, it can be a very very important topic in the next weeks. During the hackfest in Marseille, next month, we will have a group dedicated to working on persistency. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Feb 14 15:10:31 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 14 Feb 2012 15:10:31 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F34FC25.7000506@msys.ch> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> Message-ID: <4F3A6B57.9050303@biblibre.com> Le 10/02/2012 12:14, Marc Balmer a ?crit : > afaik, both MySQL and PostgreSQL support schemas. I couldn't find how it works on mySQL. Does anyone have a link with some explanation ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From marc at msys.ch Tue Feb 14 20:34:36 2012 From: marc at msys.ch (Marc Balmer) Date: Tue, 14 Feb 2012 20:34:36 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F3A6B57.9050303@biblibre.com> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> <4F3A6B57.9050303@biblibre.com> Message-ID: <4F3AB74C.3010903@msys.ch> Am 14.02.12 15:10, schrieb Paul Poulain: > Le 10/02/2012 12:14, Marc Balmer a ?crit : >> afaik, both MySQL and PostgreSQL support schemas. > I couldn't find how it works on mySQL. Does anyone have a link with some > explanation ? I will try to find out. Maybe a topic for discussions in Marseille. From marc at msys.ch Tue Feb 14 20:37:49 2012 From: marc at msys.ch (Marc Balmer) Date: Tue, 14 Feb 2012 20:37:49 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F3AB74C.3010903@msys.ch> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> <4F3A6B57.9050303@biblibre.com> <4F3AB74C.3010903@msys.ch> Message-ID: <4F3AB80D.90903@msys.ch> Am 14.02.12 20:34, schrieb Marc Balmer: > Am 14.02.12 15:10, schrieb Paul Poulain: >> Le 10/02/2012 12:14, Marc Balmer a ?crit : >>> afaik, both MySQL and PostgreSQL support schemas. >> I couldn't find how it works on mySQL. Does anyone have a link with some >> explanation ? > > I will try to find out. Maybe a topic for discussions in Marseille. Turns out that MySQL indeed has no schema support. But it supports cross-database-queries. A "database" in MySQL is very similar, if not the same, as a "schema" in PostgreSQL. From robin at catalyst.net.nz Tue Feb 14 20:41:25 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 15 Feb 2012 08:41:25 +1300 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F3AB80D.90903@msys.ch> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> <4F3A6B57.9050303@biblibre.com> <4F3AB74C.3010903@msys.ch> <4F3AB80D.90903@msys.ch> Message-ID: <4F3AB8E5.5050509@catalyst.net.nz> Op 15-02-12 08:37, Marc Balmer schreef: > Turns out that MySQL indeed has no schema support. But it supports > cross-database-queries. > > A "database" in MySQL is very similar, if not the same, as a "schema" in > PostgreSQL. Noo, not quite. I mean, they can be used like that, but I would be strongly be against using databases as schema. That way lies terrible madness. In particular, all the tools expect to deal with a database as the unit of data for an application, all permissions are associated with that database, and so on. Also, if you're using a database server administered by someone who isn't you, they'll hate you forever if you do it that way. Robin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From marc at msys.ch Tue Feb 14 20:46:06 2012 From: marc at msys.ch (Marc Balmer) Date: Tue, 14 Feb 2012 20:46:06 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F3AB8E5.5050509@catalyst.net.nz> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> <4F3A6B57.9050303@biblibre.com> <4F3AB74C.3010903@msys.ch> <4F3AB80D.90903@msys.ch> <4F3AB8E5.5050509@catalyst.net.nz> Message-ID: <4F3AB9FE.2090405@msys.ch> Am 14.02.12 20:41, schrieb Robin Sheat: > Op 15-02-12 08:37, Marc Balmer schreef: >> Turns out that MySQL indeed has no schema support. But it supports >> cross-database-queries. >> >> A "database" in MySQL is very similar, if not the same, as a "schema" in >> PostgreSQL. > > Noo, not quite. I mean, they can be used like that, but I would be > strongly be against using databases as schema. That way lies terrible > madness. > > In particular, all the tools expect to deal with a database as the unit > of data for an application, all permissions are associated with that > database, and so on. Also, if you're using a database server > administered by someone who isn't you, they'll hate you forever if you > do it that way. Oh, I was not suggesting using MySQL databases like PostgreSQL schemas, I was merely pointing out the similarity. From robin at catalyst.net.nz Tue Feb 14 20:47:57 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 15 Feb 2012 08:47:57 +1300 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F3AB9FE.2090405@msys.ch> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> <4F3A6B57.9050303@biblibre.com> <4F3AB74C.3010903@msys.ch> <4F3AB80D.90903@msys.ch> <4F3AB8E5.5050509@catalyst.net.nz> <4F3AB9FE.2090405@msys.ch> Message-ID: <4F3ABA6D.6060002@catalyst.net.nz> Op 15-02-12 08:46, Marc Balmer schreef: > Oh, I was not suggesting using MySQL databases like PostgreSQL schemas, > I was merely pointing out the similarity. Oh good :) from the SQL level, they are reasonably similar. Robin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From paul.poulain at biblibre.com Tue Feb 14 15:10:31 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 14 Feb 2012 15:10:31 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F34FC25.7000506@msys.ch> References: <4F34F512.5010707@biblibre.com> <4F34FC25.7000506@msys.ch> Message-ID: <4F3A6B57.9050303@biblibre.com> Le 10/02/2012 12:14, Marc Balmer a ?crit : > afaik, both MySQL and PostgreSQL support schemas. I couldn't find how it works on mySQL. Does anyone have a link with some explanation ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Wed Feb 15 18:16:26 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 15 Feb 2012 18:16:26 +0100 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: References: Message-ID: <4F3BE86A.2020203@biblibre.com> Le 08/02/2012 16:42, Tomas Cohen Arazi a ?crit : > Hi, I'm just starting a thread to discuss this topic so we make some > decisions and we can continue improving Koha in this aspect. As far as > I can remember there are a few issues with this: > > 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store > memcached configuration. Unless i've missed something or someone opinion, everybody agrees that the use of ENV is better, because it will result in caching koha-conf.xml itself. (I add my vote to this option) Unless someone object in the next 3 days, i'll consider the decision is taken, and will push bug 6193 patch, and subsequent patches will have to consider caching is retrieved from here. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.a at aandc.org Thu Feb 16 17:49:53 2012 From: paul.a at aandc.org (Paul) Date: Thu, 16 Feb 2012 11:49:53 -0500 Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records In-Reply-To: <4F3A307B.2050703@biblibre.com> References: <5.2.1.1.2.20120127131446.06f198f0@localhost> <5.2.1.1.2.20120106161856.00bea980@localhost> <5.2.1.1.2.20120106151732.00bea128@localhost> <5.2.1.1.2.20120106111952.00bea128@stormy.ca> <5.2.1.1.2.20120106151732.00bea128@localhost> <5.2.1.1.2.20120106161856.00bea980@localhost> <5.2.1.1.2.20120127131446.06f198f0@localhost> Message-ID: <5.2.1.1.2.20120216114404.0703cb60@localhost> At 10:59 AM 2/14/2012 +0100, Paul Poulain wrote: >Le 27/01/2012 19:41, Paul a ?crit : > > At 04:07 PM 1/27/2012 +0100, Paul Poulain wrote: > > - I installed Apache as worker + fastcgi rather than prefork > >I'm highly interested by more information for this topic. >Could you give me/us some details about your Apache configuration file ? >how did you setup fastcgi ? Did it work for both staff & opac ? >Thanks for your feedback, it can be a very very important topic in the >next weeks. [snip] I'll try and dig out my notes, especially on the .conf files. On the install, I just followed the "manual" and had no problems. As to making it work and the various timing advantages (and your question re: OPAC and Staff), I'm in the middle of rebuilding my sand-box and would ask if you could wait a few days on answers as I don't really want to risk upsetting the production server. Best - Paul From paul.a at aandc.org Thu Feb 16 18:01:20 2012 From: paul.a at aandc.org (Paul) Date: Thu, 16 Feb 2012 12:01:20 -0500 Subject: [Koha-devel] help with nomenclature Message-ID: <5.2.1.1.2.20120216111536.06229368@stormy.ca> Does anyone have a "cheat sheet" covering the nomenclature of fields, strings, descriptions, etc used in the various components of Koha? (mysql, perl, inc, tt etc) For example, I would like to add to a "moredetails.pl" prequest a couple more editing possibilities (just like "Lost", "Damaged" and "Withdrawn") such as "Shelving location" (952$c) and 952$g that we use for Fair Market Value. As an example of trying to trace a variable (from additem.pl), the raw data gets transformed/added to during various loops from 952$c and tracing "shelving" from:
which poses as many questions as it answers -- and I'd like to proceed as efficiently as possible. The various online manuals etc do not appear to have a nomenclature / logic flow chart but I am hoping that one of you may have something ready made along these lines I'd also appreciate pointers to the origins of subfield952c175402, error13, tag_952_subfield_c_166742, etc - I'm guessing I could cause a minor disaster in the sql. Thanks and best regards, Paul From paul.poulain at biblibre.com Thu Feb 16 18:15:21 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 16 Feb 2012 18:15:21 +0100 Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records In-Reply-To: <5.2.1.1.2.20120216114404.0703cb60@localhost> References: <5.2.1.1.2.20120127131446.06f198f0@localhost> <5.2.1.1.2.20120106161856.00bea980@localhost> <5.2.1.1.2.20120106151732.00bea128@localhost> <5.2.1.1.2.20120106111952.00bea128@stormy.ca> <5.2.1.1.2.20120106151732.00bea128@localhost> <5.2.1.1.2.20120106161856.00bea980@localhost> <5.2.1.1.2.20120127131446.06f198f0@localhost> <5.2.1.1.2.20120216114404.0703cb60@localhost> Message-ID: <4F3D39A9.4060003@biblibre.com> Le 16/02/2012 17:49, Paul a ?crit : > if you could wait a few days on answers as I > don't really want to risk upsetting the production server. Well, my main goal is to have a group working on this topic during the hackfest in Marseille, between march 19th and march 24th, so it can wait a little bit, no worries -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From danielg.koha at gmail.com Thu Feb 16 21:13:28 2012 From: danielg.koha at gmail.com (Daniel Grobani) Date: Thu, 16 Feb 2012 12:13:28 -0800 Subject: [Koha-devel] Call for News for the February Newsletter Message-ID: Dear Koha Kommunitarians, I'm harvesting news for the February newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two about what you're currently working on for publication in the gossip/society column. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani From M.de.Rooy at rijksmuseum.nl Mon Feb 20 10:15:12 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 20 Feb 2012 09:15:12 +0000 Subject: [Koha-devel] Improving permissions on lists (virtual shelves) Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310953A97F@S-MAIL-1B.rijksmuseum.intra> Hi all, Following up on the discussion on list permissions in December, I updated the wiki page http://wiki.koha-community.org/wiki/List_permissions and submitted the first patches for report 7310 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7310) These first patches form the foundation for further changes but still stay very close to current functionality. One new point (not discussed before): While developing and refactoring some code, I removed the increasing lists information from session storage. This simplified the code, makes the sessions much smaller, ensures actual list information and did not make a big difference in performance (depending on factors as session count, number of lists, etc.; could even be faster). Next step in the development is now test and sign-off. Anyone willing is welcome to test! A detailed test plan is included on the report and on the wiki. Hope to hear from you! Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Tue Feb 21 13:54:39 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 21 Feb 2012 13:54:39 +0100 Subject: [Koha-devel] [Discussion Tech] Cache handling in koha In-Reply-To: <4F3BE86A.2020203@biblibre.com> References: <4F3BE86A.2020203@biblibre.com> Message-ID: <4F43940F.5070408@biblibre.com> Le 15/02/2012 18:16, Paul Poulain a ?crit : >> I will push bug 6193 patch, and subsequent patches will have to > consider caching is retrieved from here. I just pushed bug 6193, and have updated status of caching related bugs: * bug 6019 has been marked RESO-INVALID * bug 7248 and 7249 have been marked "Patch Doesn't apply". However, some ideas behing 7248 are good and it should be rewritten I've added to my pre 3.8 release notes something about this change : existing install will have to update their memcache server configuration, to switch from koha-conf.xml to koha-httpd.conf -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Feb 21 14:08:07 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 21 Feb 2012 14:08:07 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F34F512.5010707@biblibre.com> References: <4F34F512.5010707@biblibre.com> Message-ID: <4F439737.7030601@biblibre.com> Le 10/02/2012 11:44, Paul Poulain a ?crit : > The possible options are on > http://wiki.koha-community.org/wiki/Table_naming, let's start the > discussion ! Back to this thread... as it seems that no-one want to start the discussion. My proposal is that we should go the easiest way: * for now, the table should be called "aqinvoices", to be consistent with other acquisitions related tables. * in the medium/long term, get rid of any prefix, and rename "aq*" tables. Sounds like a good plan ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Feb 21 14:22:04 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 21 Feb 2012 14:22:04 +0100 Subject: [Koha-devel] [Discussion tech] Generalise the use Template Toolkit plugins In-Reply-To: References: <4F34FE7A.7000905@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA31044A8E4B@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4F439A7C.2050409@biblibre.com> Le 13/02/2012 08:12, Chris Cormack a ?crit : > On 13 February 2012 20:11, Marcel de Rooy wrote: >> I would say here that a general rule is hard to make. Even disapproving a patch only for the reason of not using a plugin is "discussionable". > Current Koha does a lot of things in a lot of ways. Standardizing with routines and plugins is a continuous educational project.. > > I agree completely. I also agree completely too: Koha does a lot of things in a lot of ways. Maybe we don't conclude the same things: my conclusion is that we must coordinate & organize things as much as possible. So, my preference would go to: * it's too hard to make a general rule for display plugins. There would be too many possibilities to imagine. * for bug 4078, we should ask for a plugin though: looking at the code, it introduces dozens of: + $something = PlaceCurrencySymbol($something); Those will add complexity to the code, if one day $something must be reused after the PlaceCurrencySymbol has been applied, there will be side effects. There are *bad* things like: + $$item{field} = PlaceCurrencySymbol($$item{field}) if ($$item{field} =~ /^\d+\.\d\d$/); in the patch : they'll display a currency just in case something is numeric with 2 decimals. That can be the case of a dewey code, librarians won't like seeing a $ or ? on their dewey ;-) I'll ask for an alternate patch on the bug itself, it's really a nice feature but Aleksa probably missed the T::T plugin (great) feature ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From M.de.Rooy at rijksmuseum.nl Tue Feb 21 14:40:27 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Tue, 21 Feb 2012 13:40:27 +0000 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F439737.7030601@biblibre.com> References: <4F34F512.5010707@biblibre.com>,<4F439737.7030601@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310954014C@S-MAIL-1B.rijksmuseum.intra> Why not call it invoices, and be not consistent with an inconsistency? Renaming all aq tables is theoretically preferred of course. But is it worth the energy? ________________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Paul Poulain [paul.poulain at biblibre.com] Verzonden: dinsdag 21 februari 2012 14:08 To: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] [Discussion tech] database table naming Le 10/02/2012 11:44, Paul Poulain a ?crit : > The possible options are on > http://wiki.koha-community.org/wiki/Table_naming, let's start the > discussion ! Back to this thread... as it seems that no-one want to start the discussion. My proposal is that we should go the easiest way: * for now, the table should be called "aqinvoices", to be consistent with other acquisitions related tables. * in the medium/long term, get rid of any prefix, and rename "aq*" tables. Sounds like a good plan ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ 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/ From paul.poulain at biblibre.com Tue Feb 21 14:45:18 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 21 Feb 2012 14:45:18 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310954014C@S-MAIL-1B.rijksmuseum.intra> References: <4F34F512.5010707@biblibre.com>, <4F439737.7030601@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA310954014C@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4F439FEE.5090104@biblibre.com> Le 21/02/2012 14:40, Marcel de Rooy a ?crit : > Why not call it invoices, and be not consistent with an inconsistency? The 1st patch was without the "aq" and some noticed this inconsistency... Overall I think it's more consistent to have the "aq" for now. > Renaming all aq tables is theoretically preferred of course. But is it worth the energy? I think that, on the long term, yes, it's worth the energy. I'm sure you've been surprised more than once by some inconsistencies: ppl that know how Koha work don't have much problem with them. But being consistent helps a lot ppl to understand how things are written when they start hacking. PS: I agree that the table prefix is not the biggest inconsistency we have. About SQL, the biggest one is probably singular/plural table names ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From oleonard at myacpl.org Tue Feb 21 14:49:14 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 21 Feb 2012 08:49:14 -0500 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F439737.7030601@biblibre.com> References: <4F34F512.5010707@biblibre.com> <4F439737.7030601@biblibre.com> Message-ID: > My proposal is that we should go the easiest way: > * for now, the table should be called "aqinvoices", to be consistent > with other acquisitions related tables. > * in the medium/long term, get rid of any prefix, and rename "aq*" tables. I think this is a good plan. While the other "aq" prefixes exist, let's remain consistent. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From tajoli at cilea.it Tue Feb 21 15:18:17 2012 From: tajoli at cilea.it (tajoli at cilea.it) Date: Tue, 21 Feb 2012 15:18:17 +0100 (CET) Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F439737.7030601@biblibre.com> Message-ID: <6b7a9584-b26a-405e-ad3a-0fb9ea11fea9@esx-revenge> Hi to all, >----- Messaggio originale ----- >Da: "Paul Poulain" >Oggetto: Re: [Koha-devel] [Discussion tech] database table naming Le 10/02/2012 11:44, Paul Poulain a ?crit : > The possible options are on > http://wiki.koha-community.org/wiki/Table_naming, let's start the > discussion ! >Back to this thread... as it seems that no-one want to start the discussion. >My proposal is that we should go the easiest way: >* for now, the table should be called "aqinvoices", to be consistent >with other acquisitions related tables. for me is OK. >* in the medium/long term, get rid of any prefix, and rename "aq*" tables. I dislike this. In the medium/long term, use prefix for every table. I have update the wiki. Bye Zeno Tajoli From colin.campbell at ptfs-europe.com Tue Feb 21 16:09:08 2012 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Tue, 21 Feb 2012 15:09:08 +0000 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <4F439737.7030601@biblibre.com> References: <4F34F512.5010707@biblibre.com> <4F439737.7030601@biblibre.com> Message-ID: <20120221150908.GA5582@zazou.cscnet.co.uk> On Tue, Feb 21, 2012 at 02:08:07PM +0100, Paul Poulain wrote: > > My proposal is that we should go the easiest way: > * for now, the table should be called "aqinvoices", to be consistent > with other acquisitions related tables. > * in the medium/long term, get rid of any prefix, and rename "aq*" > tables. Why not just invoices, I think the prefixes are superfluous ( orders invoices etc are relevant objects outside of acquisition, serials uses them for instance and we dont need to distinguish them from some other type of order ) But just because we've done one more sensibly we dont need to bring the rest into line, I'm perfectly willing to continue cursing at that aq prefix (my fingers want to type acq) and we can postpone 'the great renaming' until we get around to something that requires the interface to the orders table to be updated. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From oleonard at myacpl.org Tue Feb 21 16:09:56 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 21 Feb 2012 10:09:56 -0500 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths Message-ID: I have done some work on Bug 4048, "Moving CSS and JS out of translated paths," but the work quickly becomes out of date because it touches so many files. I'm willing to keep working on it if others think it is still worthwhile, so I'd like to ask for opinions. The goal of the bug was to move common CSS and JavaScript files out of language-specific directories so that they are not duplicated. CSS and JavaScript files are not processed by the translation script, so there isn't much reason at the moment to keep them where they can be processed by it. The question is whether it might be a goal of some people to add translation of JavaScript files? The other question I have about revisiting my work on this bug is how I can submit a patch and expect it to be tested in a timely manner. Making a far-reaching change is inconvenient for everyone, I know. If we agree that the bug is worth fixing, how can we apply the fix in the least painful way? Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From gmc at esilibrary.com Tue Feb 21 16:14:13 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 21 Feb 2012 10:14:13 -0500 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <20120221150908.GA5582@zazou.cscnet.co.uk> References: <4F34F512.5010707@biblibre.com> <4F439737.7030601@biblibre.com> <20120221150908.GA5582@zazou.cscnet.co.uk> Message-ID: <49B152C5-7C9C-4071-9CB7-F0BEAF1A87F8@esilibrary.com> Hi, On Feb 21, 2012, at 10:09 AM, Colin Campbell wrote: > Why not just invoices, I think the prefixes are superfluous ( orders > invoices etc are relevant objects outside of acquisition, serials uses > them for instance and we dont need to distinguish them from some other > type of order ) But just because we've done one more sensibly we dont > need to bring the rest into line, I'm perfectly willing to continue > cursing at that aq prefix (my fingers want to type acq) and we can > postpone 'the great renaming' until we get around to something that > requires the interface to the orders table to be updated. I agree with Colin -- why not just call it 'invoices' and start dropping the prefix? Furthermore, doing that is a way to get the renaming started. However, ultimately I think it matters more that work proceed on adding invoice functionality rather than getting too hung up on the 'aq' prefix. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From mtj at kohaaloha.com Tue Feb 21 22:30:02 2012 From: mtj at kohaaloha.com (Mason James) Date: Wed, 22 Feb 2012 10:30:02 +1300 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths In-Reply-To: References: Message-ID: On 2012-02-22, at 4:09 AM, Owen Leonard wrote: > I have done some work on Bug 4048, "Moving CSS and JS out of > translated paths," but the work quickly becomes out of date because it > touches so many files. I'm willing to keep working on it if others > think it is still worthwhile, so I'd like to ask for opinions. > > The goal of the bug was to move common CSS and JavaScript files out of > language-specific directories so that they are not duplicated. CSS and > JavaScript files are not processed by the translation script, so there > isn't much reason at the moment to keep them where they can be > processed by it. The question is whether it might be a goal of some > people to add translation of JavaScript files? > > The other question I have about revisiting my work on this bug is how > I can submit a patch and expect it to be tested in a timely manner. > Making a > far-reaching change is inconvenient for everyone, I know. If we agree > that the bug is worth fixing, how can we apply the fix in the least > painful way? > heya Owen, great work! gitorious wont let me look at your patch/diff via its gui, the web error is.... 'This Git object is too large to be displayed in the browser Consider cloning the repository locally and look at the object there' i have a suggestion (that may require too much work too?) perhaps a quick-dirty script that rewrites paths on the latest master repo, rather than a patch? might that work? (remember i cant see your patch via gitorious yet :) ) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From oleonard at myacpl.org Wed Feb 22 00:45:58 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 21 Feb 2012 18:45:58 -0500 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths In-Reply-To: References: Message-ID: > gitorious wont let me look at your patch/diff via its gui, the web error is.... The gitorious branch is out of date, but you could certainly get a sense of what I was doing. > perhaps a quick-dirty script that rewrites paths on the latest master repo, rather than a patch? If someone want to write that, it's fine with me. It's a little over my head. That still leaves open the question of whether there is a course of action for getting this tested an approved which will be timely enough to make it worthwhile. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From cnighswonger at foundations.edu Wed Feb 22 00:49:40 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 21 Feb 2012 18:49:40 -0500 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: <20120221150908.GA5582@zazou.cscnet.co.uk> References: <4F34F512.5010707@biblibre.com> <4F439737.7030601@biblibre.com> <20120221150908.GA5582@zazou.cscnet.co.uk> Message-ID: On Tue, Feb 21, 2012 at 10:09 AM, Colin Campbell < colin.campbell at ptfs-europe.com> wrote: > On Tue, Feb 21, 2012 at 02:08:07PM +0100, Paul Poulain wrote: > > > > My proposal is that we should go the easiest way: > > * for now, the table should be called "aqinvoices", to be consistent > > with other acquisitions related tables. > > * in the medium/long term, get rid of any prefix, and rename "aq*" > > tables. > > Why not just invoices, I think the prefixes are superfluous ( orders > invoices etc are relevant objects outside of acquisition, serials uses > them for instance and we dont need to distinguish them from some other > type of order ) I also agree with Colin. Lets go with invoices and work from there toward ridding the db of prefixed table names. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed Feb 22 13:15:03 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 22 Feb 2012 12:15:03 +0000 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths In-Reply-To: References: , Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310954340A@S-MAIL-1B.rijksmuseum.intra> Owen wrote: > If someone want to write that, it's fine with me. It's a little over > my head. That still leaves open the question of whether there is a > course of action for getting this tested an approved which will be > timely enough to make it worthwhile. That is an interesting question in general too. If we have community consensus on some kind of change (before programming started) resulting in "time-sensitive" patches, could we have some procedure to get them on a priority lane through signoff and QA? This would probably involve not only consensus on the changes but also the promise for a quick signoff from other members. Opening up a more general discussion? From paul.poulain at biblibre.com Wed Feb 22 17:28:09 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 22 Feb 2012 17:28:09 +0100 Subject: [Koha-devel] [Discussion tech] database table naming In-Reply-To: References: <4F34F512.5010707@biblibre.com> <4F439737.7030601@biblibre.com> <20120221150908.GA5582@zazou.cscnet.co.uk> Message-ID: <4F451799.3060107@biblibre.com> Le 22/02/2012 00:49, Chris Nighswonger a ?crit : > I also agree with Colin. Lets go with invoices and work from there > toward ridding the db of prefixed table names. Colin, Galen, Chris_n, i've added your voice to "Remove all prefix" option. It seems we have almost reached a consensus, only Zeno would like to define a prefix for all modules. We consider the decision as taken and Julian can resubmit his "invoice" patch without "aq" prefix ? If you object, please say it now ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Wed Feb 22 17:32:12 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 22 Feb 2012 17:32:12 +0100 Subject: [Koha-devel] serial recieve broken (follow-up to bug 6875, signoff required ASAP) Message-ID: <4F45188C.8060409@biblibre.com> Hello, I've submitted a patch that should fix the perl error when you recieve a serial, that was caused by the de-nesting effort. See http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6875#c70 for how to reproduce the bug, attachment http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7808&action=diff for the follow-up please, signoff required ASAP ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Wed Feb 22 18:17:49 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 22 Feb 2012 18:17:49 +0100 Subject: [Koha-devel] Bugzilla email change Message-ID: <4F45233D.3020303@biblibre.com> Hello all, I recieve a lot of mails from bugzilla when someone changes something and i'm in the cc or have added a comment or am assignee. Sometimes i'm not sure if I'm the assignee or not. Could it be possible to have that added to the email sent ? Something like: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6919 > assignee: alex.arnaud at biblibre.com > > M. de Rooy changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|Signed Off |Failed QA > > --- Comment #31 from M. de Rooy 2012-02-20 13:11:19 UTC --- > Code looks good in general. One point that blocks this patch: > ... would please me a lot ! thx if galen or chris_c can do that !!! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Wed Feb 22 18:21:27 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 22 Feb 2012 18:21:27 +0100 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310954340A@S-MAIL-1B.rijksmuseum.intra> References: , <809BE39CD64BFD4EB9036172EBCCFA310954340A@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4F452417.9030208@biblibre.com> Le 22/02/2012 13:15, Marcel de Rooy a ?crit : > Owen wrote: >> If someone want to write that, it's fine with me. It's a little over >> my head. That still leaves open the question of whether there is a >> course of action for getting this tested an approved which will be >> timely enough to make it worthwhile. > > That is an interesting question in general too. If we have community consensus on some kind of change (before programming started) resulting in "time-sensitive" patches, could we have some procedure to get them on a priority lane through signoff and QA? > This would probably involve not only consensus on the changes but also the promise for a quick signoff from other members. > Opening up a more general discussion? Good point Marcel, and I think it can also be related to 2 others: * the database table naming thread = if we want to remove aq prefix, then should be remove all of them in one patch, of we do it step by step ? * bug 7113 = owen did a large job to standardize how we call the identifier of the shop where the library buys material from. It was sometimes id, sometimes supplierid, sometimes booksellerid, crapy... The patch has been pushed a few days ago, and it fixes everything, except that: - owen did not update/fix the database - there are a few places (in serials for example) un-standardized Should I have rejected the patch for this reason ? (I don't think so, it was a large patch, owen would have been tired to have to rebase it 10 times) The question can also be "rewriten" as : "for structural/deep changes", should we do small step by small step, or everything at once ? I feel/fear that everything at once will be very hard to manage. And small step by small step is much easier. For the "aq" or "not aq" thing for example, I'm not against having a "middle of the river" (frenchism ?) situation, with some tables having the "aq" prefix removed, and some not. For the CSS question, we could have, for a given period, the css available in 2 different places, so scripts updated would call the good version, and script still "to update" would call the old version. That would ensure the stability of Koha, the important thing being to have a consensus and clear volunteers. So my position here is "accept a patch if it goes in the right/consensus direction, even if it does not everything and if it does not break Koha" -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chrisc at catalyst.net.nz Wed Feb 22 18:38:46 2012 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 23 Feb 2012 06:38:46 +1300 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths In-Reply-To: <4F452417.9030208@biblibre.com> References: , <809BE39CD64BFD4EB9036172EBCCFA310954340A@S-MAIL-1B.rijksmuseum.intra> <4F452417.9030208@biblibre.com> Message-ID: If there's one thing that everyone who has been release manager has learnt. It's that big patches that change a lot at once break more than they fix. Small incremental changes are almost always better. If a patch moves the codebase forward towards a goal without causing bugs or regressions, accepting it at that point is a zillion times better than saying but can't it also do this. IMHO. Chris -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Paul Poulain wrote: Le 22/02/2012 13:15, Marcel de Rooy a ?crit : > Owen wrote: >> If someone want to write that, it's fine with me. It's a little over >> my head. That still leaves open the question of whether there is a >> course of action for getting this tested an approved which will be >> timely enough to make it worthwhile. > > That is an interesting question in general too. If we have community consensus on some kind of change (before programming started) resulting in "time-sensitive" patches, could we have some procedure to get them on a priority lane through signoff and QA? > This would probably involve not only consensus on the changes but also the promise for a quick signoff from other members. > Opening up a more general discussion? Good point Marcel, and I think it can also be related to 2 others: * the database table naming thread = if we want to remove aq prefix, then should be remove all of them in one patch, of we do it step by step ? * bug 7113 = owen did a large job to standardize how we call the identifier of the shop where the library buys material from. It was sometimes id, sometimes supplierid, sometimes booksellerid, crapy... The patch has been pushed a few days ago, and it fixes everything, except that: - owen did not update/fix the database - there are a few places (in serials for example) un-standardized Should I have rejected the patch for this reason ? (I don't think so, it was a large patch, owen would have been tired to have to rebase it 10 times) The question can also be "rewriten" as : "for structural/deep changes", should we do small step by small step, or everything at once ? I feel/fear that everything at once will be very hard to manage. And small step by small step is much easier. For the "aq" or "not aq" thing for example, I'm not against having a "middle of the river" (frenchism ?) situation, with some tables having the "aq" prefix removed, and some not. For the CSS question, we could have, for a given period, the css available in 2 different places, so scripts updated would call the good version, and script still "to update" would call the old version. That would ensure the stability of Koha, the important thing being to have a consensus and clear volunteers. So my position here is "accept a patch if it goes in the right/consensus direction, even if it does not everything and if it does not break Koha" -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _____________________________________________ 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: From mjr at phonecoop.coop Wed Feb 22 20:22:42 2012 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 22 Feb 2012 19:22:42 +0000 Subject: [Koha-devel] Bugzilla email change In-Reply-To: <4F45233D.3020303@biblibre.com> Message-ID: Paul Poulain > I recieve a lot of mails from bugzilla when someone changes something > and i'm in the cc or have added a comment or am assignee. > > Sometimes i'm not sure if I'm the assignee or not. > Could it be possible to have that added to the email sent ? Isn't it already there? I think it's near the bottom of the email, that bugzilla says why it emailed this to you. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From cnighswonger at foundations.edu Wed Feb 22 21:26:28 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 22 Feb 2012 15:26:28 -0500 Subject: [Koha-devel] 3.6.x String Freeze Message-ID: As of now 3.6.x is in string freeze for the release of 3.6.4. 3.6.4 will be released on Thursday, March 1. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Feb 22 22:50:00 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 22 Feb 2012 22:50:00 +0100 Subject: [Koha-devel] Bugzilla email change In-Reply-To: References: Message-ID: <4F456308.2080700@biblibre.com> Le 22/02/2012 20:22, MJ Ray a ?crit : > Paul Poulain >> I recieve a lot of mails from bugzilla when someone changes something >> and i'm in the cc or have added a comment or am assignee. >> >> Sometimes i'm not sure if I'm the assignee or not. >> Could it be possible to have that added to the email sent ? > > Isn't it already there? I think it's near the bottom of the email, > that bugzilla says why it emailed this to you. You're perfectly right ! As it was after '-- ', is was displayed as a signature & I never spotted that ! thx slef -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From f.demians at tamil.fr Thu Feb 23 11:14:17 2012 From: f.demians at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Thu, 23 Feb 2012 11:14:17 +0100 Subject: [Koha-devel] [Koha-translate] 3.6.x String Freeze In-Reply-To: References: Message-ID: <4F461179.8080006@tamil.fr> > As of now 3.6.x is in string freeze for the release of 3.6.4. 3.6.4 > will be released on Thursday, March 1. Translation files have been updated with 3.6.4 new strings on: http://translate.koha-community.org You can start updating your translation! Kind regards, -- Fr?d?ric DEMIANS http://www.tamil.fr/u/fdemians.html From cnighswonger at foundations.edu Thu Feb 23 13:48:37 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 23 Feb 2012 07:48:37 -0500 Subject: [Koha-devel] 3.6.x String Freeze In-Reply-To: References: Message-ID: BTW, some testing on the 3.6.x branch this week might not be a bad idea. I had to do a series of reverts for various reasons. Testing would help ensure no regressions crept in. Kind Regards, Chris On Wed, Feb 22, 2012 at 3:26 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > As of now 3.6.x is in string freeze for the release of 3.6.4. > > 3.6.4 will be released on Thursday, March 1. > > Kind Regards, > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Fri Feb 24 21:34:01 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 24 Feb 2012 15:34:01 -0500 Subject: [Koha-devel] Moving CSS and JavaScript out of translated paths In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA310954340A@S-MAIL-1B.rijksmuseum.intra> <4F452417.9030208@biblibre.com> Message-ID: 2012/2/22 Chris Cormack > > If there's one thing that everyone who has been release manager has > learnt. It's that big patches that change a lot at once break more than they > fix. Small incremental changes are almost always better. With that in mind I've prepared a new set of changes which are ready for testing. As Paul suggested, instead of moving the CSS and JS files I've created a copy of them in the new location, leaving the old files to cover templates which haven't yet been modified. That makes for too large a patch for Bugzilla so you'll have to test by cloning the branch from Gitorious: git://gitorious.org/koha-dev/koha-dev.git The branch is called ip-bug-4048-js-css-libs-path-2012-02-24 See Bug 4048 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4048) for a detailed commit message. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From danielg.koha at gmail.com Sat Feb 25 00:42:24 2012 From: danielg.koha at gmail.com (Daniel Grobani) Date: Fri, 24 Feb 2012 15:42:24 -0800 Subject: [Koha-devel] Official Koha Newsletter: Volume 3, Issue 2: February 2012 Message-ID: [Below is the text of the newsletter. For active links and a more readable format, please visit http://koha-community.org/koha-newsletter-volume-3-issue-2-february-2012] Official Koha Newsletter (ISSN 2153-8328) Volume 3, Issue 2: February 2012 Edited by Daniel Grobani, Koha Community Newsletter Editor. Please submit news items to danielg.koha at gmail.com. Table of Contents Koha Development Koha 3.6.4 Status Koha 3.6.3 Released Koha 3.4.8 Released Koha Release Statistics Release Manager?s Newsletter Koha Community New Koha Libraries Community Gossip Past Koha Events February General IRC Meeting Global Bug Squashing Day 2012-02-08 Upcoming Koha Events Marseille Hackfest March General IRC Meeting KohaCon12 Koha Development Koha 3.6.4 Status by Chris Nighswonger The 3.6.x branch is in a string freeze. Koha 3.6.4 is scheduled for release on 1 March 2012. Koha 3.6.3 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.6.3. The package can be retrieved from: http://download.koha-community.org/koha-3.06.03.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.06.03.tar.gz.MD5 http://download.koha-community.org/koha-3.06.03.tar.gz.MD5.asc http://download.koha-community.org/koha-3.06.03.tar.gz.sig Release notes for 3.6.3 are at http://koha-community.org/koha-3-6-3. Koha 3.4.8 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.4.8. The package can be retrieved from: http://download.koha-community.org/koha-3.04.08.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.08.tar.gz.MD5 http://download.koha-community.org/koha-3.04.08.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.08.tar.gz.sig Release notes for 3.4.8 are at http://koha-community.org/koha-3-4-8. Koha Release Statistics Chris Cormack, statistician par excellence, has posted some stats on recent Koha releases: Statistics for Koha 3.6.3 Statistics for Koha 3.4.8 He also posted signoff statistics for January 2012. Release Manager?s Newsletter Paul Poulain, Koha 3.8 Release Manager, is publishing a monthly newsletter dedicated to Koha 3.8 development. It can be found on the Koha Community website in the Koha News category. The first two issues were distributed via the koha-devel mailing list. The third issue is here. Koha Community New Koha Libraries Huntington Public Library (via ByWater Solutions) Kimball Public Library (via ByWater Solutions) Montgomery House Warrior Run Area Public Library (self-hosted) Plaistow Public Library (via ByWater Solutions) Sandown Public Library (via ByWater Solutions) Community Gossip Equinox Software is seeking a Library Data Specialist to work with library data and configure Koha and Evergreen systems. Kyle Hall has joined ByWater Solutions as Development Support Specialist. Nicole Engard has created a number of useful video tutorials on using Koha. Check out the map of Koha sites. Past Koha Events February General IRC Meeting The February general IRC meeting was held on 8 February 2012. For more info, including the agenda and links to the minutes, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_8_February_2012. Global Bug Squashing Day 2012-02-08 by Magnus Enger A Global bug squashing day was held on Wednesday, 8 February 2012, and there was much rejoicing. For the numbers, see http://wiki.koha-community.org/wiki/2012-02-08_Global_bug_squashing_day. Upcoming Koha Events Marseille Hackfest by Paul Poulain 25 Koha developers will be gathering to work on improving Koha from 19-25 March in Marseille, France. There will be people from Croatia (2), Switzerland (1), Italy (1), Germany (1), USA (1), and France (19). Six of us are librarians; the rest are IT/developers. We plan to focus on these topics: a small group working on performance and persistence issues, trying to make Koha Plack/mod_perl compatible a small group working on database issues, trying to remove MySQL dependencies and incorporate business/database separation logic into Koha a small group working on user interface issues, trying to improve HTML, CSS, etc. a small group working on Solr integration (that will, hopefully, be submitted for October 2012 release) the rest of us working on what we could call a Global Bug Squashing Week?testing patches, etc. We still have space, so if you?d like to come, just email me. March General IRC Meeting The March general IRC meeting will be held on Wednesday, 21 March 2012. For more info, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_21_March_2012. KohaCon12 KohaCon12 will be held in Edinburgh, Scotland, UK, 5-7 June 2012. A hackfest will be held 9-11 June. This is a free conference for everyone interested in the Koha library system, which is Free and Open Source Software. There is no registration fee, but we will ask that attendees pre-register. Further calls, including calls for papers and registrations will be posted soon. Details (travel, hotels, agenda draft, etc) can be found linked from http://wiki.koha-community.org/wiki/KohaCon12_Summary. KohaCon12 is the fifth KohaCon, following last year?s successful conference in India which brought together users and developers worldwide. KohaCon12 will feature an international slate of speakers (both Koha users and active Koha contributors) conducting presentations and workshops on a diverse range of topics. Talks will cover a range of topics from general experiences of Koha through to technical information on the various modules. ?We expect this event to have wide appeal,? said MJ Ray of host organisation and Koha support provider software.coop. ?The conference is for both techies and non-techies. In addition to presentations on the technical side of Koha, the conference will be a demonstration of how users and developers around the world cooperate to improve Free and Open Source Software. software.coop is delighted to host KohaCon in Edinburgh in our tenth anniversary year and this UN International Year of Co-operatives.? ?Koha conferences are always an informative and uplifting event, I have no doubt that this years conference in Edinburgh will be the best conference yet.? said Chris Cormack, one of the original authors of the Koha version 1.0.