From paul.poulain at biblibre.com Tue Nov 1 06:14:59 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 01 Nov 2011 06:14:59 +0100 Subject: [Koha-devel] Pushed for QA saved search on bugzilla Message-ID: <4EAF8053.9060909@biblibre.com> Hello, I just added a "pushed for QA" saved search on bugzilla. If you want to add it to your footer, just go to preferences > saved searches and click "show in footer" There are only 2 entries here, but they must not be forgotten ! HTH -- 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 Wed Nov 2 15:58:23 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 2 Nov 2011 14:58:23 +0000 Subject: [Koha-devel] FW: Patch status workflow (for Bugzilla) In-Reply-To: <4EA6D79A.7040206@biblibre.com> References: , <4EA6D79A.7040206@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31361708@S-MAIL-1B.rijksmuseum.intra> Have been reading a lot of mails about patch status workflow little bit late. But did we reach consensus on some of these points yet? Status, patch status, version, importance? I would be in favor of using the global watcher and freeing up QA Contact. I would hesitate to change too many fields now, as the procedure in 3.6 was clear. Changing several fields could result in a lot of erroneous statuses, set by unaware reporters. For instance, even making the distinction between master and rel_3_8 will not be intuitive for everyone (enh to master, bugs to rel_3_8). A last question, as Paul mentioned trivial patches too somewhere: Could we allow someone to signoff on his own patch for really trivial patches (touching comments; fixing typos; small obvious bugs pertaining to a few lines; etc.) ? QA could make the decision then to let it pass QA or reset the status to Needs Signoff, asking for an additional signoff? Would we risk getting too much not-trivial self-signoffs ? Marcel ________________________________________ 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 25 oktober 2011 17:36 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Patch status workflow (for Bugzilla) Le 25/10/2011 17:17, Ian Walls a ?crit : > Community, > > > As I'd mentioned in a previous thread, I think we should consider > removing the custom attribute "patch status" from Bugzilla, and keeping > track of this information in the regular Status attribute. This has > several advantages: > > * Easier searching, since it's a default value, not a custom value > * We can enable Workflows between Statuses > * We no longer have the dependency on Priority to control the display > of this critical value > > The Workflows allow us to specify how tickets are allowed to change > status, from which to which. Here's an example workflow: > > * NEW (default for all incoming tickets) > * ASSIGNED (to the developer working on it) > * NEEDS_SIGNOFF (once a patch has been submitted) > * SIGNED_OFF (after signoff) > * PASSED_QA (once QA'ed successfully) > * PATCH_PUSHED > * RESOLVED other potential problem : when moving all existing bugs/patches to those new status, we will set the "last modification date" to "today" right ? can't it be the source of some glitch/pain/problem/surprise/misunderstanding ? (just asking) -- 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 ian.walls at bywatersolutions.com Wed Nov 2 16:14:56 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 2 Nov 2011 11:14:56 -0400 Subject: [Koha-devel] FW: Patch status workflow (for Bugzilla) In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31361708@S-MAIL-1B.rijksmuseum.intra> References: <4EA6D79A.7040206@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA31361708@S-MAIL-1B.rijksmuseum.intra> Message-ID: Marcel, I think we can agree that using QA Contact is a good idea. I'd be very much surprised if anyone objects to that (feel free to prove me wrong). As far as trivial bug signoffs, I think the QA team's act of accepting an author-signoff would be equivalent to signing off themselves (we are signing off on the signoff). The only difference would be allowing people to mark trivial bugs as "signed off" directly, instead of after they were set to "needs signoff".... and the QA team busting a report back down to "needs signoff" if they don't feel it's trivial. I'm amenable to allowing this, at least for 3.8, to see if it works. If we find people are abusing it to get non-trivial bugs looked at by QA sooner than they should, then we can revoke the issue. What do others think of this provision? I'll ask those in Mumbai directly on Friday at the hackfest, but any opinions before then will help frame the discussion. -Ian On Wed, Nov 2, 2011 at 10:58 AM, Marcel de Rooy wrote: > Have been reading a lot of mails about patch status workflow little bit > late. But did we reach consensus on some of these points yet? Status, patch > status, version, importance? > > I would be in favor of using the global watcher and freeing up QA Contact. > I would hesitate to change too many fields now, as the procedure in 3.6 > was clear. Changing several fields could result in a lot of erroneous > statuses, set by unaware reporters. > For instance, even making the distinction between master and rel_3_8 will > not be intuitive for everyone (enh to master, bugs to rel_3_8). > > A last question, as Paul mentioned trivial patches too somewhere: Could we > allow someone to signoff on his own patch for really trivial patches > (touching comments; fixing typos; small obvious bugs pertaining to a few > lines; etc.) ? QA could make the decision then to let it pass QA or reset > the status to Needs Signoff, asking for an additional signoff? Would we > risk getting too much not-trivial self-signoffs ? > > Marcel > ________________________________________ > 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 25 oktober 2011 17:36 > Aan: koha-devel at lists.koha-community.org > Onderwerp: Re: [Koha-devel] Patch status workflow (for Bugzilla) > > Le 25/10/2011 17:17, Ian Walls a ?crit : > > Community, > > > > > > As I'd mentioned in a previous thread, I think we should consider > > removing the custom attribute "patch status" from Bugzilla, and keeping > > track of this information in the regular Status attribute. This has > > several advantages: > > > > * Easier searching, since it's a default value, not a custom value > > * We can enable Workflows between Statuses > > * We no longer have the dependency on Priority to control the display > > of this critical value > > > > The Workflows allow us to specify how tickets are allowed to change > > status, from which to which. Here's an example workflow: > > > > * NEW (default for all incoming tickets) > > * ASSIGNED (to the developer working on it) > > * NEEDS_SIGNOFF (once a patch has been submitted) > > * SIGNED_OFF (after signoff) > > * PASSED_QA (once QA'ed successfully) > > * PATCH_PUSHED > > * RESOLVED > > other potential problem : when moving all existing bugs/patches to those > new status, > we will set the "last modification date" to "today" right ? > can't it be the source of some > glitch/pain/problem/surprise/misunderstanding ? > (just asking) > > > -- > 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/ > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Fri Nov 4 10:21:33 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 04 Nov 2011 10:21:33 +0100 Subject: [Koha-devel] sending patches to koha-patches mailing list ? In-Reply-To: <20111018161816.4E3EB9F0E8@nail.towers.org.uk> References: <20111018161816.4E3EB9F0E8@nail.towers.org.uk> Message-ID: <4EB3AE9D.1020409@biblibre.com> Le 18/10/2011 18:18, MJ Ray a ?crit : > process = git.am(filename, kwargs=**{'_interactive': True, '3': True}) Just tried this on bug 6963, that does not apply without the -3 argument, and got a nasty : 10:20 ~/koha.dev/koha-community (new/bug_6963 $%)$ git bz apply 6963 File "/home/paul/bin/git-bz", line 1497 process = git.am(filename, kwargs=**{'_interactive': True, '3': True}) ^ SyntaxError: invalid syntax (It's probably easy to fix, but not for me... ) -- 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 Nov 4 10:46:35 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 04 Nov 2011 10:46:35 +0100 Subject: [Koha-devel] Release Manager stuff Message-ID: <4EB3B47B.80204@biblibre.com> Hello Koha, I've just pushed my first patches, thanks to chris & brendan for their help. The first three ones were not pushed in a specific branch, I made a mistake, that is now fixed, so it should be OK. I've started a wiki page to explain how the RM pushes patches. That will be usefull for anyone interested, and usefull for the next RM (i'm not thinking of resigning, don't worry ;-) ) -- 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 Nov 4 11:01:09 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 04 Nov 2011 11:01:09 +0100 Subject: [Koha-devel] sending patches to koha-patches mailing list ? In-Reply-To: <4EB3AE9D.1020409@biblibre.com> References: <20111018161816.4E3EB9F0E8@nail.towers.org.uk> <4EB3AE9D.1020409@biblibre.com> Message-ID: <4EB3B7E5.1040809@biblibre.com> Le 04/11/2011 10:21, Paul Poulain a ?crit : > process = git.am(filename, kwargs=**{'_interactive': True, '3': True}) Thanks robin, the correct syntax is without kwargs= Here is the patch I made (yes, git-bz uses git ;-) ) Slef, feel free to attach to your repo -- 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 Nov 4 10:59:47 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 4 Nov 2011 10:59:47 +0100 Subject: [PATCH] Add -3 parameter to git am Message-ID: With this patch, the git am now automatically has a -3 parameter That makes no difference for patches that applies directly, but is useful when it's not the case --- git-bz | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/git-bz b/git-bz index 0d1fc91..9ebdf0a 100755 --- a/git-bz +++ b/git-bz @@ -1494,7 +1494,8 @@ def do_apply(bug_reference): f.close() try: - process = git.am(filename, _interactive=True) + #process = git.am(filename, _interactive=True) + process = git.am(filename, **{'_interactive': True, '3': True}) except CalledProcessError: print "Patch left in %s" % filename break -- 1.7.5.4 --------------020700020409070904060802-- From paul.poulain at biblibre.com Fri Nov 4 11:14:42 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 04 Nov 2011 11:14:42 +0100 Subject: [Koha-devel] Release Manager stuff Message-ID: <4EB3BB12.2080607@biblibre.com> Hello Koha, I've just pushed my first patches, thanks to chris & brendan for their help. The first three ones were not pushed in a specific branch, I made a mistake, that is now fixed, so it should be OK. I've started a wiki page to explain how the RM pushes patches. That will be usefull for anyone interested, and usefull for the next RM (i'm not thinking of resigning, don't worry ;-) ) Here is the page: http://wiki.koha-community.org/wiki/How_the_RM_push -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ian.walls at bywatersolutions.com Fri Nov 4 18:49:21 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Fri, 4 Nov 2011 13:49:21 -0400 Subject: [Koha-devel] QA Contact field in Bugzilla Message-ID: Friends, I've gone ahead and moved the "koha-bugs at lists.koha-community.org" account from the default QA contact for each component in bugs.koha-community.org, to a Global Watcher. This gives us a simpler configuration, fewer risks of breakage (since someone could change the QA contact on a bug report), and the use of QA Contact for actual QA. I've set myself as the new default contact for all components; I'll work out with Jonathan and Marcel a good system for assigning them incoming tickets to QA. We may need to update this next release cycle, but it only takes a few minutes to do. I have *not* changed all the existing bugs to use this new system; that would spam the heck out of everyone. I'll just start making use of this feature as I test things, and eventually, all the unresolved bugs should get updated. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Sat Nov 5 07:55:06 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sat, 05 Nov 2011 07:55:06 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] Message-ID: <4EB4DDCA.5060305@biblibre.com> Hello, During the hackfest in Mumba?, 5 of us had a brainstorming about database changes to try to improve it. Here are the goals: * must result in patches being easier to test by testers (to sign-off) * must result in less conflict when trying to apply a patch with a DB update when another patch has been applied (the .XXXX problem) * must fix the linear problem (where patches are applied in a completly linear way) * be easy to implement We throwed many ideas, here is the one that seems both easy and usefull : * patches would be submitted in a specific file, in atomicupdate directory * a new file (YAML) would be added, that would have 2 columns, one for the version number, one for the atomicupdate file name * updatedatabase wouldn't change anymore: we would just add something like : LoadYAMLFile() ForEachLine { if (C4::Context->preference("Version") < FirstColumnYAML) { exec(secondColumnYAML); SetVersion (FirstColumnYAML); } } The YAML file would be updated only by the Release Manager, when he pushes a patch. This idea fully achieve most of our initial goals: * (very) easy to implement * it will be easier to test a patch : is there an atomic update in the patch ? OK, to test it, i'll first execute the file * there won't be any conflict anymore of a patch applied and your .XXXX file not applying anymore, needing a rebase * it fixes partially the linear problem = if you have a local branch, you can see what has been applied just looking in the yaml file. Let's say Limoges library has sponsored stuff that has resulted in atomicupdate/limogeupdate.pl Those changes are live in Limoges, but still not in official/community version. The Limoges YAML file will be: 3.07.0001 Community_change1.pl 3.07.0002 community_change2.pl localchange limogesupdate.pl 3.07.0003 community_change3.pl the "localchange" in first column will mean for the updater : "OK, apply the change but don't change the version number" When the localchange has been applied on master community branch, the official/community YAML file will look like: 3.07.0001 Community_change1.pl 3.07.0002 community_change2.pl 3.07.0003 community_change3.pl 3.07.0004 limogesupdate.pl Switching back limoges to a community version would require some manual checking, but that will be *much* easier than what we have today : * diff limoges.yaml official.yaml * apply community changes if/where needed * UPDATE systempreferences SET kohaversion=3.07.0004 manually It's done ! And if the localchange that has been made is never merged into master, whatever the reason, it will be easier to keep track of it too. And if you want to apply a submitted patch to your local setup before it's pushed onto master, you can, just by running the file in atomicupdate directory. And add a "localchange" line to your YAML file to remember the change you've made. Does anyone see a problem with this new updatedatabase procedure ? Until now, I have pushed no changes in database, so if we agree, i'll implement this change quickly (before pushing any change having a database consequence) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ian.walls at bywatersolutions.com Sat Nov 5 08:11:01 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Sat, 5 Nov 2011 03:11:01 -0400 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EB4DDCA.5060305@biblibre.com> References: <4EB4DDCA.5060305@biblibre.com> Message-ID: For my part, I'm very excited about this change. I think we're going to have a much easier time of submitting database changes this way. There will be a learning curve for folks used to doing it the old way, but like the change to using a common systempreferences.sql instead of one for each language. It'll make life easier, so I would assume adoption would occur readily. In the event it doesn't, the QA team could agree to reform old-style submissions into the new style, at least for the rest of the 3.8 release cycle. Any issues anyone can see with this approach, please bring them up. We're only a few at the hackfest, and need more opinions before we proceed. But I think this is going to work well, and solve several problems, while still preserving the quick version checking we've already got. Cheers, -Ian On Sat, Nov 5, 2011 at 2:55 AM, Paul Poulain wrote: > Hello, > > During the hackfest in Mumba?, 5 of us had a brainstorming about > database changes to try to improve it. > Here are the goals: > * must result in patches being easier to test by testers (to sign-off) > * must result in less conflict when trying to apply a patch with a DB > update when another patch has been applied (the .XXXX problem) > * must fix the linear problem (where patches are applied in a completly > linear way) > * be easy to implement > > > We throwed many ideas, here is the one that seems both easy and usefull : > * patches would be submitted in a specific file, in atomicupdate directory > * a new file (YAML) would be added, that would have 2 columns, one for > the version number, one for the atomicupdate file name > * updatedatabase wouldn't change anymore: we would just add something like > : > LoadYAMLFile() > ForEachLine { > if (C4::Context->preference("Version") < FirstColumnYAML) { > exec(secondColumnYAML); > SetVersion (FirstColumnYAML); > } > } > The YAML file would be updated only by the Release Manager, when he > pushes a patch. > > This idea fully achieve most of our initial goals: > * (very) easy to implement > * it will be easier to test a patch : is there an atomic update in the > patch ? OK, to test it, i'll first execute the file > * there won't be any conflict anymore of a patch applied and your .XXXX > file not applying anymore, needing a rebase > * it fixes partially the linear problem = if you have a local branch, > you can see what has been applied just looking in the yaml file. > Let's say Limoges library has sponsored stuff that has resulted in > atomicupdate/limogeupdate.pl > Those changes are live in Limoges, but still not in official/community > version. > The Limoges YAML file will be: > 3.07.0001 Community_change1.pl > 3.07.0002 community_change2.pl > localchange limogesupdate.pl > 3.07.0003 community_change3.pl > the "localchange" in first column will mean for the updater : "OK, apply > the change but don't change the version number" > > When the localchange has been applied on master community branch, the > official/community YAML file will look like: > 3.07.0001 Community_change1.pl > 3.07.0002 community_change2.pl > 3.07.0003 community_change3.pl > 3.07.0004 limogesupdate.pl > > Switching back limoges to a community version would require some manual > checking, but that will be *much* easier than what we have today : > * diff limoges.yaml official.yaml > * apply community changes if/where needed > * UPDATE systempreferences SET kohaversion=3.07.0004 manually > It's done ! > > And if the localchange that has been made is never merged into master, > whatever the reason, it will be easier to keep track of it too. > > And if you want to apply a submitted patch to your local setup before > it's pushed onto master, you can, just by running the file in > atomicupdate directory. And add a "localchange" line to your YAML file > to remember the change you've made. > > Does anyone see a problem with this new updatedatabase procedure ? > Until now, I have pushed no changes in database, so if we agree, i'll > implement this change quickly (before pushing any change having a > database consequence) > > -- > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.maurice at biblibre.com Sat Nov 5 08:32:17 2011 From: julian.maurice at biblibre.com (Julian Maurice) Date: Sat, 05 Nov 2011 13:02:17 +0530 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EB4DDCA.5060305@biblibre.com> References: <4EB4DDCA.5060305@biblibre.com> Message-ID: <4EB4E681.7000402@biblibre.com> It seems to be a great evolution, but there is something which I think I don't understand: > * there won't be any conflict anymore of a patch applied and your .XXXX > file not applying anymore, needing a rebase Ok there will be no more conflicts in the updatedatabase.pl file, but what about the YAML file? It still the same problem. If you have versions 001 and 002, and you add a localversion after them, and then a new version 003 is pushed into master. If you try to apply the patch, there will be a conflit, isn't it? -- Julian Maurice BibLibre From paul.poulain at biblibre.com Sat Nov 5 09:35:29 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sat, 05 Nov 2011 09:35:29 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EB4E681.7000402@biblibre.com> References: <4EB4DDCA.5060305@biblibre.com> <4EB4E681.7000402@biblibre.com> Message-ID: <4EB4F551.2080802@biblibre.com> Le 05/11/2011 08:32, Julian Maurice a ?crit : > It seems to be a great evolution, but there is something which I think I > don't understand: >> * there won't be any conflict anymore of a patch applied and your .XXXX >> file not applying anymore, needing a rebase > Ok there will be no more conflicts in the updatedatabase.pl file, but > what about the YAML file? It still the same problem. If you have > versions 001 and 002, and you add a localversion after them, and then a > new version 003 is pushed into master. If you try to apply the patch, > there will be a conflit, isn't it? > The idea is that only the RM will take care of the YAML file. If you want to submit a DB change, just create a file in atomicupdate directory. If you want to test a patch, just check if there is something about atomicupdate in the patch, and if yes, run "atomicupdate/blabla.pl" before testing => no possible conflict here (except if 2 ppl use the same name for the file, that's pretty impossible) If you have a patch that must be applied to your customer before it is pushed in Koha : - apply atomicupdate/blabla.pl - add "localchange blabla.pl" at the end of your YAML file = it will keep track of when you've added the change, once the patch is in Koha, check the diff just of the YAML file, to know what has been applied and what should be applied. Much much easier than what we have today ! In case there is a conflict because of a local change, the conflict will be only on the YAML file, and will be very easy to deal with, as each entry is just one line. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ian.walls at bywatersolutions.com Sat Nov 5 10:32:04 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Sat, 5 Nov 2011 05:32:04 -0400 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EB4F551.2080802@biblibre.com> References: <4EB4DDCA.5060305@biblibre.com> <4EB4E681.7000402@biblibre.com> <4EB4F551.2080802@biblibre.com> Message-ID: Another way to say it: No patches will be accepted with edits to the YAML file. also If you edit your local copy of the YAML file, do not assign a number; use localchange instead. Otherwise you will encounter problems. -Ian On Sat, Nov 5, 2011 at 4:35 AM, Paul Poulain wrote: > Le 05/11/2011 08:32, Julian Maurice a ?crit : > > It seems to be a great evolution, but there is something which I think I > > don't understand: > >> * there won't be any conflict anymore of a patch applied and your .XXXX > >> file not applying anymore, needing a rebase > > Ok there will be no more conflicts in the updatedatabase.pl file, but > > what about the YAML file? It still the same problem. If you have > > versions 001 and 002, and you add a localversion after them, and then a > > new version 003 is pushed into master. If you try to apply the patch, > > there will be a conflit, isn't it? > > > The idea is that only the RM will take care of the YAML file. > > If you want to submit a DB change, just create a file in atomicupdate > directory. > If you want to test a patch, just check if there is something about > atomicupdate in the patch, and if yes, run "atomicupdate/blabla.pl" > before testing => no possible conflict here (except if 2 ppl use the > same name for the file, that's pretty impossible) > If you have a patch that must be applied to your customer before it is > pushed in Koha : > - apply atomicupdate/blabla.pl > - add "localchange blabla.pl" at the end of your YAML file = it will > keep track of when you've added the change, once the patch is in Koha, > check the diff just of the YAML file, to know what has been applied and > what should be applied. Much much easier than what we have today ! > > In case there is a conflict because of a local change, the conflict will > be only on the YAML file, and will be very easy to deal with, as each > entry is just one line. > > -- > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.maurice at biblibre.com Sat Nov 5 10:47:41 2011 From: julian.maurice at biblibre.com (Julian Maurice) Date: Sat, 05 Nov 2011 15:17:41 +0530 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <4EB4DDCA.5060305@biblibre.com> <4EB4E681.7000402@biblibre.com> <4EB4F551.2080802@biblibre.com> Message-ID: <4EB5063D.4010908@biblibre.com> Le 05/11/2011 15:02, Ian Walls a ?crit : > Another way to say it: > > No patches will be accepted with edits to the YAML file. > > also > > If you edit your local copy of the YAML file, do not assign a number; > use localchange instead. Otherwise you will encounter problems. > > > -Ian > > On Sat, Nov 5, 2011 at 4:35 AM, Paul Poulain > > wrote: > > Le 05/11/2011 08:32, Julian Maurice a ?crit : > > It seems to be a great evolution, but there is something which I > think I > > don't understand: > >> * there won't be any conflict anymore of a patch applied and > your .XXXX > >> file not applying anymore, needing a rebase > > Ok there will be no more conflicts in the updatedatabase.pl > file, but > > what about the YAML file? It still the same problem. If you have > > versions 001 and 002, and you add a localversion after them, and > then a > > new version 003 is pushed into master. If you try to apply the > patch, > > there will be a conflit, isn't it? > > > The idea is that only the RM will take care of the YAML file. > > If you want to submit a DB change, just create a file in atomicupdate > directory. > If you want to test a patch, just check if there is something about > atomicupdate in the patch, and if yes, run "atomicupdate/blabla.pl > " > before testing => no possible conflict here (except if 2 ppl use the > same name for the file, that's pretty impossible) > If you have a patch that must be applied to your customer before it is > pushed in Koha : > - apply atomicupdate/blabla.pl > - add "localchange blabla.pl " at the end of > your YAML file = it will > keep track of when you've added the change, once the patch is in Koha, > check the diff just of the YAML file, to know what has been > applied and > what should be applied. Much much easier than what we have today ! > > In case there is a conflict because of a local change, the > conflict will > be only on the YAML file, and will be very easy to deal with, as each > entry is just one line. > Ok I got it, thank you. ;-) -- Julian Maurice BibLibre -------------- next part -------------- An HTML attachment was scrubbed... URL: From ef at math.uni-bonn.de Sat Nov 5 11:01:22 2011 From: ef at math.uni-bonn.de (=?iso-8859-1?Q?Edgar_Fu=DF?=) Date: Sat, 5 Nov 2011 11:01:22 +0100 Subject: [Koha-devel] Update database changes proposal In-Reply-To: <4EB4DDCA.5060305@biblibre.com> References: <4EB4DDCA.5060305@biblibre.com> Message-ID: > During the hackfest in Mumba?, 5 of us had a brainstorming about > database changes to try to improve it. Would it be feasible for the database not to track a linear version number of the update status, but a list of tickets, one for every DB update? Given these tickets are unique (centrally managed or random, i.e., a hash of the DB statements) you would have no troubles whatsoever applying patches in any order. You would even (with a corresponding un-apply DB statements file) be able to roll back individual patches. Of course, this means the update has to walk through the ticket numbers instead of checking a single version number. In case that's too expensive for the general case of a non-patched system, the update script could be taught a list of tickets of the updates that each released version contains. But I guess looking up a ticket number in a list maintained by the DB is exactly what a DB is good at. From ian.walls at bywatersolutions.com Sat Nov 5 11:56:45 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Sat, 5 Nov 2011 06:56:45 -0400 Subject: [Koha-devel] Update database changes proposal In-Reply-To: References: <4EB4DDCA.5060305@biblibre.com> Message-ID: Since right now we check that the DB is up to date with every page load, we'd need something fast. A numeric comparison is simple enough; checking through a whole directory of updates, or scanning a hashref or some other mechanism, would likely take much more processing power. Also, we've got to factor in update's depending on one another. We've got to have some kind of chain of dependence; doing it as a linear value is the easiest. The other option would be for each update to specify it's dependencies explicitly; that would give us a directed acyclic graph, like Git uses, but would be MUCH more complex to implement and maintain. -Ian On Sat, Nov 5, 2011 at 6:01 AM, Edgar Fu? wrote: > > During the hackfest in Mumba?, 5 of us had a brainstorming about > > database changes to try to improve it. > Would it be feasible for the database not to track a linear version number > of the update status, but a list of tickets, one for every DB update? > Given these tickets are unique (centrally managed or random, i.e., a hash > of the DB statements) you would have no troubles whatsoever applying > patches in any order. You would even (with a corresponding un-apply DB > statements file) be able to roll back individual patches. > Of course, this means the update has to walk through the ticket numbers > instead of checking a single version number. In case that's too expensive > for the general case of a non-patched system, the update script could be > taught a list of tickets of the updates that each released version > contains. But I guess looking up a ticket number in a list maintained by > the DB is exactly what a DB is good at. > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Sun Nov 6 04:53:39 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 06 Nov 2011 04:53:39 +0100 Subject: [Koha-devel] Very small change in bugzilla (priority) Message-ID: <4EB604C3.6000901@biblibre.com> Hello, I'm sure all of you have once asked yourself "well, is Priority 1 high, or low ?" Now you've the answer : i've updated the label facing P1 and P5, that's now P1-high and P5-low (the default value) no other changes (even if I'd like to get rid of this PATCH-Sent status that should not be here. That will be for a later change proposal ;-) ) -- 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 Sun Nov 6 06:52:15 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 06 Nov 2011 06:52:15 +0100 Subject: [Koha-devel] Date picker (bz 7182) Message-ID: <4EB6208F.6070503@biblibre.com> Hello world, As we've said previously, the Koha datepicker is out of date, unmaintained, and we should go for a jquery one. It doesn't matter which one we choose for me, but let's choose one. Anyone an opinion ? owen, you'll probably a more important voice than anyone else here. Everybody: please answer on this thread or on bug 7182, thanks. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From julian.maurice at biblibre.com Sun Nov 6 07:56:26 2011 From: julian.maurice at biblibre.com (Julian Maurice) Date: Sun, 06 Nov 2011 12:26:26 +0530 Subject: [Koha-devel] Date picker (bz 7182) In-Reply-To: <4EB6208F.6070503@biblibre.com> References: <4EB6208F.6070503@biblibre.com> Message-ID: <4EB62F9A.7000307@biblibre.com> Le 06/11/2011 11:22, Paul Poulain a ?crit : > Hello world, > > As we've said previously, the Koha datepicker is out of date, > unmaintained, and we should go for a jquery one. > It doesn't matter which one we choose for me, but let's choose one. > Anyone an opinion ? > > owen, you'll probably a more important voice than anyone else here. > > Everybody: please answer on this thread or on bug 7182, thanks. I suggest that we take the datepicker widget which comes with jQuery UI project. It comes with a lot of features, and it seems that it's well maintened. Moreover, the jQuery UI provides some other useful widgets, like autocomplete (to replace the YUI one), and all of the jQuery UI library is compatible with our version of jQuery (1.3.2). -- Julian Maurice BibLibre From paul.poulain at biblibre.com Sun Nov 6 10:55:03 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 06 Nov 2011 10:55:03 +0100 Subject: [Koha-devel] bugzilla patch status order changes Message-ID: <4EB65977.20907@biblibre.com> Hello, As I proposed a few days ago, i've updated the order of patches statuses. You'll now see Needs Signoff Signed Off Pushed for QA Passed QA Patch Pushed Does not apply Failed QA (usually, the new status is/will just be the status next to the current one. The two "failure" cases are at the end) HTH -- 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 Sun Nov 6 11:50:42 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 06 Nov 2011 11:50:42 +0100 Subject: [Koha-devel] Date picker (bz 7182) In-Reply-To: <4EB62F9A.7000307@biblibre.com> References: <4EB6208F.6070503@biblibre.com> <4EB62F9A.7000307@biblibre.com> Message-ID: <4EB66682.6070302@biblibre.com> Le 06/11/2011 07:56, Julian Maurice a ?crit : > Le 06/11/2011 11:22, Paul Poulain a ?crit : >> Hello world, >> >> As we've said previously, the Koha datepicker is out of date, >> unmaintained, and we should go for a jquery one. >> It doesn't matter which one we choose for me, but let's choose one. >> Anyone an opinion ? >> >> owen, you'll probably a more important voice than anyone else here. thanks Cait for pointing Owen already has open bug 5778 for this. both are now linked, and we've the answer to my question. If someone submit a patch: I think we shouldn't require that all the dates pickers are changed. We can handle old and new datepickers for some time. Requesting to have a "big bang" change here will result in nothing being submitted as it's a big task. And probably a lot of conflicts would appear. -- 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 Sun Nov 6 15:58:38 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 06 Nov 2011 15:58:38 +0100 Subject: [Koha-devel] Setting DEBUG=1 on your testing setups Message-ID: <4EB6A09E.4040707@biblibre.com> Hello, I just pushed a few minuts ago a patch that will have Koha raise an error message when there is a mySQL error. All developers should activate this in their staff & OPAC virtual hosts. Thus if there are errors, they'll be displayed & visible. Please have a look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7184 to get details ! -- 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 Mon Nov 7 15:03:01 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Mon, 7 Nov 2011 09:03:01 -0500 Subject: [Koha-devel] Replacing YUI javascript libraries with jQueryUI Message-ID: I see from the weekend traffic on Bugzilla that not everyone is aware of the work I've been doing on Bug 5481: Replace YUI JS libraries with Jquery UI http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5481 Over the last year I've been working to replace all instances of YUI js dependencies with jQueryUI-native functions. My hope was that native jQueryUI could handle all the functions that YUI did. Among the features which are integrated: Date picker Autocomplete Tabs So far so good, but one piece is lacking: while jQueryUI has a button widget in their current release, there is still no native menu or menu/button widget. YUI Menu is used in the OPAC in a couple of places and on any page in the staff client which has a toolbar of buttons. The jQueryUI menu widget has been in alpha for about as long as I've been working on this branch, so this project has been stalled for a while. I've been keeping the branch up to date and pushed to my repo on Gitorious. Sorry to anyone following the link from Bug 5481, the name of the branch changed: http://gitorious.org/koha-dev/koha-dev/commits/ip-bug-5481-tt-jquery-ui-2011-04-12 I check this branch regularly and fix conflicts with master. As of today it rebases cleanly for me, so it should be testable if anyone would like to see it in action. Be sure to clear your browser cache or shift-refresh to make sure the up-to-date js and CSS are loaded. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From mjr at phonecoop.coop Mon Nov 7 23:12:27 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 7 Nov 2011 22:12:27 +0000 (GMT) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EB4DDCA.5060305@biblibre.com> Message-ID: <20111107221227.802899F0E8@nail.towers.org.uk> Paul Poulain > Let's say Limoges library has sponsored stuff that has resulted in > atomicupdate/limogeupdate.pl [...] > Does anyone see a problem with this new updatedatabase procedure ? The only problem that I can see is that we should encourage updates to be .sql not .pl files. Other than that, it's a great leap forwards and removes one of the main blockers in contributing database-related changes back to koha-community! Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From lculber at mdah.state.ms.us Tue Nov 8 20:00:54 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Tue, 08 Nov 2011 13:00:54 -0600 Subject: [Koha-devel] possibility for Koha links Message-ID: <4EB97C66.5010505@mdah.state.ms.us> All, In the discussion of links in Koha, there has been discussion of there being links to in-house images, but I was wondering whether anyone had considered the possibility of those being actual hyperlinks? For example, we have digitized maps that are viewed through zoomify For example, in my catalog record http://zed.mdah.state.ms.us/cgi-bin/koha/opac-detail.pl?biblionumber=85886 it would be really wonderful to have a thumbnail of that map that links to http://mdah.state.ms.us/arrec/digital_archives/maps/map.php?map=85886-1-map.tif For the digitized video, something similar could be done. For pdf files and other such documents, we'd probably come up with a generic something. Thanks! -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824 From mdhafen at tech.washk12.org Tue Nov 8 20:47:16 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Tue, 8 Nov 2011 12:47:16 -0700 Subject: [Koha-devel] possibility for Koha links In-Reply-To: <4EB97C66.5010505@mdah.state.ms.us> References: <4EB97C66.5010505@mdah.state.ms.us> Message-ID: Some of my libraries are doing something similar to this with the items url tag (952$u) for online e-books. It shows the url in the staff and OPAC interfaces. Is that what you are talking about? On Tue, Nov 8, 2011 at 12:00 PM, Linda Culberson wrote: > All, > In the discussion of links in Koha, there has been discussion of there > being links to in-house images, but I was wondering whether anyone had > considered the possibility of those being actual hyperlinks? For example, > we have digitized maps that are viewed through zoomify > For example, in my catalog record > http://zed.mdah.state.ms.us/**cgi-bin/koha/opac-detail.pl?** > biblionumber=85886 > it would be really wonderful to have a thumbnail of that map that links to > http://mdah.state.ms.us/arrec/**digital_archives/maps/map.php?** > map=85886-1-map.tif > For the digitized video, something similar could be done. For pdf files > and other such documents, we'd probably come up with a generic something. > Thanks! > -- > Linda Culberson lculber at mdah.state.ms.us > Archives and Records Services Division > Ms. Dept. of Archives & History > P. O. Box 571 > Jackson, MS 39205-0571 > Telephone: 601/576-6873 Fax: 601/576-6824 > > ______________________________**_________________ > 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 lculber at mdah.state.ms.us Tue Nov 8 22:02:45 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Tue, 08 Nov 2011 15:02:45 -0600 Subject: [Koha-devel] possibility for Koha links In-Reply-To: References: <4EB97C66.5010505@mdah.state.ms.us> Message-ID: <4EB998F5.8010801@mdah.state.ms.us> Mike; Perhaps that might work. We are wanting it to be a clickable image. Can you do that with the 952$u? In the best of all possible worlds, we would the option of putting it on the results page as well as in the details page, which is where I'm guessing the 952$u link is? Can it appear as an image either or both places? Thanks for your help, Linda On 11/8/2011 1:47 PM, Mike Hafen wrote: > Some of my libraries are doing something similar to this with the items > url tag (952$u) for online e-books. It shows the url in the staff and > OPAC interfaces. Is that what you are talking about? > > On Tue, Nov 8, 2011 at 12:00 PM, Linda Culberson > > wrote: > > All, > In the discussion of links in Koha, there has been discussion of > there being links to in-house images, but I was wondering whether > anyone had considered the possibility of those being actual > hyperlinks? For example, we have digitized maps that are viewed > through zoomify > For example, in my catalog record > http://zed.mdah.state.ms.us/ cgi-bin/koha/opac-detail.pl? > biblionumber=85886 > > it would be really wonderful to have a thumbnail of that map that > links to > http://mdah.state.ms.us/arrec/ digital_archives/maps/map.php? > map=85886-1-map.tif > > For the digitized video, something similar could be done. For pdf > files and other such documents, we'd probably come up with a generic > something. > Thanks! > -- > Linda Culberson lculber at mdah.state.ms.us > > Archives and Records Services Division > Ms. Dept. of Archives & History > P. O. Box 571 > Jackson, MS 39205-0571 > Telephone: 601/576-6873 Fax: 601/576-6824 > > > ______________________________ _________________ > 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/ > > > -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824 From savitra.sirohi at osslabs.biz Wed Nov 9 12:45:10 2011 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Wed, 9 Nov 2011 17:15:10 +0530 Subject: [Koha-devel] EDI code Message-ID: All, we need to implement EDI for one of our customers. Can anyone point to a git repo that has EDI code please? Thanks, Savitra From mtj at kohaaloha.com Wed Nov 9 18:54:16 2011 From: mtj at kohaaloha.com (Mason James) Date: Wed, 9 Nov 2011 23:24:16 +0530 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <20111107221227.802899F0E8@nail.towers.org.uk> References: <20111107221227.802899F0E8@nail.towers.org.uk> Message-ID: <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> On 2011-11-8, at 3:42 AM, MJ Ray wrote: > Paul Poulain >> Let's say Limoges library has sponsored stuff that has resulted in >> atomicupdate/limogeupdate.pl > [...] >> Does anyone see a problem with this new updatedatabase procedure ? > > The only problem that I can see is that we should encourage > updates to be .sql not .pl files. oooh, great idea! i think this would simplify the proposed process even more do other people agree? -------------- 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 cnighswonger at foundations.edu Wed Nov 9 20:27:19 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 9 Nov 2011 14:27:19 -0500 Subject: [Koha-devel] Koha 3.4.6 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.4.6. The package can be retrieved from: http://download.koha-community.org/koha-3.04.06.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.06.tar.gz.MD5 http://download.koha-community.org/koha-3.04.06.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.06.tar.gz.sig Release notes for 3.4.6 are below. Come and get it! RELEASE NOTES FOR KOHA 3.4.6 - 09 Nov 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.4.6 can be downloaded from: http://download.koha-community.org/koha-3.04.06.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.4.6 is a bugfix/maintenance release. Highlights of 3.4.6 ====================== 1139 blocker ISBN search fails with double dashes 5995 blocker Glitch with checkauth 2453 critical (very) large biblio/item handling 6575 critical funds with no restrictions not see by librarians 6576 critical changing framework while cataloging looses data 6687 critical cannot move people in the holds queue 6854 critical import_borrowers.pl : Double password encryption on member update if there is no password in the csv and no default password value. 6879 critical Actual price should show correctly on order line and basket summary 6959 critical Can't import record via Z39.50 from MARC edit page 2599 major Search limits not working for NoZebra 5796 major actual price not taken into account in encumbrance 5945 major can't search patron's email anymore 6014 major Log viewer needs permissions 6414 major actual price not recorded when ordering 6465 major Errors in UNIMARC plugins for fixed length fields (for | and space) (T::T issue) 6490 major Lost and paid not updated when book is checked out. 6660 major limiting search to a patron category shows all patrons in category 6801 major Patron details page slow to load when many checkouts present 6927 major Typo in Overdues.pm 6974 major MARC21 Leader plugin no longer auto-fills the 000 field 6977 major Support for repeated subfields when importing an authority into a biblio record field. 7134 major patron records getting funny birthdays Bugs fixed in 3.4.6 ====================== 3258 normal routing-preview.pl : button text + redirect issue 3704 normal SIP Checkin of not checked out item returns error without additional reason 5369 normal se queries with paranthesis fail 5630 normal CAS improvements 6070 normal On a new order defined from suggestion some fields were missing. 6217 normal Searching for 3 part patron names brings no results 6253 normal Unified Patron Search subroutine 6280 normal Invalid SQL being passed in circulation checkout 6390 normal Basket only visible for librarian who created it 6460 normal No log generated if Action set to All or Modify or Delete 6513 normal Library and Category filters when searching for a borrower to add to a routing list don't work correctly. 6885 normal Superlibrarian users can't delete items from another library when IndependantBranches 6966 normal Update Help Files for Koha 3.6 Release 6972 normal Hardcoded template paths to en in showmarc 6996 normal Encoding problem in opac-showmarc 6997 normal koha-remove leaves system in inconsistent state if there is an error 7202 normal z39.50 search on bib edit not working 959 enhancement We need to be abble to modifie order line after receipt 5528 enhancement Analytical records support 5572 enhancement refinements to function merge sub merge in C4::AuthoritiesMarc 5983 enhancement Change the wording around the CAS login 6012 enhancement Set up a working example of a CAS proxy 6296 enhancement Allow authentication to Koha via PKI / x.509 certificates 6670 enhancement Link patron name on returns screen to circulation page instead of patron detail page 6875 enhancement de-nesting C4 packages 6884 enhancement Improve TinyMCE configuration on Koha News page System requirements ====================== Changes since 3.2: * Template::Toolkit Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the english version of the Koha manual is available: http://koha-community.org/documentation/3-4-manual/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.4 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr?d?ric Demians Release Maintainer (3.2.x): Chris Nighswonger Release Maintainer (3.4.x): Chris Nighswonger QA Manager: Colin Campbell Credits ====================== We thank the following individuals who contributed patches to Koha 3.4.6 (The numeral in the first column represents the number of patches included in this release): 1 Alex Arnaud 1 Larry Baerveldt 1 Greg Barniskis 2 D Ruth Bavousett 1 Jared Camins-Esakov 2 Colin Campbell 2 Fr?d?rick Capovilla 1 Galen Charlton 17 Chris Cormack 8 Fr?d?ric Demians 2 Jonathan Druart 1 Nicole Engard 2 Magnus Enger 3 Katrin Fischer 2 Mason James 6 Srdjan Jankovic 1 Janusz Kaczmarek 12 Owen Leonard 1 Matthias Meusburger 1 Joy Nelson 4 Chris Nighswonger 2 Maxime Pelletier 11 Paul Poulain 1 Meenakshi R 1 MJ Ray 4 Liz Rea 10 Marcel de Rooy 7 Robin Sheat 1 Juan Sieira 18 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix releases) is 3.4.x. The next major feature release of Koha will be Koha 3.6.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 09 Nov 2011 at 16:50:37Z ##### RELEASE NOTES FOR KOHA 3.4.6 - 09 Nov 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.4.6 can be downloaded from: http://download.koha-community.org/koha-3.04.06.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.4.6 is a bugfix/maintenance release. Highlights of 3.4.6 ====================== 1139 blocker ISBN search fails with double dashes 5995 blocker Glitch with checkauth 2453 critical (very) large biblio/item handling 6575 critical funds with no restrictions not see by librarians 6576 critical changing framework while cataloging looses data 6687 critical cannot move people in the holds queue 6854 critical import_borrowers.pl : Double password encryption on member update if there is no password in the csv and no default password value. 6879 critical Actual price should show correctly on order line and basket summary 6959 critical Can't import record via Z39.50 from MARC edit page 2599 major Search limits not working for NoZebra 5796 major actual price not taken into account in encumbrance 5945 major can't search patron's email anymore 6014 major Log viewer needs permissions 6414 major actual price not recorded when ordering 6465 major Errors in UNIMARC plugins for fixed length fields (for | and space) (T::T issue) 6490 major Lost and paid not updated when book is checked out. 6660 major limiting search to a patron category shows all patrons in category 6801 major Patron details page slow to load when many checkouts present 6927 major Typo in Overdues.pm 6974 major MARC21 Leader plugin no longer auto-fills the 000 field 6977 major Support for repeated subfields when importing an authority into a biblio record field. 7134 major patron records getting funny birthdays Bugs fixed in 3.4.6 ====================== 3258 normal routing-preview.pl : button text + redirect issue 3704 normal SIP Checkin of not checked out item returns error without additional reason 5369 normal se queries with paranthesis fail 5630 normal CAS improvements 6070 normal On a new order defined from suggestion some fields were missing. 6217 normal Searching for 3 part patron names brings no results 6253 normal Unified Patron Search subroutine 6280 normal Invalid SQL being passed in circulation checkout 6390 normal Basket only visible for librarian who created it 6460 normal No log generated if Action set to All or Modify or Delete 6513 normal Library and Category filters when searching for a borrower to add to a routing list don't work correctly. 6885 normal Superlibrarian users can't delete items from another library when IndependantBranches 6966 normal Update Help Files for Koha 3.6 Release 6972 normal Hardcoded template paths to en in showmarc 6996 normal Encoding problem in opac-showmarc 6997 normal koha-remove leaves system in inconsistent state if there is an error 7202 normal z39.50 search on bib edit not working 959 enhancement We need to be abble to modifie order line after receipt 5528 enhancement Analytical records support 5572 enhancement refinements to function merge sub merge in C4::AuthoritiesMarc 5983 enhancement Change the wording around the CAS login 6012 enhancement Set up a working example of a CAS proxy 6296 enhancement Allow authentication to Koha via PKI / x.509 certificates 6670 enhancement Link patron name on returns screen to circulation page instead of patron detail page 6875 enhancement de-nesting C4 packages 6884 enhancement Improve TinyMCE configuration on Koha News page System requirements ====================== Changes since 3.2: * Template::Toolkit Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the english version of the Koha manual is available: http://koha-community.org/documentation/3-4-manual/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.4 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr??d??ric Demians Release Maintainer (3.2.x): Chris Nighswonger Release Maintainer (3.4.x): Chris Nighswonger QA Manager: Colin Campbell Credits ====================== We thank the following individuals who contributed patches to Koha 3.4.6 (The numeral in the first column represents the number of patches included in this release): 1 Alex Arnaud 1 Larry Baerveldt 1 Greg Barniskis 2 D Ruth Bavousett 1 Jared Camins-Esakov 2 Colin Campbell 2 Fr??d??rick Capovilla 1 Galen Charlton 17 Chris Cormack 8 Fr??d??ric Demians 2 Jonathan Druart 1 Nicole Engard 2 Magnus Enger 3 Katrin Fischer 2 Mason James 6 Srdjan Jankovic 1 Janusz Kaczmarek 12 Owen Leonard 1 Matthias Meusburger 1 Joy Nelson 4 Chris Nighswonger 2 Maxime Pelletier 11 Paul Poulain 1 Meenakshi R 1 MJ Ray 4 Liz Rea 10 Marcel de Rooy 7 Robin Sheat 1 Juan Sieira 18 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix releases) is 3.4.x. The next major feature release of Koha will be Koha 3.6.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 09 Nov 2011 at 16:50:37Z ##### From mdhafen at tech.washk12.org Wed Nov 9 20:44:32 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Wed, 9 Nov 2011 12:44:32 -0700 Subject: [Koha-devel] possibility for Koha links In-Reply-To: <4EB998F5.8010801@mdah.state.ms.us> References: <4EB97C66.5010505@mdah.state.ms.us> <4EB998F5.8010801@mdah.state.ms.us> Message-ID: It ends up as a link on the details page. But that works for ebooks and such. Doesn't work for images, that would take some coding. On Tue, Nov 8, 2011 at 2:02 PM, Linda Culberson wrote: > Mike; > Perhaps that might work. We are wanting it to be a clickable image. Can > you do that with the 952$u? In the best of all possible worlds, we would > the option of putting it on the results page as well as in the details > page, which is where I'm guessing the 952$u link is? Can it appear as an > image either or both places? > > Thanks for your help, > Linda > > > On 11/8/2011 1:47 PM, Mike Hafen wrote: > >> Some of my libraries are doing something similar to this with the items >> url tag (952$u) for online e-books. It shows the url in the staff and >> OPAC interfaces. Is that what you are talking about? >> >> On Tue, Nov 8, 2011 at 12:00 PM, Linda Culberson >> >> >> wrote: >> >> All, >> In the discussion of links in Koha, there has been discussion of >> there being links to in-house images, but I was wondering whether >> anyone had considered the possibility of those being actual >> hyperlinks? For example, we have digitized maps that are viewed >> through zoomify >> For example, in my catalog record >> http://zed.mdah.state.ms.us/ cgi-bin/koha/opac-detail.pl? >> biblionumber=85886 >> > biblionumber=85886 >> > >> it would be really wonderful to have a thumbnail of that map that >> links to >> http://mdah.state.ms.us/arrec/ digital_archives/maps/map.php? >> map=85886-1-map.tif >> > map.php?map=85886-1-map.tif >> > >> For the digitized video, something similar could be done. For pdf >> files and other such documents, we'd probably come up with a generic >> something. >> Thanks! >> -- >> Linda Culberson lculber at mdah.state.ms.us >> > >> >> Archives and Records Services Division >> Ms. Dept. of Archives & History >> P. O. Box 571 >> Jackson, MS 39205-0571 >> Telephone: 601/576-6873 Fax: 601/576-6824 >> >> >> ______________________________ _________________ >> Koha-devel mailing list >> Koha-devel at lists.koha- community.org >> >> > >> http://lists.koha-community. org/cgi-bin/mailman/listinfo/ >> koha-devel >> >> > koha-devel >> > >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community. org/ >> > >> >> >> > -- > Linda Culberson lculber at mdah.state.ms.us > Archives and Records Services Division > Ms. Dept. of Archives & History > P. O. Box 571 > Jackson, MS 39205-0571 > Telephone: 601/576-6873 Fax: 601/576-6824 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Thu Nov 10 17:19:03 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 10 Nov 2011 11:19:03 -0500 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> References: <20111107221227.802899F0E8@nail.towers.org.uk> <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> Message-ID: I'd like to see the atomic update files continue to be perl, not SQL. SQL is often sufficient to do an update, but not always, particular if we're swapping out one implementation of a feature for a more generic one. Also, I'd like to see 3 different subroutines/functions for each atomic update: Check: Logic to see if the change is actually required: returns 0 or 1 Do: just like what have now, makes the change Undo: undoes the change to the database, allowing rollback to previous code states (this would be a new function) -Ian 2011/11/9 Mason James > > On 2011-11-8, at 3:42 AM, MJ Ray wrote: > > > Paul Poulain > >> Let's say Limoges library has sponsored stuff that has resulted in > >> atomicupdate/limogeupdate.pl > > [...] > >> Does anyone see a problem with this new updatedatabase procedure ? > > > > The only problem that I can see is that we should encourage > > updates to be .sql not .pl files. > > oooh, great idea! > i think this would simplify the proposed process even more > > do other people agree? > > > > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu Nov 10 17:47:29 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 Nov 2011 11:47:29 -0500 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <20111107221227.802899F0E8@nail.towers.org.uk> <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> Message-ID: 2011/11/10 Ian Walls : > Undo:? undoes the change to the database, allowing rollback to previous code > states (this would be a new function) This could get very tricky if the update also made changes to existing data. It seems there would be the need for a sort of "undelete" table/file/foo. Otherwise, the whole idea seems sound to me. Kind Regards, Chris From cnighswonger at foundations.edu Thu Nov 10 17:49:28 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 Nov 2011 11:49:28 -0500 Subject: [Koha-devel] Patch status workflow (for Bugzilla) In-Reply-To: References: <4EA6D79A.7040206@biblibre.com> <4EA83CF2.8080101@biblibre.com> <4EA90609.7070401@biblibre.com> Message-ID: Now that KohaCon is past, I'd like to see us come to a resolve on this issue. On Thu, Oct 27, 2011 at 10:48 AM, Chris Nighswonger wrote: > Hi Ian, > > On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls > wrote: >> >> So, to summarize, you're looking for a status that can be set to you know >> which of the Patches Pushed need to be applied to the previous release? >> > > Correct. > >> >> There is currently no facility for specifying multiple releases that a bug >> applies to.? We'd have to create a custom field.? The difficulty would come >> with making use of it.? For my part, I only test bugs on master, because I >> only work on master.? Verifying the bug in previous releases doubles or >> triples the work (depending on how many previous releases I'm supporting). >> That makes filing the bug report much less sustainable a practice, from a >> workflow point of view. >> > > The fundamental problem is differentiation between bug fixes for existing > features versus bug fixes for enhancements applied either to the current dev > cycle or master (they seem the same from my POV). > > During the 3.6.0 release cycle, we attempted to maintain the distinction > between bug fixes and enhancements by this topic branch nominclature: > > 'new/bug_X' for bug fixes meant to apply to the current dev branch/master > and to the current stable branch > > 'new/enh/bug_Y' for enhancements meant to apply only to the current dev > branch/master. > > As we moved forward and the 'new/enh/bug_Y' branch was merged with the > current dev branch/master, folks begin filing bug reports for bugs in > 'new/enh/bug_Y.' These patches were, in turn, pushed out as 'new/bug_Z' > topic branches. Given that these "new" bugs related to 'new/enh/bug_Y' were > practically disassociated with 'new/enh/bug_Y' both by a different topic > branch designation and a different, unassociated bug number, it became quite > difficult to decide what should or should not be backported. (Other problems > were caused by this as well, but those will be resolved if we can arrive at > a solution for this one.) > > >> >> I would think that anything that gets applied to master would be a >> candidate for inclusion in the stable release branch.? It would be the job >> of the RM to determine a) if the bug applies, b) if the patch applies and c) >> if it's too big a new feature to include in stable.? Given the quantity of >> code produced in a release cycle, I can see this being a massive job. >> > > Perhaps we have not clearly established the job of the RMaint then. > > You may recall that when I took up the 3.2.x RMaint job, I specified that > the burden of ensuring clean application of a given patch to the current > stable branch is the job of the submitter rather than the RMaint. This was > agreed to by silent consent. [1] I have followed this policy throughout the > 3.4.x RMaint cycle as well. > > Typically if a commit a) is designated as a 'new/bug_X' topic branch *and* > b) does not apply cleanly to the current stable branch, I post a request to > the submitter to rebase and reformat the patch to apply over the current > stable branch *if it should.* This places the burden of determining if the > patch should, indeed, be backported on the author. (Which is where it should > be IMHO. ie. When I mark a bug as assigned to me, I accept the > responsibility of ensuring I fix it? in all currently supported releases as > well as master. Otherwise, I have not truly fixed the bug.) > > If this is not what works the best for the majority if the development > community, then we need to come up with a work flow which best fits and > implement it. Any significant work flow alterations will require more bodies > to help with the RMaint process. Based on the response to the call for > RMaint volunteers for the 3.6.x branch, I'm guessing we'll have a pretty > hard time coming up with the more bodies. ;-) > > That said, It seems much simpler to me to just add/modify a field in BZ to > allow the author of a given bugfix to indicate which branches the fix should > apply to. If the fix needs to be reformatted to apply over multiple > branches, the author can attach multiple patches to the bug report, > indicating which patch applies to which branch. Give the capabilities of > GIT, this should not greatly disrupt the developer's work flow. (While I'm > wishing... it would really be cool to have a hook which updated the bug with > the commit id when it was pushed to whichever branch...) > > Maybe the entire problem is overblown from my prospective, so I'm certainly > open to correction. But with two RMaint cycles under the belt and a staring > a third down the throat (Englishism here), I'd love to get this whittled > down to size. > > [1] http://tinyurl.com/3facmhg > > Kind Regards, > Chris > From cnighswonger at foundations.edu Thu Nov 10 21:39:47 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 Nov 2011 15:39:47 -0500 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages Message-ID: Hi all, While we are proposing changes to workflow, etc. I would like to propose that we standardize the manner in which we reference bug numbers in our commit messages. Lately I have been working on scripts to semi-automate the generation of release notes and having a standard reference to bug numbers would greatly simplify munging through git log and extracting them. So I propose that we use the form: [BZX...X] It will be pretty nigh impossible to obtain 100% compliance, so those doing sign-off, QA, or the RM could to 'git commit --amend' to add it in if it is missing or wrong. What say ye? Kind Regards, Chris From mjr at phonecoop.coop Thu Nov 10 22:06:24 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 10 Nov 2011 21:06:24 +0000 (GMT) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: Message-ID: <20111110210624.82BDC9F0E8@nail.towers.org.uk> Ian Walls > I'd like to see the atomic update files continue to be perl, not SQL. SQL > is often sufficient to do an update, but not always, particular if we're > swapping out one implementation of a feature for a more generic one. Most things can be done with some combination of ALTER, UPDATE and occasionally temporary tables. Has any update ever absolutely needed perl? At worst, could we allow and encourage .sql files alongside .pl please? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From robin at catalyst.net.nz Thu Nov 10 22:43:20 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 11 Nov 2011 10:43:20 +1300 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: References: Message-ID: <1320961400.30118.54.camel@zarathud> Chris Nighswonger schreef op do 10-11-2011 om 15:39 [-0500]: > So I propose that we use the form: [BZX...X] Most (many?) people seem to use a variant of 'Bug 1234' somewhere on the first line, why not just use that given it seems to be habit already? It'd be easy enough to regex for it, and you'd have a reasonable amount of backwards compatibility. Also, something that's compatible with the way 'git bz' does things would be very much preferred. It uses this regex: (\b[Ss]ee\s+(?:[^\s:/]+\s+){0,2})? (?:(https?://[^/]+/show_bug.cgi\?id=[^&\s]+) | [Bb]ug\s+\#?(\d+)) so, 'See: ' or 'Bug ' seem to be what it looks for. -- 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 cnighswonger at foundations.edu Fri Nov 11 02:19:19 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 Nov 2011 20:19:19 -0500 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: <1320961400.30118.54.camel@zarathud> References: <1320961400.30118.54.camel@zarathud> Message-ID: 2011/11/10 Robin Sheat : > Chris Nighswonger schreef op do 10-11-2011 om 15:39 [-0500]: >> So I propose that we use the form: [BZX...X] > > Most (many?) people seem to use a variant of 'Bug 1234' somewhere on the > first line, why not just use that given it seems to be habit already? > It'd be easy enough to regex for it, and you'd have a reasonable amount > of backwards compatibility. Actually this is true for the most part. However, it is the 1% of times when someone uses other weirdness that make it challenging. :-) I'm not stuck on any particular form, just wanting to get everyone doing the same thing. > > Also, something that's compatible with the way 'git bz' does things > would be very much preferred. It uses this regex: > (\b[Ss]ee\s+(?:[^\s:/]+\s+){0,2})? > (?:(https?://[^/]+/show_bug.cgi\?id=[^&\s]+) > ? ? | > ? [Bb]ug\s+\#?(\d+)) > > so, 'See: ' or 'Bug ' seem to be what it looks for. Here's my current regex (its been through several revisions): ([B|b]ug|BZ)?\s?(? Ok. For any interested parties, I've added a release-tools repo to git.k-c.org. You may see it here: http://git.koha-community.org/gitweb/?p=release-tools.git;a=summary The two tools I currently use are there. They are very hackish, so beware. I will gladly accept patches introducing improvements or additional tools. Kind Regards, Chris Koha 3.2.x/3.4.x/3.6.x Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Sat Nov 12 11:05:31 2011 From: mtj at kohaaloha.com (Mason James) Date: Sat, 12 Nov 2011 15:35:31 +0530 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: References: <1320961400.30118.54.camel@zarathud> Message-ID: <98907D56-3D0B-40EC-ABEF-B5D3F4EA5D4E@kohaaloha.com> On 2011-11-11, at 6:49 AM, Chris Nighswonger wrote: > 2011/11/10 Robin Sheat : >> Chris Nighswonger schreef op do 10-11-2011 om 15:39 [-0500]: >>> So I propose that we use the form: [BZX...X] >> >> Most (many?) people seem to use a variant of 'Bug 1234' somewhere on the >> first line, why not just use that given it seems to be habit already? >> It'd be easy enough to regex for it, and you'd have a reasonable amount >> of backwards compatibility. > > Actually this is true for the most part. However, it is the 1% of > times when someone uses other weirdness that make it challenging. :-) > > I'm not stuck on any particular form, just wanting to get everyone > doing the same thing. just my 2 cents.... i agree with Robin's suggested format 'Bug XXXX - ' is the format that Bugzilla seems to generate in various places and its also a little easier to understand than 'BZXXXX' and congrats on the release-notes script Chris, its genius! -------------- 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 jonathan.druart at biblibre.com Sat Nov 12 13:00:46 2011 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Sat, 12 Nov 2011 13:00:46 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <20111107221227.802899F0E8@nail.towers.org.uk> <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> Message-ID: Hi all ! I have already developed a new version of updatedatabase. It's not totally validated yet but in order to avoid parallels initiatives, let me explain you what I have already done. Work is on BibLibre git repository giit://git.biblibre.com/koha_biblibre.giton branch solr/ft/updatedb The goal was to have an interface to know status of different versions executed on a database. Requirements: on this branch, a precedent patch create a C4/Config/File/YAML.pm file. I use this module and you need an installdir section in your koha-conf.xml (__INSTALL_BASE__). How it works : 1 file per version (.pl ou .sql). if .sql, you could use comments, separator and query one after each others. if .pl please see skeleton.pl file. in admin/updatedatabase.pl, a table contains one line per version. For each line you can execute, see status (e.g. execution was ok or not (with errors)) or "force ok" (if you know theses queries don't need to be executed or have already been handled manually). You can't rollback a version. This tool only aim to have an interface showing status for each versions. Before execution, the routine C4::Update::Database::check_coherency check (for the most common queries) if the execution is coherent (if table or syspref already exists, etc.). You are welcome if you have any question or comment. Jonathan ps: I didn''t write Unit Tests :-/ 2011/11/10 Ian Walls > I'd like to see the atomic update files continue to be perl, not SQL. SQL > is often sufficient to do an update, but not always, particular if we're > swapping out one implementation of a feature for a more generic one. > > Also, I'd like to see 3 different subroutines/functions for each atomic > update: > > Check: Logic to see if the change is actually required: returns 0 or 1 > Do: just like what have now, makes the change > Undo: undoes the change to the database, allowing rollback to previous > code states (this would be a new function) > > > -Ian > > 2011/11/9 Mason James > >> >> On 2011-11-8, at 3:42 AM, MJ Ray wrote: >> >> > Paul Poulain >> >> Let's say Limoges library has sponsored stuff that has resulted in >> >> atomicupdate/limogeupdate.pl >> > [...] >> >> Does anyone see a problem with this new updatedatabase procedure ? >> > >> > The only problem that I can see is that we should encourage >> > updates to be .sql not .pl files. >> >> oooh, great idea! >> i think this would simplify the proposed process even more >> >> do other people agree? >> >> >> >> _______________________________________________ >> 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/ >> > > > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal > > _______________________________________________ > 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 Sat Nov 12 19:04:48 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Sat, 12 Nov 2011 18:04:48 +0000 (GMT) Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: <98907D56-3D0B-40EC-ABEF-B5D3F4EA5D4E@kohaaloha.com> Message-ID: <20111112180448.5609D9F0E8@nail.towers.org.uk> Mason James > i agree with Robin's suggested format > > 'Bug XXXX - ' is the format that Bugzilla seems to generate in various places > and its also a little easier to understand than 'BZXXXX' > > and congrats on the release-notes script Chris, its genius! I agree (on the congrats too). Z looks too like two. Bug XXXX please! -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From cnighswonger at foundations.edu Sun Nov 13 02:36:55 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sat, 12 Nov 2011 20:36:55 -0500 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: <20111112180448.5609D9F0E8@nail.towers.org.uk> References: <98907D56-3D0B-40EC-ABEF-B5D3F4EA5D4E@kohaaloha.com> <20111112180448.5609D9F0E8@nail.towers.org.uk> Message-ID: On Sat, Nov 12, 2011 at 1:04 PM, MJ Ray wrote: > Mason James >> i agree with Robin's suggested format >> >> 'Bug XXXX - ' is the format that Bugzilla seems to generate in various places >> and its also a little easier to understand than 'BZXXXX' >> >> and congrats on the release-notes script Chris, its genius! > > I agree (on the congrats too). ?Z looks too like two. ?Bug XXXX please! Ok, so it sounds like we're working toward a consensus of Bug XXXX. I'd like to see us agree either to use some sort of markers (ie. [] or some such) or to proceed and follow the bug notation with a single whitespace. Presently we get things like colons, commas, and occasional other chars immediately following the XXXX part of the bug number. Kind Regards, Chris From nengard at gmail.com Sun Nov 13 02:41:14 2011 From: nengard at gmail.com (Nicole Engard) Date: Sat, 12 Nov 2011 20:41:14 -0500 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: References: <98907D56-3D0B-40EC-ABEF-B5D3F4EA5D4E@kohaaloha.com> <20111112180448.5609D9F0E8@nail.towers.org.uk> Message-ID: I'd rather say that we'll put a white space after the bug number than to put the bug number in brackets or some such, I often mistype the brackets in my signed off messages :) Nicole On Sat, Nov 12, 2011 at 8:36 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > On Sat, Nov 12, 2011 at 1:04 PM, MJ Ray wrote: > > Mason James > >> i agree with Robin's suggested format > >> > >> 'Bug XXXX - ' is the format that Bugzilla seems to generate in various > places > >> and its also a little easier to understand than 'BZXXXX' > >> > >> and congrats on the release-notes script Chris, its genius! > > > > I agree (on the congrats too). Z looks too like two. Bug XXXX please! > > Ok, so it sounds like we're working toward a consensus of Bug XXXX. > I'd like to see us agree either to use some sort of markers (ie. [] or > some such) or to proceed and follow the bug notation with a single > whitespace. Presently we get things like colons, commas, and > occasional other chars immediately following the XXXX part of the bug > number. > > Kind Regards, > Chris > _______________________________________________ > 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 robin at catalyst.net.nz Sun Nov 13 06:57:43 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Sun, 13 Nov 2011 18:57:43 +1300 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: References: <98907D56-3D0B-40EC-ABEF-B5D3F4EA5D4E@kohaaloha.com> <20111112180448.5609D9F0E8@nail.towers.org.uk> Message-ID: <4EBF5C57.7050902@catalyst.net.nz> On 13/11/11 14:36, Chris Nighswonger wrote: > Ok, so it sounds like we're working toward a consensus of Bug XXXX. > I'd like to see us agree either to use some sort of markers (ie. [] or > some such) or to proceed and follow the bug notation with a single Two things, one is that regexing for 'Bug 1234' should be pretty easy to do, no matter what follows it (something like '/^[Bb]ug (\d+)/' would do the trick.) Though I like whitespace, I think it makes it more readable too. Secondly with [...], git will strip out things in square brackets at the start of a git comment when editing (maybe applying, not sure exactly where), possibly leading to the bug number getting stripped off on signoff. Additionally, git-bz won't realise you have a bug number in there, and so will attach the URL of the bug to the bottom of the message, nor will it automatically work out what bug you're aiming to attach to. My convention, which I think is parseable and readable is something like: Bug 1234 - something something or Bug 1234 [3.6.x] - something something for things that have to apply to a specific branch. That said, I mostly do this because I picked it up somewhere else, so take that for what it's worth :) Aside: at Kohacon, Mason was working on something to auto-post to -patches from bugzilla. Hopefully that'll be ready to go when he's back from holiday. Robin. From paul.poulain at biblibre.com Sun Nov 13 20:47:46 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 13 Nov 2011 20:47:46 +0100 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: References: Message-ID: <4EC01EE2.8060201@biblibre.com> Le 10/11/2011 21:39, Chris Nighswonger a ?crit : > Hi all, > > While we are proposing changes to workflow, etc. I would like to > propose that we standardize the manner in which we reference bug > numbers in our commit messages. Lately I have been working on scripts > to semi-automate the generation of release notes and having a standard > reference to bug numbers would greatly simplify munging through git > log and extracting them. > > So I propose that we use the form: [BZX...X] I love this idea ! For many reasons: * I already use BZXXX ;-) (OK, it's a wrong reason) * Not every patch is a bug, so BZ is related to bugzilla, not bug * it takes only 2 chars, where "Bug XXXX" takes 4. In (many) places where only a part of the bug message is displayed, those 2 chars are usefull * Companies like BibLibre uses another tool to track customers bugs (Mantis). So all our internal bugs are prefixed "MTXXXX" where MT is the mantis number. I know that Catalyst uses WRMS, ByWater bugzilla, and there are probably more. We (at BibLibre) make sometimes a mistake because one of us says "bug 5432". The other search in bugzilla, while the speaker was speaking of Mantis ! (maybe that's also because we are in the same array of number in Mantis as we're in bugzilla...) PROPOSAL: Why not having each company "reserve" a prefix, thus we would know that WRMS5432 => Catalyst internal bug number. BW5432 => ByWaterSolutions BZ5432 => koha-community bugzilla number -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From psm_vu at india.com Mon Nov 14 12:10:39 2011 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Mon, 14 Nov 2011 11:10:39 +0000 (UTC) Subject: [Koha-devel] Zebra Error (Koha 3.4) In-Reply-To: References: <4EB97C66.5010505@mdah.state.ms.us> <4EB998F5.8010801@mdah.state.ms.us>, Message-ID: <20111114111039.38BD311C1@smtp02.zmail.com> An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Mon Nov 14 14:23:59 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Mon, 14 Nov 2011 08:23:59 -0500 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: <4EC01EE2.8060201@biblibre.com> References: <4EC01EE2.8060201@biblibre.com> Message-ID: I'm afraid I'm not seeing the need to standardize the expression of bug number in commit messages. We're already using "Bug XXXX" or "Enh XXXX" most of the time, and that's worked just fine for me in all my lookups and QA'ing. Do we just need a pattern that's regex-able so we can program a script to automatically process the patches? As for each company reserving it's own prefix, I don't think that's necessary (at least for ByWater). Everything we submit already has a Koha Bugzilla entry, since that's a requirement for getting submitting code in the first place. We link our local ticketing system to the Koha Bug report, so we can update the appropriate tickets as the fix makes it's way through the community process. It would just introduce complication for us to have local ByWater numbers in the first line of the commit; there could be some advantage to having them at the end of the commit message, but that would be purely for our internal use, and has particular place in a Koha commit message. I'm also with MJ: Z looks too much like 2. -Ian On Sun, Nov 13, 2011 at 2:47 PM, Paul Poulain wrote: > Le 10/11/2011 21:39, Chris Nighswonger a ?crit : > > Hi all, > > > > While we are proposing changes to workflow, etc. I would like to > > propose that we standardize the manner in which we reference bug > > numbers in our commit messages. Lately I have been working on scripts > > to semi-automate the generation of release notes and having a standard > > reference to bug numbers would greatly simplify munging through git > > log and extracting them. > > > > So I propose that we use the form: [BZX...X] > I love this idea ! > For many reasons: > * I already use BZXXX ;-) (OK, it's a wrong reason) > * Not every patch is a bug, so BZ is related to bugzilla, not bug > * it takes only 2 chars, where "Bug XXXX" takes 4. In (many) places > where only a part of the bug message is displayed, those 2 chars are > usefull > * Companies like BibLibre uses another tool to track customers bugs > (Mantis). So all our internal bugs are prefixed "MTXXXX" where MT is > the mantis number. I know that Catalyst uses WRMS, ByWater bugzilla, and > there are probably more. > > We (at BibLibre) make sometimes a mistake because one of us says "bug > 5432". The other search in bugzilla, while the speaker was speaking of > Mantis ! (maybe that's also because we are in the same array of number > in Mantis as we're in bugzilla...) > > PROPOSAL: Why not having each company "reserve" a prefix, thus we would > know that WRMS5432 => Catalyst internal bug number. BW5432 => > ByWaterSolutions BZ5432 => koha-community bugzilla number > > -- > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at gmail.com Mon Nov 14 22:39:55 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 14 Nov 2011 22:39:55 +0100 Subject: [Koha-devel] Zebra Error (Koha 3.4) In-Reply-To: <20111114111039.38BD311C1@smtp02.zmail.com> References: <4EB97C66.5010505@mdah.state.ms.us> <4EB998F5.8010801@mdah.state.ms.us> <20111114111039.38BD311C1@smtp02.zmail.com> Message-ID: Hie, do you have enougth space in /tmp ? You may use rebuild_zebra -x for marcxml use and -k for keeping the temporary files. 2011/11/14 Partha Mukhopadhyay > Dear all, > > I'm facing a problem in Zebra reindexing. In fact we entered a total of > 21000 documents (manifestation) in our Koha setup (upgraded to 3.4). > Somehow, a few documents are indexed by Zebra and as a result many of the > records are not available for seraching. I followed the steps as below to > solve the problem but it is still accessing only those records (no incraese > in indexing base; roughly aroud 8000 records are processed by Zebra > everytime). > > > > commands used: > -------------- > 1. sudo zebraidx -c /etc/koha/zebradb/zebra-biblios.cfg -g iso2709 -d > biblios init > No problem reported > > 2. sudo zebraidx -c /etc/koha/zebradb/zebra-authorities.cfg -g iso2709 > -d authorities init > No problem reported > > 3. sudo KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib > /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -r -v -b > > > > The screen goes in this way..... > > psm at psm-laptop:~$ sudo KOHA_CONF=/etc/koha/koha-conf.xml > PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/ > rebuild_zebra.pl -b -r -v > Zebra configuration information > ================================ > Zebra biblio directory = /var/lib/koha/zebradb/biblios > Zebra authorities directory = /var/lib/koha/zebradb/authorities > Koha directory = /usr/share/koha/intranet/cgi-bin > BIBLIONUMBER in : 999$c > BIBLIOITEMNUMBER in : 999$d > ================================ > skipping authorities > ==================== > exporting biblio > ==================== > > 1............................................................................... > > 101............................................................................. > > 201............................................................................. > > 301............................................................................. > > 401............................................................................. > > 501............................................................................. > > > > > 00:56:07-14/11 zebraidx(4485) [log] add grs.marcxml.record > /tmp/HcFKEQeESz/biblio/exported_records 1858559 > 00:56:07-14/11 zebraidx(4485) [log] add grs.marcxml.record > /tmp/HcFKEQeESz/biblio/exported_records 1859288 > 00:56:07-14/11 zebraidx(4485) [log] Records: 1000 i/u/d 1000/0/0 > 00:56:07-14/11 zebraidx(4485) [log] More than 1000 file log entries. > Omitting rest > 00:56:16-14/11 zebraidx(4485) [log] Records: 2000 i/u/d 2000/0/0 > 00:56:25-14/11 zebraidx(4485) [log] Records: 3000 i/u/d 3000/0/0 > 00:56:36-14/11 zebraidx(4485) [log] Records: 4000 i/u/d 4000/0/0 > 00:56:46-14/11 zebraidx(4485) [log] Records: 5000 i/u/d 5000/0/0 > 00:56:58-14/11 zebraidx(4485) [log] Records: 6000 i/u/d 6000/0/0 > 00:57:10-14/11 zebraidx(4485) [log] Records: 7000 i/u/d 7000/0/0 > 00:57:23-14/11 zebraidx(4485) [log] Records: 8000 i/u/d 8000/0/0 > > > > > 00:57:29-14/11 zebraidx(4485) [warn] Unknown register type: Subject > 00:57:35-14/11 zebraidx(4485) [log] Records: 9000 i/u/d 9000/0/0 > 00:57:45-14/11 zebraidx(4485) [log] MARC: Bad directory > 00:57:45-14/11 zebraidx(4485) [warn] MARC: Bad offsets in data. Skipping > rest > 00:57:45-14/11 zebraidx(4485) [warn] Record didn't contain match fields in > (bib1,Local-number) > 00:57:45-14/11 zebraidx(4485) [log] error grs.marcxml.record > /tmp/HcFKEQeESz/biblio/exported_records 26009459 > 00:57:55-14/11 zebraidx(4485) [log] Merge 14.8% completed; 57 seconds > remaining > 00:58:05-14/11 zebraidx(4485) [log] Merge 34.1% completed; 38 seconds > remaining > 00:58:15-14/11 zebraidx(4485) [log] Merge 50.9% completed; 28 seconds > remaining > 00:58:25-14/11 zebraidx(4485) [log] Merge 66.1% completed; 20 seconds > remaining > 00:58:35-14/11 zebraidx(4485) [log] Merge 87.9% completed; 6 seconds > remaining > 00:58:42-14/11 zebraidx(4485) [log] Iterations: isam/dict 28751767/293156 > 00:58:42-14/11 zebraidx(4485) [log] Dict: inserts/updates/deletions: > 293156/0/0 > 00:58:49-14/11 zebraidx(4485) [log] Records: 9785 i/u/d 9785/0/0 > 00:58:49-14/11 zebraidx(4485) [log] zebra_stop: 170.24 180.78 9.04 > 00:58:50-14/11 zebraidx(4495) [log] zebra_start 2.0.43 > abd433d1a315576cf1f4a53f2c70365f9a76477f > 00:58:50-14/11 zebraidx(4495) [log] config > /etc/koha/zebradb/zebra-biblios.cfg > 00:58:50-14/11 zebraidx(4495) [log] Loaded filter module > /usr/lib/idzebra-2.0/modules/mod-grs-marc.so > 00:58:50-14/11 zebraidx(4495) [log] Loaded filter module > /usr/lib/idzebra-2.0/modules/mod-dom.so > 00:58:50-14/11 zebraidx(4495) [log] Loaded filter module > /usr/lib/idzebra-2.0/modules/mod-grs-xml.so > 00:58:50-14/11 zebraidx(4495) [log] Loaded filter module > /usr/lib/idzebra-2.0/modules/mod-alvis.so > 00:58:50-14/11 zebraidx(4495) [log] Loaded filter module > /usr/lib/idzebra-2.0/modules/mod-grs-regx.so > 00:58:50-14/11 zebraidx(4495) [log] Loaded filter module > /usr/lib/idzebra-2.0/modules/mod-text.so > 00:58:50-14/11 zebraidx(4495) [log] enabling shadow > spec=/var/lib/koha/zebradb/biblios/shadow:20G > 00:58:50-14/11 zebraidx(4495) [log] cache_fname = > /var/lib/koha/zebradb/biblios/shadow/cache > 00:59:41-14/11 zebraidx(4495) [log] zebra_stop: 50.99 1.04 4.90 > ==================== > CLEANING > ==================== > psm at psm-laptop:~$ > > > > > Any idea? What to do? > > > > > > ---------------------------------------------------- > > Dr. Parthasarathi Mukhopadhyay > > Lecturer (Sr. Scale) > > Department of Library and Information Science > > The University of Burdwan (WB) > > ------------------------------------------ > > > > _______________________________________________ > 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From cnighswonger at foundations.edu Tue Nov 15 22:35:49 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 15 Nov 2011 16:35:49 -0500 Subject: [Koha-devel] Proposal to Standardize Bug Number References in Commit Messages In-Reply-To: References: <4EC01EE2.8060201@biblibre.com> Message-ID: Sorry for the pause on my part here. 2011/11/14 Ian Walls : > I'm afraid I'm not seeing the need to standardize the expression of bug > number in commit messages.? We're already using "Bug XXXX" or "Enh XXXX" > most of the time, and that's worked just fine for me in all my lookups and > QA'ing.? Do we just need a pattern that's regex-able so we can program a > script to automatically process the patches? > This is moving along in a direction I did not anticipate in my original post. Ian, it would be great if we *only* using the notation you mention above. But, in fact, we are not. To clarify, I quote from my earlier response to Robin: >> >> Also, something that's compatible with the way 'git bz' does things >> would be very much preferred. It uses this regex: >> (\b[Ss]ee\s+(?:[^\s:/]+\s+){0,2})? >> (?:(https?://[^/]+/show_bug.cgi\?id=[^&\s]+) >> | >> [Bb]ug\s+\#?(\d+)) >> >> so, 'See: ' or 'Bug ' seem to be what it looks for. > > Here's my current regex (its been through several revisions): > > ([B|b]ug|BZ)?\s?(? > This extracts the following "styles" of bug references from git log, > each of which is unique. I have a feeling that there are some other > styles which I have not yet caught. (I realize that it only catches 4 > digit bug numbers, but '+' causes it to pick up on other junk which > I've yet to figure out how to avoid.) > Bug 6905: > Bug 5995 > 5533: > bug 5780 > 6278 > Bug 5630, > BZ6268 > BZ6074: All of the eight flavors mentioned above are presently in use. As I mentioned in an earlier post as well, \d+ "should" work, but runs in to some problems when commit ids are included. At any rate. The entire discussion is irrelevant if someone can come up with a "one size fits all" regexp for every style of bug tagging currently in use. I've made my script available and am accepting any and all patches which improve it. Thanks to everyone taking time to participate in this thread! Kind Regards, Chris From jransom at library.org.nz Tue Nov 15 23:06:56 2011 From: jransom at library.org.nz (Joann Ransom) Date: Wed, 16 Nov 2011 11:06:56 +1300 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) Message-ID: Hi all, Marshall is collecting responses for the technology report about libraries perceptions of ILSs. http://www.librarytechnology.org/ Cheers Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marshall.breeding at Vanderbilt.Edu Wed Nov 16 14:36:35 2011 From: marshall.breeding at Vanderbilt.Edu (Breeding, Marshall) Date: Wed, 16 Nov 2011 07:36:35 -0600 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) Message-ID: To all libraries using Koha: As Joann mentioned, I am collecting data for the 2011 Annual Library Automation Perceptions survey. This survey aims to provide some general measurement of the levels of satisfaction that libraries have with their library automation systems and the organizations that support them. I am aware that many libraries using Koha do so independently without direct involvement of a support firm. Even in these cases, data regarding the perceived quality and functionality of the automation system would be very helpful. The survey also probes at the relative level of interest in open source automation systems. I do hope that all libraries using Koha will respond to the survey. The survey forms are linked to each library's entry in the lib-web-cats directory, so you will need to submit an entry if your library is not already represented. A large number of libraries using Koha are already represented, but I'm sure that there are many still missing. See: http://www.librarytechnology.org/libraries.pl?ILS=Koha http://www.librarytechnology.org/map.pl?ILS=Koha A strong response will help document the worldwide impact of Koha. To participate in the survey, you can start with the instructions given on the current posting on the top page of Library Technology Guides: http://www.librarytechnology.org/ Please let me know if you have an questions about the survey. Best regards, -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Joann Ransom Sent: Tuesday, November 15, 2011 4:07 PM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) Hi all, Marshall is collecting responses for the technology report about libraries perceptions of ILSs. http://www.librarytechnology.org/ Cheers Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Nov 16 14:55:51 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 16 Nov 2011 14:55:51 +0100 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: References: Message-ID: <4EC3C0E7.5050701@biblibre.com> Le 16/11/2011 14:36, Breeding, Marshall a ?crit : > To all libraries using Koha: > A strong response will help document the worldwide impact of Koha. BibLibre will try to do something for french libraries, hoping it will be more fruitfull than last year (we will to it earlier, that may help) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From programcnann at yahoo.es Sat Nov 12 22:31:14 2011 From: programcnann at yahoo.es (Si lo Necesitas Avisame) Date: 12 Nov 2011 19:31:14 -0200 Subject: [Koha-devel] koha-devel - Informe Message-ID: <20111112193114.89E4075408E4787D@yahoo.es> An HTML attachment was scrubbed... URL: From marshall.breeding at librarytechnology.org Wed Nov 16 14:02:47 2011 From: marshall.breeding at librarytechnology.org (Marshall Breeding) Date: Wed, 16 Nov 2011 07:02:47 -0600 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) Message-ID: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> To all libraries using Koha: As Joann mentioned, I am collecting data for the 2011 Annual Library Automation Perceptions survey. This survey aims to provide some general measurement of the levels of satisfaction that libraries have with their library automation systems and the organizations that support them. I am aware that many libraries using Koha do so independently without direct involvement of a support firm. Even in these cases, data regarding the perceived quality and functionality of the automation system would be very helpful. The survey also probes at the relative level of interest in open source automation systems. I do hope that all libraries using Koha will respond to the survey. The survey forms are linked to each library's entry in the lib-web-cats directory, so you will need to submit an entry if your library is not already represented. A large number of libraries using Koha are already represented, but I'm sure that there are many still missing. See: http://www.librarytechnology.org/libraries.pl?ILS=Koha http://www.librarytechnology.org/map.pl?ILS=Koha A strong response will help document the worldwide impact of Koha. To participate in the survey, you can start with the instructions given on the current posting on the top page of Library Technology Guides: http://www.librarytechnology.org/ Please let me know if you have an questions about the survey. Best regards, -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Joann Ransom Sent: Tuesday, November 15, 2011 4:07 PM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) Hi all, Marshall is collecting responses for the technology report about libraries perceptions of ILSs. http://www.librarytechnology.org/ Cheers Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jransom at library.org.nz Wed Nov 16 23:24:48 2011 From: jransom at library.org.nz (Joann Ransom) Date: Thu, 17 Nov 2011 11:24:48 +1300 Subject: [Koha-devel] Koha indian domain names. Message-ID: Hi everyone, HLT has recently taken ownership of the following domain names of behalf of the koha community: - koha-community.in - koha-community.org.in - koha.in - koha.org.in We would like to offer the use of these to domains to Indian Koha libraries. For example: - *granthalaya.koha-community.in* AND *granthalaya.koha.org.in* could both point to http://www.granthalaya.org - *delhipublic.koha.in* could redirect to http://www.dpl.gov.in - *magarpatta.koha.in* could redirect to http://library.mpatta.com etc. Does this idea have any appeal? Naturally there would be no cost for this - it is community property after all. If you are interested please contact Chris Cormack : chrisc at catalyst.co.nz Kind regards Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Nov 17 17:43:06 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 17 Nov 2011 17:43:06 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> References: <20111107221227.802899F0E8@nail.towers.org.uk> <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> Message-ID: <4EC5399A.2000100@biblibre.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 09/11/2011 18:54, Mason James a ?crit : > do other people agree? not at all ! Sometimes (not very often, but not rarely either), more complex calculations must be made, like for For example: depending on your marcflavour you do something or something else. > $DBversion = '3.05.00.017'; if (C4::Context->preference("Version") > < TransformToNum($DBversion)) { if > (C4::Context->preference("marcflavour") eq 'MARC21' || > C4::Context->preference("marcflavour") eq 'NORMARC'){ > $dbh->do("INSERT INTO `marc_subfield_structure` (`tagfield`, > `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, > `mandatory`, `kohafield`, `tab`, `authorised_value` , > `authtypecode`, `value_builder`, `isurl`, `hidden`, > `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES ('773', > '0', 'Host Biblionumber', 'Host Biblionumber', 0, 0, NULL, 7, NULL, > NULL, '', NULL, -6, '', '', '', NULL)"); $dbh->do("INSERT INTO > `marc_subfield_structure` (`tagfield`, `tagsubfield`, > `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, > `tab`, `authorised_value` , `authtypecode`, `value_builder`, > `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, > `defaultvalue`) VALUES ('773', '9', 'Host Itemnumber', 'Host > Itemnumber', 0, 0, NULL, 7, NULL, NULL, '', NULL, -6, '', '', '', > NULL)"); print "Upgrade to $DBversion done (Add 773 subfield 9 and > 0 to default framework)\n"; SetVersion ($DBversion); } elsif > (C4::Context->preference("marcflavour") eq 'UNIMARC'){ > $dbh->do("INSERT INTO `marc_subfield_structure` (`tagfield`, > `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, > `mandatory`, `kohafield`, `tab`, `authorised_value` , > `authtypecode`, `value_builder`, `isurl`, `hidden`, > `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES ('461', > '9', 'Host Itemnumber', 'Host Itemnumber', 0, 0, NULL, 7, NULL, > NULL, '', NULL, -6, '', '', '', NULL)"); print "Upgrade to > $DBversion done (Add 461 subfield 9 to default framework)\n"; > SetVersion ($DBversion); } So we must have a .pl file, not SQL - -- 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/ iQEcBAEBAgAGBQJOxTmUAAoJEK81SonuhyGoIscH/i1yDbz+viO/Qcy+y5h/Ttlw tyc2xqWlCY0ph4XE7TyE5sz6PBWB57tg0KZGPAz8ubCd3AThUkzTgU33rrRLOkg6 zIguyp9GOXH8VDWGtttnXGCMJlLqKp3wRargBZHOIRGBJVUjDkhiat1X/feqlFyr 3V3LT+H9sg+mWGSOhhbd1xRbd6XtiLBccopMllcz/bzqq133HuMbfS7Au/qw9bYF DpIrFCoJgiVM3fyUwqSpDe9rkq+sTIbLw3KN6B17lSWjUqOHCYJKtcXIskUM0fLk 1RaNqXtob9ZvvY6VibjHnBUTgsZApGzt6NRE2tvy4d/HJXUmXHD70KVebw8WHek= =F8G6 -----END PGP SIGNATURE----- From paul.poulain at biblibre.com Thu Nov 17 18:03:35 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 17 Nov 2011 18:03:35 +0100 Subject: [Koha-devel] bugzilla & email & bulkupdates Message-ID: <4EC53E67.50904@biblibre.com> Hello all (& Ian, more specifically) Digging into bugzilla administration, I see that there is an option to disable all mails: bugzilla > administration > Email > the 1st option is : mail_delivery_method Defines how email is sent, or if it is sent at all. 'Sendmail', 'SMTP' and 'Qmail' are all MTAs. You need to install a third-party sendmail replacement if you want to use sendmail on Windows. 'Test' is useful for debugging: all email is stored in 'data/mailer.testfile' instead of being sent. 'none' will completely disable email. Bugzilla continues to act as though it is sending mail, but nothing is sent or stored. So, for bulk updates, we could set the parameter to "none", do the change, and set it back to "Sendmail". For example : * I still want to clean version list (to have less than 20 very old versions...) * Ian, your idea of changing the workflow for patches could be achieved without overwhelming mails. I will do, during the week-end hopefully, a test on this feature, disabling mails, moving all 2.2.9 patches to rel_2_2 and re-enabling emails -- 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 Nov 17 19:22:00 2011 From: danielg.koha at gmail.com (Daniel Grobani) Date: Thu, 17 Nov 2011 10:22:00 -0800 Subject: [Koha-devel] Call for News for the October Newsletter (especially KohaCon11) Message-ID: Hi, I'm gathering news for the November newsletter. Please send me by the 25th anything you think the community 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. This month, I'd like to have a special section dedicated to KohaCon11. So if you were there, please send me reports, notes, impressions, incriminating evidence.... Many thanks, Daniel Grobani From mtj at kohaaloha.com Thu Nov 17 21:21:00 2011 From: mtj at kohaaloha.com (Mason James) Date: Fri, 18 Nov 2011 09:21:00 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EC5399A.2000100@biblibre.com> References: <20111107221227.802899F0E8@nail.towers.org.uk> <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> <4EC5399A.2000100@biblibre.com> Message-ID: <8EBA2DFB-A25C-4B47-8950-809F4D0206B4@kohaaloha.com> On 2011-11-18, at 5:43 AM, Paul Poulain wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 09/11/2011 18:54, Mason James a ?crit : >> do other people agree? > not at all ! Sometimes (not very often, but not rarely either), more > complex calculations must be made, like for > > For example: > depending on your marcflavour you do something or something else. >> $DBversion = '3.05.00.017'; if (C4::Context->preference("Version") >> < TransformToNum($DBversion)) { if >> (C4::Context->preference("marcflavour") eq 'MARC21' || >> C4::Context->preference("marcflavour") eq 'NORMARC'){ ... > > So we must have a .pl file, not SQL > - -- > Paul POULAIN yes, yes... a good point Paul! i think if we want to do Ian's suggested check/apply/roll-back idea for DB changes, we will indeed need to use .pl files not .sql files for new patches so, i change my mind on this point :) Mason -------------- 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 cnighswonger at foundations.edu Thu Nov 17 21:48:54 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 17 Nov 2011 15:48:54 -0500 Subject: [Koha-devel] Patch status workflow (for Bugzilla) In-Reply-To: References: <4EA6D79A.7040206@biblibre.com> <4EA83CF2.8080101@biblibre.com> <4EA90609.7070401@biblibre.com> Message-ID: Poke. On Thu, Nov 10, 2011 at 11:49 AM, Chris Nighswonger wrote: > Now that KohaCon is past, I'd like to see us come to a resolve on this issue. > > On Thu, Oct 27, 2011 at 10:48 AM, Chris Nighswonger > wrote: >> Hi Ian, >> >> On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls >> wrote: >>> >>> So, to summarize, you're looking for a status that can be set to you know >>> which of the Patches Pushed need to be applied to the previous release? >>> >> >> Correct. >> >>> >>> There is currently no facility for specifying multiple releases that a bug >>> applies to.? We'd have to create a custom field.? The difficulty would come >>> with making use of it.? For my part, I only test bugs on master, because I >>> only work on master.? Verifying the bug in previous releases doubles or >>> triples the work (depending on how many previous releases I'm supporting). >>> That makes filing the bug report much less sustainable a practice, from a >>> workflow point of view. >>> >> >> The fundamental problem is differentiation between bug fixes for existing >> features versus bug fixes for enhancements applied either to the current dev >> cycle or master (they seem the same from my POV). >> >> During the 3.6.0 release cycle, we attempted to maintain the distinction >> between bug fixes and enhancements by this topic branch nominclature: >> >> 'new/bug_X' for bug fixes meant to apply to the current dev branch/master >> and to the current stable branch >> >> 'new/enh/bug_Y' for enhancements meant to apply only to the current dev >> branch/master. >> >> As we moved forward and the 'new/enh/bug_Y' branch was merged with the >> current dev branch/master, folks begin filing bug reports for bugs in >> 'new/enh/bug_Y.' These patches were, in turn, pushed out as 'new/bug_Z' >> topic branches. Given that these "new" bugs related to 'new/enh/bug_Y' were >> practically disassociated with 'new/enh/bug_Y' both by a different topic >> branch designation and a different, unassociated bug number, it became quite >> difficult to decide what should or should not be backported. (Other problems >> were caused by this as well, but those will be resolved if we can arrive at >> a solution for this one.) >> >> >>> >>> I would think that anything that gets applied to master would be a >>> candidate for inclusion in the stable release branch.? It would be the job >>> of the RM to determine a) if the bug applies, b) if the patch applies and c) >>> if it's too big a new feature to include in stable.? Given the quantity of >>> code produced in a release cycle, I can see this being a massive job. >>> >> >> Perhaps we have not clearly established the job of the RMaint then. >> >> You may recall that when I took up the 3.2.x RMaint job, I specified that >> the burden of ensuring clean application of a given patch to the current >> stable branch is the job of the submitter rather than the RMaint. This was >> agreed to by silent consent. [1] I have followed this policy throughout the >> 3.4.x RMaint cycle as well. >> >> Typically if a commit a) is designated as a 'new/bug_X' topic branch *and* >> b) does not apply cleanly to the current stable branch, I post a request to >> the submitter to rebase and reformat the patch to apply over the current >> stable branch *if it should.* This places the burden of determining if the >> patch should, indeed, be backported on the author. (Which is where it should >> be IMHO. ie. When I mark a bug as assigned to me, I accept the >> responsibility of ensuring I fix it? in all currently supported releases as >> well as master. Otherwise, I have not truly fixed the bug.) >> >> If this is not what works the best for the majority if the development >> community, then we need to come up with a work flow which best fits and >> implement it. Any significant work flow alterations will require more bodies >> to help with the RMaint process. Based on the response to the call for >> RMaint volunteers for the 3.6.x branch, I'm guessing we'll have a pretty >> hard time coming up with the more bodies. ;-) >> >> That said, It seems much simpler to me to just add/modify a field in BZ to >> allow the author of a given bugfix to indicate which branches the fix should >> apply to. If the fix needs to be reformatted to apply over multiple >> branches, the author can attach multiple patches to the bug report, >> indicating which patch applies to which branch. Give the capabilities of >> GIT, this should not greatly disrupt the developer's work flow. (While I'm >> wishing... it would really be cool to have a hook which updated the bug with >> the commit id when it was pushed to whichever branch...) >> >> Maybe the entire problem is overblown from my prospective, so I'm certainly >> open to correction. But with two RMaint cycles under the belt and a staring >> a third down the throat (Englishism here), I'd love to get this whittled >> down to size. >> >> [1] http://tinyurl.com/3facmhg >> >> Kind Regards, >> Chris >> > From dnphadke at gmail.com Fri Nov 18 06:32:54 2011 From: dnphadke at gmail.com (Dattatray Phadke) Date: Fri, 18 Nov 2011 11:02:54 +0530 Subject: [Koha-devel] confirm b023495405f84d04f71f16ddde8366baa27cee70 In-Reply-To: References: Message-ID: Please remove my Id from List On Fri, Nov 18, 2011 at 9:48 AM, < koha-devel-request at lists.koha-community.org> wrote: > Mailing list removal confirmation notice for mailing list Koha-devel > > We have received a request for the removal of your email address, > "dnphadke at gmail.com" from the koha-devel at lists.koha-community.org > mailing list. To confirm that you want to be removed from this > mailing list, simply reply to this message, keeping the Subject: > header intact. Or visit this web page: > > > http://lists.koha-community.org/cgi-bin/mailman/confirm/koha-devel/b023495405f84d04f71f16ddde8366baa27cee70 > > > Or include the following line -- and only the following line -- in a > message to koha-devel-request at lists.koha-community.org: > > confirm b023495405f84d04f71f16ddde8366baa27cee70 > > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). > > If you do not wish to be removed from this list, please simply > disregard this message. If you think you are being maliciously > removed from the list, or have any other questions, send them to > koha-devel-owner at lists.koha-community.org. > -- Thanking you D.N.Phadke,Ph.D. Consultant Librarian,Pillai Group of Colleges C/O Dr.K.M. Vasudevan Pillai's Campus 10,Sector 16,New Panvel,New Mumbai,Mumbai 410206 Contact PhoneNo. Res.0251-2472983 Mob.+919869786186 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Fri Nov 18 17:40:41 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 18 Nov 2011 17:40:41 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <20111107221227.802899F0E8@nail.towers.org.uk> <7EB93631-92B7-46AC-B50E-7E6C4215BB03@kohaaloha.com> Message-ID: <4EC68A89.2020500@biblibre.com> Le 12/11/2011 13:00, Jonathan Druart a ?crit : > Hi all ! > I have already developed a new version of updatedatabase. It's not > totally validated yet but in order to avoid parallels initiatives, let > me explain you what I have already done. I just took one hour with Jonathan, that shows me what he did. It's already live for many of our customers, and I was not aware of this... more communication needed inside BibLibre :\ So, here is how it works: * each patch is stored in a file in a specific directory. It can be .pl or .sql, both are adressed * there is a new page on admin page, that displays, for each patch: - if it has been applied or no - the result, either failed or OK. If failed, the error is also available. You can decide to "force OK" a given patch to ignore the problem On this page, you can also apply all pending patches and/or apply them one by one. This is completly "delinearized" Those 2 points are what we have built during hackfest, but there are some differences: * there is no more automatic control of update needed. That's intended: when you update, you'll now have to go to admin/update page. This sounds quite logic to me: it's delinearized, so checking what has been applied/must be applied on everypage will be much too CPU consuming * patch numbering = in this patch, patches still have a number, thus they can be applied in order. but, as it's not linear, they can also be applied in non-linear order How does it work internally ? A table is added, that contains all applied patches, with the logging of the result. It also contains a md5sum of the applied patches, to detect a duplicate number-but-not-the-same Jonathan has sent me the patch, I'll test & submit it soon. It relies on jquery datatable, so the patch will require bug 6836 to be applied first. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Fri Nov 18 19:35:35 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 18 Nov 2011 13:35:35 -0500 Subject: [Koha-devel] Request for Koha data for development Message-ID: A common problem among those of us who do development work on Koha is the lack of complete datasets for the development and testing of features. This is probably more of a problem for those of us who do not support a large variety of organizations running Koha. I would like to see some good, sanitized datasets available for development and testing. Several of us have plead for this for years. Just now, the lack of a good dataset including a sizable number of serials is preventing me from doing some testing and development on DataTables integration work which has been started by Biblibre. So, this is a request to all of you libraries out there with small, medium, and large datasets who would be willing to contribute sanitized data for development purposes, to do so. It would be a great way to give back to the community that has provided such a wonderful product with all of its attendant benefits. Kind Regards, Chris Nighswonger Koha 3.4/3.6 Release Maintainer From mjr at phonecoop.coop Fri Nov 18 20:14:36 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 18 Nov 2011 19:14:36 +0000 (GMT) Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> Message-ID: <20111118191436.C3B669F0E8@nail.towers.org.uk> "Marshall Breeding" > I do hope that all libraries using Koha will respond to the survey. The > survey forms are linked to each library's entry in the lib-web-cats > directory, so you will need to submit an entry if your library is not > already represented. A large number of libraries using Koha are already > represented, but I'm sure that there are many still missing. See: Hi Marshall. Usual requests. Please could you decouple the outdated one-to-one relationship between LMSes and support companies? And would you release (some subset of) the data as Open Access, Free and Open Source Software in a nice ready-to-analyse format this year? It would be great to see an Open survey which reflected the reality of the new LMS support landscape. Maybe one of the above in 2011, one in 2012? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From mjr at phonecoop.coop Fri Nov 18 20:18:42 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 18 Nov 2011 19:18:42 +0000 (GMT) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <8EBA2DFB-A25C-4B47-8950-809F4D0206B4@kohaaloha.com> Message-ID: <20111118191843.06D959F0E8@nail.towers.org.uk> Mason James > On 2011-11-18, at 5:43 AM, Paul Poulain wrote: > > Le 09/11/2011 18:54, Mason James a ?crit : > >> do other people agree? > > not at all ! Sometimes (not very often, but not rarely either), more > > complex calculations must be made, like for > > > > For example: > > depending on your marcflavour you do something or something else. > >> $DBversion = '3.05.00.017'; if (C4::Context->preference("Version") > >> < TransformToNum($DBversion)) { if > >> (C4::Context->preference("marcflavour") eq 'MARC21' || > >> C4::Context->preference("marcflavour") eq 'NORMARC'){ > > ... > > > > > So we must have a .pl file, not SQL The bit quoted above doesn't require a .pl file. SQL has conditionals. > yes, yes... a good point Paul! > > i think if we want to do Ian's suggested check/apply/roll-back idea > for DB changes, we will indeed need to use .pl files not .sql files > for new patches I'm not sure about that either. Surely it could be done by setting SQL session variables in the updatedatabase that loads the sql file and conditionals in the SQL? But anyway, what about supporting both? If I'm wrong and .sql has to be trivially converted to .pl one day, it's not that awful. If I'm right and we can eventually replace all .pl with .sql, that makes updating a lot cleaner and safer. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From marshall.breeding at librarytechnology.org Fri Nov 18 20:56:19 2011 From: marshall.breeding at librarytechnology.org (Marshall Breeding) Date: Fri, 18 Nov 2011 13:56:19 -0600 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: <20111118191436.C3B669F0E8@nail.towers.org.uk> References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> Message-ID: <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> MJ, The survey needs to cover the automation scenarios in place in most libraries. Within any given niche, there may be some quirks, but almost all ILS implementations contract for support only from a single organization. In rare cases, there may be additional contracts to other vendors for development tasks, but the question focuses on support. I don't want to design the survey around edge cases that rarely occur. In this year's survey, I've added an additional factor for libraries to indicate whether they receive support directly from their "ILS vendor" or through an intermediary such as through another library or consortium. This gives me a way to analyze the results in a way that accommodates the situation in many consortia where the first-line support happens locally with only unresolved issues being directed to the contracted support organization. Libraries responding to the survey can always provide additional information in the comments field to explain any special circumstances, and often they do. I publish summaries of the survey responses in a way that protects the confidentiality of the responders. I do not plan to release the data beyond that. While it may be possible to scrub and normalize the data in a way that it could be shared publicly, it would take more effort beyond what I already put in to the survey. You are the only one that I recall that has asked for this in the five years that I have been running this survey. Best regards, -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding -----Original Message----- From: MJ Ray [mailto:mjr at phonecoop.coop] Sent: Friday, November 18, 2011 1:15 PM To: koha-devel at lists.koha-community.org Cc: marshall.breeding at librarytechnology.org Subject: Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding) "Marshall Breeding" > I do hope that all libraries using Koha will respond to the survey. > The survey forms are linked to each library's entry in the > lib-web-cats directory, so you will need to submit an entry if your > library is not already represented. A large number of libraries using > Koha are already represented, but I'm sure that there are many still missing. See: Hi Marshall. Usual requests. Please could you decouple the outdated one-to-one relationship between LMSes and support companies? And would you release (some subset of) the data as Open Access, Free and Open Source Software in a nice ready-to-analyse format this year? It would be great to see an Open survey which reflected the reality of the new LMS support landscape. Maybe one of the above in 2011, one in 2012? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From ian.walls at bywatersolutions.com Fri Nov 18 22:09:41 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Fri, 18 Nov 2011 16:09:41 -0500 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: Marshall, It's not so much an 'edge-case' as a generalization. Product and Company are two separate things to track with an N to M relationship. Any given company can support multiple products (as has been true for many years) and a product can be supported by multiple companies (this tends to only be true of open source products, but not necessarily; a company could have a license with another to support their proprietary system). I'd be happy to help make the necessary structural changes to the system to support this generalization; I know time is tight, and it's probably more important to me right now than you. But given the trends in open source ILS systems (more people adopting, very few leaving), this is only going to become more and more common as time goes by. Cheers, -Ian On Fri, Nov 18, 2011 at 2:56 PM, Marshall Breeding < marshall.breeding at librarytechnology.org> wrote: > MJ, > > The survey needs to cover the automation scenarios in place in most > libraries. Within any given niche, there may be some quirks, but almost > all > ILS implementations contract for support only from a single organization. > In rare cases, there may be additional contracts to other vendors for > development tasks, but the question focuses on support. I don't want to > design the survey around edge cases that rarely occur. > > In this year's survey, I've added an additional factor for libraries to > indicate whether they receive support directly from their "ILS vendor" or > through an intermediary such as through another library or consortium. > This > gives me a way to analyze the results in a way that accommodates the > situation in many consortia where the first-line support happens locally > with only unresolved issues being directed to the contracted support > organization. > > Libraries responding to the survey can always provide additional > information > in the comments field to explain any special circumstances, and often they > do. > > I publish summaries of the survey responses in a way that protects the > confidentiality of the responders. I do not plan to release the data > beyond > that. While it may be possible to scrub and normalize the data in a way > that it could be shared publicly, it would take more effort beyond what I > already put in to the survey. You are the only one that I recall that has > asked for this in the five years that I have been running this survey. > > Best regards, > > -marshall > > Marshall Breeding > Editor, Library Technology Guides > http://www.librarytechnology.org > marshall.breeding at librarytechnology.org > http://twitter.com/mbreeding > > > > > > > -----Original Message----- > From: MJ Ray [mailto:mjr at phonecoop.coop] > Sent: Friday, November 18, 2011 1:15 PM > To: koha-devel at lists.koha-community.org > Cc: marshall.breeding at librarytechnology.org > Subject: Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding) > > "Marshall Breeding" > > I do hope that all libraries using Koha will respond to the survey. > > The survey forms are linked to each library's entry in the > > lib-web-cats directory, so you will need to submit an entry if your > > library is not already represented. A large number of libraries using > > Koha are already represented, but I'm sure that there are many still > missing. See: > > Hi Marshall. Usual requests. Please could you decouple the outdated > one-to-one relationship between LMSes and support companies? > > And would you release (some subset of) the data as Open Access, Free and > Open Source Software in a nice ready-to-analyse format this year? > > It would be great to see an Open survey which reflected the reality of the > new LMS support landscape. Maybe one of the above in 2011, one in 2012? > > Thanks, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From swills at beyond-print.com Fri Nov 18 22:27:49 2011 From: swills at beyond-print.com (Stephen Wills) Date: Fri, 18 Nov 2011 16:27:49 -0500 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: <2A45CD09-6EEE-417F-B833-27B8E2FA2070@beyond-print.com> It seems to me that the tiered support model for software products in far from a new thing. The manufacturer puts a product into the marketplace through a distribution chain. At each stop on the chain, Manufacturer, wholesaler, retailer, in-house support group, and end user there are some levels of support provided. The thing I keep seeing folks get confused about is the way the transaction happens in the open source community. Whether you "buy" Oracle or PostgreSQL as your database, there are plenty of suppliers and support tiers for each one. My price to consult on the admin for either one is the same. I suspect that while it's true that at any given moment in time, a given ILS implementation has a primary support resource, the more choices that become availablewill yield higher turnover, more specialization and/ or better quality of service. Let's hope for a bit of all three? Stev3 Wills Free Lance Nerd. On Nov 18, 2011, at 4:09 PM, Ian Walls wrote: > Marshall, > > > It's not so much an 'edge-case' as a generalization. Product and > Company are two separate things to track with an N to M > relationship. Any given company can support multiple products (as > has been true for many years) and a product can be supported by > multiple companies (this tends to only be true of open source > products, but not necessarily; a company could have a license with > another to support their proprietary system). > > I'd be happy to help make the necessary structural changes to the > system to support this generalization; I know time is tight, and > it's probably more important to me right now than you. But given > the trends in open source ILS systems (more people adopting, very > few leaving), this is only going to become more and more common as > time goes by. > > Cheers, > > > -Ian > > On Fri, Nov 18, 2011 at 2:56 PM, Marshall Breeding > wrote: > MJ, > > The survey needs to cover the automation scenarios in place in most > libraries. Within any given niche, there may be some quirks, but > almost all > ILS implementations contract for support only from a single > organization. > In rare cases, there may be additional contracts to other vendors for > development tasks, but the question focuses on support. I don't want > to > design the survey around edge cases that rarely occur. > > In this year's survey, I've added an additional factor for libraries > to > indicate whether they receive support directly from their "ILS > vendor" or > through an intermediary such as through another library or > consortium. This > gives me a way to analyze the results in a way that accommodates the > situation in many consortia where the first-line support happens > locally > with only unresolved issues being directed to the contracted support > organization. > > Libraries responding to the survey can always provide additional > information > in the comments field to explain any special circumstances, and > often they > do. > > I publish summaries of the survey responses in a way that protects the > confidentiality of the responders. I do not plan to release the > data beyond > that. While it may be possible to scrub and normalize the data in a > way > that it could be shared publicly, it would take more effort beyond > what I > already put in to the survey. You are the only one that I recall > that has > asked for this in the five years that I have been running this survey. > > Best regards, > > -marshall > > Marshall Breeding > Editor, Library Technology Guides > http://www.librarytechnology.org > marshall.breeding at librarytechnology.org > http://twitter.com/mbreeding > > > > > > > -----Original Message----- > From: MJ Ray [mailto:mjr at phonecoop.coop] > Sent: Friday, November 18, 2011 1:15 PM > To: koha-devel at lists.koha-community.org > Cc: marshall.breeding at librarytechnology.org > Subject: Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding) > > "Marshall Breeding" > > I do hope that all libraries using Koha will respond to the survey. > > The survey forms are linked to each library's entry in the > > lib-web-cats directory, so you will need to submit an entry if your > > library is not already represented. A large number of libraries > using > > Koha are already represented, but I'm sure that there are many still > missing. See: > > Hi Marshall. Usual requests. Please could you decouple the outdated > one-to-one relationship between LMSes and support companies? > > And would you release (some subset of) the data as Open Access, Free > and > Open Source Software in a nice ready-to-analyse format this year? > > It would be great to see an Open survey which reflected the reality > of the > new LMS support landscape. Maybe one of the above in 2011, one in > 2012? > > Thanks, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit > co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former > lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > > _______________________________________________ > 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/ > > > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal > _______________________________________________ > 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 paul.a at aandc.org Fri Nov 18 22:55:58 2011 From: paul.a at aandc.org (Paul) Date: Fri, 18 Nov 2011 16:55:58 -0500 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> References: <20111118191436.C3B669F0E8@nail.towers.org.uk> <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> Message-ID: <5.2.1.1.2.20111118165323.0764b5c0@localhost> At 01:56 PM 11/18/2011 -0600, Marshall Breeding wrote: [snip] >Libraries responding to the survey can always provide additional information >in the comments field to explain any special circumstances, and often they >do. I'm glad there was a "comments" field, as I was only able to answer two of the questions (ID 61961) - anyway it's done. Best - Paul From marshall.breeding at Vanderbilt.Edu Fri Nov 18 23:06:57 2011 From: marshall.breeding at Vanderbilt.Edu (Breeding, Marshall) Date: Fri, 18 Nov 2011 16:06:57 -0600 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: Ian, So here is the response I sent to MJ off-list: ?I don't have time to dig out an irc client, but I do regularly read the logs at http://stats.workbuffer.org/irclog/koha/ I didn't say that open source support is an edge case. Of course it isn't, and I as much as anyone appreciate the enormous impact of open source in the library automation space. What I said is that having multiple support contracts is rare. If you could provide evidence to the contrary I would definitely be interested.? This year?s survey does, in fact, track the support company separate from the support vendor: [cid:image001.png at 01CCA60B.AE09CA30] The initial value is supplied through a table look-up, but responders can adjust the venders if needed. This approach accommodates for the common situation where many different firms provide support services for the same software. What it doesn?t do is account for a given library working with multiple support vendors, which I believe is the rare case. -marshall From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Ian Walls Sent: Friday, November 18, 2011 3:10 PM To: Marshall Breeding Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding) Marshall, It's not so much an 'edge-case' as a generalization. Product and Company are two separate things to track with an N to M relationship. Any given company can support multiple products (as has been true for many years) and a product can be supported by multiple companies (this tends to only be true of open source products, but not necessarily; a company could have a license with another to support their proprietary system). I'd be happy to help make the necessary structural changes to the system to support this generalization; I know time is tight, and it's probably more important to me right now than you. But given the trends in open source ILS systems (more people adopting, very few leaving), this is only going to become more and more common as time goes by. Cheers, -Ian On Fri, Nov 18, 2011 at 2:56 PM, Marshall Breeding > wrote: MJ, The survey needs to cover the automation scenarios in place in most libraries. Within any given niche, there may be some quirks, but almost all ILS implementations contract for support only from a single organization. In rare cases, there may be additional contracts to other vendors for development tasks, but the question focuses on support. I don't want to design the survey around edge cases that rarely occur. In this year's survey, I've added an additional factor for libraries to indicate whether they receive support directly from their "ILS vendor" or through an intermediary such as through another library or consortium. This gives me a way to analyze the results in a way that accommodates the situation in many consortia where the first-line support happens locally with only unresolved issues being directed to the contracted support organization. Libraries responding to the survey can always provide additional information in the comments field to explain any special circumstances, and often they do. I publish summaries of the survey responses in a way that protects the confidentiality of the responders. I do not plan to release the data beyond that. While it may be possible to scrub and normalize the data in a way that it could be shared publicly, it would take more effort beyond what I already put in to the survey. You are the only one that I recall that has asked for this in the five years that I have been running this survey. Best regards, -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding -----Original Message----- From: MJ Ray [mailto:mjr at phonecoop.coop] Sent: Friday, November 18, 2011 1:15 PM To: koha-devel at lists.koha-community.org Cc: marshall.breeding at librarytechnology.org Subject: Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding) "Marshall Breeding" > > I do hope that all libraries using Koha will respond to the survey. > The survey forms are linked to each library's entry in the > lib-web-cats directory, so you will need to submit an entry if your > library is not already represented. A large number of libraries using > Koha are already represented, but I'm sure that there are many still missing. See: Hi Marshall. Usual requests. Please could you decouple the outdated one-to-one relationship between LMSes and support companies? And would you release (some subset of) the data as Open Access, Free and Open Source Software in a nice ready-to-analyse format this year? It would be great to see an Open survey which reflected the reality of the new LMS support landscape. Maybe one of the above in 2011, one in 2012? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ _______________________________________________ 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/ -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4573 bytes Desc: image001.png URL: From mjr at phonecoop.coop Fri Nov 18 23:41:29 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 18 Nov 2011 22:41:29 +0000 (GMT) Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: <20111118224129.391B59F0E8@nail.towers.org.uk> "Marshall Breeding" > The survey needs to cover the automation scenarios in place in most > libraries. Within any given niche, there may be some quirks, but almost all > ILS implementations contract for support only from a single organization. > In rare cases, there may be additional contracts to other vendors for > development tasks, but the question focuses on support. I don't want to > design the survey around edge cases that rarely occur. I've yet to do a development contract that doesn't include any support. Is there any evidence that multi-supplier support rarely occurs in free and open source software LMSes? The perceptions survey doesn't cope with other scenarios, so it can't see them. What other LMS research is out there? [...stuff about consortia and then...] > Libraries responding to the survey can always provide additional information > in the comments field to explain any special circumstances, and often they > do. And does it inspire change in the survey? > I publish summaries of the survey responses in a way that protects the > confidentiality of the responders. I do not plan to release the data beyond > that. While it may be possible to scrub and normalize the data in a way > that it could be shared publicly, it would take more effort beyond what I > already put in to the survey. So invite some help? > You are the only one that I recall that has > asked for this in the five years that I have been running this survey. Would it really change your mind if there were multiple requests for open data? Out of respect for your time, I haven't deliberately publicised this idea outside the Koha community, but if it'd change things... Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From bob at calyx.net.au Sat Nov 19 01:12:26 2011 From: bob at calyx.net.au (Bob Birchall) Date: Sat, 19 Nov 2011 11:12:26 +1100 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: <4EC6F46A.9030201@calyx.net.au> On 19/11/11 09:06, Breeding, Marshall wrote: > > This approach accommodates for the common situation where many > different firms provide support services for the same software. What > it doesn?t do is account for a given library working with multiple > support vendors, which I believe is the rare case. > > -marshall > We are involved in one situation where an overseas Koha hosting provider hosts the library and we provide local training and support. We have had another similar situation in the past, but we now host that library. These may or may not be isolated examples. Bob Birchall Calyx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Sat Nov 19 15:21:09 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Sat, 19 Nov 2011 09:21:09 -0500 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: Marshall, Ah, I think I may have misunderstood. I was interested in keeping product and vendor separate, which it looks like you've done (but with ergonomic fix to assume the common 1-1 relationship at first selection). The case of having multiple vendors or multiple products would introduce a much larger change in system complexity (going from 1 to n always does), and I can't cite many examples where it'd be relevant. There are cases were some of our partners have contracted with others for developments, while we do the primary support, but this is pretty rare for us, and I'm not sure if it'd even be within the scope of what you're trying to track with this survey. Thanks for clarifying. I look forward to seeing the results of this year's survey! -Ian 2011/11/18 Breeding, Marshall > Ian,**** > > ** ** > > So here is the response I sent to MJ off-list:**** > > ** ** > > ?I don't have time to dig out an irc client, but I do regularly read the > logs at http://stats.workbuffer.org/irclog/koha/**** > > ** ** > > I didn't say that open source support is an edge case. Of course it > isn't, and I as much as anyone appreciate the enormous impact of open > source in the library automation space. What I said is that having > multiple support contracts is rare. If you could provide evidence to the > contrary I would definitely be interested.?**** > > ** ** > > This year?s survey does, in fact, track the support company separate from > the support vendor:**** > > **** > > ** ** > > The initial value is supplied through a table look-up, but responders can > adjust the venders if needed.**** > > ** ** > > This approach accommodates for the common situation where many different > firms provide support services for the same software. What it doesn?t do > is account for a given library working with multiple support vendors, which > I believe is the rare case.**** > > ** ** > > -marshall**** > > ** ** > > ** ** > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Ian Walls > *Sent:* Friday, November 18, 2011 3:10 PM > *To:* Marshall Breeding > *Cc:* koha-devel at lists.koha-community.org > > *Subject:* Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding)**** > > ** ** > > Marshall, > > > It's not so much an 'edge-case' as a generalization. Product and Company > are two separate things to track with an N to M relationship. Any given > company can support multiple products (as has been true for many years) and > a product can be supported by multiple companies (this tends to only be > true of open source products, but not necessarily; a company could have a > license with another to support their proprietary system). > > I'd be happy to help make the necessary structural changes to the system > to support this generalization; I know time is tight, and it's probably > more important to me right now than you. But given the trends in open > source ILS systems (more people adopting, very few leaving), this is only > going to become more and more common as time goes by. > > Cheers, > > > -Ian**** > > On Fri, Nov 18, 2011 at 2:56 PM, Marshall Breeding < > marshall.breeding at librarytechnology.org> wrote:**** > > MJ, > > The survey needs to cover the automation scenarios in place in most > libraries. Within any given niche, there may be some quirks, but almost > all > ILS implementations contract for support only from a single organization. > In rare cases, there may be additional contracts to other vendors for > development tasks, but the question focuses on support. I don't want to > design the survey around edge cases that rarely occur. > > In this year's survey, I've added an additional factor for libraries to > indicate whether they receive support directly from their "ILS vendor" or > through an intermediary such as through another library or consortium. > This > gives me a way to analyze the results in a way that accommodates the > situation in many consortia where the first-line support happens locally > with only unresolved issues being directed to the contracted support > organization. > > Libraries responding to the survey can always provide additional > information > in the comments field to explain any special circumstances, and often they > do. > > I publish summaries of the survey responses in a way that protects the > confidentiality of the responders. I do not plan to release the data > beyond > that. While it may be possible to scrub and normalize the data in a way > that it could be shared publicly, it would take more effort beyond what I > already put in to the survey. You are the only one that I recall that has > asked for this in the five years that I have been running this survey.**** > > > Best regards, > > -marshall > > Marshall Breeding > Editor, Library Technology Guides > http://www.librarytechnology.org > marshall.breeding at librarytechnology.org > http://twitter.com/mbreeding > > > > > > **** > > -----Original Message----- > From: MJ Ray [mailto:mjr at phonecoop.coop] > Sent: Friday, November 18, 2011 1:15 PM > To: koha-devel at lists.koha-community.org > Cc: marshall.breeding at librarytechnology.org > Subject: Re: [Koha-devel] ILS Perceptions survey (Marshall Breeding) > > "Marshall Breeding" > > I do hope that all libraries using Koha will respond to the survey. > > The survey forms are linked to each library's entry in the > > lib-web-cats directory, so you will need to submit an entry if your > > library is not already represented. A large number of libraries using > > Koha are already represented, but I'm sure that there are many still > missing. See: > > Hi Marshall. Usual requests. Please could you decouple the outdated > one-to-one relationship between LMSes and support companies? > > And would you release (some subset of) the data as Open Access, Free and > Open Source Software in a nice ready-to-analyse format this year? > > It would be great to see an Open survey which reflected the reality of the > new LMS support landscape. Maybe one of the above in 2011, one in 2012? > > Thanks, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > > _______________________________________________ > 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/**** > > > > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal**** > > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Sat Nov 19 22:58:36 2011 From: mtj at kohaaloha.com (Mason James) Date: Sun, 20 Nov 2011 10:58:36 +1300 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: <20111118224129.391B59F0E8@nail.towers.org.uk> References: <20111118224129.391B59F0E8@nail.towers.org.uk> Message-ID: On 2011-11-19, at 11:41 AM, MJ Ray wrote: > "Marshall Breeding" > >> I publish summaries of the survey responses in a way that protects the >> confidentiality of the responders. I do not plan to release the data beyond >> that. While it may be possible to scrub and normalize the data in a way >> that it could be shared publicly, it would take more effort beyond what I >> already put in to the survey. > > So invite some help? indeed.. i would be willing to help automate that 'scrub and normalize' process an anonymized, publicly available version of the lib-web-cats dataset would be profoundly helpful towards the promotion and advocacy of free/open-source library systems cheers, Mason -- KohaAloha, NZ -------------- 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 mtj at kohaaloha.com Sun Nov 20 01:09:32 2011 From: mtj at kohaaloha.com (Mason James) Date: Sun, 20 Nov 2011 13:09:32 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <20111118191843.06D959F0E8@nail.towers.org.uk> References: <20111118191843.06D959F0E8@nail.towers.org.uk> Message-ID: On 2011-11-19, at 8:18 AM, MJ Ray wrote: > Mason James >> >> i think if we want to do Ian's suggested check/apply/roll-back idea >> for DB changes, we will indeed need to use .pl files not .sql files >> for new patches > > I'm not sure about that either. Surely it could be done by setting > SQL session variables in the updatedatabase that loads the sql file > and conditionals in the SQL? > > But anyway, what about supporting both? If I'm wrong and .sql has to > be trivially converted to .pl one day, it's not that awful. If I'm > right and we can eventually replace all .pl with .sql, that makes > updating a lot cleaner and safer. > > Regards, > -- > MJ Ray ok, i can easily imagine future situations where .sql patch files alone just *won't* work for upgrades (lets ignore Paul's previous example) the situation i am imagining is where a patch requires a database change to made via say... an internal Koha subroutine(). (like an update made to all bib or item records, via calls to the ModBiblio() or ModItem() subroutines) now.. how could an .SQL only solution achieve this? - its impossible, right? - using .pl patches, with a *combination* of perl and sql, would allow us the best of both options - using .sql patches alone, means a patch won't be able to use any internal Koha subroutines? i realize i was originally keen on an .sql solution... but after more thought, i believe an .sql solution will be too limited for some upgrade tasks using perl, we wont *ever* bump into this potential limitation. do i have a valid point here? cheers, Mason -------------- 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 Nov 21 08:49:14 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 21 Nov 2011 08:49:14 +0100 Subject: [Koha-devel] ILS Perceptions survey (Marshall Breeding) In-Reply-To: References: <129001cca460$0a7e5950$1f7b0bf0$@librarytechnology.org> <20111118191436.C3B669F0E8@nail.towers.org.uk> <005501cca62c$2413f000$6c3bd000$@librarytechnology.org> Message-ID: <4ECA027A.4010307@biblibre.com> Le 19/11/2011 15:21, Ian Walls a ?crit : > Marshall, > > > Ah, I think I may have misunderstood. I was interested in keeping > product and vendor separate, which it looks like you've done (but with > ergonomic fix to assume the common 1-1 relationship at first > selection). The case of having multiple vendors or multiple products > would introduce a much larger change in system complexity (going from 1 > to n always does), and I can't cite many examples where it'd be > relevant. +1 And I think it's very rare to have 2 vendors *at the same time* doing training/migration with X, then, having Y for support is uncommon but sometimes happend. What happend more frequently is to have some task sub-contracted by X to Y. For example, I know for sure we sub-contract sometimes development of new features to catalyst, and I'm almost sure we are not the only ones ;-) -- 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 Nov 21 08:52:36 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 21 Nov 2011 08:52:36 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <20111118191843.06D959F0E8@nail.towers.org.uk> Message-ID: <4ECA0344.7030103@biblibre.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 20/11/2011 01:09, Mason James a ?crit : > now.. how could an .SQL only solution achieve this? - its > impossible, right? > > - using .pl patches, with a *combination* of perl and sql, would > allow us the best of both options - using .sql patches alone, means > a patch won't be able to use any internal Koha subroutines? Ian (& all): see my mail about what Jonathan has already written and that I should submit quickly (today ?) : he deals with both .sql and .pl, so we get the best of both worlds !!! (the updater detect the extension and work accordingly) HTH - -- 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/ iQEcBAEBAgAGBQJOygM/AAoJEK81SonuhyGo/G8H/3qJevFE40LXY9ei20toW720 TIMl8G2VSSFfIidSWDJW5B8z1EcNX2QUTMsWr0w5OIvpNgxTrWzcxBOox1DCfM4t W5ZhN39L0H4LuEmzIO/8Anmlsw4q2jDyUzFyJJcJf3dcag99tJDM1Pl1PP/nXG+b EbEkox73K7EEx1PNHsHea6VdcpZYThs+0OKRGsXdRFTOlYEMj4Im6lb/hUi3Q3P9 1rgrM3Y2EtAZ81z+1opkooIaVyjwCNw+cjNJUtZhblBMX6w7MtFkir2ne7oegCh4 CjiqQ++PaP1AT5Z7jz2cwvD6yKEVdoHG3JXQE3LaH4sFSDZaFLbKp9I9kNgutEk= =fUJh -----END PGP SIGNATURE----- From cnighswonger at foundations.edu Mon Nov 21 21:12:07 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 21 Nov 2011 15:12:07 -0500 Subject: [Koha-devel] Koha 3.6.x String Freeze Announcement Message-ID: Ok. I'm batting 0 for 2 on making regular maintenance releases for the past two months. However this time it was due to medical issues. So... The 3.6.x branch is entering a string freeze as of the date/time stamp of this email. Given the holiday in the USA this weekend, I will do the release on Wed. 30 November. Thanks for all of the good work! Kind Regards, Chris Koha 3.4.x/3.6.x Release Maintainer From cnighswonger at foundations.edu Mon Nov 21 21:13:46 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 21 Nov 2011 15:13:46 -0500 Subject: [Koha-devel] Koha 3.4.x String Freeze Announcement Message-ID: Now for the 3.4.x branch: The 3.4.x branch will enter a string freeze on Wed. 30 November. Koha 3.4.7 will release on 7 Dec. Kind Regards, Chris Koha 3.4.x/3.6.x Release Maintainer From jransom at library.org.nz Mon Nov 21 22:31:52 2011 From: jransom at library.org.nz (Joann Ransom) Date: Tue, 22 Nov 2011 10:31:52 +1300 Subject: [Koha-devel] Plea for help from Horowhenua Library Trust re: Koha Message-ID: As I am sure most of you are aware, Horowhenua Library Trust is the birth place of Koha and the longest serving member of the Koha community. Back in 1999 when we were working on Koha, the idea that 12 years later we would be having to write an email like this never crossed our minds. It is with tremendous sadness that we must write this plea for help to you, the other members of the Koha community. The situation we find ourselves in, is that after over a year of battling against it, PTFS/Liblime have managed to have their application for a Trademark on Koha in New Zealand accepted. We now have 3 months to object, but to do so involves lawyers and money. We are a small semi rural Library in New Zealand and have no cash spare in our operational budget to afford this, but we do feel it is something we must fight. For the library that invented Koha to now have to have a legal battle to prevent a US company trademarking the word in NZ seems bizarre, but it is at this point that we find ourselves. So, we ask you, the users and developers of Koha, from the birth place of Koha, please if you can help in anyway, let us know. Regards, Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abesottedphoenix at yahoo.com Mon Nov 21 22:58:38 2011 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Mon, 21 Nov 2011 13:58:38 -0800 (PST) Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: <1321912718.93418.YahooMailNeo@web114706.mail.gq1.yahoo.com> Salvete! >The situation we find ourselves in, is that after over a year of battling against it, PTFS/Liblime have managed to have their application for a Trademark on Koha in New Zealand accepted. We now have 3 months to object, but to do so involves lawyers and money. We are a small semi rural Library in New Zealand and have no cash spare in our operational budget to afford this, but we do feel it is something we must fight. > ??? I concur. If one doesn't stand up to the schoolyard bully, they simply keep stealing lunch money. Having poor customer service and a vanishing clientele, PTFS are clearly at the stage where they needs resort to domain camping and now trademark on a generic term long utilised in the public interest. May Justice let whichever Court ultimately hears this do so with extreme skepticism. >For the library that invented Koha to now have to have a legal battle to prevent a US company trademarking the word in NZ seems bizarre, but it is at this point that we find ourselves. > >So, we ask you, the users and developers of Koha, from the birth place of Koha, please if you can help in anyway, let us know. ??? Let us know where the paypal page is set up for this. Hardly the sort of chicanery that needs happen during a building project. Kia kaha, Brooke From lrea at nekls.org Mon Nov 21 23:55:12 2011 From: lrea at nekls.org (Liz Rea) Date: Mon, 21 Nov 2011 16:55:12 -0600 Subject: [Koha-devel] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: It is so sad to see the gift you gave us all fall into unfriendly hands. Do please let us know when the kitty is opened up for donations. Liz Rea lrea at nekls.org -------------- next part -------------- A non-text attachment was scrubbed... Name: email_signature.jpeg Type: image/jpeg Size: 4862 bytes Desc: not available URL: -------------- next part -------------- On Nov 21, 2011, at 3:31 PM, Joann Ransom wrote: > As I am sure most of you are aware, Horowhenua Library Trust is the birth place of Koha and the longest serving member of the Koha community. Back in 1999 when we were working on Koha, the idea that 12 years later we would be having to write an email like this never crossed our minds. It is with tremendous sadness that we must write this plea for help to you, the other members of the Koha community. > > The situation we find ourselves in, is that after over a year of battling against it, PTFS/Liblime have managed to have their application for a Trademark on Koha in New Zealand accepted. We now have 3 months to object, but to do so involves lawyers and money. We are a small semi rural Library in New Zealand and have no cash spare in our operational budget to afford this, but we do feel it is something we must fight. > > For the library that invented Koha to now have to have a legal battle to prevent a US company trademarking the word in NZ seems bizarre, but it is at this point that we find ourselves. > > So, we ask you, the users and developers of Koha, from the birth place of Koha, please if you can help in anyway, let us know. > > Regards, > > Jo. > > -- > Joann Ransom RLIANZA > Head of Libraries, > Horowhenua Library Trust. > > _______________________________________________ > 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.nighswonger at gmail.com Tue Nov 22 00:09:51 2011 From: chris.nighswonger at gmail.com (Christopher Nighswonger) Date: Mon, 21 Nov 2011 18:09:51 -0500 Subject: [Koha-devel] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: By all means setup a donations page... quick! :-) Kind Regards, Chris 2011/11/21 Liz Rea > It is so sad to see the gift you gave us all fall into unfriendly hands. > > Do please let us know when the kitty is opened up for donations. > > Liz Rea > lrea at nekls.org > > > > > On Nov 21, 2011, at 3:31 PM, Joann Ransom wrote: > > > As I am sure most of you are aware, Horowhenua Library Trust is the > birth place of Koha and the longest serving member of the Koha community. > Back in 1999 when we were working on Koha, the idea that 12 years later we > would be having to write an email like this never crossed our minds. It is > with tremendous sadness that we must write this plea for help to you, the > other members of the Koha community. > > > > The situation we find ourselves in, is that after over a year of > battling against it, PTFS/Liblime have managed to have their application > for a Trademark on Koha in New Zealand accepted. We now have 3 months to > object, but to do so involves lawyers and money. We are a small semi rural > Library in New Zealand and have no cash spare in our operational budget to > afford this, but we do feel it is something we must fight. > > > > For the library that invented Koha to now have to have a legal battle to > prevent a US company trademarking the word in NZ seems bizarre, but it is > at this point that we find ourselves. > > > > So, we ask you, the users and developers of Koha, from the birth place > of Koha, please if you can help in anyway, let us know. > > > > Regards, > > > > Jo. > > > > -- > > Joann Ransom RLIANZA > > Head of Libraries, > > Horowhenua Library Trust. > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ > > git : http://git.koha-community.org/ > > bugs : http://bugs.koha-community.org/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jransom at library.org.nz Tue Nov 22 00:21:59 2011 From: jransom at library.org.nz (Joann Ransom) Date: Tue, 22 Nov 2011 12:21:59 +1300 Subject: [Koha-devel] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: Hi everyone, Thank you so much for your speedy and supportive replies ... I'm feeling a little less despairing now :) I have set up a PayPal account for gathering funds towards mounting a legal challenge. It is a separate account from the HLT operating accounts and I am very happy to give a community representative access to the records etc. So here it is: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FQ6JH3L48LV5Y And thanks :) Cheers Jo. On 22 November 2011 12:09, Christopher Nighswonger < chris.nighswonger at gmail.com> wrote: > By all means setup a donations page... quick! :-) > > Kind Regards, > Chris > > > 2011/11/21 Liz Rea > >> It is so sad to see the gift you gave us all fall into unfriendly hands. >> >> Do please let us know when the kitty is opened up for donations. >> >> Liz Rea >> lrea at nekls.org >> >> >> >> >> On Nov 21, 2011, at 3:31 PM, Joann Ransom wrote: >> >> > As I am sure most of you are aware, Horowhenua Library Trust is the >> birth place of Koha and the longest serving member of the Koha community. >> Back in 1999 when we were working on Koha, the idea that 12 years later we >> would be having to write an email like this never crossed our minds. It is >> with tremendous sadness that we must write this plea for help to you, the >> other members of the Koha community. >> > >> > The situation we find ourselves in, is that after over a year of >> battling against it, PTFS/Liblime have managed to have their application >> for a Trademark on Koha in New Zealand accepted. We now have 3 months to >> object, but to do so involves lawyers and money. We are a small semi rural >> Library in New Zealand and have no cash spare in our operational budget to >> afford this, but we do feel it is something we must fight. >> > >> > For the library that invented Koha to now have to have a legal battle >> to prevent a US company trademarking the word in NZ seems bizarre, but it >> is at this point that we find ourselves. >> > >> > So, we ask you, the users and developers of Koha, from the birth place >> of Koha, please if you can help in anyway, let us know. >> > >> > Regards, >> > >> > Jo. >> > >> > -- >> > Joann Ransom RLIANZA >> > Head of Libraries, >> > Horowhenua Library Trust. >> > >> > _______________________________________________ >> > Koha-devel mailing list >> > Koha-devel at lists.koha-community.org >> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> > website : http://www.koha-community.org/ >> > git : http://git.koha-community.org/ >> > bugs : http://bugs.koha-community.org/ >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Tue Nov 22 02:09:16 2011 From: nengard at gmail.com (Nicole Engard) Date: Mon, 21 Nov 2011 20:09:16 -0500 Subject: [Koha-devel] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: Joann, In addition to money, if you think a petition signed by members of the community from around the world will help with your appeal then maybe there is a way we can all e-sign one for you. I'm so sorry you're having to deal with this :( Nicole 2011/11/21 Joann Ransom > Hi everyone, > > Thank you so much for your speedy and supportive replies ... I'm feeling a > little less despairing now :) > > I have set up a PayPal account for gathering funds towards mounting a > legal challenge. It is a separate account from the HLT > operating accounts and I am very happy to give a community representative > access to the records etc. > > So here it is: > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FQ6JH3L48LV5Y > > And thanks :) > > Cheers Jo. > > > On 22 November 2011 12:09, Christopher Nighswonger < > chris.nighswonger at gmail.com> wrote: > >> By all means setup a donations page... quick! :-) >> >> Kind Regards, >> Chris >> >> >> 2011/11/21 Liz Rea >> >>> It is so sad to see the gift you gave us all fall into unfriendly hands. >>> >>> Do please let us know when the kitty is opened up for donations. >>> >>> Liz Rea >>> lrea at nekls.org >>> >>> >>> >>> >>> On Nov 21, 2011, at 3:31 PM, Joann Ransom wrote: >>> >>> > As I am sure most of you are aware, Horowhenua Library Trust is the >>> birth place of Koha and the longest serving member of the Koha community. >>> Back in 1999 when we were working on Koha, the idea that 12 years later we >>> would be having to write an email like this never crossed our minds. It is >>> with tremendous sadness that we must write this plea for help to you, the >>> other members of the Koha community. >>> > >>> > The situation we find ourselves in, is that after over a year of >>> battling against it, PTFS/Liblime have managed to have their application >>> for a Trademark on Koha in New Zealand accepted. We now have 3 months to >>> object, but to do so involves lawyers and money. We are a small semi rural >>> Library in New Zealand and have no cash spare in our operational budget to >>> afford this, but we do feel it is something we must fight. >>> > >>> > For the library that invented Koha to now have to have a legal battle >>> to prevent a US company trademarking the word in NZ seems bizarre, but it >>> is at this point that we find ourselves. >>> > >>> > So, we ask you, the users and developers of Koha, from the birth place >>> of Koha, please if you can help in anyway, let us know. >>> > >>> > Regards, >>> > >>> > Jo. >>> > >>> > -- >>> > Joann Ransom RLIANZA >>> > Head of Libraries, >>> > Horowhenua Library Trust. >>> > >>> > _______________________________________________ >>> > Koha-devel mailing list >>> > Koha-devel at lists.koha-community.org >>> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> > website : http://www.koha-community.org/ >>> > git : http://git.koha-community.org/ >>> > bugs : http://bugs.koha-community.org/ >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> >> > > > -- > Joann Ransom RLIANZA > Head of Libraries, > Horowhenua Library Trust. > > > _______________________________________________ > 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 sandeep.bhavsar at gmail.com Tue Nov 22 08:22:40 2011 From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR) Date: Tue, 22 Nov 2011 12:52:40 +0530 Subject: [Koha-devel] Information Required Message-ID: Respected All I would like to integrate EBSCO, Open access databases, through pazpar2 in Koha. Kindly guide me for the documentation. Step by step screenshots or video of the process in lecture form will be preferred. -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar at gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rijal.it at gmail.com Tue Nov 22 09:16:26 2011 From: rijal.it at gmail.com (Nitesh Rijal) Date: Tue, 22 Nov 2011 13:46:26 +0530 Subject: [Koha-devel] Information Required In-Reply-To: References: Message-ID: Haven't tried that till date. Even I'm interested if there are any resources. Regards. 2011/11/22 SANDEEP BHAVSAR > Respected All > > I would like to integrate EBSCO, Open access databases, through pazpar2 > in Koha. Kindly guide me for the documentation. Step by step screenshots or > video of the process in lecture form will be preferred. > > -- > Thanks and Regards > > Sandeep Bhavsar > Librarian > Dr.V.N.Bedekar Institute of Management Studies > Thane(W) 400601 > MUMBAI. INDIA > @@@@@@@@@@@@@@@@@@@@@@@@@@ > email : sandeep.bhavsar at gmail.com > Mob : 9029 345777 > elibrary :http://www.vpmthane.org/im/elib/main.htm > @@@@@@@@@@@@@@@@@@@@@@@@@@ > > _______________________________________________ > 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/ > -- Er. Nitesh Rijal rijal.it at gmail.com http://niteshrijal.com.np http://facebook.com/openrijal http://twitter.com/open_zilla +9779841458173 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Tue Nov 22 12:05:06 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Tue, 22 Nov 2011 16:35:06 +0530 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: 2011/11/22 Joann Ransom > As I am sure most of you are aware, Horowhenua Library Trust is the birth > place of Koha and the longest serving member of the Koha community. Back in > 1999 when we were working on Koha, the idea that 12 years later we would be > having to write an email like this never crossed our minds. It is with > tremendous sadness that we must write this plea for help to you, the other > members of the Koha community. > > The situation we find ourselves in, is that after over a year of battling > against it, PTFS/Liblime have managed to have their application for a > Trademark on Koha in New Zealand accepted. We now have 3 months to object, > but to do so involves lawyers and money. We are a small semi rural Library > in New Zealand and have no cash spare in our operational budget to afford > this, but we do feel it is something we must fight. > > For the library that invented Koha to now have to have a legal battle to > prevent a US company trademarking the word in NZ seems bizarre, but it is > at this point that we find ourselves. > > So, we ask you, the users and developers of Koha, from the birth place of > Koha, please if you can help in anyway, let us know. > > Regards, > > Jo. > > -- > Joann Ransom RLIANZA > Head of Libraries, > Horowhenua Library Trust. > > > _______________________________________________ > > Joann, This is preposterous behavior on the part of a greedy company. I strongly denounce this approval of Koha trademark in NZ. If there is any way this can reach the Trademark approving authority in NZ, I would like to appeal to them to reconsider the trademark approval. Koha is a open source software from birth. The rightful owners of Koha trademark should be the Koha community and the community has reposed the responsibility of holding such ownership to HLT. So HLT doubly qualifies for holding the Trademarks firstly as the place that gave birth to Koha ( & gave it to the world ) and secondly as stated above, as the body chosen by the Koha community to hold Koha related Trademarks and legal rights. We stand firmly behind HLT and will do all in our power to help. I have already sent a small donation through paypal towards the Koha Trademark fund. I urge all community members (and even others interested in open source software) to donate as much as they can. If you think a letter campaign to the Trademark approving authority in NZ might help in this battle, lets organize one. Please let us know in what other ways we can help. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lori.ayre at galecia.com Tue Nov 22 15:53:56 2011 From: lori.ayre at galecia.com (Lori Bowen Ayre) Date: Tue, 22 Nov 2011 06:53:56 -0800 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: As much as I hate to say it, I wonder if it isn't time to give up this fight. The truth is that the law isn't really on the Koha community's side on this issue because of the sale of the domain to Liblime way back when. That sale really makes the difference as to whether we have any legal footing on this issue. It is clear that the moral issue is meaningless so hoping for others to just do the right thing isn't going to happen. There has already been plenty of outrage expressed by the Koha community and clearly it hasn't made a difference. In the interest of keeping the community on track, I strongly urge everyone to reconsider taking up this legal battle and focusing again on Koha, the name, instead of Koha, the software and, more important, Koha, the community. We lost over a year in wrangling with Liblime/PTFS and I think the product suffered for it, as did the community. Could we possibly find another wonderful word from the birthplace of Koha and make a fresh start? I'm sure the same creative minds that came up with Koha could find another word that is appropriate for this new stage of life and we could just start fresh. Let Liblime take the word, they will never take the community. And the confusion between the true Koha and Liblime Koha hurts the community a whole lot more than it hurts Liblime. I say this with the community interests at heart. I really believe it would be best to walk away from this fight. Disengage and focus on what is most important. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-= Lori Bowen Ayre // Library Technology Consultant / The Galecia Group Oversight Board & Communications Committee / Evergreen (707) 763-6869 // Lori.Ayre at galecia.com Specializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2011/11/21 Joann Ransom > As I am sure most of you are aware, Horowhenua Library Trust is the birth > place of Koha and the longest serving member of the Koha community. Back in > 1999 when we were working on Koha, the idea that 12 years later we would be > having to write an email like this never crossed our minds. It is with > tremendous sadness that we must write this plea for help to you, the other > members of the Koha community. > > The situation we find ourselves in, is that after over a year of battling > against it, PTFS/Liblime have managed to have their application for a > Trademark on Koha in New Zealand accepted. We now have 3 months to object, > but to do so involves lawyers and money. We are a small semi rural Library > in New Zealand and have no cash spare in our operational budget to afford > this, but we do feel it is something we must fight. > > For the library that invented Koha to now have to have a legal battle to > prevent a US company trademarking the word in NZ seems bizarre, but it is > at this point that we find ourselves. > > So, we ask you, the users and developers of Koha, from the birth place of > Koha, please if you can help in anyway, let us know. > > Regards, > > Jo. > > -- > Joann Ransom RLIANZA > Head of Libraries, > Horowhenua Library Trust. > > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Nov 22 16:29:23 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 22 Nov 2011 10:29:23 -0500 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: 2011/11/22 Lori Bowen Ayre : > The truth is that the law isn't really on the Koha community's side > on this issue because of the sale of the domain to Liblime way back when. Putting aside the issue of whether we should fight this fight or not, the sale of the domain to Liblime has nothing to do with whether PTFS should own a trademark on the term Koha in New Zealand. Owning a domain name does not give you a trademark on that term. We were naive to let Liblime get a US trademark on Koha in the first place. We should not repeat that error. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Tue Nov 22 16:47:44 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 Nov 2011 16:47:44 +0100 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: <4ECBC420.2000405@biblibre.com> Le 21/11/2011 22:31, Joann Ransom a ?crit : > As I am sure most of you are aware, Horowhenua Library Trust is the > birth place of Koha and the longest serving member of the Koha > community. Hi Jo, I agree with all what has been said, and I'd like to rise 3 points: == point 1 == 1 do you have a lawyer already ? 2 how much would it cost to build/write the objection? 3 what are our chances to win ? If #1 is yes, you should/could have an answer to #2 and #3 (for free). If answer to #2 is 100k NZD and to #3 is 5% chances, then => change the name If answer to #2 is 1k NZD and to #3 is 75%, then => fight ! (and you'll get the money) == point 2 == I tend to be very very very sad when thinking to changing the name. OTOH, in the greek conference, someone made a presentation about tools for small libraries, and she presented ... Koha ... with the "LibLime KOHA" logo :((( So, maybe changing the name will remove the confusion, and will be worth for all of the community ! == point 3 == I'm sure Catalyst have lawyers and Don will throw his hat in the game. In fact, Catalyst is probably the first one that could/would be annoyed by this trademark... -- 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 Tue Nov 22 16:53:18 2011 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Tue, 22 Nov 2011 07:53:18 -0800 (PST) Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: <1321977198.7320.YahooMailNeo@web114714.mail.gq1.yahoo.com> Salvete! > 2011/11/22 Lori Bowen Ayre : >> The truth is that the law isn't really on the Koha community's side >> on this issue because of the sale of the domain to Liblime way back when. ??? I think it's premature to say that. To my knowledge, this hasn't actually been navigated in court yet. Until our appeals are exhausted, I don't think we should give up. Doing so sends a message that it's okay for a large corporation to shove the public interest about. As far as what is in the name is concerned, it chafes me to see a native term, in especial that one, abused. ??? We've already tried the way of the two row wampum. We've already said we'll be over here, you stay over there, and we'll mutually mind our own business. This has not stopped the personal attacks or the corporate ones. If it is a fight they want, then it is a fight they'll get. > > Putting aside the issue of whether we should fight this fight or not, > the sale of the domain to Liblime has nothing to do with whether PTFS > should own a trademark on the term Koha in New Zealand. Owning a > domain name does not give you a trademark on that term. > ??? *nod* Even at the stage of owning a trademark, one must defend that trademark to retain it. I really do believe that the horse left the stall quite a while back. I'd love to see that tested in court. > We were naive to let Liblime get a US trademark on Koha in the first > place. We should not repeat that error. ??? I agree, and certainly not in the birthplace of Koha. Cheers, Brooke From mjr at phonecoop.coop Tue Nov 22 20:07:42 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 22 Nov 2011 19:07:42 +0000 (GMT) Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: Message-ID: <20111122190742.0E6E39F0E8@nail.towers.org.uk> Lori Bowen Ayre > I say this with the community interests at heart. I really believe it > would be best to walk away from this fight. Disengage and focus on what is > most important. And when should we stop running away and stand our ground, exactly? Before private corporations use trademarks to limit all languages? How weak should we let their claims be before we dispute them? We should take care of this beautiful Koha, defend this lovely gift from Horowhenua, so far as we are reasonably able. As the original commissioner, I think HLT was a joint first user of the mark in NZ and Koha has been in continuous use in their libraries, so it's absurd to try to deny them use of it, isn't it? It was a tactical error that the .org domain went to the supply side of that original relationship and it was a tactical error to let Liblime register a dodgy US trademark despite other earlier US Koha developers. Nevertheless, HLT still used the mark as part of delivering their library services in Horowhenua for all this time. Why should US corporations get away with such outrageous expropriation? If there was no HLT, there would probably have been no Koha LMS, so there would have been no business for Liblime to buy and thus no Liblime for PTFS to buy! I'll put this to the co-op's next meeting, but my view is clear: Occupy Koha! -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From 5p4m at gmx.de Tue Nov 22 20:44:49 2011 From: 5p4m at gmx.de (Mirko) Date: Tue, 22 Nov 2011 20:44:49 +0100 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust In-Reply-To: <20111122190742.0E6E39F0E8@nail.towers.org.uk> References: <20111122190742.0E6E39F0E8@nail.towers.org.uk> Message-ID: <4ECBFBB1.80002@gmx.de> MJ Ray schrieb am 22.11.2011 19:07:42 > We should take care of this beautiful Koha, defend this lovely gift > from Horowhenua, so far as we are reasonably able. A gift, exactly. How the concept of the word "Koha" would make any sense in relation to LibLime is beyond me. Having a look in a M?ori dictionary, there are a lot of beautiful words that would fit much better. My favourite so far is kaikaiwai?. Would fit in with the abbreviation and probably no trademark needed. > Occupy Koha! +1 Angry, Mirko From cath.sheard at stdc.govt.nz Mon Nov 21 23:59:16 2011 From: cath.sheard at stdc.govt.nz (Cath Sheard) Date: Mon, 21 Nov 2011 22:59:16 +0000 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: <6FAB523C701A13479463419A46522DBE26AB2617@STDCEXCH01.internal.stdc.govt.nz> Good morning Jo I am sending you this afternoon a personal cheque for $50 towards court costs as I am outraged that this can be happening. It a time when people are protesting on Wall Street about corporate greed, it seems there are examples a lot closer to home. If there are practical tasks that need assistance at any stage, please contact me and I will be happy to help. Kind regards, Cath S From: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Joann Ransom Sent: Tuesday, 22 November 2011 10:32 a.m. To: koha-devel at lists.koha-community.org; koha; web4lib at webjunction.org Subject: [Koha] Plea for help from Horowhenua Library Trust re: Koha As I am sure most of you are aware, Horowhenua Library Trust is the birth place of Koha and the longest serving member of the Koha community. Back in 1999 when we were working on Koha, the idea that 12 years later we would be having to write an email like this never crossed our minds. It is with tremendous sadness that we must write this plea for help to you, the other members of the Koha community. The situation we find ourselves in, is that after over a year of battling against it, PTFS/Liblime have managed to have their application for a Trademark on Koha in New Zealand accepted. We now have 3 months to object, but to do so involves lawyers and money. We are a small semi rural Library in New Zealand and have no cash spare in our operational budget to afford this, but we do feel it is something we must fight. For the library that invented Koha to now have to have a legal battle to prevent a US company trademarking the word in NZ seems bizarre, but it is at this point that we find ourselves. So, we ask you, the users and developers of Koha, from the birth place of Koha, please if you can help in anyway, let us know. Regards, Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorised and may be illegal. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

CAN'T OPEN ATTACHMENTS?

The Council has upgraded to Microsoft office 2007 suite. This may mean you cannot open attachments if you have older versions of office. Click here to access Microsoft Office 2007's compatibility website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kathryn at catalyst.net.nz Wed Nov 23 03:47:52 2011 From: kathryn at catalyst.net.nz (Kathryn Tyree) Date: Wed, 23 Nov 2011 15:47:52 +1300 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: <4ECBC420.2000405@biblibre.com> References: <4ECBC420.2000405@biblibre.com> Message-ID: <1322016472.1794.349.camel@tyree.wgtn.cat-it.co.nz> Hi Paul and all, In reply to Paul's mention of Catalyst below - yes Don Christie (Catalyst Director) is planning to contribute - we are keeping in touch with the wider Koha community and planning the best way to use our resources to help. I confess I've been following your messages quietly without introducing myself so far :) I'm Kathryn, the fairly new Project Manager for the Koha team at Catalyst in NZ. This is my first post to this list. It's been awesome to read all your messages over the past day. Kathryn > > == point 3 == > I'm sure Catalyst have lawyers and Don will throw his hat in the game. > In fact, Catalyst is probably the first one that could/would be annoyed > by this trademark... > From paul.poulain at biblibre.com Wed Nov 23 12:01:50 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 23 Nov 2011 12:01:50 +0100 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: References: Message-ID: <4ECCD29E.5070606@biblibre.com> Hi chris_n, The 6328 patch has been QAed by Ian, and can now be pushed. BUT there is a problem that i'll try to explain: * as i've announced in my Koha 3.8 release notes and we've worked during KohaCon11 Hackfest, we're working on a new method to update database on a non linear way. Jonathan has written code for that. It works pretty well, i'm testing and there is only (I think) a remaining problem for fresh installs I plan to work on today. Then i'll submit the patch (see bug 7167). * my plan, until this is ready, is to queue all patches that have a database update. Thus, 3.8 will only have the new method for update. * The problem is for bugfixes that have a DB update and must be in 3.6. There should be only a few of them, but here is the 1st, so, we must deal with it. My proposition: * you apply this patch on the 3.6.x * when the new method is ready, we rewritte the patch for 3.8 updatedb At the end: * fresh 3.8 will have directly the correct DB * 3.6.2+ will be updated to have the correct DB. When upgrading to 3.8, the new updater will have to check for this and not try to update the DB once again * 3.6.0 upgraded to 3.8 will be upgraded through the new DB update, that will handle this case. Is there something i'm missing ? Are you OK with this proposition ? -------- Message original -------- Sujet: Re: Bug 6328 (fine in days) and QA Date : Sat, 19 Nov 2011 10:08:36 -0500 De : Ian Walls Pour : Paul Poulain Passed, with a note about a small template change still required on circ/circulation.tt around line 390. Not worth holding up QA for this, though, as a followup patch could be very easily generated. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chris.nighswonger at gmail.com Wed Nov 23 15:27:32 2011 From: chris.nighswonger at gmail.com (Chris Nighswonger) Date: Wed, 23 Nov 2011 09:27:32 -0500 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: <4ECCD29E.5070606@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> Message-ID: Hey Paul, On Wed, Nov 23, 2011 at 6:01 AM, Paul Poulain wrote: > My proposition: > * you apply this patch on the 3.6.x > * when the new method is ready, we rewritte the patch for 3.8 updatedb > > At the end: > * fresh 3.8 will have directly the correct DB > * 3.6.2+ will be updated to have the correct DB. When upgrading to 3.8, > the new updater will have to check for this and not try to update the DB > once again > * 3.6.0 upgraded to 3.8 will be upgraded through the new DB update, that > will handle this case. > > Is there something i'm missing ? Are you OK with this proposition ? I am a little confused. If you are suggesting that we back port the new updatedatabase scheme, I am in support of this. While this is technically an enhancement, it is not a "feature" in the proper sense. It is only a "feature" from a developer's prospective. Applying it to 3.6.x will keep a maintenance nightmare from occurring. The question regarding such a nightmare is not really "if" but "when." If the new updatedatabase code will be applied to master in the next week, I am inclined to wait to apply the fix for 6328. Since this touches template files and 3.6.x is presently in a string freeze, it will not make it into 3.6.1 any way, so the wait will not hurt. If the new updatedatabase code will *not* be applied in the next week, then as soon as the 3.6.x branch is thawed, I'll be glad to apply this patch. Feel free to set me straight if I'm not understanding your proposal. Kind Regards, Chris From dschust1 at gmail.com Wed Nov 23 15:57:22 2011 From: dschust1 at gmail.com (David Schuster) Date: Wed, 23 Nov 2011 08:57:22 -0600 Subject: [Koha-devel] Reading history concerns and opinions Message-ID: This is a library question on policy and just curious how others are handling it. Reading history can be maintained in Koha - I understand that, and as a policy we protect individuals freedom to read what they want. As a School district - we often get the request from teachers and parents "I need a list of what Susie has read this semester"... Currently we have not been providing access to even the students so it is easy for us to say "Sorry we don't keep that information"... I know we could say "Sorry that is private student information and I can't share it", Teachers could probably be thwarted with that, but not so much Parents... Then the whole "FBI" coming for reading history is another issue... As we build these features that allow "staring" and "if you read X you might enjoy Y" or "people who read X also read Y" - what is our best avenue for defending our clients reading history, yet making these features available to them. Just pondering... -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Nov 23 16:04:03 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 23 Nov 2011 16:04:03 +0100 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> Message-ID: <4ECD0B63.9080201@biblibre.com> Le 23/11/2011 15:27, Chris Nighswonger a ?crit : > I am a little confused. If you are suggesting that we back port the > new updatedatabase scheme, I am in support of this. Not at all ! I was suggesting to: * keep actual updatedatabase as it is for 3.6 * have the new updatedatabase for 3.8 * for patches that require an updatedatabase in 3.6.x, we will need to have : - the 3.6 updatedatabase (for ppl updating to 3.6.x) - the 3.8 updatedatabase (for ppl that, in the future will upgrade from 3.Y to 3.8 (Y<6) ) But, working more deeply on this, I think it's a *bad idea*. My feeling here is that we will face a lot of pain to manage both 3.6=> 3.8 and 3.0 / 3.2 / 3.4 => 3.8, by trying to have 2 different updatedatabase methods at the same time. SO, maybe we should define as mandatory to migrate in 2 steps: - from 3.0 / 3.2 / 3.4 to 3.6.x, (old method) - then 3.6.x => 3.8 (new method) That's what we did for migration from 2.2 to 3.0 = 1st, execute updatedatabase22to30.pl (that was totally different from the 3.x updatedatabase), then the new updatedatabase.pl In this case, the 6328 patch can be applied on both branches (master and 3.6 The updatedatabase part of the 3.8 will be useless -as updatedatabase will be deprecated in 3.8, in favour of the new non-linear update system) BUT for libraries migrating from a version before 3.6, the workflow would be: updatedatabase.pl (the old one, renamed updatedatabase30to36.pl maybe), THEN the new updatedb system. Am I clear ? Do others understand and agree ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chris.nighswonger at gmail.com Wed Nov 23 16:23:02 2011 From: chris.nighswonger at gmail.com (Chris Nighswonger) Date: Wed, 23 Nov 2011 10:23:02 -0500 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: <4ECD0B63.9080201@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> Message-ID: On Wed, Nov 23, 2011 at 10:04 AM, Paul Poulain wrote: > Le 23/11/2011 15:27, Chris Nighswonger a ?crit : > >> I am a little confused. If you are suggesting that we back port the >> new updatedatabase scheme, I am in support of this. > Not at all ! I was suggesting to: So why is moving 3.6.x to the new updatedatabase code not a good idea? It presents a rather simple solution to all of the 3.6.x maintenance issues and even migration issues at this point. What am I missing? Kind Regards, Chris From M.de.Rooy at rijksmuseum.nl Wed Nov 23 17:02:52 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 23 Nov 2011 16:02:52 +0000 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECA0344.7030103@biblibre.com> References: <20111118191843.06D959F0E8@nail.towers.org.uk> , <4ECA0344.7030103@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31378C02@S-MAIL-1B.rijksmuseum.intra> Quote from Bugzilla #7167 Here is how it works: * each database update is stored in a numbered file, in installer/data/mysql/versions * database updates can be .sql or .pl files. 2 skeletons are provided to explain how it works * there is no more automatic checking of the database update on each page. The librarian/sysadmin must go to the admin/updatedatabase.pl page on each update. * the updatedatabase.pl script keep track of all updates that have been applied, how it went. And it's non-linear: 3.7.2.3 can be applied after 3.7.2.4 * The about.pl will display the highest db update applied, but maybe there are some missing, it's only the highest applied [End of quote] My questions are now: How do I submit a new db update? I cannot give it a number myself; in that case somebody else could have a patch pending using that number already. So I assume that the RM renames the file. What convention do we use? Is there still a check at login time if all updates have been run which redirects to the update screen? I would say that we do not need that check everywhere, but I would keep it at login time. Would you allow an admin to install only partially the updates? Isn't that asking for trouble? It is not linear, but some patches with db updates will be sensitive to the order applied. Is there any logic to prevent problems in that area? Marcel ________________________________________ 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: maandag 21 november 2011 8:52 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Update database changes proposal [IMPORTANT] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 20/11/2011 01:09, Mason James a ?crit : > now.. how could an .SQL only solution achieve this? - its > impossible, right? > > - using .pl patches, with a *combination* of perl and sql, would > allow us the best of both options - using .sql patches alone, means > a patch won't be able to use any internal Koha subroutines? Ian (& all): see my mail about what Jonathan has already written and that I should submit quickly (today ?) : he deals with both .sql and .pl, so we get the best of both worlds !!! (the updater detect the extension and work accordingly) HTH - -- 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/ iQEcBAEBAgAGBQJOygM/AAoJEK81SonuhyGo/G8H/3qJevFE40LXY9ei20toW720 TIMl8G2VSSFfIidSWDJW5B8z1EcNX2QUTMsWr0w5OIvpNgxTrWzcxBOox1DCfM4t W5ZhN39L0H4LuEmzIO/8Anmlsw4q2jDyUzFyJJcJf3dcag99tJDM1Pl1PP/nXG+b EbEkox73K7EEx1PNHsHea6VdcpZYThs+0OKRGsXdRFTOlYEMj4Im6lb/hUi3Q3P9 1rgrM3Y2EtAZ81z+1opkooIaVyjwCNw+cjNJUtZhblBMX6w7MtFkir2ne7oegCh4 CjiqQ++PaP1AT5Z7jz2cwvD6yKEVdoHG3JXQE3LaH4sFSDZaFLbKp9I9kNgutEk= =fUJh -----END PGP SIGNATURE----- _______________________________________________ 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 Wed Nov 23 17:54:39 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 23 Nov 2011 17:54:39 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31378C02@S-MAIL-1B.rijksmuseum.intra> References: <20111118191843.06D959F0E8@nail.towers.org.uk> , <4ECA0344.7030103@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA31378C02@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4ECD254F.6000201@biblibre.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 23/11/2011 17:02, Marcel de Rooy a ?crit : > Quote from Bugzilla #7167 Here is how it works: * each database > update is stored in a numbered file, in > installer/data/mysql/versions * database updates can be .sql or .pl > files. 2 skeletons are provided to explain how it works * there is > no more automatic checking of the database update on each page. The > librarian/sysadmin must go to the admin/updatedatabase.pl page on > each update. * the updatedatabase.pl script keep track of all > updates that have been applied, how it went. And it's non-linear: > 3.7.2.3 can be applied after 3.7.2.4 * The about.pl will display > the highest db update applied, but maybe there are some missing, > it's only the highest applied [End of quote] > > My questions are now: How do I submit a new db update? just create a file under installer/data/mysql/versions > I cannot give it a number myself; in that case somebody else could > have a patch pending using that number already. So I assume that > the RM renames the file. What convention do we use? yes you can : as it's not linear, you can. To know which numbers have been "reserved", we could have a wiki page. If you've reserved 3.07.01.017 and someone has a 3.07.01.018, the 018 can be pushed *before* your 017, there's no problem with that. > Is there still a check at login time if all updates have been run > which redirects to the update screen? no. Because it takes a long time to check all versions, and, as it's unlinearized, you must check each version, not just check you've the "highest number" > I would say that we do not need that check everywhere, but I would > keep it at login time. This idea could be investigated for someone that log-in with admin permission, for example. Does others think it's a must-have ? Here at BibLibre, most of us think checking the database update is a part of an update, so if it's not made, it means you're doing a poor job. > Would you allow an admin to install only partially the updates? > Isn't that asking for trouble? yes, you could. Even if, I agree, that would be a strange idea. And that's why there is a [UPDATE] on the top that update everything > It is not linear, but some patches with db updates will be > sensitive to the order applied. Is there any logic to prevent > problems in that area? Nope, and we discussed a lot of this during hackfest, there is no solution for this. Plus, investigating actual updatedatabase show only a few cases that could cause a problem. 90% of the updates are syspref/index/foreign keys related. HTH - -- 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/ iQEcBAEBAgAGBQJOzSVIAAoJEK81SonuhyGo4JAIAJWxr3IMX8OgxDU2a4QNgwQD BRcKqNQDTG3YJneW7CRh959wglzk2gABQdiKcZqoO0XrAKNnqxaEinrpWbbTq63p 4yev1h8A1RFYwMYjtHSsFtdJFDWBf6XWPzHkl5gscPohPbFWteLBqeNePgTxXkh+ D4dPi6PG1HPK3iAt75tv26zruLA3Zn9DsML1Zhv0hvLqgsuFVobmXFA8R4OGRawm CGaPFD5NZW1PfHjqNdAC4Bfb0hrqd59q1+bTlsDcd2gJrePKelDmC8Yge2S9n3GN v/g+vWq0Vmmd1fdEfFWkui60iw9XJizKA0JFOpcq1Dzc5Z+OzQMelkxyHcYLtkM= =xN9m -----END PGP SIGNATURE----- From paul.poulain at biblibre.com Wed Nov 23 18:21:49 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 23 Nov 2011 18:21:49 +0100 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> Message-ID: <4ECD2BAD.6040605@biblibre.com> Le 23/11/2011 16:23, Chris Nighswonger a ?crit : > On Wed, Nov 23, 2011 at 10:04 AM, Paul Poulain > wrote: >> Le 23/11/2011 15:27, Chris Nighswonger a ?crit : >> >>> I am a little confused. If you are suggesting that we back port the >>> new updatedatabase scheme, I am in support of this. >> Not at all ! I was suggesting to: > > So why is moving 3.6.x to the new updatedatabase code not a good idea? > It presents a rather simple solution to all of the 3.6.x maintenance > issues and even migration issues at this point. What am I missing? We had a long discussion about this on IRC (kf, jcamins, chris_n & me) I explain again my idea: * a patch related to a bug, that would end in 3.6.x, will require a installer/data/mysql/updatedatabase patch, as previously (no change here) * a patch related to an improvement, that will be released in 3.8 will require a admin>updatedd patch, the new mechanism. It means there is no need to have 2 versions of the DB update. The version needed is defined by the version where it will appear: * if it's a bugfix => 3.6 => old mechanism * if it's an ENH => 3.8 => new mechanism BUT: It seems there is a case i had forgotten: people running master (bywater, hello ;-) ) Tests cases: Day 1 : version= 3.06.00.001 has been released D2 : patch pushed, with new update system, version=3.07.00.001 Will be released officially in 3.8.0 D2 : patch pushed, it's a bug, so cope with old updatedatabase system, version=3.06.00.002. Released in 3.6.2 == Someone upgrade from 3.4 to 3.6.2 == No problem = the version is set to 3.06.00.002, and later upgrade to 3.8 will add 3.07.00.001 as well == Someone upgrade from 3.6.x to 3.8 == No problem = the upgrade use the new system, and upgrade to 3.07.00.001 == Someone upgrade from 3.4 to 3.8 == No problem = the upgrade will explain someone will have to run installer/data/mysql/updatedatabase (the old mechanism) THEN admin>updatedatabase (the new one) That was exactly how we did for 2.2 => 3.0 upgrade (see http://wiki.koha-community.org/wiki/Upgrading_2.2: > installer/data/mysql/update22to30.pl That will update the database to the 3.0 structure. > Go and take a coffee, it can be long or very long, depending on your Database size. > installer/data/mysql/updatedatabase.pl this script will finish the update of the database. == Someone install a fresh 3.8 == No problem = works without any specific update == Someone run git.koha-community.org/master == Problem = on Day 1, someone is running 3.06.00.001, it's OK. on Day 2, the install says "version is 3.07.00.001", it's still OK on Day 3, the "old" updatedatabase will say "3.06.00.002 already applied, nothing to do" (because the number is set to 3.07, that is bigger than 3.06 !) => BUG, the 3.06.00.002 won't be applied and someone will face a problem !!! As i've been told that bywater customers are running master, we must deal with this case. I had a discussion with Jonathan (joubu), that made the work at BibLibre, he had a great and easy-to-do idea. The idea would be: * don't change the "version" systempreference on the new system for instance. In about.pl, we still would see 3.06.01.002 (in my example) * Just before releasing 3.8, reintroduce version increase, to have "3.08.00.001" displayed in about.pl That would change nothing for ppl using only released versions, and would work well for ppl running master ! Is there still a case that would cause pain ? kf & others proposed an IRC meeting to discuss of this. Is it still needed ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From jcamins at cpbibliography.com Wed Nov 23 20:16:34 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 23 Nov 2011 14:16:34 -0500 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: <1322016472.1794.349.camel@tyree.wgtn.cat-it.co.nz> References: <4ECBC420.2000405@biblibre.com> <1322016472.1794.349.camel@tyree.wgtn.cat-it.co.nz> Message-ID: Welcome to the community! One of the great things about the community--possibly the greatest--is how supportive and welcoming it is. Speaking as an American business owner, I hope that you do not take this as indicative of the "American Way." As most of you probably know, I am in the business of preserving cultural heritage, not co-opting it. About a year ago I shared my feelings on the importance of openness and community, and I still stand by what I said. Koha is a gift from Horowhenua Library Trust, and I, for one, am very grateful for it. I am very sorry that not everyone recognizes that, and that this absurd trademark application is an issue at all. Regards, Jared On Nov 22, 2011 9:56 PM, "Kathryn Tyree" wrote: > Hi Paul and all, > > In reply to Paul's mention of Catalyst below - yes Don Christie > (Catalyst Director) is planning to contribute - we are keeping in touch > with the wider Koha community and planning the best way to use our > resources to help. > > I confess I've been following your messages quietly without introducing > myself so far :) I'm Kathryn, the fairly new Project Manager for the > Koha team at Catalyst in NZ. This is my first post to this list. > > It's been awesome to read all your messages over the past day. > > Kathryn > > > > > == point 3 == > > I'm sure Catalyst have lawyers and Don will throw his hat in the game. > > In fact, Catalyst is probably the first one that could/would be annoyed > > by this trademark... > > > > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Wed Nov 23 21:01:36 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 23 Nov 2011 15:01:36 -0500 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: <4ECD2BAD.6040605@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> Message-ID: On Wed, Nov 23, 2011 at 12:21 PM, Paul Poulain wrote: > Is there still a case that would cause pain ? > > kf & others proposed an IRC meeting to discuss of this. Is it still needed ? I would like to see us do something like this: 1. Publish a test branch which implements what Paul has described in full working form, including the ability to demo adding a db update to both 3.6.x and 3.7.x as proof-of-concept. Theory and explanations are nice, but a working demo is proof of the pudding (Englishism here). 2. Following this, we can conclude our list discussion and/or irc discussion, and go from there. This will also give us an opportunity to submit further improvements/enhancements/etc. which may arise out of testing the proof-of-concept. We can even set a time table for these things to happen. I see absolutely no reason to rush this sort of change. The system we have in place now *does* work. It may be a bit of a pain to some, but it has worked through at least three release cycles. The proposed change does not affect the user in any case. I realize that some may be already going a different direction internally with regard to db updates, while others may be relying on the master branch for production use. Each may choose his own poison in this regard, but rushing through changes which have global effects will surely lead to disastrous results. For the record: I am not particularly married to the existing updatedatabase.pl methodology. What I don't want is to see the current stable release laid to rest early. Assurances aside, I'd like to see proof-of-concept before withdrawing my objections. Kind Regards, Chris From chris at bigballofwax.co.nz Wed Nov 23 21:30:34 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 24 Nov 2011 09:30:34 +1300 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: 2011/11/24 Buster > > > 2011/11/22 Lori Bowen Ayre > >> There has already been plenty of outrage expressed by the Koha community >> and clearly it hasn't made a difference. >> > > Oh, I don't know about that. We investigated Koha and Evergreen for a year > and recently decided to go with community Koha using ByWater Solutions as a > vendor rather than LibLime largely because of LibLime's position within (or > rather, without) the community. That, and the fact its product has > basically become a proprietary system with all the weaknesses and pitfalls > of such systems. While investigating, we did visit a couple of LibLime > clients who are jumping ship as soon as they are legally able, for many of > the same reasons we eschewed it from the git-go. > > So, I think it has, in fact, made a difference. People who care do pay > attention. > > Some very interesting news. http://diligentroom.wordpress.com/2011/11/22/the-exemplar-of-stupid-koha-vs-liblime-trademark/#comment-1761 From mjr at phonecoop.coop Wed Nov 23 23:46:03 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 23 Nov 2011 22:46:03 +0000 (GMT) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECD254F.6000201@biblibre.com> Message-ID: <20111123224603.B592D9F0E8@nail.towers.org.uk> Paul Poulain > Le 23/11/2011 17:02, Marcel de Rooy a ?crit : > > I would say that we do not need that check everywhere, but I would > > keep it at login time. > This idea could be investigated for someone that log-in with admin > permission, for example. > Does others think it's a must-have ? Here at BibLibre, most of us > think checking the database update is a part of an update, so if it's > not made, it means you're doing a poor job. I think it may be a good idea. Not only experts like you and me install Koha. Some hobbyists and accidental tech workers are doing it for themselves. What would be very cool is if the version number was computed somehow from the updates that had been applied (which may make it go nonlinear) in a way that we could see what been applied. One possibility would be for the RM to give each update a prime number and we just sum them, but the version number might get verrrry big. Can anyone do better or should we junk that idea? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From robin at catalyst.net.nz Thu Nov 24 00:10:02 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 24 Nov 2011 12:10:02 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <20111123224603.B592D9F0E8@nail.towers.org.uk> References: <20111123224603.B592D9F0E8@nail.towers.org.uk> Message-ID: <1322089802.21393.0.camel@zarathud> MJ Ray schreef op wo 23-11-2011 om 22:46 [+0000]: > Can anyone do better or should we junk that idea? I tend to agree with you here, I think. Perhaps a quick hash/CRC of the filenames of the patches that have been applied? Should be quick to generated and test, and will tell us immediately if we need to run again. -- 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 Nov 24 00:23:13 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 23 Nov 2011 18:23:13 -0500 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <1322089802.21393.0.camel@zarathud> References: <20111123224603.B592D9F0E8@nail.towers.org.uk> <1322089802.21393.0.camel@zarathud> Message-ID: You know what this thread is missing? 2 cents from yours truly! > Perhaps a quick hash/CRC of the filenames of the patches that have been > applied? Should be quick to generated and test, and will tell us > immediately if we need to run again. > +1 from me My vote is for using a hash for identifying updates in every situation. Preferable to file names or hardcoded version numbers, in my view. -- 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 nsr at etome.net Thu Nov 24 04:44:45 2011 From: nsr at etome.net (Nick Rosasco) Date: Wed, 23 Nov 2011 22:44:45 -0500 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: Gah! I feel rather embarrassed that again a fellow US citizen (well, entity) is causing this sort of concern. Thanks for the link on the community site to the donations page. I sincerely hope this can be worked out, or absent a solution, a suitably representative new name can be found if it can't. (Should that latter become necessary, I'd strongly recommend arrangement of suitably legal safeguards in such a way that ensures the interested parties community as a whole has both the ability to protect and participate.... if only to avoid a repeat of the hassles.) The gang at the Apache Software Foundation might also be a good resource for practical advice as well. Is there anything else that can be done? Relurking, Nick ...wishing now he'd helped do something to help pre-empt this and the earlier complications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Thu Nov 24 08:51:07 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 24 Nov 2011 07:51:07 +0000 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECD254F.6000201@biblibre.com> References: <20111118191843.06D959F0E8@nail.towers.org.uk> , <4ECA0344.7030103@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA31378C02@S-MAIL-1B.rijksmuseum.intra> <4ECD254F.6000201@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31379019@S-MAIL-1B.rijksmuseum.intra> >> I would say that we do not need that check everywhere, but I would >> keep it at login time. > This idea could be investigated for someone that log-in with admin > permission, for example. > Does others think it's a must-have ? Here at BibLibre, most of us > think checking the database update is a part of an update, so if it's > not made, it means you're doing a poor job. I understand that (poor job-argument) for a production database, but for a test db on latest master (fetching new commits all the time) it would be very comfortable if Koha could check if I am missing an update instead of checking it manually and forgetting to do so.. If the check is done via some kind of hash function, it should not take long time. From M.de.Rooy at rijksmuseum.nl Thu Nov 24 09:08:43 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 24 Nov 2011 08:08:43 +0000 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: <4ECD2BAD.6040605@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31379097@S-MAIL-1B.rijksmuseum.intra> > I explain again my idea: > * a patch related to a bug, that would end in 3.6.x, will require a > installer/data/mysql/updatedatabase patch, as previously (no change here) > * a patch related to an improvement, that will be released in 3.8 will > require a admin>updatedd patch, the new mechanism. > > It means there is no need to have 2 versions of the DB update. The > version needed is defined by the version where it will appear: > * if it's a bugfix => 3.6 => old mechanism > * if it's an ENH => 3.8 => new mechanism Would that bugfix not be included in 3.8 too? So you do need two versions? > == Someone run git.koha-community.org/master == > Problem = > on Day 1, someone is running 3.06.00.001, it's OK. > on Day 2, the install says "version is 3.07.00.001", it's still OK > on Day 3, the "old" updatedatabase will say "3.06.00.002 already > applied, nothing to do" (because the number is set to 3.07, that is > bigger than 3.06 !) > => BUG, the 3.06.00.002 won't be applied and someone will face a problem !!! > > As i've been told that bywater customers are running master, we must > deal with this case. > > I had a discussion with Jonathan (joubu), that made the work at > BibLibre, he had a great and easy-to-do idea. > The idea would be: > * don't change the "version" systempreference on the new system for > instance. In about.pl, we still would see 3.06.01.002 (in my example) > * Just before releasing 3.8, reintroduce version increase, to have > "3.08.00.001" displayed in about.pl > > That would change nothing for ppl using only released versions, and > would work well for ppl running master ! I would not like the idea of postponing version number increase. If we use a hash function for checking the version, we could catch this situation ? From mjr at phonecoop.coop Thu Nov 24 11:37:23 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 24 Nov 2011 10:37:23 +0000 (GMT) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <1322089802.21393.0.camel@zarathud> Message-ID: <20111124103723.9D5409F0E8@nail.towers.org.uk> Robin Sheat > Perhaps a quick hash/CRC of the filenames of the patches that have been > applied? Should be quick to generated and test, and will tell us > immediately if we need to run again. That was another idea, but I thought a sufficient hash would be a very long version number from the start and also would not necessarily increase as updates are applied, or tell us simply which updates have been applied when people ask for help, so I went with multiplying primes. But both have their merits. Hash, CRC or primes are fine by me. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From ian.walls at bywatersolutions.com Thu Nov 24 12:37:51 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 24 Nov 2011 06:37:51 -0500 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31379097@S-MAIL-1B.rijksmuseum.intra> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA31379097@S-MAIL-1B.rijksmuseum.intra> Message-ID: I'm with Chris N that a proof-of-concept test for this change would be required first, before we switch over our entire process. What we have works, just not as well as our new method could. I think that when the decision is made to implement this, we switch to it completely. Ideally, I'd like to see 3.6.0 as the cut-off, since that's when both a stable release branch and master coinicided. 3.4.x is nearing end of life, and I don't see too much difficulty in continuing to apply database changes the old way to that branch. But if we could just move on from both master and 3.6.0 using the new method, we'd be able to reap more of it's benefits. If we cannot get this tested and ready in short order, it may be necessary to postpone until 3.8. As said, this is completely transparent to the end user, so we're not delaying any useful features by being cautious. And, given this will change how developers do their coding, it'd be nice to give enough time so that everyone can be trained up on the new method, so the QA team doesn't have to do too much rejection or reformatting of perfectly functional patches. Cheers, -Ian On Thu, Nov 24, 2011 at 3:08 AM, Marcel de Rooy wrote: > > I explain again my idea: > > * a patch related to a bug, that would end in 3.6.x, will require a > > installer/data/mysql/updatedatabase patch, as previously (no change here) > > * a patch related to an improvement, that will be released in 3.8 will > > require a admin>updatedd patch, the new mechanism. > > > > It means there is no need to have 2 versions of the DB update. The > > version needed is defined by the version where it will appear: > > * if it's a bugfix => 3.6 => old mechanism > > * if it's an ENH => 3.8 => new mechanism > > Would that bugfix not be included in 3.8 too? So you do need two versions? > > > > == Someone run git.koha-community.org/master == > > Problem = > > on Day 1, someone is running 3.06.00.001, it's OK. > > on Day 2, the install says "version is 3.07.00.001", it's still OK > > on Day 3, the "old" updatedatabase will say "3.06.00.002 already > > applied, nothing to do" (because the number is set to 3.07, that is > > bigger than 3.06 !) > > => BUG, the 3.06.00.002 won't be applied and someone will face a problem > !!! > > > > As i've been told that bywater customers are running master, we must > > deal with this case. > > > > I had a discussion with Jonathan (joubu), that made the work at > > BibLibre, he had a great and easy-to-do idea. > > The idea would be: > > * don't change the "version" systempreference on the new system for > > instance. In about.pl, we still would see 3.06.01.002 (in my example) > > * Just before releasing 3.8, reintroduce version increase, to have > > "3.08.00.001" displayed in about.pl > > > > That would change nothing for ppl using only released versions, and > > would work well for ppl running master ! > > I would not like the idea of postponing version number increase. If we use > a hash function for checking the version, we could catch this situation ? > > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Thu Nov 24 12:43:14 2011 From: mtj at kohaaloha.com (Mason James) Date: Fri, 25 Nov 2011 00:43:14 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECA0344.7030103@biblibre.com> References: <20111118191843.06D959F0E8@nail.towers.org.uk> <4ECA0344.7030103@biblibre.com> Message-ID: <95526B6F-7483-4D3D-8171-5B6E320FE242@kohaaloha.com> On 2011-11-21, at 8:52 PM, Paul Poulain wrote: > > Le 20/11/2011 01:09, Mason James a ?crit : >> now.. how could an .SQL only solution achieve this? - its >> impossible, right? >> >> - using .pl patches, with a *combination* of perl and sql, would >> allow us the best of both options - using .sql patches alone, means >> a patch won't be able to use any internal Koha subroutines? > > Ian (& all): see my mail about what Jonathan has already written and > that I should submit quickly (today ?) : he deals with both .sql and > .pl, so we get the best of both worlds !!! (the updater detect the > extension and work accordingly) > hi Paul ok, this is perfect! - now i shut up :) -------------- 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 cnighswonger at foundations.edu Thu Nov 24 12:45:13 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 24 Nov 2011 06:45:13 -0500 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <20111123224603.B592D9F0E8@nail.towers.org.uk> <1322089802.21393.0.camel@zarathud> Message-ID: 2011/11/23 Jared Camins-Esakov : > You know what this thread is missing? 2 cents from yours truly! > >> >> Perhaps a quick hash/CRC of the filenames of the patches that have been >> applied? Should be quick to generated and test, and will tell us >> immediately if we need to run again. > > +1 from me +1 here as well. Kind Regards, Chris From ian.walls at bywatersolutions.com Thu Nov 24 12:49:31 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 24 Nov 2011 06:49:31 -0500 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <20111124103723.9D5409F0E8@nail.towers.org.uk> References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> Message-ID: We were discussing the following at hackfest: a directory of atomic database updates. While my intent was for .pl files, we could adapt to include .sql, as well. I just really like the idea of a CHECK/DO/UNDO interface A YAML file, edited by the RM only, that assigns those update files to a specific database revision number. This gives us a quick and ordered means of determining what has been "blessed" by the release team, and allow us to continue a quick check of "is DB version equal to software version?" on every page. If a user needs to make a local change, they can either apply the atomic update file directly (for testing), or add it to the YAML file, but with a placeholder string like "LOCALNUMBER" instead of an actual DB rev number. This would allow people to put together their own database update combinations for local developments, without getting their DB version number out of whack. The script that reads the YAML file and applies the update can be called just in the event that DB number != Code number. This would require that the sysadmin manually add the atomic update the first time, but if they're applying patches that require DB updates, they should be savvy enough to complete that small additional step. I do like the idea of hashes... but looking at it, we'd essentially be mimicking the data structure we already have with Git commits. Plus, readability goes down. Cheers, -Ian On Thu, Nov 24, 2011 at 5:37 AM, MJ Ray wrote: > Robin Sheat > > Perhaps a quick hash/CRC of the filenames of the patches that have been > > applied? Should be quick to generated and test, and will tell us > > immediately if we need to run again. > > That was another idea, but I thought a sufficient hash would be a very > long version number from the start and also would not necessarily > increase as updates are applied, or tell us simply which updates have > been applied when people ask for help, so I went with multiplying > primes. > > But both have their merits. Hash, CRC or primes are fine by me. > > Regards, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Thu Nov 24 13:22:10 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 25 Nov 2011 01:22:10 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> Message-ID: <4ECE36F2.8070205@catalyst.net.nz> Op 25-11-11 00:49, Ian Walls schreef: > I do like the idea of hashes... but looking at it, we'd essentially be > mimicking the data structure we already have with Git commits. Plus, > readability goes down. Is readability an issue here? I was thinking a process like: 1) on each page (and this'll improve heaps when we get persistence :) the list of patch files is build, concated, CRCed. 2) if that value is different from what's stored in the DB, we can then do a more expensive process to work out what has and hasn't been applied. 3) apply the ones we need to, note that however (exercise for reader:) 4) save the hash generated in (1) into the DB 5) ??? 6) Profit! Just an idea, please take and rework as you see fit, or not. I'm a fan of some kind of check for every page load (or, perhaps just every "main" page load, e.g. the front page of each module - no check on the speed critical pages would be good) though, otherwise people _will_ get caught out and confused. Another option may be saving the date of the most recent patch file, however I can see issues there with local customisations on top of a tarball or something. Also, git isn't good at keeping timestamps intact. But basically, a quick check to see "do we need to?" followed by "yes we do, lets spend 10 seconds working out the details because it's OK to do that now" kind of thing. 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 Thu Nov 24 16:20:19 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 24 Nov 2011 16:20:19 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECE36F2.8070205@catalyst.net.nz> References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> <4ECE36F2.8070205@catalyst.net.nz> Message-ID: <4ECE60B3.4020101@biblibre.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 24/11/2011 13:22, Robin Sheat a ?crit : > Op 25-11-11 00:49, Ian Walls schreef: >> I do like the idea of hashes... but looking at it, we'd >> essentially be mimicking the data structure we already have with >> Git commits. Plus, readability goes down. > > Is readability an issue here? I was thinking a process like: > > 1) on each page (and this'll improve heaps when we get persistence > :) the list of patch files is build, concated, CRCed. There are 2 strong opinions here: * upgrade is a process you know you're doing, so no need to check on every page * upgrade is safer if you check often if you're uptodate: the computer must fix human mistakes. Maybe a middle solution would be to have do a check on the login page only (or on mainpage.pl ?). As it's mandatory to log-in on the staff interface, that seems fair. > Perhaps a quick hash/CRC of the filenames of the patches that have > been applied? Should be quick to generated and test, and will tell > us immediately if we need to run again. In a few months, we will have 40 different files. And hashing/CRCing 40 files is not negligible. We want to improve perfs, so I think it's a wrong idea. On the login page though, I think it's something we can afford. (for those who are not reading Bug 6328 (fines in days) and updatedatabase, I'll also add comments here, and both threads are related) - -- 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/ iQEcBAEBAgAGBQJOzmCvAAoJEK81SonuhyGoizkH/RLfsfNzC/KaWCHk37YUXI8q Hq86OuwibnT1pdgnn3XY9QkDEiwJRXIh8kjZDQNJJhdJhqwIZvL27vnwon/ZBMJT No8RM8efuTYKTDvCbNDRSlMtqLXgRhjzfDPJygPZEcYipgRqfq/z1nDvB1dHmnTT eWNQpQpLu2KX/s0Oduj3PPzln8Ri/nWsWQDgFSTn0/62IQ+ibmSo98TjyjYWZ2Kb NotSe+MGLLfIHGaf7WpZt6GitYzJA26sWiGFYJI4wd55bm/dapwB5r1ML30WRTm7 6xTCmjRyX/0wZt2gpI9TMmoL7ZKF17TryAWSgNK5/L/Ub86QKfbcNG525CZAR3w= =/Cjt -----END PGP SIGNATURE----- From paul.poulain at biblibre.com Thu Nov 24 16:27:23 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 24 Nov 2011 16:27:23 +0100 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> Message-ID: <4ECE625B.9060701@biblibre.com> Le 23/11/2011 21:01, Chris Nighswonger a ?crit : > On Wed, Nov 23, 2011 at 12:21 PM, Paul Poulain > wrote: >> Is there still a case that would cause pain ? >> >> kf & others proposed an IRC meeting to discuss of this. Is it still needed ? > > I would like to see us do something like this: > > 1. Publish a test branch which implements what Paul has described in > full working form, including the ability to demo adding a db update to > both 3.6.x and 3.7.x as proof-of-concept. Theory and explanations are > nice, but a working demo is proof of the pudding (Englishism here). The patch attached on the bug are almost working. I'll update them, and that will be easy to test. > 2. Following this, we can conclude our list discussion and/or irc > discussion, and go from there. This will also give us an opportunity > to submit further improvements/enhancements/etc. which may arise out > of testing the proof-of-concept. Agreed. > I see absolutely no reason to rush this sort of change. My hurry was due to the fact I don't wanted to block bugfixes that have an impact on updatedatabase because of the new updatedb management system is not ready. But after all those discussions, I think the previous 3.6 will be OK even with the new 3.8 one. So I'll probably push those patches as they are (for both master & 3.6.x) > It may be a bit of a pain to some, but > it has worked through at least three release cycles. The proposed > change does not affect the user in any case. Yes it does: if a customer has sponsored a feature with DB changes, applying the patch to this customer before it's included in official version is a nightmare. And it appends more than once a year for BibLibre. PS: as i've said on the other thread, i'll work on patches to have something ready to test, in a very close delay. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Thu Nov 24 16:57:27 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 24 Nov 2011 10:57:27 -0500 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECE60B3.4020101@biblibre.com> References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> <4ECE36F2.8070205@catalyst.net.nz> <4ECE60B3.4020101@biblibre.com> Message-ID: On Thu, Nov 24, 2011 at 10:20 AM, Paul Poulain wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 24/11/2011 13:22, Robin Sheat a ?crit : >> Op 25-11-11 00:49, Ian Walls schreef: >>> I do like the idea of hashes... but looking at it, we'd >>> essentially be mimicking the data structure we already have with >>> Git commits. ?Plus, readability goes down. >> >> Is readability an issue here? I was thinking a process like: >> >> 1) on each page (and this'll improve heaps when we get persistence >> :) the list of patch files is build, concated, CRCed. > There are 2 strong opinions here: > * upgrade is a process you know you're doing, so no need to check on > every page > * upgrade is safer if you check often if you're uptodate: the computer > must fix human mistakes. > > Maybe a middle solution would be to have do a check on the login page > only (or on mainpage.pl ?). As it's mandatory to log-in on the staff > interface, that seems fair. I tend to agree with Paul here. Checking at login for up-to-date deps seems to be the best way to go, introducing the least overall latency from the user's prospective. > >> Perhaps a quick hash/CRC of the filenames of the patches that have >> been applied? Should be quick to generated and test, and will tell >> us immediately if we need to run again. > > In a few months, we will have 40 different files. And hashing/CRCing > 40 files is not negligible. We want to improve perfs, so I think it's > a wrong idea. On the login page though, I think it's something we can > afford. Of course, we could always relegate the hashing/CRCing *and* update check to a cron job which runs once very and gives an appropriate status indication on mainpage.pl. Kind Regards, Chris From cnighswonger at foundations.edu Thu Nov 24 17:02:55 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 24 Nov 2011 11:02:55 -0500 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: <4ECE625B.9060701@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> Message-ID: On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain wrote: > Le 23/11/2011 21:01, Chris Nighswonger a ?crit : >> It may be a bit of a pain to some, but >> it has worked through at least three release cycles. The proposed >> change does not affect the user in any case. > Yes it does: if a customer has sponsored a feature with DB changes, > applying the patch to this customer before it's included in official > version is a nightmare. And it appends more than once a year for BibLibre. > IMHO customers who want features before master inclusion is really a vendor issue, not a community issue. Yes, we want to make changes that will make life easier on vendors (and therefore their customers), *but* not at the expense of rushing and possibly introducing a potentially buggy, not-throughly-tested "enhancement." Don't interpret this as "anti-vendor," rather as "pro-stability." ;-) Kind Regards, Chris From dpavlin at rot13.org Thu Nov 24 20:35:38 2011 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Thu, 24 Nov 2011 20:35:38 +0100 Subject: [Koha-devel] Bug 6929 and Status field in Bugzilla in relation to git master Message-ID: <20111124193537.GA5219@rot13.org> I'm working on a system which would allow me to automatically apply arbitrary number of patches from bug tracker to new koha instance (using unique git branch for it) for easy testing of multiple-patch interaction. It's in planning stage, but I started going through my Cc bugs in Bugzilla and stumbled upon 6929 which was in git master, so I chaged it's Status to RESOLVED FIXED Then it occured to me that this not be OK, since Robin might depend on bug beeing assigned to him as reminder to apply it to production somewhere. Should I keep my hands off Status field in bugzilla or try to update them to current master? -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From robin at catalyst.net.nz Thu Nov 24 21:46:47 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 25 Nov 2011 09:46:47 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECE60B3.4020101@biblibre.com> References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> <4ECE36F2.8070205@catalyst.net.nz> <4ECE60B3.4020101@biblibre.com> Message-ID: <4ECEAD37.50407@catalyst.net.nz> Op 25-11-11 04:20, Paul Poulain schreef: > In a few months, we will have 40 different files. And hashing/CRCing > 40 files is not negligible. File_names_, not files. And CRCing on string of 40 filenames is pretty negligible. I just want to avoid people trucking along with new code on an old database schema. I think there's a risk of something bad happening. 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 robin at catalyst.net.nz Thu Nov 24 21:50:18 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 25 Nov 2011 09:50:18 +1300 Subject: [Koha-devel] Bug 6929 and Status field in Bugzilla in relation to git master In-Reply-To: <20111124193537.GA5219@rot13.org> References: <20111124193537.GA5219@rot13.org> Message-ID: <4ECEAE0A.5040408@catalyst.net.nz> Op 25-11-11 08:35, Dobrica Pavlinusic schreef: > Should I keep my hands off Status field in bugzilla or try to update > them to current master? No, it would be bad for me to rely on bugzilla for my own internal processes. If it's in master and working, I think it should be always OK to mark it resolved. 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 mjr at phonecoop.coop Fri Nov 25 11:15:52 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 25 Nov 2011 10:15:52 +0000 (GMT) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: Message-ID: <20111125101552.BF5FD9F0E8@nail.towers.org.uk> Ian Walls [...] > We were discussing the following at hackfest: :-( but thank you for documenting it now. [...] > A YAML file, edited by the RM only, that assigns those update files to a > specific database revision number. This gives us a quick and ordered means > of determining what has been "blessed" by the release team, and allow us to > continue a quick check of "is DB version equal to software version?" on > every page. I don't understand what this gains us. What does the revision number mean? That a particular update has been applied, or that all updates up to and including that point in the numbering file have been applied? > If a user needs to make a local change, they can either apply the atomic > update file directly (for testing), or add it to the YAML file, but with a > placeholder string like "LOCALNUMBER" instead of an actual DB rev number. > This would allow people to put together their own database update > combinations for local developments, without getting their DB version > number out of whack. So how could we infer anything from the DB version number in problem reports? Thanks for any answers anyone could give. Confused, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From savitra.sirohi at osslabs.biz Fri Nov 25 12:39:08 2011 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Fri, 25 Nov 2011 17:09:08 +0530 Subject: [Koha-devel] EDIfact Integration - update please Message-ID: Hi Mark, We need to implement EDI for one our customers by end of March. Can you please send an update on the EDIfact integration work you have been doing? Specifically: Is this branch up-to-date: https://github.com/paddyfitz/koha/tree/EDIfact_3.4.x? Have you implemented other messages outside of Quotes and Orders? We have the resources to start work on EDI from middle of December, if possible we would like to collaborate on this. I found this email from you dating from July of this year. >>>>>>>>>>>>>> Koha-devel] EDIfact integration Mark Gavillet mark.gavillet at ptfs-europe.com Mon Jul 11 13:19:00 CEST 2011 Hi Henri UK public authorities and academic institutions now require EDIfact integration so this has become something which we at PTFS Europe have been working toward over the past couple of months. We now have a branch containing EDIfact integration for Koha which is online at GitHub (https://github.com/paddyfitz/koha/tree/EDIfact_3.4.x). Bertrams and Dawsons booksellers have been a part of the process throughout and the current implementation successfully processes QUOTE and ORDER messages to/from both vendors. We currently have one live customer using the EDIfact module successfully, and another will be going live in the next couple of weeks. We will be tidying the code and submitting to the community in the near future. Regards, Mark Thanks, Savitra Sirohi Nucsoft OSS Labs http://www.osslabs.biz From mark.gavillet at ptfs-europe.com Fri Nov 25 13:05:01 2011 From: mark.gavillet at ptfs-europe.com (Mark Gavillet) Date: Fri, 25 Nov 2011 12:05:01 +0000 Subject: [Koha-devel] EDIfact Integration - update please In-Reply-To: References: Message-ID: Hi Savitra I've been working on an updated module that will implement Invoices as well as Quotes and Orders which should work with both Koha and Evergreen systems. Hopefully it should also be a bit more flexible when working with different message formats supplied by different vendors. It's still in development at the moment but I will be pushing it to the same GitHub repository once I have a working version. As always, any contribution toward the development of the module will be greatly appreciated! Regards, Mark On 25 Nov 2011, at 11:39, savitra sirohi wrote: > Hi Mark, > > We need to implement EDI for one our customers by end of March. > > Can you please send an update on the EDIfact integration work you have > been doing? > > Specifically: > Is this branch up-to-date: https://github.com/paddyfitz/koha/tree/EDIfact_3.4.x? > Have you implemented other messages outside of Quotes and Orders? > > We have the resources to start work on EDI from middle of December, if > possible we would like to collaborate on this. > > I found this email from you dating from July of this year. > >>>>>>>>>>>>>>> > > Koha-devel] EDIfact integration > Mark Gavillet mark.gavillet at ptfs-europe.com > Mon Jul 11 13:19:00 CEST 2011 > > Hi Henri > > UK public authorities and academic institutions now require EDIfact > integration so this has become something which we at PTFS Europe have > been working toward over the past couple of months. We now have a > branch containing EDIfact integration for Koha which is online at > GitHub (https://github.com/paddyfitz/koha/tree/EDIfact_3.4.x). > Bertrams and Dawsons booksellers have been a part of the process > throughout and the current implementation successfully processes QUOTE > and ORDER messages to/from both vendors. > > We currently have one live customer using the EDIfact module > successfully, and another will be going live in the next couple of > weeks. We will be tidying the code and submitting to the community in > the near future. > > Regards, > Mark > > Thanks, > Savitra Sirohi > Nucsoft OSS Labs > http://www.osslabs.biz > _______________________________________________ > 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 Fri Nov 25 19:02:54 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 25 Nov 2011 19:02:54 +0100 Subject: [Koha-devel] RM monthly newsletter Message-ID: <4ECFD84E.7080307@biblibre.com> Hello, I'll try to release every month a newsletter that will summarize what has been done during the previous month. i've started my job one month ago, so, here is my 1st newsletter == Starting my job == We had a few trouble to setup the permissions on git repository. Thanks to chris & brendan work, I could start pushing during the KohaCon11. I have written on the wiki how I push patches on git.koha-community.org (http://wiki.koha-community.org/wiki/How_the_RM_push) There are a few patches i've pushed directly (and only) on master branch. That's only documentation of typo fixes. == Roadmap == I've written a roadmap on the wiki (see http://wiki.koha-community.org/wiki/Roadmap_to_3.8) There are 2 differents parts on this roadmap: technical improvements and functionnal improvements. Some of those improvements already have a bugzilla entry, and some of them even have a patch. For technical improvements, i've made an omnibus entry: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7119 For functionnal improvements promized by BibLibre, there is an omnibus entry as well: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7163 I highlight 2 points on the roadmap that have seen some progress this month: === Updatedatabase news === There has been a lot of discussions about database update, and how to de-linearize the DB update process. The bug is the number 7167, and some code will be submitted very soon === YUI/Jquery stuff === We plan to remove YUI in favor of jquery. Owen has started a lot of work on this, you can look at bug 5481, that provide a link to his gitorious repository. We also have to replace the old calendar picker by a more recent one, owen's work does that as well Last comment on jquery: Julian has submitted some code in bug 6836. Jared & Owen are working on this patch, and I hope it will be signed-off & pushed quickly. One it's OK, the hardest part will have to be made= work on each page with a table to replace tablesorter by datatables ! == Important patch pushed == This paragraph highlight some patches that are not related to features, but to the code itself === mySQL error trapping === (Bug 7184) If you set DEBUG=1 in your Apache virtual host, any MySQL error will result in a die with the exact error. This will prevent Koha being silent in case of a wrong SQL query and help a lot fixing any problem === docbook documentation === (Bug 4877) Many documentation has been added to manage koha-* tools. Thanks to Magnus == Perl::Critic compliance == (Bug 6697) Many scripts have been updated to be Perl::Critic compliant. Thanks to chris for the effort, hoping other will join. It's quite "easy" to identify what must be done: just run "perlcritic scriptname.pl" to test if scriptname.pl is compliant or no. If it is not, you'll have errors detailled. For example: perlcritic tools/export.pl says: tools/export.pl: I/O layer ":utf8" used at line 59, column 5. Use ":encoding(UTF-8)" to get strict validation. (Severity: 5) == Hilighted patches needing signoff == All patches are worth being signed-off, but i'd like to hilight some of them: - Bug 6836, to replace tablesorter by datatable - Bug 7127, to have templates be valid XHTML - Bug 7240, to clean up the database from out-of-date datas (old imported_records for example) - Bug 6990, to improve performances of MARC to Koha decoding. This sub is called in many places, so the improvement will be a big boost ! - Bug 6875, to improve performances, by de-nesting nested C4::Packages. Some of the proposed bugs have already been pushed, but many are still to be signed-off. If everything was signed-off, that would mean -24% in the number of perl statements executed on mainpage.pl and -16% for opac-details ! - Bug 6716, to improve the database documentation. This will be usefull for schema.koha-community.org and all users wanting to build SQL queries == Bugzilla == When I push a patch, I usually check the following things: - is the patch "assigned" ? Sometimes, it's still "NEW". In this case, I set the patch to "ASSIGNED", and, if needed update the assignee to reflect the author of the patch pushed - if the patch is an ENH, set version to rel_3_8. Otherwise, set version to rel_3_6. It help chris_n knowing which patch must be pushed on 3.6.x, and will also help knowing what is in rel_3_8 == Jenkins == At the moment, jenkins says that master is unstable. It means some test have failed. If someone want to volunteer to investigate why and fix the problem, he will be warmly welcomed ! It can be because a patch has been pushed with a problem, or because the test is wrong. In this case, just fix the test in t/ directory, and, once it's pushed by me, jenkins will automatically run the updated test. See you next month for the 2nd RM newsletter ! PS: is this newsletter worth being published on koha-community.org website ? somewhere else (send me your ideas !) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chris at bigballofwax.co.nz Fri Nov 25 21:03:26 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 26 Nov 2011 09:03:26 +1300 Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: An update on the situation http://koha-community.org/update-2/ Chris From abesottedphoenix at yahoo.com Fri Nov 25 23:15:52 2011 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Fri, 25 Nov 2011 14:15:52 -0800 (PST) Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4ECE60B3.4020101@biblibre.com> References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> <4ECE36F2.8070205@catalyst.net.nz> <4ECE60B3.4020101@biblibre.com> Message-ID: <1322259352.68773.YahooMailNeo@web114705.mail.gq1.yahoo.com> Kia ora! > Maybe a middle solution would be to have do a check on the login page > only (or on mainpage.pl ?). As it's mandatory to log-in on the staff > interface, that seems fair. ??? Any reason not to do it at logoff in the background? Cheers, Brooke From paul.poulain at biblibre.com Fri Nov 25 23:37:42 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 25 Nov 2011 23:37:42 +0100 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <4EB4DDCA.5060305@biblibre.com> References: <4EB4DDCA.5060305@biblibre.com> Message-ID: <4ED018B6.60106@biblibre.com> Hello, I just have submitted on bug 7167 3 patches that are working as expected. You can also get a document with screenshots at https://depot.biblibre.com/ppoulain/updatedb%20for%203.8.odt (can't upload it on bugzilla, it's too large: 1.6MB, vs a 1.0MB limit) (Note that the "testing patch" is here just for testing & validating) I think this code handle all the cases (ppl running 3.6, ppl upgrading to 3.8 when it's released, ppl running master), and is a major improvement for everybody: * for developers, it will be easier to submit patches * for users, they'll keep track of what has been applied and what has not. And get feedback if there is a problem Please have a look, test, and, if you think it's OK, sign-off. I worked hard on this in the last days. Also notice that I won't push any patch with an updatedatabase that should be in 3.8 until we've reached an agreement on this improvement (and that's why I considered this as needing to be done urgently) I'll push bugfixes that are for 3.6 without any problem, as the proposed new system won't change anything for 3.6 related db updates. Waiting for your feedback. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From robin at catalyst.net.nz Sat Nov 26 00:14:31 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Sat, 26 Nov 2011 12:14:31 +1300 Subject: [Koha-devel] Update database changes proposal [IMPORTANT] In-Reply-To: <1322259352.68773.YahooMailNeo@web114705.mail.gq1.yahoo.com> References: <1322089802.21393.0.camel@zarathud> <20111124103723.9D5409F0E8@nail.towers.org.uk> <4ECE36F2.8070205@catalyst.net.nz> <4ECE60B3.4020101@biblibre.com> <1322259352.68773.YahooMailNeo@web114705.mail.gq1.yahoo.com> Message-ID: <4ED02157.6020502@catalyst.net.nz> Op 26-11-11 11:15, BWS Johnson schreef: > Any reason not to do it at logoff in the background? People may not logoff, also they may not see errors/warnings if they go away immediately. That said, if you do it on the login screen, which is where the logoff screen takes you, it's really the same thing :) 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 wrobertson1981 at yahoo.co.nz Sat Nov 26 05:47:32 2011 From: wrobertson1981 at yahoo.co.nz (Waylon Robertson) Date: Fri, 25 Nov 2011 20:47:32 -0800 (PST) Subject: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha In-Reply-To: References: Message-ID: <1322282852.39748.YahooMailNeo@web39413.mail.mud.yahoo.com> Made front page of the Manawatu Evening Standard, today. ________________________________ From: Chris Cormack To: Buster Cc: koha ; web4lib at webjunction.org; koha-devel at lists.koha-community.org Sent: Saturday, 26 November 2011 9:03 AM Subject: Re: [Koha] Plea for help from Horowhenua Library Trust re: Koha An update on the situation http://koha-community.org/update-2/ Chris _______________________________________________ Koha mailing list? http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Sat Nov 26 06:23:46 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 26 Nov 2011 18:23:46 +1300 Subject: [Koha-devel] RM monthly newsletter In-Reply-To: <4ECFD84E.7080307@biblibre.com> References: <4ECFD84E.7080307@biblibre.com> Message-ID: On 26 November 2011 07:02, Paul Poulain wrote: > > PS: is this newsletter worth being published on koha-community.org > website ? somewhere else (send me your ideas !) > -- I think on the website is a great place for it Chris From magnus at enger.priv.no Sat Nov 26 09:49:56 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Sat, 26 Nov 2011 09:49:56 +0100 Subject: [Koha-devel] RM monthly newsletter In-Reply-To: References: <4ECFD84E.7080307@biblibre.com> Message-ID: On 26 November 2011 06:23, Chris Cormack wrote: > On 26 November 2011 07:02, Paul Poulain wrote: >> PS: is this newsletter worth being published on koha-community.org >> website ? somewhere else (send me your ideas !) >> -- > > I think on the website is a great place for it +1 Magnus From jcamins at cpbibliography.com Sat Nov 26 22:19:26 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Sat, 26 Nov 2011 16:19:26 -0500 Subject: [Koha-devel] Master broken Message-ID: Hello. Just a heads' up- the master branch on git.k-c.org is currently broken. I can't tell exactly when it broke, but it was sometime after the security patch that was pushed yesterday. The error message you get when you try to log in to the staff client is: Can't call method "cookie" on an undefined value at /home/jcamins/k ohaclone/C4/Templates.pm line 323 I don't have time to troubleshoot this, but I wanted to warn people of the problem before too many people updated their systems with catastrophic results (hopefully this will stave off a bit of the wailing and gnashing of teeth which would otherwise accompany the git pull at 9am Monday morning). Regards, Jared Camins-Esakov -- 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 chris at bigballofwax.co.nz Sat Nov 26 22:58:24 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sun, 27 Nov 2011 10:58:24 +1300 Subject: [Koha-devel] Master broken In-Reply-To: References: Message-ID: 99% probability that its the patch patch since that was around cookies. The good news it can be reverted out, since neither master or the 3.6.x branch were/are vulnerable. Only 3.4.6 and older were. So we can revert it back out with no issue. Thanks for the catch Jared, this will happen from time to time, mistakes happen (this time my fault), luckily not often I think twice in the last year. But master is the unstable branch, so it can happen, I recommend people use the stable branches in production Chris On 27 Nov 2011 10:19, "Jared Camins-Esakov" wrote: > Hello. > > Just a heads' up- the master branch on git.k-c.org is currently broken. I > can't tell exactly when it broke, but it was sometime after the security > patch that was pushed yesterday. The error message you get when you try to > log in to the staff client is: > > Can't call method "cookie" on an undefined value at /home/jcamins/k > ohaclone/C4/Templates.pm line 323 > > I don't have time to troubleshoot this, but I wanted to warn people of the > problem before too many people updated their systems with catastrophic > results (hopefully this will stave off a bit of the wailing and gnashing of > teeth which would otherwise accompany the git pull at 9am Monday morning). > > Regards, > Jared Camins-Esakov > > -- > 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/ > > > _______________________________________________ > 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 chris at bigballofwax.co.nz Sun Nov 27 07:06:02 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sun, 27 Nov 2011 19:06:02 +1300 Subject: [Koha-devel] Master broken In-Reply-To: References: Message-ID: Hmmm I can't replicate this error on master, Can you tell me exactly how got it, I can logout and login just fine in both the opac and staff interface Chris On 27 November 2011 10:58, Chris Cormack wrote: > 99% probability that its the patch patch since that was around cookies. The > good news it can be reverted out, since neither master or the 3.6.x branch > were/are vulnerable. > Only 3.4.6 and older were. > > So we can revert it back out with no issue. > > Thanks for the catch Jared, this will happen from time to time, mistakes > happen (this time my fault), luckily not often I think twice in the last > year. But master is the unstable branch, so it can happen, I recommend > people use the stable branches in production > > Chris > > On 27 Nov 2011 10:19, "Jared Camins-Esakov" > wrote: >> >> Hello. >> Just a heads' up- the master branch on git.k-c.org is currently broken. I >> can't tell exactly when it broke, but it was sometime after the security >> patch that was pushed yesterday. The error message you get when you try to >> log in to the staff client is: >> Can't call method "cookie" on an undefined value at >> /home/jcamins/kohaclone/C4/Templates.pm line 323 >> >> I don't have time to troubleshoot this, but I wanted to warn people of the >> problem before too many people updated their systems with catastrophic >> results (hopefully this will stave off a bit of the wailing and gnashing of >> teeth which would otherwise accompany the git pull at 9am Monday morning). >> Regards, >> Jared Camins-Esakov >> -- >> 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/ >> >> _______________________________________________ >> 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 Katrin.Fischer at bsz-bw.de Sun Nov 27 08:52:39 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Sun, 27 Nov 2011 08:52:39 +0100 Subject: [Koha-devel] Master broken References: Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD0162659E@Bodensee.bsz-bw.de> I was able to reproduce the problem, I think it's related to the web installer: URL: /cgi-bin/koha/installer/install.pl?step=3 Software error: Can't call method "cookie" on an undefined value at .../kohaclone/C4/Templates.pm line 323. -- Katrin -----Urspr?ngliche Nachricht----- Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris Cormack Gesendet: So 27.11.2011 07:06 An: Jared Camins-Esakov Cc: koha-devel at lists.koha-community.org Betreff: Re: [Koha-devel] Master broken Hmmm I can't replicate this error on master, Can you tell me exactly how got it, I can logout and login just fine in both the opac and staff interface Chris On 27 November 2011 10:58, Chris Cormack wrote: > 99% probability that its the patch patch since that was around cookies. The > good news it can be reverted out, since neither master or the 3.6.x branch > were/are vulnerable. > Only 3.4.6 and older were. > > So we can revert it back out with no issue. > > Thanks for the catch Jared, this will happen from time to time, mistakes > happen (this time my fault), luckily not often I think twice in the last > year. But master is the unstable branch, so it can happen, I recommend > people use the stable branches in production > > Chris > > On 27 Nov 2011 10:19, "Jared Camins-Esakov" > wrote: >> >> Hello. >> Just a heads' up- the master branch on git.k-c.org is currently broken. I >> can't tell exactly when it broke, but it was sometime after the security >> patch that was pushed yesterday. The error message you get when you try to >> log in to the staff client is: >> Can't call method "cookie" on an undefined value at >> /home/jcamins/kohaclone/C4/Templates.pm line 323 >> >> I don't have time to troubleshoot this, but I wanted to warn people of the >> problem before too many people updated their systems with catastrophic >> results (hopefully this will stave off a bit of the wailing and gnashing of >> teeth which would otherwise accompany the git pull at 9am Monday morning). >> Regards, >> Jared Camins-Esakov >> -- >> 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/ >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From semarie-koha at latrappe.fr Sun Nov 27 09:16:30 2011 From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie) Date: Sun, 27 Nov 2011 09:16:30 +0100 Subject: [Koha-devel] Master broken In-Reply-To: References: Message-ID: <20111127081629.GA4234@latrappe.fr> On Sat, Nov 26, 2011 at 04:19:26PM -0500, Jared Camins-Esakov wrote: > > Can't call method "cookie" on an undefined value at /home/jcamins/k > ohaclone/C4/Templates.pm line 323 > The patch (9a4e9e54f26b0c1bf69c5be1f5b0fea93134c06a / Bug 6629 : Sanitizing input from language cookie) has removed a conditional assignement to a simple assignement. C4/Templates.pm: - $lang = $query->cookie('KohaOpacLanguage') - if defined $query and $query->cookie('KohaOpacLanguage'); + $lang = getlanguagecookie($query); And as C4::Templates::getlanguagecookie deference $query for obtain cookie information... when $query is undef, not method to call. Has a bug report created ? The patch for 6629 as introduce a new bug... -- Fr?re S?bastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe T?l: 02.33.84.17.00 Fax: 02.33.34.98.57 Web: http://www.latrappe.fr/ From chris at bigballofwax.co.nz Sun Nov 27 09:22:47 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sun, 27 Nov 2011 21:22:47 +1300 Subject: [Koha-devel] Master broken In-Reply-To: <20111127081629.GA4234@latrappe.fr> References: <20111127081629.GA4234@latrappe.fr> Message-ID: 2011/11/27 Fr?re S?bastien : > On Sat, Nov 26, 2011 at 04:19:26PM -0500, Jared Camins-Esakov wrote: >> >> Can't call method "cookie" on an undefined value at /home/jcamins/k >> ohaclone/C4/Templates.pm line 323 >> > > The patch (9a4e9e54f26b0c1bf69c5be1f5b0fea93134c06a / Bug 6629 : Sanitizing input from language cookie) has removed a conditional assignement to a simple assignement. > > C4/Templates.pm: > - ? ?$lang = $query->cookie('KohaOpacLanguage') > - ? ? ? ?if defined $query and $query->cookie('KohaOpacLanguage'); > + ? ?$lang = getlanguagecookie($query); > > And as C4::Templates::getlanguagecookie deference $query for obtain cookie information... when $query is undef, not method to call. > > Has a bug report created ? The patch for 6629 as introduce a new bug... > -- New patch on 6629, it turns out InstallAuth.pm had its own vulnerability that this error lead me to discover. Patch addresses this error and fixes the vulnerability in the web installer Please test and sign off Chris From sandeep.bhavsar at gmail.com Sun Nov 27 18:06:57 2011 From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR) Date: Sun, 27 Nov 2011 22:36:57 +0530 Subject: [Koha-devel] Information Required Message-ID: Respected All I would like to integrate EBSCO, Open access databases, through pazpar2 in Koha. Kindly guide me for the documentation. Step by step screenshots or video of the process in lecture form will be preferred. -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar at gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeep.bhavsar at gmail.com Mon Nov 28 09:46:07 2011 From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR) Date: Mon, 28 Nov 2011 14:16:07 +0530 Subject: [Koha-devel] git revert Message-ID: Respected All Just upgraded the Koha ver through git and facing the error Can't call method "cookie" on an undefined value at /usr/share/koha/lib/C4/Templates.pm line 323. gone through the yesterday's solution of koha forum but not successful. Kindly guide me for git revert.(exact command) -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar at gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Mon Nov 28 09:47:44 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 28 Nov 2011 21:47:44 +1300 Subject: [Koha-devel] git revert In-Reply-To: References: Message-ID: 2011/11/28 SANDEEP BHAVSAR : > Respected All > > Just upgraded the Koha ver through git and facing the error > > Can't call method "cookie" on an undefined value at > /usr/share/koha/lib/C4/Templates.pm line 323. > > gone through the yesterday's solution of koha forum but not successful. > > You could wait a few minutes, and do a new git pull. The fix for that error is being checked by the Release Manager at the moment Chris From paul.poulain at biblibre.com Mon Nov 28 10:00:10 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 Nov 2011 10:00:10 +0100 Subject: [Koha-devel] git revert In-Reply-To: References: Message-ID: <4ED34D9A.7020701@biblibre.com> Le 28/11/2011 09:47, Chris Cormack a ?crit : > 2011/11/28 SANDEEP BHAVSAR : >> Respected All >> >> Just upgraded the Koha ver through git and facing the error >> >> Can't call method "cookie" on an undefined value at >> /usr/share/koha/lib/C4/Templates.pm line 323. >> >> gone through the yesterday's solution of koha forum but not successful. >> >> > You could wait a few minutes, and do a new git pull. The fix for that > error is being checked by the Release Manager at the moment The patch has been pushed now. So you can update again, it should work now. Don't hesitate to confirm on bugzilla 6629 that it works ! -- 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 Nov 28 10:01:18 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 Nov 2011 10:01:18 +0100 Subject: [Koha-devel] Master broken In-Reply-To: References: <20111127081629.GA4234@latrappe.fr> Message-ID: <4ED34DDE.2020501@biblibre.com> Le 27/11/2011 09:22, Chris Cormack a ?crit : > Patch addresses this error and fixes the vulnerability in the web installer Follow-up patch tested and pushed -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From sandeep.bhavsar at gmail.com Mon Nov 28 10:27:52 2011 From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR) Date: Mon, 28 Nov 2011 14:57:52 +0530 Subject: [Koha-devel] [Koha] git revert In-Reply-To: References: <4ED34D9A.7020701@biblibre.com> Message-ID: Yes again update through git pull, it works !!! Thank you all On Mon, Nov 28, 2011 at 2:36 PM, Joel Harbottle < Joel.Harbottle at hotmail.com.au> wrote: > Hi All, > > I had to attempt it a few times before it worked for me last night, but > the patch works :) - Just need a bit of patience. > > Cheers, > Joel > > > > Sent from my iPhone > > On 28/11/2011, at 7:00 PM, "Paul Poulain" > wrote: > > > Le 28/11/2011 09:47, Chris Cormack a ?crit : > >> 2011/11/28 SANDEEP BHAVSAR : > >>> Respected All > >>> > >>> Just upgraded the Koha ver through git and facing the error > >>> > >>> Can't call method "cookie" on an undefined value at > >>> /usr/share/koha/lib/C4/Templates.pm line 323. > >>> > >>> gone through the yesterday's solution of koha forum but not successful. > >>> > >>> > >> You could wait a few minutes, and do a new git pull. The fix for that > >> error is being checked by the Release Manager at the moment > > The patch has been pushed now. So you can update again, it should work > > now. Don't hesitate to confirm on bugzilla 6629 that it works ! > > > > > > -- > > Paul POULAIN > > http://www.biblibre.com > > Expert en Logiciels Libres pour l'info-doc > > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > > Koha mailing list http://koha-community.org > > Koha at lists.katipo.co.nz > > http://lists.katipo.co.nz/mailman/listinfo/koha > -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar at gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Mon Nov 28 14:35:11 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Mon, 28 Nov 2011 08:35:11 -0500 Subject: [Koha-devel] Bug 6328 (fine in days) and updatedatabase In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> Message-ID: On Thu, Nov 24, 2011 at 11:02 AM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain > wrote: > > Yes it does: if a customer has sponsored a feature with DB changes, > > applying the patch to this customer before it's included in official > > version is a nightmare. And it appends more than once a year for > BibLibre. > > > > IMHO customers who want features before master inclusion is really a > vendor issue, not a community issue. Yes, we want to make changes that > will make life easier on vendors (and therefore their customers), > *but* not at the expense of rushing and possibly introducing a > potentially buggy, not-throughly-tested "enhancement." > Agreed. While it's not ideal, having a separate script for non-community feature database changes isn't that difficult, if you need to do it a lot. And it's encouragement to make sure that all database changes are idempotent, which isn't a bad thing. I decided not to go that route, because any features of that complexity go to the community first. This way someone else tests them before they're deployed. But putting private updates in a different file is easily manageable, and greatly reduces merge conflicts. I don't remember exactly how I did it off the top of my head, but I think I just added an updatedatabase-cp.pl script which was run by the updatedatabase.pl script, when I was experimenting with applying database updates in advance of the features being committed. I did this way back, when I needed OpacPublic and we were still working on revising the patch for inclusion in Master. 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 cnighswonger at foundations.edu Tue Nov 29 03:05:02 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 28 Nov 2011 21:05:02 -0500 Subject: [Koha-devel] Koha 3.6.1 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.6.1. The package can be retrieved from: http://download.koha-community.org/koha-3.06.01.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.06.01.tar.gz.MD5 http://download.koha-community.org/koha-3.06.01.tar.gz.MD5.asc http://download.koha-community.org/koha-3.06.01.tar.gz.sig Release notes for 3.6.1 are below. Come and get it! RELEASE NOTES FOR KOHA 3.6.1 29 Nov 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.6.1 can be downloaded from: http://download.koha-community.org/koha-3.06.01.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.6.1 is a bugfix/maintenance release. Highlights of 3.6.1 ====================== 6628 critical [security] help system use insecure REFERRER for file inclusion 4211 major Acquisitions actions on suggestions don't generate email 6824 major Basket permissions not looked up correctly 6977 major Support for repeated subfields when importing an authority into a biblio record field. 7069 major Javascript errors in tags/review 7207 major Cannot export label batches Bugs fixed in 3.6.1 ====================== 2847 normal Use HTML escape in templates where appropriate 3958 normal Standardize vendor/supplier/bookseller terminology 5072 normal Filling an order page with no budget defined causes a 500 error 5885 normal UNIMARC XSLT changes 5974 normal Bogus auth check for "StaffMember" role 6253 normal Unified Patron Search subroutine 6280 normal Invalid SQL being passed in circulation checkout 6369 normal Formatting problems on some items when printing an order form (PDF). 6390 normal Basket only visible for librarian who created it 6676 normal Acquisition basket access control trivially by-passable 6963 normal When creating a new order, the item isn't added if its barcode already exists in the items table. 3184 enhancement Show creator and budget receiving a document 4161 enhancement When adding Vendor default to active currencies 5436 enhancement Extended patron attributes display improvements 6721 enhancement Add Basket number and Invoice number search 6875 enhancement de-nesting C4 packages 7173 enhancement Detect duplicates when creating items while receiving System requirements ====================== Changes since 3.4: * Perl 5.10 is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.6/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese (Taiwan) * Danish * English (USA) * English (UK) * French (France) * German * Italian * Portuguese (Brazil) * Spanish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.6 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr??d??ric Demians QA Manager: Ian Walls Bug Wranglers: MJ Ray, Marcel Roy, Paul Poulain, Mason James Release Maintainer (3.4.x): Chris Nighswonger Release Maintainer (3.6.x): Chris Nighswonger Credits ====================== We thank the following libraries who are known to have sponsored new features in Koha 3.6: * Los Gatos Public Library * NEKLS * East Brunswick Public Library * Athens County Public Libraries * Horowhenua Library Trust * Halton Borough Council * South Taranaki District Council We thank the following individuals who contributed patches to Koha 3.6.1. 1 Nahuel ANGELINETTI 5 Fr??d??rick Capovilla 12 Chris Cormack 2 Fr??d??ric Demians 4 Katrin Fischer 6 Owen Leonard 1 Julian Maurice 1 Joy Nelson 3 Chris Nighswonger 2 Maxime Pelletier 5 Paul Poulain 2 Liz Rea 1 Marcel de Rooy 1 Salvador Zaragoza Rubio 7 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.6.x (i.e., this version of Koha and future bugfix releases) is 3.6.x. The next major feature release of Koha will be Koha 3.8.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 29 Nov 2011 at 01:20:19Z ##### From chris at bigballofwax.co.nz Tue Nov 29 03:15:55 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 29 Nov 2011 15:15:55 +1300 Subject: [Koha-devel] Koha 3.6.1 is now available In-Reply-To: References: Message-ID: On 29 November 2011 15:05, Chris Nighswonger wrote: > It is with pleasure that I announce the release of Koha 3.6.1. > > The package can be retrieved from: > > http://download.koha-community.org/koha-3.06.01.tar.gz > > You can use the following checksum and signature files to verify the download: > > http://download.koha-community.org/koha-3.06.01.tar.gz.MD5 > http://download.koha-community.org/koha-3.06.01.tar.gz.MD5.asc > http://download.koha-community.org/koha-3.06.01.tar.gz.sig > I would thoroughly recommend anyone running 3.6.0 to upgrade to 3.6.1 as it contains a couple of security fixes. Chris From tdavis at uttyler.edu Tue Nov 29 18:05:08 2011 From: tdavis at uttyler.edu (Elliott Davis) Date: Tue, 29 Nov 2011 11:05:08 -0600 Subject: [Koha-devel] Hourly Loans Message-ID: <8754F6E19960C249BB9C8FFECA627740018DD91C4C@dogbert> Hi Koha Devels, I am running the hourly loans branch in my production system and am merging it daily with master. It seems like this gets harder with each merge because of increasing code conflicts. Recently I have set up a branch to keep hourly up to date with master that is on github. As I'm sure most of you know I have been actively pushing to get the hourly branch merged into master. I am sending this message to the devel list in an attempt to possibly expedite this process. The issue that I believe we have is this branch is fairly untested which we all know can cause issues when pushed into prod. I am running this branch with no issues in production but I would like to see some other libraries pick up this branch and test. As a side note I think to really generate serious academic library interest in Koha the hourly loans module is a must. I know it was for us when we implemented Koha and not having it in master is really hurting us in regards to time solving merge conflicts. Let me know if anyone is interested. Best, Elliott Davis Robert R. Muntz Library University of Texas at Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielg.koha at gmail.com Tue Nov 29 23:23:15 2011 From: danielg.koha at gmail.com (Daniel Grobani) Date: Tue, 29 Nov 2011 14:23:15 -0800 Subject: [Koha-devel] Official Koha Newsletter: Volume 2, Issue 11: November 2011 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-2issue-11-november-2011] Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 11: November 2011 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.4.6 Released Koha 3.4.x String Freeze Koha 3.6.1 Released Request for Koha Data for Development Koha Community New Koha Libraries Community Gossip PTFS/LibLime Granted Provisional NZ Koha Trademark Past Koha Events KohaCon11 Reports November General IRC Meeting Global Bug Squashing Day Upcoming Koha Events December General IRC Meeting KohaCon12 Koha Development Koha 3.4.6 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.4.6. The package can be retrieved from: http://download.koha-community.org/koha-3.04.06.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.06.tar.gz.MD5 http://download.koha-community.org/koha-3.04.06.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.06.tar.gz.sig Release notes for 3.4.6 are at http://koha-community.org/koha-3-4-6. Koha 3.4.x String Freeze by Chris Nighswonger The 3.4.x branch will enter a string freeze on 30 November. Koha 3.4.7 will release on 7 December. Koha 3.6.1 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.6.1. The package can be retrieved from: http://download.koha-community.org/koha-3.06.01.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.06.01.tar.gz.MD5 http://download.koha-community.org/koha-3.06.01.tar.gz.MD5.asc http://download.koha-community.org/koha-3.06.01.tar.gz.sig Release notes for 3.6.1 are at http://koha-community.org/koha-3-6-1. Request for Koha Data for Development by Chris Nighswonger A common problem among those of us who do development work on Koha is the lack of complete datasets for the development and testing of features. This is probably more of a problem for those of us who do not support a large variety of organizations running Koha. I would like to see some good, sanitized datasets available for development and testing. Several of us have pleaded for this for years. Just now, the lack of a good dataset including a sizable number of serials is preventing me from doing some testing and development on DataTables integration work, which has been started by Biblibre. So, this is a request to all of you libraries out there with small, medium, or large datasets who would be willing to contribute sanitized data for development purposes, to do so. It would be a great way to give back to the community that has provided such a wonderful product with all of its attendant benefits. Kind Regards, Chris Nighswonger Koha 3.4/3.6 Release Maintainer cnighswonger at foundations.edu Koha Community New Koha Libraries Hernando County Public Library (via ByWater Solutions) Reserve Bank of New Zealand (via Catalyst) Shasta Historical Society (via ByWater Solutions) Community Gossip Albert Oller has joined ByWater Solutions as Development Support Specialist. ByWater Solutions has posted a Koha Testing Plan at http://bywatersolutions.com/koha-testing-plan/. Chris Cormack has posted a visualisation of when work is done on Koha at http://blog.bigballofwax.co.nz/2011/11/04/nice-visualisation-of-when-work-is-done-on-koha/. Chris Hall is back working on Koha at Catalyst for the New Zealand summer. Ed Veal has joined ByWater Solutions as Development Support Specialist. Ian Walls writes about integrating Solr into Koha at http://bywatersolutions.com/2011/11/02/kohacon-11-solr-and-koha/. Laurence Lefaucheur is now posting a French translation of the Koha community newsletter at http://www.koha-fr.org/category/tags/newsletter. Paul Poulain, Koha 3.8 Release Manager, will be publishing a monthly newsletter summarizing 3.8 developments of the previous month. His first issue can be read at http://lists.koha-community.org/pipermail/koha-devel/2011-November/036525.html. Paul Poulain has also posted a first draft of a document outlining how the release manager pushes a patch at http://wiki.koha-community.org/wiki/How_the_RM_push. PTFS/LibLime Granted Provisional NZ Koha Trademark PTFS/LibLime has been granted provisional use of a trademark for the use of the term Koha as it applies to Integrated Library Software (ILS) in New Zealand. PTFS?s press release is at http://www.liblime.com/ptfsliblime-granted-provisional-use-of-koha-trademark-in-new-zealand?a=1&c=1254. Joann Ransom?s plea to assist Horowhenua Library Trust in disputing the decision is at http://library-matters.blogspot.com/2011/11/plea-for-help-from-horowhenua-library.html; her update is at http://library-matters.blogspot.com/2011/11/update-on-nz-koha-trademark.html. Nicole Engard is maintaining a bibliography of the dispute. Her initial post is at http://www.web2learning.net/archives/4910; updates are at http://www.web2learning.net/archives/4915 and http://www.web2learning.net/archives/4921. The entire bibliography can be viewed at https://www.zotero.org/groups/koha/items/collectionKey/RR77I3HT/order/dateModified. Past Koha Events KohaCon11 Reports KohaCon11 was held 31 October to 6 November 2011 in Thane, India. Bob Birchall reports: One of the exciting aspects of the Hackfest was that a Koha training course was conducted for about 36 local librarians and students. Run over two days, the course covered all major features of Koha. Trainers were Jo Ransom (New Zealand), Marijana Glavica (Croatia), Irma and Bob Birchall (Australia) and Savitra Sirohi (India); Brooke Johnson (US) helped out and ByWater Solutions provided the training Koha instance ? a real international effort! It was a pleasure to teach these librarians who were so hungry for knowledge of Koha. Also during the Hackfest the translation of Koha into Hindi was progressed and translation into Marathi started. Congratulations to the staff and students of VPM Thane for this outstanding contribution to Koha. Robin Sheat reports: A few of us got together to work on improving Koha?s Open Library integration. On the OL side there was Noufal Ibrahim and Anand Chitipothu. From the Koha side, Dobrica Pavlinu?i?, Ian Walls, Savitra Sirohi, and I spent time discussing how to make things work. I then spent much of the hackfest adding features to Koha that would allow Open Library to become something of a central cover repository with streamlined uploading to it. At the same time, Anand was working on the APIs on the OL side that Koha would talk to to make this easy. This project is still a work in progress, but the current state can be seen at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7152. For more stuff about the Open Library + Koha integration that went on, have a look at Noufal?s blog post at http://blog.openlibrary.org/?p=954. JoAnn Ransom blogged about some of her KohaCon11 experiences at http://library-matters.blogspot.com/2011/10/notes-from-day-1-of-kohacon11-in-thane.html. The slides from her keynote address are at http://www.slideshare.net/jransom/it-takes-a-village-9955138. Paul Poulain blogged about BibLibre?s presentations at http://drupal.biblibre.com/en/blog/entry/kohacon11-our-presentations. Mumbai-based newspaper DNA reported on KohaCon11 at http://epaper.dnaindia.com/epapermain.aspx?edorsup=Sup&queryed=37&querypage=7&boxid=30762914&parentid=153604&eddate=11/05/2011. November General IRC Meeting The November general IRC meeting was held on 16 November 2011. For more info, including the agenda and links to the minutes, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_16_November_2011. Global Bug Squashing Day by Magnus Enger A Global bug sqashing day was held on 4 November 2011, and there was much rejoicing. For the numbers, see http://wiki.koha-community.org/wiki/2011-11-04_Global_bug_squashing_day. Upcoming Koha Events December General IRC Meeting The December general IRC meeting will be held on 7 December 2011. For more info, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_December_2011. KohaCon12 MJ Ray reports that KohaCon12 will probably be held 5-7 June 2012 for the conference and 9-11 June for the hackfest. From paul.poulain at biblibre.com Wed Nov 30 06:21:08 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 06:21:08 +0100 Subject: [Koha-devel] Hourly Loans In-Reply-To: <8754F6E19960C249BB9C8FFECA627740018DD91C4C@dogbert> References: <8754F6E19960C249BB9C8FFECA627740018DD91C4C@dogbert> Message-ID: <4ED5BD44.5070107@biblibre.com> Le 29/11/2011 18:05, Elliott Davis a ?crit : > Hi Koha Devels, > I am running the hourly loans branch in my production system and am > merging it daily with master. Hi Elliott, Do you mean http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5549 ? I've a few comments: * about the interest of this agree it's a major improvement * if you run it in production, and are not the author of the patch, you can change the statut so "signed-off". And I tend to say using it in production is a good proof it works. Then, QA would be made, and I can promize i'll take care of QA as quickly as possible, this feature is a must, I agree. * This bug, as all bugs with a lot of comment has a problem: how to test it ? There are patch attached, branches. There is a new dependancy (comment 5). It's very complicated to understand how to test. We must address this problem for this bug, and, ideally, find a re-usable way to do so. I'll start a thread about that in a few minuts, in the meantime, please just add a comment explaining everything. HTH -- 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 Nov 30 06:50:55 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 06:50:55 +0100 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> Message-ID: <4ED5C43F.3080300@biblibre.com> Le 24/11/2011 17:02, Chris Nighswonger a ?crit : > On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain > IMHO customers who want features before master inclusion is really a > vendor issue, not a community issue. Chris_n, I disagree (strongly) with you here: according to me, anyone issue is important. We should not discard anything just because it's "a vendor issue". Well, at least when the ppl who had a problem comes with a patch! For example, Eliott' thread started a few hours ago is interesting: frankly, having pain merging the hourly loans patch is "a library issue, not a community ones". Well, in fact, I don't think so. Solving problems and making ppl happy is important. That's how we will attract more developers. 6 months ago, i've started a thread that explain this better than I do: http://www.codesimplicity.com/post/open-source-community-simplified/ Just the paragraphs headers: " Retaining Contributors * Respond to contributions immediately. * Be extremely kind and visibly appreciative. * Encourage a total absence of personal negativity. " In this specific case, bug 7167 is trying to solve a problem that has been discussed during hackfest, and ppl agree it is (a problem). So it's not a "vendor issue" only. The patch will: * ease developer work (ie: merge conflict removed) * ease RM work (ie: no number to assign when pushing). It also mean lower the risk of doing a mistake * simplify the code a little bit (ie: not checking on everypage that there is something to do, it's made just on mainpage.pl) * give more feedback (ie: DB changes are stored in the database. If there is a problem, you'll be able to know what happened. As a vendor, it's important: we can "prove" that a patch has been applied -or not- even 2 months after the update. That's a *big* improvement when you have 100+ Koha setups to manage !) I can also add "having a feature before official inclusion" is, in fact very good for the community ! I think there are some (few ?) libraries that could be happy to: * test a patch on their test server * if it works, apply it to production server * if things goes OK, "sign-off" the patch on bugzilla => patch is signed-off, it's good for the community. > Yes, we want to make changes that > will make life easier on vendors (and therefore their customers), > *but* not at the expense of rushing and possibly introducing a > potentially buggy, not-throughly-tested "enhancement." I don't understand why you say that. The patch is submitted, i've tested it heavily, I don't plan to push is without respecting the workflow, so there is no more risks than for any other patch ! What I agree with is that I won't let this bug be lost in the wild, as it's an important structural change I want to do first before pushing any important new feature. For version consistency, it's better. So, my proposal: stop feeding a possible troll, and go test my patch ;-) HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From tdavis at uttyler.edu Wed Nov 30 07:21:32 2011 From: tdavis at uttyler.edu (Elliott Davis) Date: Wed, 30 Nov 2011 00:21:32 -0600 Subject: [Koha-devel] Hourly Loans In-Reply-To: <4ED5BD44.5070107@biblibre.com> Message-ID: Hi Paul, First of all thanks for getting back to me on the issue. Yes, the ticket I'm talking about is 5549. I have signed off on this patch before since I have made modifications (see comments 27, 29, and 32) and as such I was under the impression that I am no longer eligible to sign off. I am still relatively new to Koha development and the patching process so you'll have to forgive me if I am wrong. I agree that running it in production is a very good test and thus far we haven't run across any major issues. If we have they have been addressed and patched. I also agree that this is a big issue with large bug testing. I think working out a procedure for testing this bug would be a great precursor for implementing Solr. Let me know your thoughts or if you would like any more information. Elliott Davis On 11/29/11 11:21 PM, "Paul Poulain" wrote: >Le 29/11/2011 18:05, Elliott Davis a ?crit : >> Hi Koha Devels, >> I am running the hourly loans branch in my production system and am >> merging it daily with master. >Hi Elliott, > >Do you mean http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5549 >? >I've a few comments: >* about the interest of this agree it's a major improvement >* if you run it in production, and are not the author of the patch, you >can change the statut so "signed-off". And I tend to say using it in >production is a good proof it works. Then, QA would be made, and I can >promize i'll take care of QA as quickly as possible, this feature is a >must, I agree. >* This bug, as all bugs with a lot of comment has a problem: how to test >it ? There are patch attached, branches. There is a new dependancy >(comment 5). It's very complicated to understand how to test. We must >address this problem for this bug, and, ideally, find a re-usable way to >do so. I'll start a thread about that in a few minuts, in the meantime, >please just add a comment explaining everything. > >HTH >-- >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 Wed Nov 30 10:15:13 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 10:15:13 +0100 Subject: [Koha-devel] Testing patches with a lot of comments Message-ID: <4ED5F421.9070209@biblibre.com> Hello koha-devel, I sometimes face patches that have a lot of comments, more than one patch, and it's not always easy to understand how to test the proposed patches. We need the following things to be very clearly explained: * test case / step to reproduce * which patch(es) to apply (* anything else ?) Does anyone see a way to have those points clearly displayed/described in the bug ? For example, look at bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5549, about hourly loans = 33 comments, it has only 2 small patches, it's clear more things are needed, maybe the git repo in comment 1. Or is it the one in comment 3? which repo does comment 6 use ? Maybe it's comment 25 in fact. Anyway, it's quite unclear, and, even with all my willingness, I don't know how/what to test. I took this example just because Eliott rises this bug a few hours ago on this ML. But it's not a single case. If anyone has a suggestion, it's welcomed !!! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From Katrin.Fischer at bsz-bw.de Wed Nov 30 10:50:05 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Wed, 30 Nov 2011 10:50:05 +0100 Subject: [Koha-devel] Testing patches with a lot of comments In-Reply-To: <4ED5F421.9070209@biblibre.com> References: <4ED5F421.9070209@biblibre.com> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD019E2340@Bodensee.bsz-bw.de> Hi, I agree with Paul that we need a clear description to be able to test a big feature like this: - does it add new system preferences? - new options in other configuration parameters? - does it need a cronjob? - does it introduce new requirements? - which modules/parts of Koha might be affected by those changes? - ... Additionally, we need information about test cases. But ideally people should not only test those, but think about it and test a bit more. To come up with a complete test plan for big features is very hard. I think it's a plus that this branch is already used in production, but it still needs testing. One library might not use all features or have figured out a setup that works, while variations of this configuration might not. I think we could use a wiki page here, where people can see what to do and how to test, add comments about what they tested, additional test cases etc. For other smaller bugs I would like to see the test plans included in the commit message. So the most recent patch should have all the information I need for testing. -- Katrin > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Paul Poulain > Sent: Wednesday, November 30, 2011 10:15 AM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] Testing patches with a lot of comments > > Hello koha-devel, > > I sometimes face patches that have a lot of comments, more than one > patch, and it's not always easy to understand how to test the proposed > patches. > We need the following things to be very clearly explained: > * test case / step to reproduce > * which patch(es) to apply > (* anything else ?) > > Does anyone see a way to have those points clearly displayed/described > in the bug ? > > For example, look at bug > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5549, about > hourly loans = 33 comments, it has only 2 small patches, it's clear more > things are needed, maybe the git repo in comment 1. Or is it the one in > comment 3? which repo does comment 6 use ? Maybe it's comment 25 in > fact. Anyway, it's quite unclear, and, even with all my willingness, I > don't know how/what to test. > > I took this example just because Eliott rises this bug a few hours ago > on this ML. But it's not a single case. > > If anyone has a suggestion, it's welcomed !!! > -- > 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 magnus at enger.priv.no Wed Nov 30 10:50:54 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 30 Nov 2011 10:50:54 +0100 Subject: [Koha-devel] New dates for GBSD: 2011-12-07 and 2012-01-06 Message-ID: Yes, that's right, after some consultation on IRC I'm proposing two dates, to avoid the short notices that have been creeping up on us lately: http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day And yes, 2011-12-07 is a Wednesday (some of us have been talking about trying another dey than Friday) and yes it does fall on the same date as the next general IRC meeting. The devious plan of the bug wranglers is to cajole people into squashing bugs after the meeting! ;-) See you there! Magnus From paul.poulain at biblibre.com Wed Nov 30 10:53:01 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 10:53:01 +0100 Subject: [Koha-devel] New dates for GBSD: 2011-12-07 and 2012-01-06 In-Reply-To: References: Message-ID: <4ED5FCFD.8090903@biblibre.com> Le 30/11/2011 10:50, Magnus Enger a ?crit : > http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day Just to let everybody know: BibLibre has planned working on bugzilla on friday (in 2 days). It's too late for us to switch to dec 7th, so you can expect an unusual activity on bugzilla on dec, 2nd as well. A+ -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Wed Nov 30 15:54:50 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 30 Nov 2011 09:54:50 -0500 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: <4ED5C43F.3080300@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> Message-ID: On Wed, Nov 30, 2011 at 12:50 AM, Paul Poulain wrote: > Le 24/11/2011 17:02, Chris Nighswonger a ?crit : >> On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain >> IMHO customers who want features before master inclusion is really a >> vendor issue, not a community issue. > Chris_n, I disagree (strongly) with you here: according to me, anyone > issue is important. We should not discard anything just because it's "a > vendor issue". Well, at least when the ppl who had a problem comes with > a patch! I stand by my original statement. Issues which are fundamentally vendor/client are not and should not be the driving/motivating/controlling force behind the way the community moves. If this were the case, chaos would ensue as we change direction attempting to "fix" vendor/client issues, etc. I think you my be interpreting my statement as "anti-vendor." As I clearly stated: it is not. We do need to make adjustments to make the life of a vendor as easy as possible. But rushing a db update change because Biblibre, or any other vendor, has clients who run non-master modifications, is not at all a valid option. Having said that, if you have the proposed db update changes throughly tested, debugged, and production ready, then by all means, let's implement them in master. You will carefully recall my objections: 1. We should not introduce this "feature" without proof-of-concept *and* through testing. This "feature" over any other must be as stable as we can make it when it is introduced into master simply because instability could greatly slow down development. And while we are speaking of vendor/client relationships, imagine what problems ensue for vendors who have clients running over master when master breaks? Well, the vendor knows the risk and assumes liability for it in those cases, but you can see where we would be if we suddenly judged every move by vendor/client relationships. 2. If the db update improvements are introduced into master during the 3.7.x development cycle, they must be back ported to the 3.6.x branch. The only condition I will withdraw this objection under is if this "feature" is pushed immediately prior to the release of 3.8.0. I think that as a non-vendor, our views will always be in a tension. But that tension should be constructive in helping to maintain a proper balance in the best interest of the community. > For example, Eliott' thread started a few hours ago is interesting: > frankly, having pain merging the hourly loans patch is "a library issue, > not a community ones". Well, in fact, I don't think so. Solving problems > and making ppl happy is important. That's how we will attract more > developers. It is a pain. And that pain may be getting to a sufficient level to motivate some to either test/sign-off/QA or to pay to have it done... problem solved. Until that pain reaches that level, it will continue to be a pain. Whatever one's viewpoint, In a majority rules context, the majority does not always move the direction of the individual. Under those rules, it is incumbent upon the individual to create a majority. No single vendor represents a majority. The rules for acceptance of a feature into master have been well defined at this point in our history. Sign-off, QA approval, and you're in. I'm not sure where hourly loans is hung up in this process, but I don't see why it has to be if someone wants to throw time or money at it. Kind Regards, Chris From paul.poulain at biblibre.com Wed Nov 30 16:53:32 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 16:53:32 +0100 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> Message-ID: <4ED6517C.9020808@biblibre.com> Le 30/11/2011 15:54, Chris Nighswonger a ?crit : > We do need to make adjustments to make the life of a vendor as easy as > possible. OK, so we agree. I just want that ! (is my english saying something so different than this ?) > But rushing a db update change because Biblibre, or any > other vendor, has clients who run non-master modifications, is not at > all a valid option. agreed. And I don't want to rush pushing. I just rushed proposing something. Now, please test ! I want to do this quickly not because our customers are in a hurry, but because i'm starting pushing for 3.8 and I want to have a clean situation, not a mechanism that is the old one for the first 3 months, and the new one for the last 3 months. > Having said that, if you have the proposed db update changes throughly > tested, debugged, and production ready, then by all means, let's > implement them in master. OK, so, feel free to test ! > You will carefully recall my objections: > > 1. We should not introduce this "feature" without proof-of-concept > *and* through testing. This "feature" over any other must be as stable > as we can make it when it is introduced into master simply because > instability could greatly slow down development. agreed. And that's why we made so many tests (Jonathan and me) and took care of some problems that have been noticed. Now, I think I've submitted a patch that works quite well, with documentation. So please test & report any issue you could find ! > And while we are > speaking of vendor/client relationships, imagine what problems ensue > for vendors who have clients running over master when master breaks? > Well, the vendor knows the risk and assumes liability for it in those > cases, but you can see where we would be if we suddenly judged every > move by vendor/client relationships. agreed (even if we don't have any library running master) > 2. If the db update improvements are introduced into master during the > 3.7.x development cycle, they must be back ported to the 3.6.x branch. > The only condition I will withdraw this objection under is if this > "feature" is pushed immediately prior to the release of 3.8.0. I don't understand why we need to backport this new mechanism. With the new system, we can address separately updateDB patches for stable and master version (with the same patch, I don't mean in 2 different patches). I think that's how we must do it. Let me give you an example with actual mechanism: Day 1 => updatedatabase for bugfix passes QA and can be pushed Day 2 => updatedatabase for a new feature passes QA and can be pushed Day 3 => updatedatabase for a bugfix passes QA and can be pushed How will you deal with D2 patch ? ATM, you'll have a problem, isn't it ? D1 = should be 3.07.00.001 on master D2 = should be 3.07.00.002 on master D3 = should be 3.07.00.003 on master except you're not supposed to push D2 patch on stable branch. (or there's something i'm missing) > I think that as a non-vendor, our views will always be in a tension. > But that tension should be constructive in helping to maintain a > proper balance in the best interest of the community. +1 -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Wed Nov 30 16:58:05 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 30 Nov 2011 10:58:05 -0500 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: <4ED6517C.9020808@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> <4ED6517C.9020808@biblibre.com> Message-ID: On Wed, Nov 30, 2011 at 10:53 AM, Paul Poulain wrote: > Le 30/11/2011 15:54, Chris Nighswonger a ?crit : >> 2. If the db update improvements are introduced into master during the >> 3.7.x development cycle, they must be back ported to the 3.6.x branch. >> The only condition I will withdraw this objection under is if this >> "feature" is pushed immediately prior to the release of 3.8.0. > I don't understand why we need to backport this new mechanism. > With the new system, we can address separately updateDB patches for > stable and master version (with the same patch, I don't mean in 2 > different patches). I think that's how we must do it. > > Let me give you an example with actual mechanism: > Day 1 => updatedatabase for bugfix passes QA and can be pushed > Day 2 => updatedatabase for a new feature passes QA and can be pushed > Day 3 => updatedatabase for a bugfix passes QA and can be pushed > > How will you deal with D2 patch ? > ATM, you'll have a problem, isn't it ? > D1 = should be 3.07.00.001 on master > D2 = should be 3.07.00.002 on master > D3 = should be 3.07.00.003 on master > except you're not supposed to push D2 patch on stable branch. > (or there's something i'm missing) I think you have missed something. Take a look at the release notes for 3.6.1. You will see several enhancement bugs included. These are smallish and are included because they improve existing features. This has been true from day one of my tenure as Release Maintainer. If you remove the ability to back port all enhancements, you remove this option. I maintain my opposition to not back-porting the db update changes. Kind Regards, Chris From ian.walls at bywatersolutions.com Wed Nov 30 17:18:44 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 30 Nov 2011 11:18:44 -0500 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> <4ED6517C.9020808@biblibre.com> Message-ID: As eager as I am to have a more robust database update method, I think the ship has sailed for 3.8. I believe the new mechanism should be part of both 3.6.x and master, so we're going to need a time when 3.6.x == master, at least on the DB level. That may or may not happen, as new features come along. The next time we know stable release and master will be equal is just after 3.8 releases. So, how about we test this new mechanism, but slate it for release along with 3.8? -Ian On Wed, Nov 30, 2011 at 10:58 AM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > On Wed, Nov 30, 2011 at 10:53 AM, Paul Poulain > wrote: > > Le 30/11/2011 15:54, Chris Nighswonger a ?crit : > >> 2. If the db update improvements are introduced into master during the > >> 3.7.x development cycle, they must be back ported to the 3.6.x branch. > >> The only condition I will withdraw this objection under is if this > >> "feature" is pushed immediately prior to the release of 3.8.0. > > I don't understand why we need to backport this new mechanism. > > With the new system, we can address separately updateDB patches for > > stable and master version (with the same patch, I don't mean in 2 > > different patches). I think that's how we must do it. > > > > Let me give you an example with actual mechanism: > > Day 1 => updatedatabase for bugfix passes QA and can be pushed > > Day 2 => updatedatabase for a new feature passes QA and can be pushed > > Day 3 => updatedatabase for a bugfix passes QA and can be pushed > > > > How will you deal with D2 patch ? > > ATM, you'll have a problem, isn't it ? > > D1 = should be 3.07.00.001 on master > > D2 = should be 3.07.00.002 on master > > D3 = should be 3.07.00.003 on master > > except you're not supposed to push D2 patch on stable branch. > > (or there's something i'm missing) > > I think you have missed something. Take a look at the release notes > for 3.6.1. You will see several enhancement bugs included. These are > smallish and are included because they improve existing features. This > has been true from day one of my tenure as Release Maintainer. If you > remove the ability to back port all enhancements, you remove this > option. > > I maintain my opposition to not back-porting the db update changes. > > Kind Regards, > Chris > _______________________________________________ > 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Nov 30 17:32:53 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 17:32:53 +0100 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> <4ED6517C.9020808@biblibre.com> Message-ID: <4ED65AB5.5080500@biblibre.com> Le 30/11/2011 17:18, Ian Walls a ?crit : > As eager as I am to have a more robust database update method, I think > the ship has sailed for 3.8. I believe the new mechanism should be part > of both 3.6.x and master, so we're going to need a time when 3.6.x == > master, at least on the DB level. That may or may not happen, as new > features come along. The next time we know stable release and master > will be equal is just after 3.8 releases. > > So, how about we test this new mechanism, but slate it for release along > with 3.8? I don't see where/why the ship has sailed for 3.8. I have pushed only DB updates that are bugfixes, and would not be changed at all by the new system. I just refrain from pushing big ENH that would make the ship sail. And that's why I seem to be in a hurry: it's because I want to block as shortly as possible the ship! -- 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 Nov 30 17:34:37 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Nov 2011 17:34:37 +0100 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> <4ED6517C.9020808@biblibre.com> Message-ID: <4ED65B1D.8070406@biblibre.com> Le 30/11/2011 16:58, Chris Nighswonger a ?crit : > I maintain my opposition to not back-porting the db update changes. Just to be clear: I have no opposition to back-port this improvement. I just was not seeing why it would be necessary. Now I understand. And agree. And nothing must be changed on the new system, as it can handle every case (I think). -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Wed Nov 30 17:49:49 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 30 Nov 2011 11:49:49 -0500 Subject: [Koha-devel] updatedatabase (bug 7167) In-Reply-To: <4ED65B1D.8070406@biblibre.com> References: <4ECCD29E.5070606@biblibre.com> <4ECD0B63.9080201@biblibre.com> <4ECD2BAD.6040605@biblibre.com> <4ECE625B.9060701@biblibre.com> <4ED5C43F.3080300@biblibre.com> <4ED6517C.9020808@biblibre.com> <4ED65B1D.8070406@biblibre.com> Message-ID: On Wed, Nov 30, 2011 at 11:34 AM, Paul Poulain wrote: > Le 30/11/2011 16:58, Chris Nighswonger a ?crit : >> I maintain my opposition to not back-porting the db update changes. > > Just to be clear: I have no opposition to back-port this improvement. I > just was not seeing why it would be necessary. Now I understand. And agree. > And nothing must be changed on the new system, as it can handle every > case (I think). Ok, as soon as the necessary sign-off/QA is done, I have no objection to this being pushed up. We just need to act a soon as possible. I'll try to sign-off today or tomorrow, but it would be good for others to do so as well. Kind Regards, Chris From paul.a at aandc.org Wed Nov 30 20:47:16 2011 From: paul.a at aandc.org (Paul) Date: Wed, 30 Nov 2011 14:47:16 -0500 Subject: [Koha-devel] Fresh install 3.6.1 Message-ID: <5.2.1.1.2.20111130142258.070d5930@stormy.ca> Just built a new server (Ubuntu 11.10) and preparing it for a fresh install of Koha 3.6.1 -- we're trying to take all precautions ahead of time, so ran the Perl dependencies script: paul at nelson:~/koha/koha-3.06.01$ perl koha_perl_deps.pl -m -u [Wed Nov 30 09:07:17 2011] koha_perl_deps.pl: could not find ParserDetails.ini in /usr/local/share/perl/5.10.1/XML/SAX Installed Required Module is Module Name Version Version Required -------------------------------------------------------------------------------------------- Business::ISBN 0 * 2.05 Yes CGI::Session::Driver::memcached 0 * 0.04 No Gravatar::URL 0 * 1.03 No -------------------------------------------------------------------------------------------- Total modules reported: 3 * Module is missing or requires an upgrade. I would appreciate help on two points: 1) I don't know if that is the definitive list of "missing" dependencies, as koha_perl_deps.pl seems to be looking for ParserDetails.ini in a spot where it isn't: paul at nelson:~/koha/koha-3.06.01$ locate ParserDetails.ini /etc/perl/XML/SAX/ParserDetails.ini /usr/share/perl5/XML/SAX/ParserDetails.ini /var/lib/ucf/cache/:etc:perl:XML:SAX:ParserDetails.ini 2) memcached 1.4.6 *is* installed (haven't yet looked into the other two) Thanks in advance - Paul Paul Tired old sys-admin From chris at bigballofwax.co.nz Wed Nov 30 20:55:28 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 1 Dec 2011 08:55:28 +1300 Subject: [Koha-devel] Fresh install 3.6.1 In-Reply-To: <5.2.1.1.2.20111130142258.070d5930@stormy.ca> References: <5.2.1.1.2.20111130142258.070d5930@stormy.ca> Message-ID: On 1 December 2011 08:47, Paul wrote: > Just built a new server (Ubuntu 11.10) and preparing it for a fresh install > of Koha 3.6.1 -- we're trying to take all precautions ahead of time, so ran > the Perl dependencies script: > > paul at nelson:~/koha/koha-3.06.01$ perl koha_perl_deps.pl -m -u > [Wed Nov 30 09:07:17 2011] koha_perl_deps.pl: could not find > ParserDetails.ini in /usr/local/share/perl/5.10.1/XML/SAX > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Installed ? ? ? ? Required > ? ?Module is > Module Name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Version ? ? ? ? ? Version > Required > -------------------------------------------------------------------------------------------- > Business::ISBN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 * ? ? ? ? ? ? ? 2.05 > ? ? ? ? ? ?Yes > CGI::Session::Driver::memcached ? ? ? ? ? ? ? 0 * ? ? ? ? ? ? ? 0.04 > ? ? ? ? ? ?No > Gravatar::URL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0 * ? ? ? ? ? ? ? 1.03 > ? ? ? ? ? ?No > > -------------------------------------------------------------------------------------------- > Total modules reported: 3 ? ? ? ? ? ? ? ? ? ? ?* Module is missing or > requires an upgrade. > > I would appreciate help on two points: > > 1) ?I don't know if that is the definitive list of "missing" dependencies, > as koha_perl_deps.pl seems to be looking for ParserDetails.ini in a spot > where it isn't: > > paul at nelson:~/koha/koha-3.06.01$ locate ParserDetails.ini > /etc/perl/XML/SAX/ParserDetails.ini > /usr/share/perl5/XML/SAX/ParserDetails.ini > /var/lib/ucf/cache/:etc:perl:XML:SAX:ParserDetails.ini > > 2) ?memcached 1.4.6 *is* installed ?(haven't yet looked into the other two) > memcached might be, but that is asking for a perl module CGI::Session::Driver::memcached The other 2 are perl modules also Chris > Thanks in advance - Paul > > Paul > Tired old sys-admin > _______________________________________________ > 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 Joel.Harbottle at hotmail.com.au Mon Nov 28 10:06:46 2011 From: Joel.Harbottle at hotmail.com.au (Joel Harbottle) Date: Mon, 28 Nov 2011 19:06:46 +1000 Subject: [Koha-devel] [Koha] git revert In-Reply-To: <4ED34D9A.7020701@biblibre.com> References: <4ED34D9A.7020701@biblibre.com> Message-ID: Hi All, I had to attempt it a few times before it worked for me last night, but the patch works :) - Just need a bit of patience. Cheers, Joel Sent from my iPhone On 28/11/2011, at 7:00 PM, "Paul Poulain" wrote: > Le 28/11/2011 09:47, Chris Cormack a ?crit : >> 2011/11/28 SANDEEP BHAVSAR : >>> Respected All >>> >>> Just upgraded the Koha ver through git and facing the error >>> >>> Can't call method "cookie" on an undefined value at >>> /usr/share/koha/lib/C4/Templates.pm line 323. >>> >>> gone through the yesterday's solution of koha forum but not successful. >>> >>> >> You could wait a few minutes, and do a new git pull. The fix for that >> error is being checked by the Release Manager at the moment > The patch has been pushed now. So you can update again, it should work > now. Don't hesitate to confirm on bugzilla 6629 that it works ! > > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha From tanzeem.mb at gmail.com Thu Nov 24 06:35:28 2011 From: tanzeem.mb at gmail.com (tanzeem) Date: Thu, 24 Nov 2011 05:35:28 -0000 Subject: [Koha-devel] what is the need of the tables: deletedbiblio, deletedbiblioitems, deleteditems Message-ID: <1322112927010-5019267.post@n5.nabble.com> what is the need of the tables: deletedbiblio,deletedbiblioitems,deleteditems in the koha database. Does it have anything to do with restoring deleted biblio items.If yes then please explain how to restore deleted values -- View this message in context: http://koha.1045719.n5.nabble.com/what-is-the-need-of-the-tables-deletedbiblio-deletedbiblioitems-deleteditems-tp5019267p5019267.html Sent from the Koha-devel mailing list archive at Nabble.com.