[% IF ( ShowReviewer ) %] + [% IF ( review.avatarurl ) %] +

+ [% END %]

Comment by [% review.title %] diff --git a/opac/opac-detail.pl b/opac/opac-detail.pl index 3e4c76c..cf63a17 100755 --- a/opac/opac-detail.pl +++ b/opac/opac-detail.pl @@ -295,6 +295,13 @@ $template->param( ocoins => GetCOinSBiblio($biblionumber), ); +my $libravatar_available = 0; + +eval 'use Libravatar::URL'; +if (! $@) { + $libravatar_available = 1; +} + my $reviews = getreviews( $biblionumber, 1 ); my $loggedincommenter; foreach ( @$reviews ) { @@ -303,6 +310,9 @@ foreach ( @$reviews ) { $_->{title} = $borrowerData->{'title'}; $_->{surname} = $borrowerData->{'surname'}; $_->{firstname} = $borrowerData->{'firstname'}; + if ($libravatar_available and $borrowerData->{'email'}) { + $_->{avatarurl} = libravatar_url(email => $borrowerData->{'email'}, https => $ENV{HTTPS}); + } $_->{userid} = $borrowerData->{'userid'}; $_->{cardnumber} = $borrowerData->{'cardnumber'}; $_->{datereviewed} = format_date($_->{datereviewed}); -- 1.7.4.4 From francois at debian.org Fri May 6 05:08:26 2011 From: francois at debian.org (Francois Marier) Date: Fri, 6 May 2011 15:08:26 +1200 Subject: [Koha-devel] [PATCH 2/2] Bug 6298 : Show avatars on the recent comments page In-Reply-To: <1304651306-28164-1-git-send-email-francois@debian.org> References: <1304651306-28164-1-git-send-email-francois@debian.org> Message-ID: <1304651306-28164-2-git-send-email-francois@debian.org> Add smaller Libravatar-based images to the recent comments page. Signed-off-by: Francois Marier --- koha-tmpl/opac-tmpl/prog/en/css/opac.css | 1 + .../opac-tmpl/prog/en/modules/opac-showreviews.tt | 6 +++++- opac/opac-showreviews.pl | 11 +++++++++++ 3 files changed, 17 insertions(+), 1 deletions(-) diff --git a/koha-tmpl/opac-tmpl/prog/en/css/opac.css b/koha-tmpl/opac-tmpl/prog/en/css/opac.css index a1e1663..b8a531f 100644 --- a/koha-tmpl/opac-tmpl/prog/en/css/opac.css +++ b/koha-tmpl/opac-tmpl/prog/en/css/opac.css @@ -1875,6 +1875,7 @@ a#MARCview, a#MARCviewPop, a#ISBDview, a#Normalview, a#Fullhistory, a#Briefhisto } .commentline .avatar { float : right; + padding-left : .5em; } #comments #addcomment { margin : 0 -1em -1em -1em; diff --git a/koha-tmpl/opac-tmpl/prog/en/modules/opac-showreviews.tt b/koha-tmpl/opac-tmpl/prog/en/modules/opac-showreviews.tt index e64fcae..2839460 100644 --- a/koha-tmpl/opac-tmpl/prog/en/modules/opac-showreviews.tt +++ b/koha-tmpl/opac-tmpl/prog/en/modules/opac-showreviews.tt @@ -46,7 +46,11 @@ $(document).ready(function(){ [% END %] [% IF ( review.copyrightdate ) %]Date:[% review.copyrightdate %][% END %]
-
[% review.review |html %] +
+ [% IF ( review.avatarurl ) %] + + [% END %] + [% review.review |html %] Added [% review.datereviewed %] [% IF ( review.your_comment ) %] by you[% ELSE %] [% IF ( ShowReviewer ) %] by [% review.firstname %] [% review.surname %][% END %][% END %]
diff --git a/opac/opac-showreviews.pl b/opac/opac-showreviews.pl index f1e0b53..fbce8a2 100755 --- a/opac/opac-showreviews.pl +++ b/opac/opac-showreviews.pl @@ -65,6 +65,13 @@ if($format eq "rss"){ ); } +my $libravatar_available = 0; + +eval 'use Libravatar::URL'; +if (! $@) { + $libravatar_available = 1; +} + my $reviews = getallreviews(1,$offset,$results_per_page); my $marcflavour = C4::Context->preference("marcflavour"); my $hits = numberofreviews(); @@ -92,6 +99,10 @@ for my $result (@$reviews){ $result->{timestamp} = $bib->{'timestamp'}; $result->{firstname} = $borr->{'firstname'}; $result->{surname} = $borr->{'surname'}; + if ($libravatar_available and $borr->{'email'}) { + $result->{avatarurl} = libravatar_url(email => $borr->{'email'}, size => 40, https => $ENV{HTTPS}); + } + if ($result->{borrowernumber} eq $borrowernumber) { $result->{your_comment} = 1; } -- 1.7.4.4 From altaf.mahmud at gmail.com Sat May 7 12:00:45 2011 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Sat, 7 May 2011 16:00:45 +0600 Subject: [Koha-devel] Enabling SSL for Koha staff view Message-ID: Hello, I'm trying to implement SSL in my Koha server running on Debian 6.0 (squeeze). I've implemented it for my OPAC view, I've created another file 'koha-ssl' in ../apache2/sites-available/ directory and enabled it. I've edited ../apache2/sites-available/koha like following: NameVirtualHost :80 ..... ..... And ../apache2/sites-available/koha-ssl like following: NameVirtualHost :443 ..... SSLEngine On SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key ..... Now https://127.0.1.1/ is showing the OPAC. But I can't figure it out how to implement it for staff-view Request for port 80 is redirecting to port 443, how can I do that for port 8080? In fact, I don't have any prior idea on doing this; a descriptive suggestion is appropriate for me. Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Mon May 9 01:12:57 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 09 May 2011 11:12:57 +1200 Subject: [Koha-devel] [Koha-patches] [PATCH 5/5] Bug 6298 : Add optional dependency on Gravatar::URL 1.03 In-Reply-To: <1304810425-22545-5-git-send-email-francois@debian.org> References: <1304810425-22545-1-git-send-email-francois@debian.org> <1304810425-22545-5-git-send-email-francois@debian.org> Message-ID: <1304896377.18426.3.camel@zarathud> However, the version now in the koha debian repositories should work (it's at 1.04.) Francois Marier schreef op zo 08-05-2011 om 11:20 [+1200]: > This CPAN module is needed for the ShowReviewerPhoto functionality. > > Unfortunately the version in Squeeze (1.02) is not sufficient so it > has to be installed from CPAN: > > sudo apt-get install libnet-dns-perl libtest-warn-perl > sudo cpan Gravatar::URL > > Signed-off-by: Francois Marier > --- > C4/Installer/PerlDependencies.pm | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/C4/Installer/PerlDependencies.pm b/C4/Installer/PerlDependencies.pm > index 576dde4..63d14a6 100644 > --- a/C4/Installer/PerlDependencies.pm > +++ b/C4/Installer/PerlDependencies.pm > @@ -479,6 +479,11 @@ our $PERL_DEPS = { > 'required' => '1', > 'min_ver' => '2.22', > }, > + 'Gravatar::URL' => { > + 'usage' => 'Photos in OPAC reviews', > + 'required' => '0', > + 'min_ver' => '1.03', > + }, > }; > > 1; -- 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 kyle.m.hall at gmail.com Mon May 9 13:47:12 2011 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Mon, 9 May 2011 07:47:12 -0400 Subject: [Koha-devel] What's the current state of Course Reserves? In-Reply-To: References: Message-ID: Thanks for the update. Is there an RFC on the wiki for course reserves? That may be a good start if there isn't one. Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org ) On Thu, May 5, 2011 at 4:39 PM, Ian Walls wrote: > Kyle, > > > Hourly Loans is moving forward, and once complete will open the door for > Course Reserves, but Course Reserves itself is not fully spec'ed out and > ready to begin.? There are different ways to implement it, and I'm not sure > which is best. > > My thinking is that putting an item on course reserve is really just > changing some detail about it temporarily (like it's item type or collection > code).? In this way, it's like rotating collections.? But there is another > element that needs to be taken into account, and that's searching by > Course/Professor and the like.? The data structure of this additional > metadata should be easily mappable to all the major courseware systems out > there currently, or at least follow some kind of agreed-upon standard (there > may be something in MARC21 already...). > > We've also got to ask, should search for Course Reserves be integrated into > normal searching, or use a separate system like Tagging does? > > I don't know the best answers; I throw this open to the great minds of the > community. > > > -Ian > > On Wed, May 4, 2011 at 7:48 AM, Kyle Hall wrote: >> >> Hello All, >> ?Some months ago there was talk on the list about adding course >> reserves to Koha. I was just wondering if there was anyone actively >> developing this feature. I know that support for hourly loans is >> needed first, and that there is an RFC on the koha community wiki >> written by Ian. Is this feature in active development, or has it >> stalled? >> >> Thanks, >> Kyle >> >> http://www.kylehall.info >> Mill Run Technology Solutions ( http://millruntech.com ) >> Crawford County Federated Library System ( http://www.ccfls.org ) >> Meadville Public Library ( http://www.meadvillelibrary.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 > ALA Booth 732 > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal > From cnighswonger at foundations.edu Mon May 9 13:55:53 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 9 May 2011 07:55:53 -0400 Subject: [Koha-devel] 3.2.x String Freeze and Roadmap Update Message-ID: Hi All, We are going to keep with May 15, 2011 for the 3.2.8 release which puts 3.2.x into a string freeze as of today. The 3.2.x branch has quite a few commits since 3.2.7, so this will be an important release. 3.2.x will thaw on May 16. Subsequent 3.2.x releases will be largely dependent upon commits available for back porting and patches submitted directly against the 3.2.x branch. At present, the plan is to support 3.2.x through 3.2.10 if there are commits/patches to do so. When we get to 3.2.10 or when it is clear we will not get there, I'll add a monthly IRC meeting agenda item to discuss EOL for the 3.2.x branch. As always: Thanks to all the individuals who have put time, effort, and money into making Koha a great ILS! Kind Regards, Chris Nighswonger 3.2.x/3.4.x Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon May 9 15:46:58 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 09 May 2011 15:46:58 +0200 Subject: [Koha-devel] Document to read Message-ID: <4DC7F052.7060706@biblibre.com> Hello, chris gave this url on IRC, I think it's worth sharing : http://www.codesimplicity.com/post/open-source-community-simplified/ it's a great document. I think it's worth asking ourself : "what are we doing well, what could we improve" This question is specifically sent to new contributors: what did we well, what could be improve for new/future newbies ? -- 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 May 9 17:25:29 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 09 May 2011 17:25:29 +0200 Subject: [Koha-devel] Hacker's corner, week 19 Message-ID: <4DC80769.2060309@biblibre.com> Hello, Sorry for staying silent for 4 weeks, but after the hackfest, I've been AFK for one week, then needed 2 weeks not to be late anymore on my daily stuff... So, here it is: Last week, 220 messages have been sent to the bugs mailing list (reminder, each change on a bug means a mail) Patches to sign-off =========== After the hackfest, there were 112 bugs waiting for sign-off. Today, this number has increased again: 139 bugs are waiting for you ! Some are related to CRItical bugs, so they're really worth a signature: 6292 Overdue notices have a bug when multiple overdues exist 5860Adding duplicate stocknumber will fail silently 5683 link_bibs_to_authorities.pl can corrupt records 5379import_borrowers.pl fails with db insert/update errors 4993 ldap search always anonymous when using auth_by_bind 3652XSS vulnerabilities 2246 Label printing doesn't work with Unicode characters All other are worth a signature though. Patches signed-off =========== 19 patches have been signed-off. Almost 10 different individuals have signed-off something. Congrats to Nicole, that is "sign-off of the week" ! Shame on all other developers (including me) that have signed-off nothing last week... Patches pushed ========= Chris has pushed only 4 patches last week. It means there is now 18 patches that can be pushed and will probably be soon. -- 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 Mon May 9 20:43:11 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 10 May 2011 06:43:11 +1200 Subject: [Koha-devel] Hacker's corner, week 19 In-Reply-To: <4DC80769.2060309@biblibre.com> References: <4DC80769.2060309@biblibre.com> Message-ID: On 10 May 2011 03:25, Paul Poulain wrote: > Hello, > > Sorry for staying silent for 4 weeks, but after the hackfest, I've been > AFK for one week, then needed 2 weeks not to be late anymore on my daily > stuff... > > So, here it is: > Last week, 220 messages have been sent to the bugs mailing list > (reminder, each change on a bug means a mail) > > Patches to sign-off > =========== > After the hackfest, there were 112 bugs waiting for sign-off. Today, > this number has increased again: 139 bugs are waiting for you ! > Some are related to CRItical bugs, so they're really worth a signature: > 6292 Overdue notices have a bug when multiple overdues exist > > 5860Adding duplicate stocknumber will fail silently > > 5683 link_bibs_to_authorities.pl can corrupt records > > 5379import_borrowers.pl fails with db insert/update errors > > 4993 ldap search always anonymous when using auth_by_bind > > 3652XSS vulnerabilities > > 2246 Label printing doesn't work with Unicode characters > > All other are worth a signature though. > > Patches signed-off > =========== > 19 patches have been signed-off. Almost 10 different individuals have > signed-off something. Congrats to Nicole, that is "sign-off of the week" > ! Shame on all other developers (including me) that have signed-off > nothing last week... > > Patches pushed > ========= > Chris has pushed only 4 patches last week. It means there is now 18 > patches that can be pushed and will probably be soon. > Actually for 3.6.x the workflow has changed slightly. http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow Step 5 has been added, so in the next few days Ian will be setting those signed off bugs to passed qa, I will do a final test, then merge to master. I then make a note for Chris N, whether I think they are suitable for 3.4.x. We have a wiki page for this http://wiki.koha-community.org/wiki/Commits_to_cherry-pick_for_3.4 And then he makes the final decision on what to pull in. There is another link (should be on the bottom of the bugzilla page) or at http://koha-releasemanagement.branchable.com/ for a list of bugs that are sitting at passed qa. This frees me up to do some signoffs on patches too, and get them to the signed off state, as someone else (Ian) will still look at them too. And having me do the final sign off affords Ian the opportunity to. It means we can both sign off on patches without the risk of either of us being the only sign off. So every patch gets at least 2 sign offs, most 3, and we have a rock solid 3.4.x and 3.6.0 :) Chris From dpavlin at rot13.org Mon May 9 21:55:29 2011 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Mon, 9 May 2011 21:55:29 +0200 Subject: [Koha-devel] Hacker's corner, week 19 In-Reply-To: References: <4DC80769.2060309@biblibre.com> Message-ID: <20110509195529.GA10480@rot13.org> On Tue, May 10, 2011 at 06:43:11AM +1200, Chris Cormack wrote: > Actually for 3.6.x the workflow has changed slightly. > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow Excuse me, but I don't quote understand how my batch of LDAP fixes (Koha bugs 4993, 4994 and 6022) will get into bug/enhancement? Would it help to merge all LDAP changes in single bug and submit that? I have been using this code for years, and it seems that only few users use LDAP with auth_by_bind in Koha. I was recently contacted by one library which had problem with it, so there is interest other than my own library needs. -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From chris at bigballofwax.co.nz Mon May 9 22:10:51 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 10 May 2011 08:10:51 +1200 Subject: [Koha-devel] Hacker's corner, week 19 Message-ID: On 10 May 2011 07:55, "Dobrica Pavlinusic" wrote: > > On Tue, May 10, 2011 at 06:43:11AM +1200, Chris Cormack wrote: > > Actually for 3.6.x the workflow has changed slightly. > > > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow > > Excuse me, but I don't quote understand how my batch of LDAP fixes > (Koha bugs 4993, 4994 and 6022) will get into bug/enhancement? You are doing the exact right thing bringing it up on the devel list. > > Would it help to merge all LDAP changes in single bug and submit that? > Linking them altogether with the depends feature would be good, can they be tested independently? If not noting that on the bug would be great. > I have been using this code for years, and it seems that only few users > use LDAP with auth_by_bind in Koha. I was recently contacted by one > library which had problem with it, so there is interest other than my > own library needs. > Excellent, the first step is finding someone to sign off. I have a client who uses auth by bind, so I am willing to do the initial sign off on these. I will attempt to do this today, if there is anything I need to know when testing please let me know. Finding the initial person to signoff can be tricky, but asking on the mailing list and/or irc is a perfect way to do it. Chris > -- > Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org > Unix addict. Internet consultant. http://www.rot13.org/~dpavlin -------------- next part -------------- An HTML attachment was scrubbed... URL: From librarian at daffodilvarsity.edu.bd Tue May 10 11:24:31 2011 From: librarian at daffodilvarsity.edu.bd (Librarian, DIU) Date: Tue, 10 May 2011 15:24:31 +0600 Subject: [Koha-devel] For Kind Information Message-ID: Dear Koha development manager I would like to inform you that I am a librarian of Daffodil International University, Bangladesh , Dhaka. Recently we installed KOHA in our library and a training on KOHA +MARC 21 also completed successfully. We are mapping our whole data and uploaded in koha database. When we are searching any book by title but search result is showing not found and sometime error like Could not find opac-search.xml in /usr/share/koha/opac/cgi-bin/opac/ at /usr/share/koha/lib/C4/Search.pm line 579. We did not find out whats problem arise, please help me in this regards. Thank you very much. With best regards, Md. Milan Khan Librarian Daffodil International University Dhaka, Bangladesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Tue May 10 16:41:05 2011 From: nengard at gmail.com (Nicole Engard) Date: Tue, 10 May 2011 10:41:05 -0400 Subject: [Koha-devel] CircControl, HomeOrHoldingBranch and HomeOrHoldingBranchReturn Message-ID: Okay, developers I need some help both in understanding and in documenting the above preferences. Right now CircControl and HomeOrHoldingBranch have the same descriptions, but I doubt that they do the same thing. I vaguely remember HomeOrHoldingBranch being deprecated in favor of HomeOrHoldingBranchReturn ... but don't see a bug for that, and obviously it didn't happen. Next, in the manual I say that HomeOrHoldingBranch has something to do with IndependantBranches (is that true? if so how?) There are a series of bug reports on this issue: http://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=homeorholding&list_id=5333 but I'm not sure what the final consensus is? How do I use these three preferences? and How do I document them for librarians? Log from IRC Chat [10:29] need me some sys pref help [10:29] CircControl and HomeOrHoldingBranch have the same descriptions ... [10:29] and then there is HomeOrHoldingBranchReturn [10:29] what does HomeOrHoldingBranch do? [10:29] and i the manual correct when I say it's linked to IndependantBranches [10:30] * wizzyrea has always been confused by that [10:30] but I know that it has something to do with the way the rules are applied for circulation, and what happens when books are returned [10:31] that much is clear, paul_p was this a Biblibre addition? [10:31] all three have to do with circ rules and checking in and out ... just not sure which does what [10:32] there is at least one bug to report here though ... CircControl and HomeOrHoldingBranch have the same descriptions [10:33] they can't both do the same thing ... or if they do then we don't need two prefs : [10:33] :) [10:33] I think that one of them is supposed to be eliminated, but wasn't yet. [10:33] HomeOrHolding was going away in favor of CircControl [10:33] but there's a bug on deprecating it [10:34] and I believe there was objection [10:34] * paul_p reading [10:34] (hello USA !) [10:34] http://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=homeorholding&list_id=5333 [10:36] mmm... sorry, I won't be able to help you, it's not clear for me too [10:37] wizzyrea, okay, that's confusing [10:37] gonna put this to the dev list I guess [10:37] I didn't say you'd like the answer ;) [10:38] * paul_p looking to french descriptions of those sysprefs to see if it helps... [10:39] same description too, it doesn't help... From ian.walls at bywatersolutions.com Tue May 10 17:43:43 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Tue, 10 May 2011 11:43:43 -0400 Subject: [Koha-devel] Hacker's corner, week 19 In-Reply-To: References: Message-ID: Dobrica: excellent! I've got some clients looking at these kinds of LDAP improvements, as well, so passing QA got that much easier. All: My apologies for letting the SIGNED_OFF stage of tickets back up; I've been moving house, and am only now starting to carve out a little bit of home in this pile of boxes and furniture. I hope to get the list greatly reduced by the end of the day. Cheers, -Ian 2011/5/9 Chris Cormack > > On 10 May 2011 07:55, "Dobrica Pavlinusic" wrote: > > > > On Tue, May 10, 2011 at 06:43:11AM +1200, Chris Cormack wrote: > > > Actually for 3.6.x the workflow has changed slightly. > > > > > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow > > > > Excuse me, but I don't quote understand how my batch of LDAP fixes > > (Koha bugs 4993, 4994 and 6022) will get into bug/enhancement? > > You are doing the exact right thing bringing it up on the devel list. > > > > > Would it help to merge all LDAP changes in single bug and submit that? > > > Linking them altogether with the depends feature would be good, can they be > tested independently? > If not noting that on the bug would be great. > > > I have been using this code for years, and it seems that only few users > > use LDAP with auth_by_bind in Koha. I was recently contacted by one > > library which had problem with it, so there is interest other than my > > own library needs. > > > Excellent, the first step is finding someone to sign off. I have a client > who uses auth by bind, so I am willing to do the initial sign off on these. > > I will attempt to do this today, if there is anything I need to know when > testing please let me know. > > Finding the initial person to signoff can be tricky, but asking on the > mailing list and/or irc is a perfect way to do it. > > Chris > > > -- > > > Dobrica Pavlinusic 2share!2flame > dpavlin at rot13.org > > Unix addict. Internet consultant. > http://www.rot13.org/~dpavlin > > _______________________________________________ > 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 ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From henridamien.laurent at biblibre.com Tue May 10 17:59:12 2011 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Tue, 10 May 2011 17:59:12 +0200 Subject: [Koha-devel] CircControl, HomeOrHoldingBranch and HomeOrHoldingBranchReturn In-Reply-To: References: Message-ID: <4DC960D0.9040307@biblibre.com> Le 10/05/2011 16:41, Nicole Engard a ?crit : > Okay, developers I need some help both in understanding and in > documenting the above preferences. Right now CircControl and > HomeOrHoldingBranch have the same descriptions, but I doubt that they > do the same thing. > > I vaguely remember HomeOrHoldingBranch being deprecated in favor of > HomeOrHoldingBranchReturn ... but don't see a bug for that, and > obviously it didn't happen. > > Next, in the manual I say that HomeOrHoldingBranch has something to do > with IndependantBranches (is that true? if so how?) > > There are a series of bug reports on this issue: > http://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=homeorholding&list_id=5333 > but I'm not sure what the final consensus is? How do I use these three > preferences? and How do I document them for librarians? > > > > Log from IRC Chat > > > [10:29] need me some sys pref help > [10:29] CircControl and HomeOrHoldingBranch have the same > descriptions ... > [10:29] and then there is HomeOrHoldingBranchReturn > [10:29] what does HomeOrHoldingBranch do? > [10:29] and i the manual correct when I say it's linked to > IndependantBranches > [10:30] * wizzyrea has always been confused by that > [10:30] but I know that it has something to do with the > way the rules are applied for circulation, and what happens when books > are returned > [10:31] that much is clear, paul_p was this a Biblibre addition? > [10:31] all three have to do with circ rules and checking > in and out ... just not sure which does what > [10:32] there is at least one bug to report here though ... > CircControl and HomeOrHoldingBranch have the same descriptions > [10:33] they can't both do the same thing ... or if they do > then we don't need two prefs : > [10:33] :) > [10:33] I think that one of them is supposed to be > eliminated, but wasn't yet. > [10:33] HomeOrHolding was going away in favor of CircControl > [10:33] but there's a bug on deprecating it > [10:34] and I believe there was objection > [10:34] * paul_p reading > [10:34] (hello USA !) > [10:34] > http://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=homeorholding&list_id=5333 > [10:36] mmm... sorry, I won't be able to help you, it's not > clear for me too > [10:37] wizzyrea, okay, that's confusing > [10:37] gonna put this to the dev list I guess > [10:37] I didn't say you'd like the answer ;) > [10:38] * paul_p looking to french descriptions of those sysprefs to > see if it helps... > [10:39] same description too, it doesn't help... follow up : (17:07:35) hdl: It is the system preference description which is not really good. (17:08:02) talljoy_ [~talljoy at 99-27-151-96.lightspeed.rcsntx.sbcglobal.net] a rejoint le salon. (17:08:27) hdl: circontrol set to the items branch. And then you would choose homebranch or holdingbranch (17:09:23) hdl: In your case the real rule followed is : the library the item was checked out from (17:10:00) nengard: hdl, i'm sorry i'm still very confused (17:11:44) hdl: nengard: in the case of Circcontrol, you have the choice between "3 tables" : issues (or C4::Context-userenv) borrowers, items. (17:11:53) hdl: It is that level of choice. (17:12:17) hdl: for CircControl (17:12:27) wizzyrea: so you can circ with rules based on issuing library, borrower's homebranch, or the item's home branch (17:12:33) wizzyrea: with CircControl (17:12:51) hdl: HomeOrHoldingBranch is to decide whether it is items' homebranch or items' holding branch (17:12:58) wizzyrea: so only items (17:13:06) hdl: i.e. the library rule where the item last was. (17:13:09) wizzyrea: and nothing to do with borrowers or logged in branch (17:13:17) hdl: No. (17:13:22) hdl: only items... (17:13:52) wizzyrea: oh, only the current location (17:14:35) wizzyrea: (holding branch) (17:14:56) hdl: holding branch is the library which latest had the book. (17:15:02) wizzyrea: right (17:15:15) wizzyrea: (where it is now) (17:15:57) hdl: well... where it is supposed to be now... The library which has it. (17:17:37) hdl: The inner behaviour for an item is different depending on the HomeOrHoldingBranch or PickupLibrary (17:17:55) hdl: PickupLibrary only impacts issuingrule. (17:18:38) hdl: when HomeOrHoldingBranch set to HoldingBranch, it changes the holdingbranch when a borrower returns a book to another library, not the homebranch. (17:19:27) hdl: Because in a network, it is important to keep track of the library who OWNS the item, and the library who HOLDS the item. (17:21:47) wizzyrea: the application of this is that you can have floating items, items that were checked out from their home branch, but returned at another branch (17:23:46) ***conan notices meeting will be at 23 hs today for him (17:23:46) wizzyrea: home or holding return decides whether, when an item is returned, it is held at the holding branch or force returned to the home branch (17:23:46) wizzyrea: I think (17:23:46) wizzyrea: that (17:23:46) wizzyrea: one is one that I've had to futz with lately (17:23:46) talljoy_ a quitt? le salon wizzyrea wizzyrea_away (17:33:10) hdl: wizzyrea nengard does that make more sense now ? (17:33:45) wizzyrea: I think so? (17:33:49) wizzyrea: the basic idea I got (17:34:19) wizzyrea: CircControl = rules based on one of item homebranch, patron homebranch, or logged in user branch (17:34:43) wizzyrea: HomeOrHolding = rules based only on items (possibly to be deprecated From nengard at gmail.com Tue May 10 18:07:50 2011 From: nengard at gmail.com (Nicole Engard) Date: Tue, 10 May 2011 12:07:50 -0400 Subject: [Koha-devel] CircControl, HomeOrHoldingBranch and HomeOrHoldingBranchReturn In-Reply-To: <4DC960D0.9040307@biblibre.com> References: <4DC960D0.9040307@biblibre.com> Message-ID: Based on this info, we need clearer explanations of the preferences ... and I'm not sure how to label them so that they make sense. Suggestions? Nicole On Tue, May 10, 2011 at 11:59 AM, LAURENT Henri-Damien wrote: > Le 10/05/2011 16:41, Nicole Engard a ?crit : >> Okay, developers I need some help both in understanding and in >> documenting the above preferences. ?Right now CircControl and >> HomeOrHoldingBranch have the same descriptions, but I doubt that they >> do the same thing. >> >> I vaguely remember HomeOrHoldingBranch being deprecated in favor of >> HomeOrHoldingBranchReturn ... but don't see a bug for that, and >> obviously it didn't happen. >> >> Next, in the manual I say that HomeOrHoldingBranch has something to do >> with IndependantBranches (is that true? if so how?) >> >> There are a series of bug reports on this issue: >> http://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=homeorholding&list_id=5333 >> but I'm not sure what the final consensus is? How do I use these three >> preferences? and How do I document them for librarians? >> >> >> >> Log from IRC Chat >> >> >> [10:29] ? need me some sys pref help >> [10:29] ? CircControl ?and HomeOrHoldingBranch ?have the same >> descriptions ... >> [10:29] ? and then there is HomeOrHoldingBranchReturn >> [10:29] ? what does HomeOrHoldingBranch do? >> [10:29] ? and i the manual correct when I say it's linked to >> IndependantBranches >> [10:30] ?* wizzyrea has always been confused by that >> [10:30] ? but I know that it has something to do with the >> way the rules are applied for circulation, and what happens when books >> are returned >> [10:31] ? that much is clear, paul_p was this a Biblibre addition? >> [10:31] ? all three have to do with circ rules and checking >> in and out ... just not sure which does what >> [10:32] ? there is at least one bug to report here though ... >> CircControl ?and HomeOrHoldingBranch ?have the same descriptions >> [10:33] ? they can't both do the same thing ... or if they do >> then we don't need two prefs : >> [10:33] ? :) >> [10:33] ? I think that one of them is supposed to be >> eliminated, but wasn't yet. >> [10:33] ? HomeOrHolding was going away in favor of CircControl >> [10:33] ? but there's a bug on deprecating it >> [10:34] ? and I believe there was objection >> [10:34] ?* paul_p reading >> [10:34] ? (hello USA !) >> [10:34] ? >> http://bugs.koha-community.org/bugzilla3/buglist.cgi?quicksearch=homeorholding&list_id=5333 >> [10:36] ? mmm... sorry, I won't be able to help you, it's not >> clear for me too >> [10:37] ? wizzyrea, okay, that's confusing >> [10:37] ? gonna put this to the dev list I guess >> [10:37] ? I didn't say you'd like the answer ;) >> [10:38] ?* paul_p looking to french descriptions of those sysprefs to >> see if it helps... >> [10:39] ? same description too, it doesn't help... > > follow up : > (17:07:35) hdl: It is the system preference description which is not > really good. > (17:08:02) talljoy_ > [~talljoy at 99-27-151-96.lightspeed.rcsntx.sbcglobal.net] a rejoint le salon. > (17:08:27) hdl: circontrol set to the items branch. And then you would > choose homebranch or holdingbranch > (17:09:23) hdl: In your case the real rule followed is : the library the > item was checked out from > (17:10:00) nengard: hdl, i'm sorry i'm still very confused > (17:11:44) hdl: nengard: in the case of Circcontrol, you have the choice > between "3 tables" : issues (or C4::Context-userenv) borrowers, items. > (17:11:53) hdl: It is that level of choice. > (17:12:17) hdl: for CircControl > (17:12:27) wizzyrea: so you can circ with rules based on issuing > library, borrower's homebranch, or the item's home branch > (17:12:33) wizzyrea: with CircControl > (17:12:51) hdl: HomeOrHoldingBranch is to decide whether it is items' > homebranch or items' holding branch > (17:12:58) wizzyrea: so only items > (17:13:06) hdl: i.e. the library rule where the item last was. > (17:13:09) wizzyrea: and nothing to do with borrowers or logged in branch > (17:13:17) hdl: No. > (17:13:22) hdl: only items... > (17:13:52) wizzyrea: oh, only the current location > (17:14:35) wizzyrea: (holding branch) > (17:14:56) hdl: holding branch is the library which latest had the book. > (17:15:02) wizzyrea: right > (17:15:15) wizzyrea: (where it is now) > (17:15:57) hdl: well... where it is supposed to be now... The library > which has it. > (17:17:37) hdl: The inner behaviour for an item is different depending > on the HomeOrHoldingBranch or PickupLibrary > (17:17:55) hdl: PickupLibrary only impacts issuingrule. > (17:18:38) hdl: when HomeOrHoldingBranch set to HoldingBranch, it > changes the holdingbranch when a borrower returns a book to another > library, not the homebranch. > (17:19:27) hdl: Because in a network, it is important to keep track of > the library who OWNS the item, and the library who HOLDS the item. > (17:21:47) wizzyrea: the application of this is that you can have > floating items, items that were checked out from their home branch, but > returned at another branch > (17:23:46) ***conan notices meeting will be at 23 hs today for him > (17:23:46) wizzyrea: home or holding return decides whether, when an > item is returned, it is held at the holding branch or force returned to > the home branch > (17:23:46) wizzyrea: I think > (17:23:46) wizzyrea: that > (17:23:46) wizzyrea: one is one that I've had to futz with lately > (17:23:46) talljoy_ a quitt? le salon > wizzyrea wizzyrea_away > (17:33:10) hdl: wizzyrea nengard does that make more sense now ? > (17:33:45) wizzyrea: I think so? > (17:33:49) wizzyrea: the basic idea I got > (17:34:19) wizzyrea: CircControl = rules based on one of item > homebranch, patron homebranch, or logged in user branch > (17:34:43) wizzyrea: HomeOrHolding = rules based only on items (possibly > to be deprecated > _______________________________________________ > 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 colin.campbell at ptfs-europe.com Tue May 10 18:49:04 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Tue, 10 May 2011 17:49:04 +0100 Subject: [Koha-devel] CircControl, HomeOrHoldingBranch and HomeOrHoldingBranchReturn In-Reply-To: References: <4DC960D0.9040307@biblibre.com> Message-ID: <4DC96C80.9000507@ptfs-europe.com> On 10/05/11 17:07, Nicole Engard wrote: > Based on this info, we need clearer explanations of the preferences > ... and I'm not sure how to label them so that they make sense. > Suggestions? > Theres a routine in Circulation.pm _GetCircControlBranch which uses the two of them to return the branch's policy is to be used in the circ transaction, logic flow is: if CircControl == 'PickupLibrary' use the branch you are logged in at if CircControl == 'PatronLibrary' use the borrowers library if neither of the above use the field identified in HomeOrHoldingBranch from the item (unless its holding and there isn't a value there, in which case revert to home). C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From paul.poulain at biblibre.com Tue May 10 18:55:46 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 10 May 2011 18:55:46 +0200 Subject: [Koha-devel] Hacker's corner, week 19 In-Reply-To: References: <4DC80769.2060309@biblibre.com> Message-ID: <4DC96E12.7000402@biblibre.com> Le 09/05/2011 20:43, Chris Cormack a ?crit : > Actually for 3.6.x the workflow has changed slightly. > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow oups, I missed this change. When has it been discussed/decided/announced ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From henridamien.laurent at biblibre.com Tue May 10 21:07:53 2011 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Tue, 10 May 2011 21:07:53 +0200 Subject: [Koha-devel] 3.0.x maintenance discontinued Message-ID: <4DC98D09.7000807@biblibre.com> Hi any Koha users will have noticed that 3.0.x has had no release in one year. I just have to face the facts. I am not able to get any release for this version out seriously tested. So I have to announce that the maintenance of this version is over. Please consider upgrading to 3.2 or even better 3.4 If anyone is interested in taking that action, please step in onlist and ask for access. Thanks. -- Henri-Damien LAURENT From chrisc at catalyst.net.nz Tue May 10 22:43:54 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 11 May 2011 08:43:54 +1200 Subject: [Koha-devel] 3.0.x maintenance discontinued In-Reply-To: <4DC98D09.7000807@biblibre.com> References: <4DC98D09.7000807@biblibre.com> Message-ID: <20110510204354.GT9732@rorohiko.wgtn.cat-it.co.nz> * LAURENT Henri-Damien (henridamien.laurent at biblibre.com) wrote: > Hi > any Koha users will have noticed that 3.0.x has had no release in one year. > I just have to face the facts. I am not able to get any release for this > version out seriously tested. > So I have to announce that the maintenance of this version is over. Thank you for all your hard work Henri-Damien. For those who don't know Henri-Damien worked as release maintainer of 3.0 for over 2 years, a commendable effort. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From fridolyn.somers at gmail.com Wed May 11 11:24:36 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 11 May 2011 11:24:36 +0200 Subject: [Koha-devel] deleteditems marc Message-ID: Hello, I found that there is, in current revision on git.koha-community.org, a difference between "items" and "deleteditems" tables in "kohastructure.sql" : "deleteditems" has a field "marc" not existing in "items". Can it be deleted ? Regards, -- 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 henridamien.laurent at gmail.com Wed May 11 13:47:00 2011 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Wed, 11 May 2011 13:47:00 +0200 Subject: [Koha-devel] deleteditems marc In-Reply-To: References: Message-ID: <4DCA7734.2090305@gmail.com> Le 11/05/2011 11:24, Fridolyn SOMERS a ?crit : > Hello, > > I found that there is, in current revision on git.koha-community.org > , a difference between "items" and > "deleteditems" tables in "kohastructure.sql" : > "deleteditems" has a field "marc" not existing in "items". > > Can it be deleted ? > It should be imho. Patch welcome :) -- Henri-Damien LAURENT > Regards, > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > From M.de.Rooy at rijksmuseum.nl Wed May 11 14:00:37 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 11 May 2011 12:00:37 +0000 Subject: [Koha-devel] Hacker's corner, week 19 In-Reply-To: <4DC96E12.7000402@biblibre.com> References: <4DC80769.2060309@biblibre.com> , <4DC96E12.7000402@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3124EC7B@S-MAIL-1B.rijksmuseum.intra> Did not see it either until now.. I would say that at least a discussion on irc or meeting could go together with asking input on dev list? Or maybe I missed that one. ________________________________________ 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 10 mei 2011 18:55 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Hacker's corner, week 19 Le 09/05/2011 20:43, Chris Cormack a ?crit : > Actually for 3.6.x the workflow has changed slightly. > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow oups, I missed this change. When has it been discussed/decided/announced ? -- 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 M.de.Rooy at rijksmuseum.nl Wed May 11 14:19:26 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 11 May 2011 12:19:26 +0000 Subject: [Koha-devel] FW: Code simplicity document Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? imo we need some more structure at the signoff side. We have the Bugzilla categories that define the default assignment for a new bug. Would it be useful to assign a default signer per category too? Such assignments could be evaluated regularly to see if they still work. 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 9 mei 2011 15:46 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] Document to read Hello, chris gave this url on IRC, I think it's worth sharing : http://www.codesimplicity.com/post/open-source-community-simplified/ it's a great document. I think it's worth asking ourself : "what are we doing well, what could we improve" This question is specifically sent to new contributors: what did we well, what could be improve for new/future newbies ? -- 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 dschust1 at gmail.com Wed May 11 14:55:34 2011 From: dschust1 at gmail.com (David Schuster) Date: Wed, 11 May 2011 07:55:34 -0500 Subject: [Koha-devel] FW: Code simplicity document In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> Message-ID: I too enjoyed this article and took note of this and saw during the IRC meeting a comment about after a release how the community drops off. "In the past, before a major release, we would ?freeze? the trunk. This meant that no new features could be developed for several weeks or months until we felt that trunk was stable enough to call a ?release candidate.? Then we would create a new stable branch from the trunk and re-open the main-line trunk for features. However, while trunk was frozen, there was no feature development happening anywhere in the Bugzilla Project. Graph analysis showed very clearly that every time we would freeze, the community would shrink drastically and it would take several months after we un-froze for the size of the community to recover. It happened uniformly, every single time we would freeze, over many years and many releases." - Quote from "Open source simplified, read today 05/11/2011 - at URL - http://www.codesimplicity.com/post/open-source-community-simplified/ David Schuster On Wed, May 11, 2011 at 7:19 AM, Marcel de Rooy wrote: > Liked that article! > As relative new member of the community, I am wondering if the current > signoff/passed_qa procedure really encourages new members to keep sending > patches. > It could happen easily now that a patch does not get any attention. What > makes someone now select a patch for signoff? Coincidence, contacts, > application feature? > imo we need some more structure at the signoff side. We have the Bugzilla > categories that define the default assignment for a new bug. Would it be > useful to assign a default signer per category too? Such assignments could > be evaluated regularly to see if they still work. > > 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 9 mei 2011 15:46 > Aan: koha-devel at lists.koha-community.org > Onderwerp: [Koha-devel] Document to read > > Hello, > > chris gave this url on IRC, I think it's worth sharing : > http://www.codesimplicity.com/post/open-source-community-simplified/ > > it's a great document. I think it's worth asking ourself : "what are we > doing well, what could we improve" > > This question is specifically sent to new contributors: what did we > well, what could be improve for new/future newbies ? > > -- > 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/ > -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Wed May 11 15:00:41 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 11 May 2011 09:00:41 -0400 Subject: [Koha-devel] FW: Code simplicity document In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> Message-ID: > Graph analysis showed very clearly that every time we would freeze, the > community would shrink drastically and it would take several months after we > un-froze for the size of the community to recover Sure, because fixing bugs is very unsexy. It's great to get all the feature contributions before a feature freeze, but I wish it was as easy to get people to fix bugs. It's a shame, because while contributing features may be more fun for an experienced developer, fixing a bug is probably the best way for a newcomer to the community to get a foot in the door. The complexity of bugs varies, but there are always a few which are minor enough to be tackled by a newbie. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chrisc at catalyst.net.nz Wed May 11 16:14:10 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 12 May 2011 02:14:10 +1200 Subject: [Koha-devel] Hacker's corner, week 19 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124EC7B@S-MAIL-1B.rijksmuseum.intra> References: <4DC80769.2060309@biblibre.com> <4DC96E12.7000402@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA3124EC7B@S-MAIL-1B.rijksmuseum.intra> Message-ID: <20110511141409.GX9732@rorohiko.wgtn.cat-it.co.nz> * Marcel de Rooy (M.de.Rooy at rijksmuseum.nl) wrote: > Did not see it either until now.. > I would say that at least a discussion on irc or meeting could go together with asking input on dev list? > Or maybe I missed that one. It's not a new thing http://wiki.koha-community.org/wiki/Roadmap_to_3.4 "All patches should have at least 1 signoff before the Release Manager looks at them, (exceptions will be made for trivial patches). Preferably 2 signoffs, 1 from the QA manager and 1 from someone else. Although 1 from the QA manager will suffice." And here http://lists.koha-community.org/pipermail/koha-devel/2010-November/034655.html And in fact the idea goes back all the way to the first QA manager. We didn't manage to pull it off for 3.4, (we sort of did for 3.0), 3.2 we didnt have a QA manager http://koha.1045719.n5.nabble.com/Summary-of-community-meeting-on-koha-td3055814.html. We are trying again for 3.6. So its not a new idea, all that is new is clarifying the procedure (on what is a relatively new wiki page). Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From chris at bigballofwax.co.nz Wed May 11 16:22:10 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 12 May 2011 02:22:10 +1200 Subject: [Koha-devel] FW: Code simplicity document In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> Message-ID: On 12 May 2011 00:19, Marcel de Rooy wrote: > Liked that article! > As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. > It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? Unfortunately that has always been the case since we moved to the workflow of having patches. The new statuses and reports showing bugs waiting for sign off have I think made it less likely. For 3.4.0 for example there were over 1000 patches, from 66 different people in 6 months that made it in. So I think we are slowly improving all the time, and should strive to continue to do so. Currently now the best way of getting a patch signed off, is asking someone to look at it. > imo we need some more structure at the signoff side. We have the Bugzilla categories that define the default assignment for a new bug. Would it be useful to assign a default signer per category too? Such assignments could be evaluated regularly to see if they still work. > This is also not a new idea, for a long time now we have been trying to get people to volunteer to 'own' a section of Koha. IE someone volunteer to look after circulation, someone else the opac, someone else xslt etc. So far without success, I'd love for this to happen though :) Chris From paul.poulain at biblibre.com Wed May 11 17:22:15 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 11 May 2011 17:22:15 +0200 Subject: [Koha-devel] FW: Code simplicity document In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4DCAA9A7.9090709@biblibre.com> Le 11/05/2011 16:22, Chris Cormack a ?crit : > On 12 May 2011 00:19, Marcel de Rooy wrote: >> Liked that article! >> As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. >> It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? > Unfortunately that has always been the case since we moved to the > workflow of having patches. The new statuses and reports showing bugs > waiting for sign off have I think made it less likely. For 3.4.0 for > example there were over 1000 patches, from 66 different people in 6 > months that made it in. So I think we are slowly improving all the > time, and should strive to continue to do so. > > Currently now the best way of getting a patch signed off, is asking > someone to look at it. Jumping in the discussion: the workflow is great, in theory. But when no-one find time to sign-off a patch, it results in patches being lost in limbo. And when someone suddenly takes care, unfortunatly, the patch does not apply anymore, so the patch writter has to rebase,... It not a good method to motivate ppl to contribute, obviously ! At the moment, we have 140 patches waiting for sign-off. Some including critical bugs. Just picking one of them: 5995 = It requires a CAS server to be tested, and I fear no-one has one. I can guarantee that the problem has been reported by a library using Koha. I can guarantee this is the patch we've applied, and the library has closed the bug on our internal platform. I can guarantee that this is exactly the patch we've made. And I can guarantee the library will never sign-off anything. So ... we're waiting for someone to sign-off this patch. And I feel we'll wait for a long time. Another example: 3652 (XSS vulnerabilities) I could add that many features we've submitted still have not made their way into Koha master, and it's not because of our efforts, it's because of this too strong workflow. They're too complex to apply/test/sign for someone not able to dedicate a full day to this task. But, once again, those features are working well for our customers, but they'll never sign-off anything ! Chris, I know we disagree here. But the workflow would be a good one if we had a long list of developers available, and we don't have. What's the solution ? I already have proposed, at the beginning of 3.4, to have pending features merged "immediatly", to let ppl (including librarians) time to do QA. You rejected this idea. I make it again : I think we should have a small time of, say, 2 months, where new features will be included easily. With a sandbox setup for anyone to test them (i'm definetly sure I could motivate french librarians to test. I'll never succeed to make them sign-off !). And during the 4 remaining months, 1- fix bugs on merged features (and even revert some if needed, like no feedback from the dev and big problems), 2- add features after a strong patch workflow. To summarize : T+0 - T+60 = any feature/patch that applies and is sent cleanly by a contributor that can promize he will take care of problems on the feature are merged T+60- T+150 = features/patches added only after a standard QA/signoff (i'm not sure i'm happy with a 1signoff+1QA barrier, I fear it's too high, but...) T+150 - T+180 = features & string freeze Without this, I think/feel that the "140" patches waiting for signoff will never be lowered. 15 persons worked for one full week during hackfest, and after 1 months, we're back to a number I consider as huge. PS : challenge: who is interested in signing BZ6328 i just submitted ? I feel no-one, as it's related to fines in days, and it seems it's something strange to US/NZ and many countries. -- 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 Wed May 11 17:56:27 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 11 May 2011 11:56:27 -0400 Subject: [Koha-devel] FW: Code simplicity document In-Reply-To: <4DCAA9A7.9090709@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> <4DCAA9A7.9090709@biblibre.com> Message-ID: Paul, I agree that having 140 patches needing signoff is way too many; I'd like to see all them signed off and ready for QA. Lots of good stuff out there, and if it's not being integrated, we're losing out. However, the workflow is a good one from a quality assurance point of view. Someone writes the code, someone else confirms it applies and seems to solve the bug, then QA checks for integration with all other aspects of Koha (so adding something new doesn't break something else), and finally the RM pushes it. As an internal measure, we at ByWater started signing off on all our out-going patches before putting them on the list. The idea here was just make sure we were putting out code free of typos, silly errors and the like (I've been known to make such mistakes, and loved having another set of eyes in the company check things before I publicly released them). We found that for Koha 3.4, that was often enough of a sign-off to get things committed. I was concerned that since it was "in company", the signoff would be less, and for larger, deeper devs, perhaps it is, but for many of the bugfixes it was sufficient. So, code that one of the BibLibre team has written could be signed off on by any other member of the company, and that would advance the status. Anything that's in the SIGNED_OFF state is in my queue for QA. The signoffs can come from anyone, even within a company; I'll still be doing rigourous testing. I'll factor in the sign-offs, especially for things like CAS that I don't have the services to test with right now, but I don't want to do any blind signing off, or pushing things that need followup patches to complete them (because what if THOSE never get their signoff, and we reach release time?). Once the SIGNED_OFF list is exhausted, I'll start selecting from the NEEDS_SIGNOFF pool, and putting those through QA, as time permits. SIGNED_OFF will take priority, but this will provide a way to keep things flowing if folks aren't doing signoffs as fast as I'm doing QA. I hope this helps elucidate where I'm looking to go with this workflow and how we can work to get it flowing along. Cheers, -Ian On Wed, May 11, 2011 at 11:22 AM, Paul Poulain wrote: > Le 11/05/2011 16:22, Chris Cormack a ?crit : > > On 12 May 2011 00:19, Marcel de Rooy wrote: > >> Liked that article! > >> As relative new member of the community, I am wondering if the current > signoff/passed_qa procedure really encourages new members to keep sending > patches. > >> It could happen easily now that a patch does not get any attention. What > makes someone now select a patch for signoff? Coincidence, contacts, > application feature? > > Unfortunately that has always been the case since we moved to the > > workflow of having patches. The new statuses and reports showing bugs > > waiting for sign off have I think made it less likely. For 3.4.0 for > > example there were over 1000 patches, from 66 different people in 6 > > months that made it in. So I think we are slowly improving all the > > time, and should strive to continue to do so. > > > > Currently now the best way of getting a patch signed off, is asking > > someone to look at it. > Jumping in the discussion: the workflow is great, in theory. > But when no-one find time to sign-off a patch, it results in patches > being lost in limbo. And when someone suddenly takes care, unfortunatly, > the patch does not apply anymore, so the patch writter has to rebase,... > It not a good method to motivate ppl to contribute, obviously ! > > At the moment, we have 140 patches waiting for sign-off. Some including > critical bugs. > > Just picking one of them: 5995 = It requires a CAS server to be tested, > and I fear no-one has one. > > I can guarantee that the problem has been reported by a library using > Koha. I can guarantee this is the patch we've applied, and the library > has closed the bug on our internal platform. I can guarantee that this > is exactly the patch we've made. And I can guarantee the library will > never sign-off anything. So ... we're waiting for someone to sign-off > this patch. And I feel we'll wait for a long time. > > Another example: 3652 (XSS vulnerabilities) > > > I could add that many features we've submitted still have not made their > way into Koha master, and it's not because of our efforts, it's because > of this too strong workflow. > They're too complex to apply/test/sign for someone not able to dedicate > a full day to this task. But, once again, those features are working > well for our customers, but they'll never sign-off anything ! > > Chris, I know we disagree here. But the workflow would be a good one if > we had a long list of developers available, and we don't have. > > What's the solution ? > I already have proposed, at the beginning of 3.4, to have pending > features merged "immediatly", to let ppl (including librarians) time to > do QA. You rejected this idea. > > I make it again : I think we should have a small time of, say, 2 months, > where new features will be included easily. With a sandbox setup for > anyone to test them (i'm definetly sure I could motivate french > librarians to test. I'll never succeed to make them sign-off !). > And during the 4 remaining months, 1- fix bugs on merged features (and > even revert some if needed, like no feedback from the dev and big > problems), 2- add features after a strong patch workflow. > > To summarize : > T+0 - T+60 = any feature/patch that applies and is sent cleanly by a > contributor that can promize he will take care of problems on the > feature are merged > T+60- T+150 = features/patches added only after a standard QA/signoff > (i'm not sure i'm happy with a 1signoff+1QA barrier, I fear it's too > high, but...) > T+150 - T+180 = features & string freeze > > > Without this, I think/feel that the "140" patches waiting for signoff > will never be lowered. 15 persons worked for one full week during > hackfest, and after 1 months, we're back to a number I consider as huge. > > > PS : challenge: who is interested in signing BZ6328 i just submitted ? I > feel no-one, as it's related to fines in days, and it seems it's > something strange to US/NZ and many countries. > > -- > 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 ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Wed May 11 18:03:42 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 11 May 2011 12:03:42 -0400 Subject: [Koha-devel] FW: Code simplicity document In-Reply-To: <4DCAA9A7.9090709@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> <4DCAA9A7.9090709@biblibre.com> Message-ID: > But when no-one find time to sign-off a patch, it results in patches > being lost in limbo. And when someone suddenly takes care, unfortunately, > the patch does not apply anymore, so the patch writer has to rebase,... Yes, and that's why we should all be maintaining our own git branches for any patch which we've submitted but which hasn't been accepted. It's up to each of us to rebase these branches frequently to make sure they still apply and to resubmit patches when necessary. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chris at bigballofwax.co.nz Wed May 11 19:01:45 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 12 May 2011 05:01:45 +1200 Subject: [Koha-devel] Release Manager 3.6 Message-ID: Hi All Recently I have been having a crisis of confidence. I have, I hope, always tried to do what I think is best for the project. Often I do make mistakes, a notable one happened in 2007, which I hope I in part was rectified in 2008. But my underlying motivation with Koha has always been to do the best for the users of the software. In my role as Release Manager for 3.4 (and again for 3.6) what I felt was best for the software users was a stable and well tested release. This is something I made clear in my proposal, and which I had assumed was understood (but you know what they say about assumptions ;)). With the huge amount of work put in by over 80 people, I think we managed to achieve some measure of success with that with 3.4.0 and that the stability of the 3.2.x releases is something we can all be proud of. Over the last couple of weeks, comments and mails both on and off list have made me think that maybe I am out of step with what the community desires. For 3.6 quality was still the major goal, but perhaps I have misjudged what others want. This has resulted in sleepless nights and quite a large amount of self doubt. Luckily we are still early in the 3.6 cycle, there is time to fix it. Options as I see them 1/ Continue with the current workflow, patches signed off, passed qa, then into master, with the goal to increase the rate patches are signed off 2/ Refine the workflow to make signing off easier 3/ Redesign the workflow eliminating sign off (for a period, or all of the release) 4/ Step aside to let someone else have a go at RM As Paul has noted in another thread, I am not comfortable with allowing patches into master untested, and I don't think I could do a good job as RM if that were to become the case. In that case I would rather become one of the developers submitting patches again, so perhaps 3 and 4 are the same for me. So, in the interest of transparency and openness, there's where my head and heart are. I wish what is best for the users of Koha, and I fear that maybe I am out of step. Comments? Chris From nengard at gmail.com Wed May 11 19:38:25 2011 From: nengard at gmail.com (Nicole Engard) Date: Wed, 11 May 2011 13:38:25 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: On Wed, May 11, 2011 at 1:01 PM, Chris Cormack wrote: > Options as I see them > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off This is my vote! I know it takes more work and more time for features to be approved, but I'm for a more stable, tested Koha. That said, I am most certainly not for option #4. Chris has done amazing things for Koha, for open source, and for me personally. Without your efforts Chris I wouldn't be a Koha community member today and would have never thought to help get the manual off the ground. I agree that you do look out for the best interests of Koha and I think that a more stable Koha is in the best interests of the software and the community. Nicole From oleonard at myacpl.org Wed May 11 19:33:20 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 11 May 2011 13:33:20 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off This option has my vote. I think it would be a mistake to approve untested patches. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From info at bywatersolutions.com Wed May 11 19:49:17 2011 From: info at bywatersolutions.com (Brendan A. Gallagher) Date: Wed, 11 May 2011 10:49:17 -0700 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: On May 11, 2011, at 10:01 AM, Chris Cormack wrote: > > > Options as I see them > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off We feel that the "well-defined" workflow has been missing before the start of 3.4 and would be very upset if this workflow was changed (untested patches--). Maybe it's just taking everyone time to adjust to this workflow. Honestly this has been much better and clearer for our organization to both track the process and for our organization to get our work into Koha. The way that I look at it - it's the responsibility of the developer (in my case - the company) to get the QA/sign-off necessary and we also add that amount of work into our workflows and contracts. Our job is not done until the code is tested and in - If that's the contract we sign (releasing it - is not enough in my opinion). This option is very clear for both the developer and the QA/RM roles. Yes it's more work for the developer - but it's a necessary for the stable project. I'm glad that someone is sticking to the rules and not bending. I/we vote for option #1. -Brendan ByWater Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer at bsz-bw.de Wed May 11 19:53:48 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Wed, 11 May 2011 19:53:48 +0200 Subject: [Koha-devel] Release Manager 3.6 References: Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD98EF1F@Bodensee.bsz-bw.de> Hi Chris, I totally agree with Nicole, Owen and Brendan. I also vote for: > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off With the increasing number of patches, developments and developers having a good qa process with many eyes checking the code and the functionality seems even more important to me than ever before. We all have to put effort and time into that, but I think it's more than worth it. Katrin -----Urspr?ngliche Nachricht----- Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris Cormack Gesendet: Mi 11.05.2011 19:01 An: koha-devel at lists.koha-community.org Betreff: [Koha-devel] Release Manager 3.6 Hi All Recently I have been having a crisis of confidence. I have, I hope, always tried to do what I think is best for the project. Often I do make mistakes, a notable one happened in 2007, which I hope I in part was rectified in 2008. But my underlying motivation with Koha has always been to do the best for the users of the software. In my role as Release Manager for 3.4 (and again for 3.6) what I felt was best for the software users was a stable and well tested release. This is something I made clear in my proposal, and which I had assumed was understood (but you know what they say about assumptions ;)). With the huge amount of work put in by over 80 people, I think we managed to achieve some measure of success with that with 3.4.0 and that the stability of the 3.2.x releases is something we can all be proud of. Over the last couple of weeks, comments and mails both on and off list have made me think that maybe I am out of step with what the community desires. For 3.6 quality was still the major goal, but perhaps I have misjudged what others want. This has resulted in sleepless nights and quite a large amount of self doubt. Luckily we are still early in the 3.6 cycle, there is time to fix it. Options as I see them 1/ Continue with the current workflow, patches signed off, passed qa, then into master, with the goal to increase the rate patches are signed off 2/ Refine the workflow to make signing off easier 3/ Redesign the workflow eliminating sign off (for a period, or all of the release) 4/ Step aside to let someone else have a go at RM As Paul has noted in another thread, I am not comfortable with allowing patches into master untested, and I don't think I could do a good job as RM if that were to become the case. In that case I would rather become one of the developers submitting patches again, so perhaps 3 and 4 are the same for me. So, in the interest of transparency and openness, there's where my head and heart are. I wish what is best for the users of Koha, and I fear that maybe I am out of step. Comments? 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 ruth at bywatersolutions.com Wed May 11 19:58:20 2011 From: ruth at bywatersolutions.com (D Ruth Bavousett) Date: Wed, 11 May 2011 13:58:20 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: <4DCACE3C.3090701@bywatersolutions.com> On 5/11/2011 1:38 PM, Nicole Engard wrote: > On Wed, May 11, 2011 at 1:01 PM, Chris Cormack wrote: >> Options as I see them >> 1/ Continue with the current workflow, patches signed off, passed qa, >> then into master, with the goal to increase the rate patches are >> signed off > This is my vote! I know it takes more work and more time for features > to be approved, but I'm for a more stable, tested Koha. Nicole says it spot-on; the current process requires some more time, but it is well worth it, in terms of a running product, IMO. +1 for option 1. I also strongly approve of Chris's leadership of this transition phase--you've done a great job, Chris. It's been an adjustment, for everyone, getting to the slightly-more-challenging process, but most folks I have talked to feel that it does make for a better product. -- D Ruth Bavousett Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software VISIT US AT ALA: BOOTH 732 Headquarters: Santa Barbara, CA Office: Washington, DC Phone/Fax (888)900-8944 http://bywatersolutions.com ruth at bywatersolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gary.Harris at state.nm.us Wed May 11 19:59:16 2011 From: Gary.Harris at state.nm.us (Harris, Gary, DCA) Date: Wed, 11 May 2011 17:59:16 +0000 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: <2A8EB265AD24D9499CE20D3D25CAE7531FD377A3@CEXMB001.nmes.lcl> +1 for 1/ and for Chris Cormack. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gary L. Harris, M.L.S. M.A. Director, Technical Services Bureau New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 (505) 476-9730 gary.harris at state.nm.us http://www.nmstatelibrary.org "You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete." -- Buckminster Fuller -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Nicole Engard Sent: Wednesday, May 11, 2011 11:38 AM To: Chris Cormack Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 On Wed, May 11, 2011 at 1:01 PM, Chris Cormack wrote: > Options as I see them > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off This is my vote! I know it takes more work and more time for features to be approved, but I'm for a more stable, tested Koha. That said, I am most certainly not for option #4. Chris has done amazing things for Koha, for open source, and for me personally. Without your efforts Chris I wouldn't be a Koha community member today and would have never thought to help get the manual off the ground. I agree that you do look out for the best interests of Koha and I think that a more stable Koha is in the best interests of the software and the community. Nicole _ 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 jcamins at cpbibliography.com Wed May 11 20:01:23 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 11 May 2011 14:01:23 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: All, On Wed, May 11, 2011 at 1:01 PM, Chris Cormack wrote: > > With > the huge amount of work put in by over 80 people, I think we managed > to achieve some measure of success with that with 3.4.0 and that the > stability of the 3.2.x releases is something we can all be proud of. > I certainly think so! Also, we've had releases every month! Options as I see them > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off > 2/ Refine the workflow to make signing off easier > 3/ Redesign the workflow eliminating sign off (for a period, or all of > the release) > 4/ Step aside to let someone else have a go at RM > I think it would be very unfortunate to lose you as RM. Under your leadership, 3.4 rocked, and 3.6 promises to be even better. I vote for choice 1, unless someone has a concrete suggestion on how to refine the workflow for choice 2 (though, I will say, to me personally the current workflow seems to make a lot of sense), at which point I'd be interested in listening. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Freelance 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 ruth at bywatersolutions.com Wed May 11 20:21:40 2011 From: ruth at bywatersolutions.com (D Ruth Bavousett) Date: Wed, 11 May 2011 14:21:40 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: <4DCAD3B4.20609@bywatersolutions.com> Okay, Jared, you touched a spot that I've got to point at, teammate. On 5/11/2011 2:01 PM, Jared Camins-Esakov wrote: > has a concrete suggestion Here, precisely, is what's needed, rather that someone kvetching about a process that they don't approve of. If someone is unhappy with the current process--as sane as it seems to me and (apparently) many others--then that's fine; no one requires that you be happy with it. But bring a concrete alternative that isn't "go back, go back!".... The community has proven that they're willing to hear new ideas, over and over again, and no one's gonna throw you over the wall without listening first. There's no such thing as an easy way to do what we're trying to do--it's too big, and too complex, for "easy." Any process will of necessity have a bottleneck or two, no avoiding it. But the current process, as demonstrated by the 3.4 release, works, and it's only going to get better. If someone has an alternative that they think might work better, bring it. Upsetting Chris and others is not a process that will work better. -- D Ruth Bavousett Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software VISIT US AT ALA: BOOTH 732 Headquarters: Santa Barbara, CA Office: Washington, DC Phone/Fax (888)900-8944 http://bywatersolutions.com ruth at bywatersolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmcharlt at gmail.com Wed May 11 20:24:15 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Wed, 11 May 2011 14:24:15 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: Hi, On Wed, May 11, 2011 at 1:01 PM, Chris Cormack wrote: > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off +1 > As Paul has noted in another thread, I am not comfortable with > allowing patches into master untested, and I don't think I could do a > good job as RM if that were to become the case. In that case I would > rather become one of the developers submitting patches again, so > perhaps 3 and 4 are the same for me. This would be a huge step backwards. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From indradg at gmail.com Wed May 11 20:39:41 2011 From: indradg at gmail.com (Indranil Das Gupta) Date: Thu, 12 May 2011 00:09:41 +0530 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: On Wed, May 11, 2011 at 11:03 PM, Owen Leonard wrote: >> 1/ Continue with the current workflow, patches signed off, passed qa, >> then into master, with the goal to increase the rate patches are >> signed off > > This option has my vote. I think it would be a mistake to approve > untested patches. +1. -- Indranil Das Gupta Phone : +91-98300-20971 Blog? ? : http://indradg.randomink.org/blog IRC? ? ? : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From jbrice at ccfls.org Wed May 11 21:22:03 2011 From: jbrice at ccfls.org (John Brice) Date: Wed, 11 May 2011 15:22:03 -0400 Subject: [Koha-devel] Copy of e-mail I sent Chris Message-ID: <4DCAE1DB.7030406@ccfls.org> I sent Chris the following e-mail today and he asked that I post it to the full community. John Brice Meadville Public Library Dear Chris: > > Hi! John Brice here from Meadville. > > I usually just lurk about these mail lists but I thought I would give you > my two cents worth concerning the sign off process. > > First, we seem to have three issues that I can identify. > > Issue 1. There is a large number of submissions (140 at last count) that > need to be signed off on. > > Issue 2. A small number of the patches our very specific and are difficult > to test unless one is running the exact same configuration. > > Issue 3. Quality assurance is becoming more and more critical especially > considering that the installed base is getting bigger. One small problem in > the code can now effect 1,000's of libraries across the world. > > Really, to solve the above three issues you have to identify the most > important issue and then work backwards from their to come up with the > proper solution from there. > > I personally believe that the Issue 3 Quality Assurance is the most > important. There are just too many libraries out there now relying on Koha, > in a production setting, to risk putting in code that has not been properly > vetted. The bottom line is that only a low percentage of libraries will > benefit from a new feature while everyone benefits from clean code. > > Having said that how do we fix issue One and Two? Well Issue one seems to > be a manpower issue. While, Issue two is a very difficult technical issue > concerning system configuration. > > The best way to solve Issue Two is to have a waiver process for certain > developers. Certain developers associated with a large percentage of code > development could, in certain specific circumstances, request a waiver from the > traditional sign off process. The reasons for the waiver would have to be > very specific, such as it would be too difficult too test outside of a > production server. The waivers would have to be tracked (yeah another > thing for the database to keep track of) and if there is any problem at all > the entity granted the waiver would have to be responsible for all > subsequent revisions and fixes. The waiver is not the solution to reduce > the large number of outstanding issues it is a simple means to add code to > Koha that is too difficult to test outside of a very specific configuration. > > So then we come to the big Issue Number 1 the large amount of checks that > have to be made. This is the problem with open source we have to rely on > the good graces of everyone involved in order to move the project forward. > This means that everyone has to set aside their own personal projects and > do stuff for the good of the overall Koha project. That is a tough sell, but frankly, it > is one that is needed. The best way to get this logjam cleared up is to > have someone be put in charge of the issue and then that person start > writing e-mails and so forth to encourage cajole or outright bang heads to > get the sign-offs that are required. If all the developers in Koha would > sign off on one outstanding issue a week we could have the problem resolved > in three to four months. Someone needs to keep hammering away at this issue > and I don't think it should be you Chris. > > Just some thoughts from a librarian stuck in the Allegheny National Forest. > > John Brice From kyle.m.hall at gmail.com Wed May 11 21:22:43 2011 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 11 May 2011 15:22:43 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: Another vote for keeping the current workflow. Chris has done a fantastic job as RM, nothing else needs to be said. Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org ) On Wed, May 11, 2011 at 1:01 PM, Chris Cormack wrote: > Hi All > > Recently I have been having a crisis of confidence. I have, I hope, > always tried to do what I think is best for the project. Often I do > make mistakes, a notable one happened in 2007, which I hope I in part > was rectified in 2008. But my underlying motivation with Koha has > always been to do the best for the users of the software. > In my role as Release Manager for 3.4 (and again for 3.6) what I felt > was best for the software users was a stable and well tested release. > This is something I made clear in my proposal, and which I had assumed > was understood (but you know what they say about assumptions ;)). With > the huge amount of work put in by over 80 people, I think we managed > to achieve some measure of success with that with 3.4.0 and that the > stability of the 3.2.x releases is something we can all be proud of. > > Over the last couple of weeks, comments and mails both on and off list > have made me think that maybe I am out of step with what the community > desires. For 3.6 quality was still the major goal, but perhaps I have > misjudged what others want. ?This has resulted in sleepless nights and > quite a large amount of self doubt. > > Luckily we are still early in the 3.6 cycle, there is time to fix it. > > Options as I see them > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off > 2/ Refine the workflow to make signing off easier > 3/ Redesign the workflow eliminating sign off (for a period, or all of > the release) > 4/ Step aside to let someone else have a go at RM > > As Paul has noted in another thread, I am not comfortable with > allowing patches into master untested, and I don't think I could do a > good job as RM if that were to become the case. In that case I would > rather become one of the developers submitting patches again, so > perhaps 3 and 4 are the same for me. > > So, in the interest of transparency and openness, there's where my > head and heart are. I wish what is best for the users of Koha, and I > fear that maybe I am out of step. > > Comments? > > 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/ > From cnighswonger at foundations.edu Wed May 11 21:50:00 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 11 May 2011 15:50:00 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: On Wed, May 11, 2011 at 2:24 PM, Galen Charlton wrote: > Hi, > > On Wed, May 11, 2011 at 1:01 PM, Chris Cormack > wrote: > > 1/ Continue with the current workflow, patches signed off, passed qa, > > then into master, with the goal to increase the rate patches are > > signed off > > +1 > > +1 as well. > > As Paul has noted in another thread, I am not comfortable with > > allowing patches into master untested, and I don't think I could do a > > good job as RM if that were to become the case. In that case I would > > rather become one of the developers submitting patches again, so > > perhaps 3 and 4 are the same for me. > > This would be a huge step backwards. > It would indeed. The 3.4-plus workflow and release schedules have been changes necessary to the substructure of Koha in order for it to support the rapidly expanding superstructure. Reverse them, and the entire thing is in danger of collapsing. Anyone who expects their work to be pushed untested is out of line imho. Kudos to Chris C for a job well done and sticking to the rules. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From indradg at gmail.com Wed May 11 22:54:45 2011 From: indradg at gmail.com (Indranil Das Gupta) Date: Thu, 12 May 2011 02:24:45 +0530 Subject: [Koha-devel] How to add additional options to the items search page for label batch creator? In-Reply-To: References: Message-ID: Hi all, My client has a spine label generation requirement, where they want the following options from screen generated by label-item-search.pl a) based on a date range (in which the books are processed) b) based on an accession number range c) based on a class no. (e.g. i want to print the stickers for items with 005 / DDC22) From fridolyn.somers at gmail.com Thu May 12 09:05:22 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Thu, 12 May 2011 09:05:22 +0200 Subject: [Koha-devel] deleteditems marc In-Reply-To: <4DCA7734.2090305@gmail.com> References: <4DCA7734.2090305@gmail.com> Message-ID: BUG6331 created. On Wed, May 11, 2011 at 1:47 PM, LAURENT Henri-Damien < henridamien.laurent at gmail.com> wrote: > Le 11/05/2011 11:24, Fridolyn SOMERS a ?crit : > > Hello, > > > > I found that there is, in current revision on git.koha-community.org > > , a difference between "items" and > > "deleteditems" tables in "kohastructure.sql" : > > "deleteditems" has a field "marc" not existing in "items". > > > > Can it be deleted ? > > > It should be imho. > Patch welcome :) > -- > Henri-Damien LAURENT > > Regards, > > > > -- > > Fridolyn SOMERS > > ICT engineer > > PROGILONE - Lyon - France > > fridolyn.somers at gmail.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/ > -- 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 M.de.Rooy at rijksmuseum.nl Thu May 12 09:13:38 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 12 May 2011 07:13:38 +0000 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3124F0B5@S-MAIL-1B.rijksmuseum.intra> Chris, You are doing an excellent job as release manager!! Looking at the list, you are certainly not out of step with the community. Please continue to do so, perhaps even with some more sleep ;) Referring to a mail I posted yesterday, I would go for something between option 1 and option 2. I do not favor pushing without testing. So please excuse my repeating it here: Could we also assign people to signing off patches by bug category, just as we have some (old?) defaults for bug assignment? These persons could signoff themselves or take the lead in asking others to signoff a patch. (Or even thank the new developers for sending a patch, just as in the simplicty document.) I would be willing to have one or two categories.. If this approach of having two assignments is not practical, we could reevaluate the current assignments and ask everyone on that list to take the signoff responsibility too (including delegating signoffs and advertizing bugs just like Paul's hacking corner mails). It would add to the job of "bug wrangler" and hopefully make it easier for QA manager and RM.. Any comments on that approach?? Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Chris Cormack Verzonden: woensdag 11 mei 2011 19:02 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] Release Manager 3.6 Hi All Recently I have been having a crisis of confidence. I have, I hope, always tried to do what I think is best for the project. Often I do make mistakes, a notable one happened in 2007, which I hope I in part was rectified in 2008. But my underlying motivation with Koha has always been to do the best for the users of the software. In my role as Release Manager for 3.4 (and again for 3.6) what I felt was best for the software users was a stable and well tested release. This is something I made clear in my proposal, and which I had assumed was understood (but you know what they say about assumptions ;)). With the huge amount of work put in by over 80 people, I think we managed to achieve some measure of success with that with 3.4.0 and that the stability of the 3.2.x releases is something we can all be proud of. Over the last couple of weeks, comments and mails both on and off list have made me think that maybe I am out of step with what the community desires. For 3.6 quality was still the major goal, but perhaps I have misjudged what others want. This has resulted in sleepless nights and quite a large amount of self doubt. Luckily we are still early in the 3.6 cycle, there is time to fix it. Options as I see them 1/ Continue with the current workflow, patches signed off, passed qa, then into master, with the goal to increase the rate patches are signed off 2/ Refine the workflow to make signing off easier 3/ Redesign the workflow eliminating sign off (for a period, or all of the release) 4/ Step aside to let someone else have a go at RM As Paul has noted in another thread, I am not comfortable with allowing patches into master untested, and I don't think I could do a good job as RM if that were to become the case. In that case I would rather become one of the developers submitting patches again, so perhaps 3 and 4 are the same for me. So, in the interest of transparency and openness, there's where my head and heart are. I wish what is best for the users of Koha, and I fear that maybe I am out of step. Comments? 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/ From fridolyn.somers at gmail.com Thu May 12 10:13:24 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Thu, 12 May 2011 10:13:24 +0200 Subject: [Koha-devel] For Kind Information In-Reply-To: References: Message-ID: Hie, You may have a wrong Apache configuration. Koha seams to have a problem to find the templates folder (opac-tmpl). Can you give us your koha-httpd.conf ? Regards, 2011/5/10 Librarian, DIU > Dear > Koha development manager > > I would like to inform you that I am a librarian of Daffodil International > University, Bangladesh , Dhaka. Recently we installed KOHA in our library > and a training on KOHA +MARC 21 also completed successfully. We are mapping > our whole data and uploaded in koha database. When we are searching any book > by title but search result is showing not found and sometime error like Could > not find opac-search.xml in /usr/share/koha/opac/cgi-bin/opac/ at > /usr/share/koha/lib/C4/Search.pm line 579. We did not find out whats > problem arise, please help me in this regards. Thank you very much. > > > With best regards, > > > Md. Milan Khan > Librarian > Daffodil International University > Dhaka, Bangladesh > > _________________________ > 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 paul.poulain at biblibre.com Thu May 12 12:15:39 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 12:15:39 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: <4DCBB34B.9010904@biblibre.com> Le 11/05/2011 19:01, Chris Cormack a ?crit : > Hi All Hi All > Recently I have been having a crisis of confidence. It's exactly the same for me, as we're speaking openly. > I have, I hope, > always tried to do what I think is best for the project. It's exactly the same for me (does anyone have a doubt about that ?) > Often I do > make mistakes, a notable one happened in 2007, which I hope I in part > was rectified in 2008. But my underlying motivation with Koha has > always been to do the best for the users of the software. Repeating (sorry): it's exactly the same for me. > In my role as Release Manager for 3.4 (and again for 3.6) what I felt > was best for the software users was a stable and well tested release. > This is something I made clear in my proposal, and which I had assumed > was understood (but you know what they say about assumptions ;)). With > the huge amount of work put in by over 80 people, I think we managed > to achieve some measure of success with that with 3.4.0 and that the > stability of the 3.2.x releases is something we can all be proud of. > > Over the last couple of weeks, comments and mails both on and off list > have made me think that maybe I am out of step with what the community > desires. For 3.6 quality was still the major goal, but perhaps I have > misjudged what others want. This has resulted in sleepless nights and > quite a large amount of self doubt. It's exactly the same for me: sleepless nights a a large amount of self doubt. I'm really not kidding. > Luckily we are still early in the 3.6 cycle, there is time to fix it. > > Options as I see them > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off > 2/ Refine the workflow to make signing off easier > 3/ Redesign the workflow eliminating sign off (for a period, or all of > the release) > 4/ Step aside to let someone else have a go at RM > > As Paul has noted in another thread, I am not comfortable with > allowing patches into master untested, and I don't think I could do a > good job as RM if that were to become the case. In that case I would > rather become one of the developers submitting patches again, so > perhaps 3 and 4 are the same for me. well, the question is not the one I asked (maybe i'm not clear enough, sorry, in french it would be easier to say what I mean, but won't be easier to understand for you ;-) ) (chris: I think the 4 options of your query form a kind of -unwanted- syllogism http://en.wikipedia.org/wiki/Syllogism or sophism -http://en.wikipedia.org/wiki/Sophism ) First of all, the question is not "should I resign" (maybe I agree that you should have a break, at least during a few nights ;-) ). If I had think you were not a good RM, I would not have suggested to be RM for more than 1 release (see my mail on koha-devel, 2010, july, 24th "Release Manager, How long (open question)") The question is not either "should we abandon stability ?". That's the underlying question you're asking, at least that's how ppl understand it: Owen : > I think it would be a mistake to approve untested patches. my opinion: 'of course it would be !' Nicole: > I think that a more stable Koha is in the best interests of the software and the community. my opinion: 'of course it is !' (I must add it's in the best interests of the libraries -and we have 100+ libraries using Koha through BibLibre, so it's the best interests for our business ;-) ) Brendan: > (untested patches--) my opinion: 'of course -- !' ... I repeat: my concern is not to insert "untested" patches into a public release, not at all ! I'm saying that: * BibLibre patches reaches bugzilla after they've been tested. * new features stay unsigned-off for a long period, that's a pity, unefficient, and add a lot of overhead for the submitter! Here is the workflow we follow at BibLibre: * for bugfixes: devA write a patch on a branch, hdl/me tests the patch and merge it on biblibre/master (see git.biblibre.com, the only few exceptions are really trivial patches like removing warns), apply immediatly to customer that declared the bug, apply to everybody on next quarterly update. If we submit the patch, can't we consider it has been tested/validated by enough eyes ? Do we need another one ? frankly, I don't think so ! * for new features: devA write a cool new feature sponsored by a library. It's tested by our project manager (a librarian, that don't know how to "sign-off" a patch !), tested by the customer/library, go live to the customer library. Can't we consider it has been tested/validated by enough eyes ? Do we need another one ? Worst of all: the new feature is untested by anyone, it stays on bugzilla for weeks/months. Then someone else submit a cool new feature that is signed-off and merged quickly, except it overlaps with the 1st one. That is no more applicable. So, stuff to do again and again. Just one example: the branch 5575/5872 from BibLibre, for circulation improvements. It has been done ... 4 times ! once sponsored by the customer, once splitted by hdl/me before KohaCon10, once splitted again by chris (funded by BibLibre, without library sponsorship), and, hackfest came, we've discovered that ByWaterSolution made something interesting for hard-due dates that ... is not compatible with this branch (#5548). hdl takes 3 more days to work on it. And it's still not here. This problem is huge for us, as we have something like 30 branches with cool new features (most if not all of them are on the wiki). Many of them have Branch A required for branchB, required for branchC,... imagine a second how long it will take to merge them into official... Back to community workflow: I see that the workflow ensure stability, but we have completly lost agility ! And we need agility as well as stability. Otherwise, we will end as stable as a stone, but as moving as a stone (exaggerating a little bit, I agree ;-) ) Let me take some example again: * really, don't you think having a security hole for ppl using CAS (#5595) is not a problem that must be dealed quickly ? I say BibLibre wrote, tested and went live with it. What do we really need more ? * really, don't you think having a patch to fix something on LDAP not merged for months is OK ? (see mail from Dobrica this week) * large stuff usually requires a lot of time & conditions & pre-requisites to be tested. The community has proven to be unable to test "large" features (thx owen for the work you made on 5575/5872, but it has not hit master yet...), so should we continue to ignore that fact ? (BibLibre stuff around solR is almost done, it works well, result in huge improvements on many aspects, will anyone be able to take something like 5 full days to setup solr and test ?) I'm not sure I have an immediate solution. But I see there is a problem. However, the community may decide there is no problem at all. In this case, BibLibre is stuck with a "de facto" fork, and will have to explain to his customers/libraries that the features they've sponsored haven't be merged into official/master despite our efforts, so the customer has 2 solutions: drop the features, and stay with the community version or keep the features and be a "de facto fork". None of those solutions are good I'm sure you agree. So, here is the final question. Please vote: 1- Paul, OK, the problem you rise is a real one, you're a valuable contributor, let's try to find a solution to retrieve agility (without loosing stability) 2- Paul, shut-up, everything is perfect we don't need to change anything. [In this case, BibLibre only option will be to explain to our customers they've a de-facto fork and they must choose between their features and stay "community". And that probably means we will start an official fork, with all our cool -and stable- new stuff. Sorry, but I don't see an other possibility] At the end, i haven't answered chris question: I vote 1 AND 2 : > 1/ Continue with the current workflow, patches signed off, passed qa, > then into master, with the goal to increase the rate patches are > signed off > 2/ Refine the workflow to make signing off easier My opinion is that we won't increase the rate patches are signed off without refining the workflow. > So, in the interest of transparency and openness, there's where my > head and heart are. I wish what is best for the users of Koha, and I > fear that maybe I am out of step. Same for me: that's where my head and heart are [chris: There are so many things we share ;-)] -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From mjr at phonecoop.coop Thu May 12 12:30:52 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 12 May 2011 11:30:52 +0100 (BST) Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: Message-ID: <20110512103052.8CDE89EC0B@nail.towers.org.uk> Chris Cormack > Over the last couple of weeks, comments and mails both on and off list > have made me think that maybe I am out of step with what the community > desires. For 3.6 quality was still the major goal, but perhaps I have > misjudged what others want. This has resulted in sleepless nights and > quite a large amount of self doubt. [...] > Comments? I think you're right. We're reworking ourselves to meet this policy (it will be good for the soul!) and should be back on board properly soon. I'd be disappointed to see the process change just as we really got it figured out! Hope that helps, -- 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 irmalibraries at gmail.com Thu May 12 14:13:01 2011 From: irmalibraries at gmail.com (Irma Birchall) Date: Thu, 12 May 2011 22:13:01 +1000 Subject: [Koha-devel] 3.0.x maintenance discontinued In-Reply-To: <4DC98D09.7000807@biblibre.com> References: <4DC98D09.7000807@biblibre.com> Message-ID: <4DCBCECD.6090101@gmail.com> Thanks for all your hard work on Koha V 3.0. Henri-Damien!!! Irma CALYX On 11/05/11 05:07, LAURENT Henri-Damien wrote: > Hi > any Koha users will have noticed that 3.0.x has had no release in one year. > I just have to face the facts. I am not able to get any release for this > version out seriously tested. > So I have to announce that the maintenance of this version is over. > Please consider upgrading to 3.2 or even better 3.4 > If anyone is interested in taking that action, please step in onlist and > ask for access. > Thanks. From oleonard at myacpl.org Thu May 12 14:35:42 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 12 May 2011 08:35:42 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124F0B5@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3124F0B5@S-MAIL-1B.rijksmuseum.intra> Message-ID: > So please excuse my repeating it here: Could we also assign people to signing off > patches by bug category, just as we have some (old?) defaults for bug assignment? I don't think we should set up a new "rule" to follow and old one that doesn't much work. Having default bug assignments doesn't really work very well because hardly any bug category has few enough bugs for any one person to be responsible for them. How would this be any different with assignments for signing off on bugs? Particularly when the same pool of people who are getting the default assignments will be splitting up the default signoffs. Perhaps we need to get creative about soliciting signoffs. "I'll test yours if you test mine?" -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From bob at calyx.net.au Thu May 12 14:41:40 2011 From: bob at calyx.net.au (Bob Birchall) Date: Thu, 12 May 2011 22:41:40 +1000 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBB34B.9010904@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> Message-ID: <4DCBD584.4000006@calyx.net.au> On 12/05/11 20:15, Paul Poulain wrote: (snip) >> So, in the interest of transparency and openness, there's where my >> head and heart are. I wish what is best for the users of Koha, and I >> fear that maybe I am out of step. > Same for me: that's where my head and heart are [chris: There are so > many things we share ;-)] > I am not a developer. I enter this discussion in a spirit of the greatest respect for Chris and for Paul, two giants of the Koha project. I am aware that in all likelihood, my understanding of the issues here is shallow. I desperately want to preserve the unity of the community. I think the work flow is sound and that Chris is to be congratulated for enforcing it, to ensure the quality of the Koha code. I also think Biblibre's problem is real and deserves recognition. There are times (or features) where the community lacks the resources to achieve sign-off. A compromise is needed. My thinking is influenced by the knowledge that the patches Biblibre seeks to incorporate have been tested and accepted by customers and are operating features in regular use. The main issue (I guess) is the passage of time since they were re-based against Master. (Forgive me if that is not technically correct - I think its close in principal?) How about this approach: - we designate a very small number of companies with the capacity and track record of major feature integration, as being authorised to short cut community QA before integrating major features (only); - minor features and bug fixes remain subject to the existing work flow; - I'm thinking ByWater, Biblibre and Catalyst at this stage - others can argue their own case; - such features must be integrated at least two months before a scheduled release, and assistance provided to community members to perform testing; - if significant problems are detected that are not rectified n weeks (2?) before release date, the feature will be withdrawn. I'm sorry if this is naive. I hope it may help the discussion along. Bob Birchall From oleonard at myacpl.org Thu May 12 14:51:49 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 12 May 2011 08:51:49 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBD584.4000006@calyx.net.au> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> Message-ID: On Thu, May 12, 2011 at 8:41 AM, Bob Birchall wrote: > How about this approach: > - we designate a very small number of companies with the capacity and track > record of major feature integration, as being authorised to short cut > community QA before integrating major features (only); > > - minor features and bug fixes remain subject to the existing work flow; Minor features and bug fixes are less likely to break something than major features. It is precisely because some of the features pending signoff are so large and broadly-scoped that it is difficult to properly test them. Part of becoming more "agile," if we must use that term, is to learn to keep our contributions manageable and feature-specific. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From nengard at gmail.com Thu May 12 14:57:48 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 12 May 2011 08:57:48 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBD584.4000006@calyx.net.au> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> Message-ID: On Thu, May 12, 2011 at 8:41 AM, Bob Birchall wrote: > How about this approach: > - we designate a very small number of companies with the capacity and track > record of major feature integration, as being authorised to short cut > community QA before integrating major features (only); > - minor features and bug fixes remain subject to the existing work flow; > - I'm thinking ByWater, Biblibre and Catalyst at this stage - others can > argue their own case; > - such features must be integrated at least two months before a scheduled > release, and assistance provided to community members to perform testing; > - if significant problems are detected that are not rectified n weeks (2?) > before release date, the feature will be withdrawn. I don't like this (even if ByWater is included above). Who decides who's special? Why do we need someone to be 'special'? The rules should apply to everyone regardless of who they are. That's why it was so much fun for me to mark one of Chris's patches as failing QA :) ... using your model his patch would have made it in to Koha and wouldn't have done what it expected. Not to pick on Chris, but the point is that no one should be exempt and no one is flawless. On Thu, May 12, 2011 at 8:51 AM, Owen Leonard wrote: > Part of becoming more "agile," if we must use that term, is to learn > to keep our contributions manageable and feature-specific. I agree with Owen. We need to make things manageable. Nicole From paul.poulain at biblibre.com Thu May 12 15:03:26 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 15:03:26 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBD584.4000006@calyx.net.au> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> Message-ID: <4DCBDA9E.80202@biblibre.com> Le 12/05/2011 14:41, Bob Birchall a ?crit : > My thinking is influenced by the knowledge that the patches Biblibre > seeks to incorporate have been tested and accepted by customers and > are operating features in regular use. The main issue (I guess) is > the passage of time since they were re-based against Master. (Forgive > me if that is not technically correct - I think its close in principal?) You're technically correct. > How about this approach: > - we designate a very small number of companies with the capacity and > track record of major feature integration, as being authorised to > short cut community QA before integrating major features (only); Sounds a good idea/necessity according to me. Of course, features should not be merged "from nowhere" and clearly/proudly announced. Any feature that sounds a problem to the community should not be merged either (for example, BibLibre wouldn't merge his solR stuff without agreement from a functionnal point of view. I don't mean a sign-off, because I'm "sure" no-one would be able tosign-off. I see something very interesting with this option : we could have a "sandbox" where librarians/anyone could test a freshly merged feature. I'm sure that would increase the number of tester & bug reporters. > - minor features and bug fixes remain subject to the existing work flow; the question being "what is minor" ? but maybe the monthly meeting can be the place to discuss all the features and decide which is "minor" and which is not ;-) > - I'm thinking ByWater, Biblibre and Catalyst at this stage - others > can argue their own case; sounds a good list ( except it's BibLibre, not Biblibre :D ) > - such features must be integrated at least two months before a > scheduled release, and assistance provided to community members to > perform testing; mmm... I feel 2 months may be too close to the release for major changes. I think 4 months is better. (see my proposal tomorrow: 2 months "quick features", 2 months "strong QA features" and 2 months "feature freeze", roughly. > - if significant problems are detected that are not rectified n weeks > (2?) before release date, the feature will be withdrawn. Yep. But I can promize that BibLibre will rectify any problems immediatly, as it will be the version we will release to our customers ! that's our business responsability !!! > I'm sorry if this is naive. I hope it may help the discussion along. This is not naive, this is a very good proposition to be agile again ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From tajoli at cilea.it Thu May 12 15:26:41 2011 From: tajoli at cilea.it (Zeno Tajoli) Date: Thu, 12 May 2011 15:26:41 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBD584.4000006@calyx.net.au> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> Message-ID: <4DCBE011.4070908@cilea.it> Hi to all, Reading the Paul and Chris mails, I think we can give different level to developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch Attention the idea is A-developers CAN auto sign_off, and the the bugzilla need to isert where the test the feature (user that regulary use it, bug on public git, etc.). More power = more resposability. If an A-developer doesn't sign_off its patch in one day, it is a patch that needs sign_off from an other person. A B-developer need to find a person to test his code, and could be also a user, if he prepare a test enviroment. In fact I'm planning to do exatly in this way. I have 1-2 user with good IT skill, I will open to them a demo site with master + my patch and they read bugzilla, do tests and after they sign_off. Bye Zeno -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer From oleonard at myacpl.org Thu May 12 15:40:13 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 12 May 2011 09:40:13 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBE011.4070908@cilea.it> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> Message-ID: On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli wrote: > Reading the Paul and Chris mails, I think we can give different level to > developers. > A-developers = you can auto-sign_off > B-developer: a person of an other firm need to sign_off your patch This discussion started in part because people were talking about how to get more people involved in Koha development. Setting up a hierarchy like this doesn't sound like a good way to get more people involved. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Thu May 12 16:03:54 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 16:03:54 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> Message-ID: <4DCBE8CA.7070600@biblibre.com> Le 12/05/2011 15:40, Owen Leonard a ?crit : > On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli wrote: >> Reading the Paul and Chris mails, I think we can give different level to >> developers. >> A-developers = you can auto-sign_off >> B-developer: a person of an other firm need to sign_off your patch > This discussion started in part because people were talking about how > to get more people involved in Koha development. Setting up a > hierarchy like this doesn't sound like a good way to get more people > involved. Strongly disagreeing: many projects uses that kind of organisation. And as a newbie i would be happy to know i'm in a special state that ensure that what I'm doing will be reviewed by someone experienced ! Let me say also that getting more ppl involved does also mean not loosing your existing contributors (which is what will arrive with BibLibre contributions if we can't find an agreement that is OK for everybody) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From colin.campbell at ptfs-europe.com Thu May 12 16:18:04 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 12 May 2011 15:18:04 +0100 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> Message-ID: <4DCBEC1C.2090202@ptfs-europe.com> On 12/05/11 14:40, Owen Leonard wrote: > On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli wrote: > >> Reading the Paul and Chris mails, I think we can give different level to >> developers. >> A-developers = you can auto-sign_off >> B-developer: a person of an other firm need to sign_off your patch > > This discussion started in part because people were talking about how > to get more people involved in Koha development. Setting up a > hierarchy like this doesn't sound like a good way to get more people > involved. And its not absolute. Someone might confidently signoff fixes in one area but not have any confidence in signing off in another. Especially for new contributors the most useful thing isn't a sign off or rejection but the 'Great but have you considered the implications in x' kind of feedback. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From lculber at mdah.state.ms.us Thu May 12 16:25:41 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Thu, 12 May 2011 09:25:41 -0500 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBE8CA.7070600@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> Message-ID: <4DCBEDE5.8080802@mdah.state.ms.us> As a) a newbie myself, b) someone scared to death of the development process but still wanting to be involved, and c) one who wants a lot of things developed that will benefit the Koha community as a whole but specifically help Koha to work for archival institutions, I'm going to go against what seems to be the position of my support company (ByWater Solutions) and side with Paul on this one. I'd be more willing to contribute to if I were "in a special state that ensures that what I'm doing will be reviewed by someone experienced !" The way Paul describes, I think, makes everyone "special" - which we all are - just in different ways. IMHO, it's not as much a "hierarchy" (I'm better than you are and therefore look down on you) situation, as a fact of life. I don't know what the compromise is, but I think there is bound to be one. Sorry, if I overstepped by voicing my opinion, since I'm not sure I even get a vote. Linda On 5/12/2011 9:03 AM, Paul Poulain wrote: > Le 12/05/2011 15:40, Owen Leonard a ?crit : >> On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli wrote: >>> Reading the Paul and Chris mails, I think we can give different level to >>> developers. >>> A-developers = you can auto-sign_off >>> B-developer: a person of an other firm need to sign_off your patch >> This discussion started in part because people were talking about how >> to get more people involved in Koha development. Setting up a >> hierarchy like this doesn't sound like a good way to get more people >> involved. > Strongly disagreeing: many projects uses that kind of organisation. > And as a newbie i would be happy to know i'm in a special state that > ensure that what I'm doing will be reviewed by someone experienced ! > > Let me say also that getting more ppl involved does also mean not > loosing your existing contributors (which is what will arrive with > BibLibre contributions if we can't find an agreement that is OK for > everybody) > -- 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 oleonard at myacpl.org Thu May 12 16:29:52 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 12 May 2011 10:29:52 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBEDE5.8080802@mdah.state.ms.us> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> Message-ID: On Thu, May 12, 2011 at 10:25 AM, Linda Culberson wrote: > ?I'd be more willing to > contribute to if I were "in a special state that ?ensures that what I'm > doing will be reviewed by someone experienced !" That's the way the process works now, only everyone must get their work reviewed. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Thu May 12 16:32:16 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 16:32:16 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBEDE5.8080802@mdah.state.ms.us> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> Message-ID: <4DCBEF70.4080408@biblibre.com> Le 12/05/2011 16:25, Linda Culberson a ?crit : > Sorry, if I overstepped by voicing my opinion, since I'm not sure I > even get a vote. Nope, you haven't overstepped anything. We are specially listening to newbies opinion. Old timers like chris & me may have experience, but newbies may have ideas. That's one of the reason why, after being RM for 2 versions I've been happy to see someone else, with a lot of ideas, being a candidate ( as chris said: it was not the best decision i've "voted", but it's easy to say that now we know what happened -see http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html if you don't know- ) -- 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 Thu May 12 16:45:27 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 13 May 2011 02:45:27 +1200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBEDE5.8080802@mdah.state.ms.us> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> Message-ID: On 13 May 2011 02:25, "Linda Culberson" wrote: > > As a) a newbie myself, b) someone scared to death of the development process but still wanting to be involved, and c) one who wants a lot of things developed that will benefit the Koha community as a whole but specifically help Koha to work for archival institutions, I'm going to go against what seems to be the position of my support company (ByWater Solutions) and side with Paul on this one. I'd be more willing to contribute to if I were "in a special state that ensures that what I'm doing will be reviewed by someone experienced !" The way Paul describes, I think, makes everyone "special" - which we all are - just in different ways. IMHO, it's not as much a "hierarchy" (I'm better than you are and therefore look down on you) situation, as a fact of life. I don't know what the compromise is, but I think there is bound to be one. > > Sorry, if I overstepped by voicing my opinion, since I'm not sure I even get a vote. > Linda > Everyone gets a vote. And as Owen said you aren't actually siding against ByWater (im not sure there even are sides), all new patches get oversight, in fact ALL patches get oversight. Thats the current process. What we are discussing, and there seems to be a good discussion on IRC about how to make it easier for people to provide oversight. I am very heartened the discussion is moving in that direction, because I think that is where we win. Make the sign off easier, not remove the need for sign off Chris > > On 5/12/2011 9:03 AM, Paul Poulain wrote: >> >> Le 12/05/2011 15:40, Owen Leonard a ?crit : >>> >>> On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli wrote: >>>> >>>> Reading the Paul and Chris mails, I think we can give different level to >>>> developers. >>>> A-developers = you can auto-sign_off >>>> B-developer: a person of an other firm need to sign_off your patch >>> >>> This discussion started in part because people were talking about how >>> to get more people involved in Koha development. Setting up a >>> hierarchy like this doesn't sound like a good way to get more people >>> involved. >> >> Strongly disagreeing: many projects uses that kind of organisation. >> And as a newbie i would be happy to know i'm in a special state that >> ensure that what I'm doing will be reviewed by someone experienced ! >> >> Let me say also that getting more ppl involved does also mean not >> loosing your existing contributors (which is what will arrive with >> BibLibre contributions if we can't find an agreement that is OK for >> everybody) >> > > -- > 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 skushner at mtpl.org Thu May 12 16:49:20 2011 From: skushner at mtpl.org (Scott Kushner) Date: Thu, 12 May 2011 10:49:20 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBEF70.4080408@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com><4DCBEDE5.8080802@mdah.state.ms.us> <4DCBEF70.4080408@biblibre.com> Message-ID: <3F5DBA7C1433624D870AF4F965358FD660E92F@exchange.mplmain.mtpl.org> Maybe I'm not getting it here, BUT..have we forgotten how long it takes PROPRIETARY VENDORS to develop and debug their code? Maybe it's just me, but I'm amazed at how fast these releases are getting out there. (3.0, 3.2, 3.4...3.6...already?) It will be out soon, I'm sure. Also, and I know it's a hassle, but what's stopping you from writing your own code, integrating it into your instance of Koha, and using it while waiting for code to be tested and accepted into community? You're getting the benefits of your own written, or sponsored, code while having the peace of mind of getting the QA testing from the community. Again, maybe it's me, but am I missing something here? Have we become that impatient and spoiled that we want our pellet now, and let the process be damned? Scott Kushner Information Systems Librarian Middletown Public Library -----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: Thursday, May 12, 2011 10:32 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 Le 12/05/2011 16:25, Linda Culberson a ?crit : > Sorry, if I overstepped by voicing my opinion, since I'm not sure I > even get a vote. Nope, you haven't overstepped anything. We are specially listening to newbies opinion. Old timers like chris & me may have experience, but newbies may have ideas. That's one of the reason why, after being RM for 2 versions I've been happy to see someone else, with a lot of ideas, being a candidate ( as chris said: it was not the best decision i've "voted", but it's easy to say that now we know what happened -see http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html if you don't know- ) -- 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 Thu May 12 16:56:27 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 16:56:27 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> Message-ID: <4DCBF51B.6000405@biblibre.com> Le 12/05/2011 16:45, Chris Cormack a ?crit : > I am very heartened the discussion is moving in that direction, because I > think that is where we win. Make the sign off easier, not remove the need > for sign off I'm not requesting to remove the sign-off. I'm saying our code reaches bugzilla already "signed-off" at least twice (project manager and customer/library), so, yes, the "A-dev" idea of zeno or the "shortcut" idea of Bob is a good one. And I know that "with great power comes great responsibility". I'm very disheartened that the discussion just moves to "make signoff easier". -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From nengard at gmail.com Thu May 12 16:58:26 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 12 May 2011 10:58:26 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBF51B.6000405@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> Message-ID: On Thu, May 12, 2011 at 10:56 AM, Paul Poulain wrote: > I'm not requesting to remove the sign-off. I'm saying our code reaches > bugzilla already "signed-off" at least twice (project manager and > customer/library), Paul, I'm very confused, if your stuff is "signed off" why not just stick the -s in the format-patch command and be done with it? Show everyone that it's signed off and it will go to QA and not have to wait for the rest of us to sign off again. If your patches are signed off, just show that in the patch itself. Nicole From paul.poulain at biblibre.com Thu May 12 17:07:14 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 17:07:14 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> Message-ID: <4DCBF7A2.8020005@biblibre.com> Le 12/05/2011 16:58, Nicole Engard a ?crit : > On Thu, May 12, 2011 at 10:56 AM, Paul Poulain > wrote: >> I'm not requesting to remove the sign-off. I'm saying our code reaches >> bugzilla already "signed-off" at least twice (project manager and >> customer/library), > Paul, Nicole, > I'm very confused, if your stuff is "signed off" why not just stick > the -s in the format-patch command and be done with it? Show everyone > that it's signed off and it will go to QA and not have to wait for the > rest of us to sign off again. It's because we can't ask the customer or the project manager (a librarian) to git format-patch -s ! They are validating the feature by testing, and say "OK, it works". So no "signed-off by XXX" on the patch. Do you think/mean we should just create all our patches with status "signed-off" ? It's a kind of "shortcut" / "A-developer" isn't it ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From nengard at gmail.com Thu May 12 17:10:55 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 12 May 2011 11:10:55 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBF7A2.8020005@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> Message-ID: On Thu, May 12, 2011 at 11:07 AM, Paul Poulain wrote: > It's because we can't ask the customer or the project manager (a > librarian) to git format-patch -s ! As a librarian that's just you not giving them enough credit. I agree you don't ask the customer (unless the customer wants to do it) but you can ask and train your project manager. We have customers test our patches and then they're passed on to one of us for a sign off. It's simple, it takes 1 minute more time and it means our patches make it to QA. I feel like this is all being made much harder than it really is. Patches must be signed off, we have a policy in place for that, we cannot assume that patches have been signed off based on who submits them because then we start making exceptions all over the place. Nicole From chris at bigballofwax.co.nz Thu May 12 17:25:14 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 13 May 2011 03:25:14 +1200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> Message-ID: On 13 May 2011 03:10, Nicole Engard wrote: > On Thu, May 12, 2011 at 11:07 AM, Paul Poulain > wrote: >> It's because we can't ask the customer or the project manager (a >> librarian) to git format-patch -s ! > > As a librarian that's just you not giving them enough credit. I agree > you don't ask the customer (unless the customer wants to do it) but > you can ask and train your project manager. ?We have customers test > our patches and then they're passed on to one of us for a sign off. > It's simple, it takes 1 minute more time and it means our patches make > it to QA. > > I feel like this is all being made much harder than it really is. > Patches must be signed off, we have a policy in place for that, we > cannot assume that patches have been signed off based on who submits > them because then we start making exceptions all over the place. > Another option is to set the bug to Signed Off And note in the notes, who signed it off "Billy Bob Library signed this off on the 12/5/2011, tested also by Janey Joe Library. Developed internally by sue and james, and signed off internally by kathy" Also the signed off part of a patch is not anything super special you don't have to do it with -s If Lyon has signed off a patch (tested it, approved it works and breaks nothing else). You can add Signed-off-by: Lyon University To the patch just before the ---, and it will show as signed off. git is cool like that Chris From cnighswonger at foundations.edu Thu May 12 17:26:55 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 12 May 2011 11:26:55 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBF7A2.8020005@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> Message-ID: Hi Paul, On Thu, May 12, 2011 at 11:07 AM, Paul Poulain wrote: > Do you think/mean we should just create all our patches with status > "signed-off" ? It's a kind of "shortcut" / "A-developer" isn't it ? > We are currently accepting patches into QA which are signed off by employees of the same company as the author of the patch. So I'm a bit confused as to why Biblibre cannot adopt a similar procedure in order to get their patches into QA? Perhaps if the issue is moving patches representing larger/more complicated features through QA, the submitter could provide references to installations/clients currently running the feature(s). The QA manager could then contact the supplied reference to verify QA and push the patch on up the chain. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu May 12 17:30:14 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 17:30:14 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> Message-ID: <4DCBFD06.8000900@biblibre.com> Le 12/05/2011 17:10, Nicole Engard a ?crit : > As a librarian that's just you not giving them enough credit. I agree > you don't ask the customer (unless the customer wants to do it) but > you can ask and train your project manager. We have customers test > our patches and then they're passed on to one of us for a sign off. > It's simple, it takes 1 minute more time and it means our patches make > it to QA. Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So you've inclined to vote 2 to my previous question? (Or do I go too far, and it's not what you want to say) Paul wrote: > So, here is the final question. > Please vote: > 1- Paul, OK, the problem you rise is a real one, you're a valuable > contributor, let's try to find a solution to retrieve agility (without > loosing stability) > 2- Paul, shut-up, everything is perfect we don't need to change > anything. [In this case, BibLibre only option will be to explain to our > customers they've a de-facto fork and they must choose between their > features and stay "community". And that probably means we will start an > official fork, with all our cool -and stable- new stuff. Sorry, but I > don't see an other possibility] -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From nengard at gmail.com Thu May 12 17:34:44 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 12 May 2011 11:34:44 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBFD06.8000900@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFD06.8000900@biblibre.com> Message-ID: On Thu, May 12, 2011 at 11:30 AM, Paul Poulain wrote: > Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So > you've inclined to vote 2 to my previous question? > (Or do I go too far, and it's not what you want to say) I'm saying that you're not giving your librarian/project manager enough credit. I'm saying that as a trainer I hate it when people say that a librarian can't do something cause they're a librarian. Nicole From skushner at mtpl.org Thu May 12 17:36:05 2011 From: skushner at mtpl.org (Scott Kushner) Date: Thu, 12 May 2011 11:36:05 -0400 Subject: [Koha-devel] FW: Release Manager 3.6 Message-ID: <3F5DBA7C1433624D870AF4F965358FD660E931@exchange.mplmain.mtpl.org> I vote for #1...obviously don't want to see a fork. We've been down that road... But the question is, to my mind, how to implement a new sign off process....?? Scott Kushner Information Systems Librarian Middletown Public Library -----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: Thursday, May 12, 2011 11:30 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 Le 12/05/2011 17:10, Nicole Engard a ?crit : > As a librarian that's just you not giving them enough credit. I agree > you don't ask the customer (unless the customer wants to do it) but > you can ask and train your project manager. We have customers test > our patches and then they're passed on to one of us for a sign off. > It's simple, it takes 1 minute more time and it means our patches make > it to QA. Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So you've inclined to vote 2 to my previous question? (Or do I go too far, and it's not what you want to say) Paul wrote: > So, here is the final question. > Please vote: > 1- Paul, OK, the problem you rise is a real one, you're a valuable > contributor, let's try to find a solution to retrieve agility (without > loosing stability) > 2- Paul, shut-up, everything is perfect we don't need to change > anything. [In this case, BibLibre only option will be to explain to our > customers they've a de-facto fork and they must choose between their > features and stay "community". And that probably means we will start an > official fork, with all our cool -and stable- new stuff. Sorry, but I > don't see an other possibility] -- 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 Thu May 12 17:42:26 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 12 May 2011 17:42:26 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> Message-ID: <4DCBFFE2.4060508@biblibre.com> Le 12/05/2011 17:26, Chris Nighswonger a ?crit : > We are currently accepting patches into QA which are signed off by employees > of the same company as the author of the patch. > > So I'm a bit confused as to why Biblibre cannot adopt a similar procedure in > order to get their patches into QA? I'm not only speaking of patches fixing a bug, but also of large updates adding a feature. Chris has said he wouldn't accept such a patch/branch self-signed. > Perhaps if the issue is moving patches representing larger/more complicated > features through QA, the submitter could provide references to > installations/clients currently running the feature(s). The QA manager could > then contact the supplied reference to verify QA and push the patch on up > the chain. mmm... That would be fun to see one of our -French speaking- library answering a mail in English ;-) I don't think it's a possible way to go. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From laurenthdl at alinto.com Thu May 12 18:04:00 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Thu, 12 May 2011 18:04:00 +0200 Subject: [Koha-devel] Technical issues with current workflow [ was: Release Manager 3.6] In-Reply-To: <3F5DBA7C1433624D870AF4F965358FD660E92F@exchange.mplmain.mtpl.org> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com><4DCBEDE5.8080802@mdah.state.ms.us> <4DCBEF70.4080408@biblibre.com> <3F5DBA7C1433624D870AF4F965358FD660E92F@exchange.mplmain.mtpl.org> Message-ID: <4DCC04F0.60302@alinto.com> Le 12/05/2011 16:49, Scott Kushner a ?crit : > Maybe I'm not getting it here, BUT..have we forgotten how long it takes PROPRIETARY VENDORS to develop and debug their code? > > Maybe it's just me, but I'm amazed at how fast these releases are getting out there. (3.0, 3.2, 3.4...3.6...already?) It will be out soon, I'm sure. Also, and I know it's a hassle, but what's stopping you from writing your own code, integrating it into your instance of Koha, and using it while waiting for code to be tested and accepted into community? You're getting the benefits of your own written, or sponsored, code while having the peace of mind of getting the QA testing from the community. > > Again, maybe it's me, but am I missing something here? Have we become that impatient and spoiled that we want our pellet now, and let the process be damned? > > Scott Kushner > Information Systems Librarian > Middletown Public Library > Scott, The problem we have in BibLibre is that we developped things for 3.4 as 3.2 was not out. And that some other features have been pushed that broke our code. Therefore we had to re engineer that code 4 times. And that at some point, we are quite getting upset to see that still, that code is not going to get seriously considered because it scares ppl away. Having waited for over 2 years is quite a long time. And we would like to get things validated. More and more libraries are working now with that code... because they ask for Koha AND those features... Kyle Hall may have the same issues, but his features are more external modules, so he may be ok with that and handle that ok. For us it has not been a problem not to see that in 3.2 . It was announced in RFCs for 3.4, but it was developped and delivered before 3.2 was out. And contains both new features and bug fixes... (Because, believe it or not, as we developped, we discovered existing bugs...) And we have our french bugtracker. But each and every bug we declared in our bugtracker was not translated and updated in bugzilla because we worked hard to get things done. And the wonderful job done by the community (which I donot negate) is making our lives a nightmare rebasing and redoing things. So that we are wondering whether we could continue working and proposing features, if we cannot make them in 2 years after they are delivered and tested. But it is not only a BibLibre problem. I think, many libraries are working with a Koha fork (little or big, a fork is a fork, would it be just an xslt change) that is fitting their needs. Our problem is that we donot want this to happen for our libraries and our code, and we care. And that we have vainly struggled to make them in in many ways. So that at some point, financially, technically, and strategically some concerns have to be discussed. What will happen when we are more than 5 very active companies if some big features are lost in the wild and re processed by another firm or will have to be re engineered over and over again because there is no planning, no developing group, no vision, no common goal. It already happened with fine in days. Two companies did work on that feature, we and xercode, and still, that feature is not in Koha. And it is just an exemple. Friendly -- Henri-Damien LAURENT From laurenthdl at alinto.com Thu May 12 18:27:36 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Thu, 12 May 2011 18:27:36 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> Message-ID: <4DCC0A78.6050803@alinto.com> Le 12/05/2011 16:58, Nicole Engard a ?crit : > On Thu, May 12, 2011 at 10:56 AM, Paul Poulain > wrote: >> I'm not requesting to remove the sign-off. I'm saying our code reaches >> bugzilla already "signed-off" at least twice (project manager and >> customer/library), > > Paul, > > I'm very confused, if your stuff is "signed off" why not just stick > the -s in the format-patch command and be done with it? Show everyone > that it's signed off and it will go to QA and not have to wait for the > rest of us to sign off again. > > If your patches are signed off, just show that in the patch itself. > > Nicole Nicole We have a merge workflow rather than a sign off on individual patches. That way, features can be tested and integrated much more smoothly. Unfortunately, signing off changes the commit id. And it requires some more actions, that our project manager will not be able and not be willing to add in their process. So that, Paul is speaking of a user sign off but not a git sign-off. That 'git sign-off' all mighty process looks strange to me. It supposes a feature touches only some little parts of Koha, and quite often, it is not the case or makes very little changes. The problem is that those not signed-off patches were rebased from our code, then re-process by Paul and then by Chris, and we kept from signing off on those because Chris wanted some other company to sign them... And Chris kept from having them signed-off by one of his catalyst teammate because he wanted some one else to have a look at them. Problem is that then... noone tests them sign off on them. Your workflow doesnot fit merge workflow. How would we cope with a git-pullrequest ? would we ask for a signoff in every single patch ? would we just test the branch, see how it works and do the merge and if that does not merge straight forward, ask for rebase ? And when you develop things once, twice and then 4 times, one ends up quite nervous at getting things behind. We participated and play our part in sign off, and development process. Some features were not contributed though talked about for some time now. I think because of that kind of thing (thinking of EDI for instance, but maybe some other RFID process). It takes time to reprocess things and to adapt them when new features come into the way. Maybe libraries are ok with that. But in my opinion, when their features have not reached the trunk, they have wasted their money, and developers wasted their time. -- Henri-Damien LAURENT From laurenthdl at alinto.com Thu May 12 18:50:52 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Thu, 12 May 2011 18:50:52 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFD06.8000900@biblibre.com> Message-ID: <4DCC0FEC.30203@alinto.com> Le 12/05/2011 17:34, Nicole Engard a ?crit : > On Thu, May 12, 2011 at 11:30 AM, Paul Poulain > wrote: >> Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So >> you've inclined to vote 2 to my previous question? >> (Or do I go too far, and it's not what you want to say) > > I'm saying that you're not giving your librarian/project manager > enough credit. I'm saying that as a trainer I hate it when people say > that a librarian can't do something cause they're a librarian. > > Nicole Well, translations, trainings, project management, interface with libraries in the global design are already HUGE tasks. It is not a matter of 'credit', it is a matter of time. I donot want to ask them to spend time on what looks geeky stuff to them. They have a role, with enough responsablility and are devoted enough not to add them a task, taking the git code onto their laptop, and adding sign-off on the patch. But ok it is not out of reach to imagine that future patches will have sign offs when they are submitted, even fancy ones like Limoges and Saint Etienne... Even though, sign off changes the commit id. With a merge workflow, it breaks the whole thing. But OK the community despises merge workflow. We could send patches onlist. Fair enough... For the future, if we can continue to contribute. But we have some old patches there. And those patches are touching serious parts (circulation and members). And those patches are important both for us and for some of our libraries. And rebasing, having to reengineer them over and over makes that more and more risky. Adding a REBASE tag to the patch and resending all the patches that need rebasing any time they need rebasing would quite spam the list I guess with the 150 patches waiting sign-off (I am not speaking of BibLibre particularly there but xss patch for instance.). Friendly -- Henri-Damien LAURENT From dearden at sarsf.org Thu May 12 19:03:09 2011 From: dearden at sarsf.org (Doug Dearden) Date: Thu, 12 May 2011 11:03:09 -0600 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCC0FEC.30203@alinto.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFD06.8000900@biblibre.com> <4DCC0FEC.30203@alinto.com> Message-ID: Greetings all, Reading this thread I think the core issue is this. Can a big enhancement that has been developed by one company be signed off by that company as well. Currently the work flow suggests that anything more than minor bugs should not be signed off by someone in the same company. However, if within the company developer A has done the work, developer B has tested it and signed off internally, and it is in use at a library that the company supports and is running without issue, then is that enough to allow it to be pushed to the master branch of that release? I think it is. As a minor developer (I submitted an enhancement that the librarian where I work wanted implemented) I can say that I welcomed the help of the community, including the feedback during the process as well as some revisions to my code to make it cleaner. The process was a little daunting for a total newbie but I got a lot of help and was happy to have the requirement in place that someone else sign off on my changes. But I am the IT support person for a small non-profit that includes an academic library. This is a small part of my job, not my primary business. I don't mind having different rules for me than for those that are providing the primary development and support for Koha. So perhaps a simple change fixes this, allowing an internal sign off for any bug/enhancement, not just for the "minor" ones. Then push to master so no one has to rebase constantly. Or am I missing something crucial? Regards, Doug Dearden Director, IT School for Advanced Research (505)954-7220 sarweb.org -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of LAURENT Henri-Damien Sent: Thursday, May 12, 2011 10:51 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 Le 12/05/2011 17:34, Nicole Engard a ?crit : > On Thu, May 12, 2011 at 11:30 AM, Paul Poulain > wrote: >> Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So >> you've inclined to vote 2 to my previous question? >> (Or do I go too far, and it's not what you want to say) > > I'm saying that you're not giving your librarian/project manager > enough credit. I'm saying that as a trainer I hate it when people say > that a librarian can't do something cause they're a librarian. > > Nicole Well, translations, trainings, project management, interface with libraries in the global design are already HUGE tasks. It is not a matter of 'credit', it is a matter of time. I donot want to ask them to spend time on what looks geeky stuff to them. They have a role, with enough responsablility and are devoted enough not to add them a task, taking the git code onto their laptop, and adding sign-off on the patch. But ok it is not out of reach to imagine that future patches will have sign offs when they are submitted, even fancy ones like Limoges and Saint Etienne... Even though, sign off changes the commit id. With a merge workflow, it breaks the whole thing. But OK the community despises merge workflow. We could send patches onlist. Fair enough... For the future, if we can continue to contribute. But we have some old patches there. And those patches are touching serious parts (circulation and members). And those patches are important both for us and for some of our libraries. And rebasing, having to reengineer them over and over makes that more and more risky. Adding a REBASE tag to the patch and resending all the patches that need rebasing any time they need rebasing would quite spam the list I guess with the 150 patches waiting sign-off (I am not speaking of BibLibre particularly there but xss patch for instance.). Friendly -- Henri-Damien LAURENT _______________________ 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 gmcharlt at gmail.com Thu May 12 19:17:37 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Thu, 12 May 2011 13:17:37 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFD06.8000900@biblibre.com> <4DCC0FEC.30203@alinto.com> Message-ID: Hi, On Thu, May 12, 2011 at 1:03 PM, Doug Dearden wrote: > Reading this thread I think the core issue is this. ?Can a big enhancement that has been > developed by one company be signed off by that company as well. ?Currently the work > flow suggests that anything more than minor bugs should not be signed off by someone > in the same company. ?However, if within the company developer A has done the work, > developer B has tested it and signed off internally, and it is in use at a library that the > company supports and is running without issue, then is that enough to allow it to be > pushed to the master branch of that release? ?I think it is. I disagree. Successful use in a library is evidence that the feature meets that particular library's needs. It is not sufficient evidence that the implementation of the feature is good and does not interfere with other libraries' use of Koha. It is also not sufficient evidence that the work has been constructed, documented or explained enough for other users or developers to understand, build on, or enhance the feature. The larger the feature, the more independent review matters. I would consider one developer working for a given employer signing off on the work of another employee to be the bare minimum of acceptable process, and for small patches, that's often enough. For larger features, particularly ones that involve architectural changes, I will make a flat out assertion: sign-offs within the same employer doesn't cut it. It has to work well enough and be explained well enough that, at minimum, the QA manager and the release manager can understand it and test. One key thing is that larger features must be developed incrementally, in the open, and with as much discussion as possible. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From henridamien.laurent at gmail.com Thu May 12 20:00:10 2011 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Thu, 12 May 2011 20:00:10 +0200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFD06.8000900@biblibre.com> <4DCC0FEC.30203@alinto.com> Message-ID: <4DCC202A.5080606@gmail.com> Le 12/05/2011 19:17, Galen Charlton a ?crit : > Hi, > > On Thu, May 12, 2011 at 1:03 PM, Doug Dearden wrote: >> Reading this thread I think the core issue is this. Can a big enhancement that has been >> developed by one company be signed off by that company as well. Currently the work >> flow suggests that anything more than minor bugs should not be signed off by someone >> in the same company. However, if within the company developer A has done the work, >> developer B has tested it and signed off internally, and it is in use at a library that the >> company supports and is running without issue, then is that enough to allow it to be >> pushed to the master branch of that release? I think it is. > > I disagree. Successful use in a library is evidence that the feature > meets that particular library's needs. It is not sufficient evidence > that the implementation of the feature is good and does not interfere > with other libraries' use of Koha. It is also not sufficient evidence > that the work has been constructed, documented or explained enough for > other users or developers to understand, build on, or enhance the > feature. > > The larger the feature, the more independent review matters. I would > consider one developer working for a given employer signing off on the > work of another employee to be the bare minimum of acceptable process, > and for small patches, that's often enough. For larger features, > particularly ones that involve architectural changes, I will make a > flat out assertion: sign-offs within the same employer doesn't cut it. > It has to work well enough and be explained well enough that, at > minimum, the QA manager and the release manager can understand it and > test. > > One key thing is that larger features must be developed > incrementally, in the open, and with as much discussion as possible. Well on that regard, we have never been developped in the background. It has been announced with RFCs, it has been added with bugs. Discussion, with whom, when, where ? At least we never avoided that. For many aspects, we have tried to provoke discussion before. The fact is that we cannot always beg for comments externally and wait for ppl to realise that we are working. We also have due dates. Every one has. If ppl are not willing to discuss the moment we need to discuss, when things are done, if there is discussion, then ppl may also share the work and not just burry others with idle criticisms. And about documentation and explanation, well, it seems quite strange to say so when you look at the current status of most of the current code and all the oddities in behaviour or coding standards we have seen. I reckon we also took a part in that. And maybe you will say that our contributions are so terrible we should not even dare. But still, the remove items branch was quite a common work... even if it took much time. And I think it was valuable, although you missed one of the important point I tried to assign : display. (it was done maybe quite awkwardly for want of time, but done) And then again, documentation is nice, but also needs to be maintained and detailed. And something that may seems obvious to one person can not be for someone else... For what it is worth, most of the time, we have to dive into the code and cannot rely on the documented behaviour. -- Henri-Damien LAURENT From chris at bigballofwax.co.nz Thu May 12 21:03:37 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 13 May 2011 07:03:37 +1200 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBFFE2.4060508@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFFE2.4060508@biblibre.com> Message-ID: On 13 May 2011 03:42, Paul Poulain wrote: > Le 12/05/2011 17:26, Chris Nighswonger a ?crit : >> We are currently accepting patches into QA which are signed off by employees >> of the same company as the author of the patch. >> >> So I'm a bit confused as to why Biblibre cannot adopt a similar procedure in >> order to get their patches into QA? > I'm not only speaking of patches fixing a bug, but also of large updates > adding a feature. Chris has said he wouldn't accept such a patch/branch > self-signed. That's exactly right, but luckily for 3.6 we have another step, the QA manager. So self signed would be enough, (preferably one external one as well) to get it to the QA manager. If it then passes QA, its on to me as RM. >> Perhaps if the issue is moving patches representing larger/more complicated >> features through QA, the submitter could provide references to >> installations/clients currently running the feature(s). The QA manager could >> then contact the supplied reference to verify QA and push the patch on up >> the chain. > mmm... That would be fun to see one of our -French speaking- library > answering a mail in English ;-) > I don't think it's a possible way to go. > Well I still think its important that it is noted on the bug or on the patch, who has claimed that it works. They should get credit for testing at least Chris From cnighswonger at foundations.edu Thu May 12 21:13:17 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 12 May 2011 15:13:17 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCBFFE2.4060508@biblibre.com> References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFFE2.4060508@biblibre.com> Message-ID: On Thu, May 12, 2011 at 11:42 AM, Paul Poulain wrote: > Le 12/05/2011 17:26, Chris Nighswonger a ?crit : > > Perhaps if the issue is moving patches representing larger/more > complicated > > features through QA, the submitter could provide references to > > installations/clients currently running the feature(s). The QA manager > could > > then contact the supplied reference to verify QA and push the patch on up > > the chain. > mmm... That would be fun to see one of our -French speaking- library > answering a mail in English ;-) > I don't think it's a possible way to go. > > Language will always be a "problem" with any international project. So this really is a non-argument imho. Providing a reference for QA on large feature sets would be valuable and well worth the effort it would take to get over the translation hurtle. I'm sure that just the time consumed in pursuing this very thread would have been sufficient to have accomplished a confirmation of QA with a non-English speaking reference including time taken to obtain an accurate translation. I work in an environment every day of the year with folks from multiple countries who are non-native English speakers (some only speak a very few words of English) and this is by no means a show-stopper for our business. Difficult? Yes. Impossible? No. So I respectfully disagree: This is a very possible way to go. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Thu May 12 21:14:04 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 12 May 2011 15:14:04 -0400 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: <4DCBB34B.9010904@biblibre.com> <4DCBD584.4000006@calyx.net.au> <4DCBE011.4070908@cilea.it> <4DCBE8CA.7070600@biblibre.com> <4DCBEDE5.8080802@mdah.state.ms.us> <4DCBF51B.6000405@biblibre.com> <4DCBF7A2.8020005@biblibre.com> <4DCBFFE2.4060508@biblibre.com> Message-ID: On Thu, May 12, 2011 at 3:03 PM, Chris Cormack wrote: > On 13 May 2011 03:42, Paul Poulain wrote: > > Le 12/05/2011 17:26, Chris Nighswonger a ?crit : > >> We are currently accepting patches into QA which are signed off by > employees > >> of the same company as the author of the patch. > >> > >> So I'm a bit confused as to why Biblibre cannot adopt a similar > procedure in > >> order to get their patches into QA? > > I'm not only speaking of patches fixing a bug, but also of large updates > > adding a feature. Chris has said he wouldn't accept such a patch/branch > > self-signed. > > That's exactly right, but luckily for 3.6 we have another step, the QA > manager. > So self signed would be enough, (preferably one external one as well) > to get it to the QA manager. If it then passes QA, its on to me as > RM. > Following up on this, for work developed and internally signed off by ByWater Solutions, I'm going to mark smaller things that pass QA as such. But, for larger developments, I'm going to need someone's eyes from outside my company to check the code and give a signoff. If my judgement of what's "small" and what's "large" ever seems suspect to anyone, PLEASE call shenanigans on me, and I'll address it. -Ian -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Fri May 13 16:05:17 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 13 May 2011 11:05:17 -0300 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: On Wed, May 11, 2011 at 2:01 PM, Chris Cormack wrote: > Hi All > > Recently I have been having a crisis of confidence. I have, I hope, > always tried to do what I think is best for the project. Often I do > make mistakes, a notable one happened in 2007, which I hope I in part > was rectified in 2008. But my underlying motivation with Koha has > always been to do the best for the users of the software. > In my role as Release Manager for 3.4 (and again for 3.6) what I felt > was best for the software users was a stable and well tested release. > This is something I made clear in my proposal, and which I had assumed > was understood (but you know what they say about assumptions ;)). With > the huge amount of work put in by over 80 people, I think we managed > to achieve some measure of success with that with 3.4.0 and that the > stability of the 3.2.x releases is something we can all be proud of. > > Over the last couple of weeks, comments and mails both on and off list > have made me think that maybe I am out of step with what the community > desires. For 3.6 quality was still the major goal, but perhaps I have > misjudged what others want. ?This has resulted in sleepless nights and > quite a large amount of self doubt. First of all, Chris++ for the hard and good work he is doing every day. For a noob like me its leadership has been really inspiring and I'm comfortable with the current workflow which I think . As a 'small' (+30 libraries/koha deploys) contributor University, we've faced several times this problem Paul brought into discussion last year about BibLibre's difficulties to make community development roadmap/process fit their own's, and its' business model. Even if we are a small non-profit contributor we 'felt the same' [1]. I think it is not easy to avoid this problem: the tension between community established roadmap and the needs of a third party's business. Companies like BibLibre have made Koha the great piece of software it is now (the same goes for LibLime and other companies), so it is not just BibLibre's problem. Community and third parties roadmaps diverge easily. As Paul said, perhaps forking is the only solution for a business model if we don't find a proper solution. I'd like to see an approach that provided a proper semi-formal way to make strategic decisions on the future of the project, so that third parties can propose the community a "big feature" or a "big change", and the core developers can plan on how the integration will be done. If it fits the business model (i.e. secrecy is not a need for it), maybe even make external core devs have access to relevant information on the inside development process: develop on the open. I'd like to elaborate a bit more on the need for a strategic decision taking mechanism, but i've been busy with other project for which i'll fly to europe tomorrow. Maybe I get some more time to spend in koha in a few weeks. Thanks for all the hard work and good will put into this discussion. To+ [1] We even stopped developing some features our librarians asked for until we could understand and fit into the dev community and the process itself. WE DON'T WANT TO FORK. Several times we had the feeling we could have spent our money/time in a more feature-providing way, but where confident that we could make our voice into the dev community. Day suspension fines is a feature we proposed to develop ourselves with some core-developer guidance but only got this answer: "liblime has developed that, wait for them to merge their branch". We are currently working with a small, harmless fork we can maintain updated. From colin.campbell at ptfs-europe.com Fri May 13 17:37:01 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Fri, 13 May 2011 16:37:01 +0100 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: References: Message-ID: <4DCD501D.2010508@ptfs-europe.com> On 13/05/11 15:05, Tomas Cohen Arazi wrote: > [1] We even stopped developing some features our librarians asked for > until we could understand and fit into the dev community and the > process itself. WE DON'T WANT TO FORK. Several times we had the > feeling we could have spent our money/time in a more feature-providing > way, but where confident that we could make our voice into the dev > community. Day suspension fines is a feature we proposed to develop > ourselves with some core-developer guidance but only got this answer: > "liblime has developed that, wait for them to merge their branch". We > are currently working with a small, harmless fork we can maintain > updated. I think there is a problem with the process that rfc's stake out areas out areas of development then people wait around until the original proposer delivers putting things on hold. If it doesn't get delivered, delivered when expected or as expected then everyone loses out. Really until you show some code its all wishful thinking. ( I have a number of projects that will solve the world's ills but I've not released any code yet ). We should not be fearful of forking, the license we use could be seen as encouraging it but insisting that having forked you preserve the rights to the code you have just taken advantage of. With regular scheduled releases its easier to keep the fork in touch with the main branch which also makes it easier to fold it back in to the main line of development, because even if your fork has features that others may not want, you want all the good stuff that is in the main branch. As a community we are very good at implementing the middle range features (and don't belittle them they are what most of are users cherish in the system ). We're a bit less good at the big chunks of functionality but I'm sure thats fixable, (and Chris's successful shifting to TT for 3.4 shows big things can be done). We're also a bit behind the curve on the plumber like code maintenance tasks ( we are going to have use warnings in all scripts oneday, right?) that have less visible user impact but aid future development and avoid introducing bugs. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From fridolyn.somers at gmail.com Fri May 13 18:33:55 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 13 May 2011 18:33:55 +0200 Subject: [Koha-devel] Z3950 UNIMARC Message-ID: Hie, For the first time, I have enabled the SRU on Zebra server by editing koha-conf.xml : tcp:@:9999 > > /var/lib/zebradb/biblios > /etc/koha/zebradb/zebra-biblios.cfg > /etc/koha/zebradb/pqf.properties > > > > > > > /etc/koha/zebradb/ccl.properties > xxxx > xxxx > > I Koha administration, I added this Z3950 server. It works well but : I have installed everything in UNIMARC and SRU only works when : - I configure the server Z3950 with USMARC/MARC21. - I configure retrieval syntax="usmarc" instead of "unimarc" Does that mean that Zebra internal database is always in USMARC ? Thanks for your help. -- 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 laurenthdl at alinto.com Fri May 13 18:47:06 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Fri, 13 May 2011 18:47:06 +0200 Subject: [Koha-devel] Z3950 UNIMARC In-Reply-To: References: Message-ID: <4DCD608A.3070306@alinto.com> Le 13/05/2011 18:33, Fridolyn SOMERS a ?crit : > Hie, > > For the first time, I have enabled the SRU on Zebra server by editing > koha-conf.xml : > > tcp:@:9999 > > /var/lib/zebradb/biblios > /etc/koha/zebradb/zebra-biblios.cfg > /etc/koha/zebradb/pqf.properties > > > > > > > /etc/koha/zebradb/ccl.properties > xxxx > xxxx > > > > I Koha administration, I added this Z3950 server. > > It works well but : > I have installed everything in UNIMARC and SRU only works when : > - I configure the server Z3950 with USMARC/MARC21. > - I configure retrieval syntax="usmarc" instead of "unimarc" > > Does that mean that Zebra internal database is always in USMARC ? > > Thanks for your help. Well, it means that internally, zebra thinks that data is always usmarc and exposes data as such. Consider that as a bug or not, that could be changed but would require some deep changes both in Koha Code and zebra configuration. And require reindexation. I think that some users in France had it right on their configuration... But I could mislead myself. Hope that helps. -- Henri-Damien LAURENT From frederic at tamil.fr Fri May 13 19:30:30 2011 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Fri, 13 May 2011 19:30:30 +0200 Subject: [Koha-devel] Z3950 UNIMARC In-Reply-To: References: Message-ID: <4DCD6AB6.4040803@tamil.fr> Old story: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3087 http://www.mail-archive.com/koha-patches at lists.koha.org/msg01881.html -- Fr?d?ric DEMIANS http://www.tamil.fr/u/fdemians.html From tomascohen at gmail.com Fri May 13 19:05:19 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 13 May 2011 14:05:19 -0300 Subject: [Koha-devel] Release Manager 3.6 In-Reply-To: <4DCD501D.2010508@ptfs-europe.com> References: <4DCD501D.2010508@ptfs-europe.com> Message-ID: On Fri, May 13, 2011 at 12:37 PM, Colin Campbell wrote: > On 13/05/11 15:05, Tomas Cohen Arazi wrote: > >> [1] We even stopped developing some features our librarians asked for >> until we could understand and fit into the dev community and the >> process itself. WE DON'T WANT TO FORK. Several times we had the >> feeling we could have spent our money/time in a more feature-providing >> way, but where confident that we could make our voice into the dev >> community. Day suspension fines is a feature we proposed to develop >> ourselves with some core-developer guidance but only got this answer: >> "liblime has developed that, wait for them to merge their branch". We >> are currently working with a small, harmless fork we can maintain >> updated. FTR: I'm in no way blaming LibLime in the example I provided. It should be read as self-criticism, probably because we feared having to fork (we cannot afford to do it, i'm the only dev maintaining all this stuff here) and wanted to do it "the right way" (from our perspective as a public university this means that if we invested some hours of human labour they should be applied to make koha better for everyone, specially spanish-speaking/latin-american users that, as Paul said, have interests in features NZ and US libraries don't even think about in their daily workflow ("who is interested in signing BZ6328 i just submitted ?": me)). I agree with the concepts you provided. Regards To+ (with a parenthesis nightmare) From marshall.breeding at Vanderbilt.Edu Sun May 15 17:01:34 2011 From: marshall.breeding at Vanderbilt.Edu (Breeding, Marshall) Date: Sun, 15 May 2011 10:01:34 -0500 Subject: [Koha-devel] [Koha] Need a user friendly Koha users list In-Reply-To: References: Message-ID: Vimal?s message prompts me to suggest that libraries using Koha review their information in lib-web-cats. While there may be reasons to keep a separate listing on the community?s wiki, there are also advantages to also registering libraries using Koha in lib-web-cats. The lib-web-cats international directory of libraries aims to include all of the libraries that use Koha, as well as other library automation systems. It currently lists 1,285 Koha libraries: http://www.librarytechnology.org/libraries.pl?ILS=Koha http://www.librarytechnology.org/map.pl?ILS=Koha Inclusion on the Koha wiki provides a few more details on Koha version numbers and such (which are quickly outdated) and is a good resource for the Koha community. lib-web-cats has a broad audience and provides exposure regarding the impact of Koha worldwide. It is a component of Library Technology Guides (www.librarytechnology.org) which provides many resources on library automation products and organizations, including both open source and propriety options. I do hope that any libraries involved with Koha that are not already included in lib-web-cats use this form to submit your information: http://www.librarytechnology.org/lwc-submit-library.pl (Please search to be sure it?s not already listed to avoid duplicate entries) You can also just drop me an e-mail with the information. -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding From: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Vimal Kumar Sent: Friday, May 13, 2011 12:22 PM To: Koha-List Subject: [Koha] Need a user friendly Koha users list Dear Friends, It seems that users list of Koha is in complete. The reason is that Koha users feel difficult editing wiki pages. http://wiki.koha-community.org/wiki/Koha_Users_Worldwide We need a user friendly interface to enter the details of libraries using Koha. We can follow the model of Libwebcat of Marshal Breeding for new Koha users list, http://www.librarytechnology.org/libwebcats/ This information helpful for libraries they are like to implement Koha soon. Using the information, they can find Koha installed libraries in their own area and can evaluate its performance. Regards, -- Vimal Kumar V. Mahatma Gandhi University Library Kottayam, Kerala- 686 560 Web: http://www.vimalkumar.co.nr Blog: http://vimalkumar.oksociety.in http://linuxhalwa.blogspot.com --------------------------------------------------------------------------- "I forget what I was taught. I only remember what I have learnt" -Patrick White -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Sun May 15 20:57:19 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 15 May 2011 14:57:19 -0400 Subject: [Koha-devel] Koha 3.2.8 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.2.8. The package can be retrieved from: http://download.koha-community.org/koha-3.02.08.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.08.tar.gz.MD5 http://download.koha-community.org/koha-3.02.08.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.08.tar.gz.sig Release notes for 3.2.8 are below. Come and get it! RELEASE NOTES FOR KOHA 3.2.8 - 15 May 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.2.8 can be downloaded from: http://download.koha-community.org/koha-3.02.08.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation Koha 3.2.8 is a bugfix/maintenance release. IMPORTANT ANNOUNCEMENT CONCERNING 3.2.x EOL ======================================================================== With the release of 3.4.0, the 3.2.x branch is nearing its EOL. After 3.2.10 or 04/15/2011, a motion will be made at the August 2011 general IRC meeting to officially announce EOL for the 3.2.x branch. Please keep this in mind when planning new deployments and upgrades to existing systems. Highlights of 3.2.8 ====================== Some of the higher profile bugs addressed in this release are: 3072 critical 'Heading-Main' authority-index breaks authority searching in STABLE 5860 critical Adding duplicate stocknumber will fail silently 6104 critical Modifying an item causes it to lose its branch 2505 major enable Perl warnings in all modules and scripts 4903 major OAI doesn't work out of the box - XSL path 5942 major UNIMARC Authorities SQL data 6001 major batchRebuildBiblioTables.pl crashes when GetMarcBiblio fails. 6014 major Log viewer needs permissions 6056 major Notes on order line not shown when modifying 6106 major add item not respecting framework in acq 6164 major messaging tab on staff client loses name 6282 major HomeOrHoldingBranchReturn syspref missing from .pref file Bugs fixed in 3.2.8 ====================== 3523 Menu of existing lists limited to 10 3543 Spine labels - NLM call numbers not splitting 4196 Defintion of popularity index into Unimarc setup 4374 Data entry form doesn't use hidden/mandatory flag as expected 4837 Circulation Print Page uses incorrect heading / incorrect information 5156 JavaScript error when adding list 5234 Remove unused CSS files 5275 no way to change framework by editing 5509 Packaging scripts get upset when there's an LDAP configuration in the koha_conf.xml 5529 Staff client shows "Your lists:" and "public lists:" when there are none 5708 Incorrect Discount applied to rental charge at checkout 5903 French authorised values fixed - country codes must be in capital letters 5941 Change the link in the authority search results, to a phrase search 5948 Missing quantity column in receipt screen 5964 aqbudgets.tmpl contains untranslatable fields 6017 Editing an extended attribute can cause a 500 error 6028 Fixing the 9999 rows limiation on export to csv 6031 koha-rebuild-zebra doesn't allow XML and verbose indexing 6032 Give biblios register and shadow sane default max sizes 6037 Invalid markup, missing breadcrumbs on Keyword to MARC Mapping page 6077 qty not incremented for AcqCreateItem=recieve 6096 GetAllShelves has obfuscated return type 6099 pagination error on GROUP BY guided reports 6100 request.pl should check maxreserves exists before using it 6118 Title-host missing in Search.pm 6126 Slip print doesn't work on Webkit based browsers 6154 Default sorting by title doesn't work 6169 Inventory tool fails when ignoreissued set 6170 'More options' in advanced search broken 6211 SubscriptionHistory doesn't have default value set 3628 Add opacSerialDefaultTab preference to display shortened serial collection instead of holdings by default 4049 Search on itemtypes returning noise 4189 Searching z39.50 without selecting any servers results in error message 4393 Searching with scan indexes and sort by title fails 4912 After editing private list, user should be redirect to private lists 5213 Suffix number sequence not resetting properly in hmyymmincr barcode autogen pattern 5915 UNIMARC Authorities : 100$a simple error: Sometimes, language is encoded fre50 and not frey50. 5923 Authorities list :removing link on Summary 5947 Adding a date filter to the suggestions search 5949 Popup alert when deleting orders from a basket 5950 changing frameworks doesn't change anymore 5951 Acquisitions: changing planning value to statistics value 5971 Minor markup error in holds queue report 5972 DisplayClearScreenButton preference introduces invalid markup 5990 Lists and Cart show LOC code, not Location Authorized value 6005 Transit slips cause Firefox 4 to display "prevent this page from opening additional dialogs" 6062 Basketgroup ordering 6072 Acquisition permissions inconsistencies 6088 remove a perl warning 6108 Quicksearch in member.pl does not display paging correctly 6109 Hey! 5895 Correct translation error in German frameworks 5982 OPAC : Serials changing some wording on opac-detail.tmpl 6095 Wrong display of acute charaters in html letters 3644 Support for NORMARC 4506 Add support of record linking by record control number in $w 5917 Switch Koha to use Template::Toolkit 6024 Run a Report immediately after creating or editing Translations new/updated in 3.2.8 ====================== ar-Arab hi it-IT ja-Jpan pl-PL pt-BR pt-PT tet zh-Hans-TW ====================== Changes since 3.0: The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.x. 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, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ 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://www.kohadocs.org/usersguide/apb.html 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.2 is Release Manager: Galen Charlton Documentation Manager: Nicole Engard Translation Manager: Chris Cormack Release Maintainer (3.0.x): Henri-Damien Laurent Release Maintainer (3.2.x): Chris Nighswonger Credits ====================== We thank the following individuals who contributed patches to Koha 3.2.8: Alex Arnaud Jared Camins-Esakov Colin Campbell Fr??d??rick Capovilla Galen Charlton Tomas Cohen Chris Cormack Christophe Croullebois Marcel de Rooy St??phane Delaune Fr??d??ric Demians Ricardo Dias Jonathan Druart Frederic Durand Nicole Engard Magnus Enger Katrin Fischer Srdjan Jankovic Koustubha Kalekoha-preprod at sys-tech.net Henri-Damien Laurent Owen Leonard Matthias Meusburger Sophie Meynieux Chris Nighswonger Paul Poulainroot at lists.nekls.org Robin Sheat Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes tokoha-patches at lists.koha-community.org. The 3.2.x Release Maintainer especially thanks the 3.6 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 680 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.8 on its announced schedule. 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.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Sun May 15 21:12:15 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 15 May 2011 15:12:15 -0400 Subject: [Koha-devel] Fwd: 3.4.x String Freeze Message-ID: Hi All, We are going to keep with May 22, 2011 for the 3.4.1 release which puts 3.4.x into a string freeze as of today. Translators: Please get any work you want included in 3.4.1 in by May 20, 2011. Kind Regards, Chris Nighswonger 3.2.x/3.4.x Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Mon May 16 04:41:31 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 15 May 2011 22:41:31 -0400 Subject: [Koha-devel] Koha 3.2.9 is now available Message-ID: Due to a security issue, it is necessary to announce the quick release of 3.2.9. The package can be retrieved from: http://download.koha-community.org/koha-3.02.09.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.09.tar.gz.MD5 http://download.koha-community.org/koha-3.02.09.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.09.tar.gz.sig Release notes for 3.2.9 are below. Come and get it, quick! RELEASE NOTES FOR KOHA 3.2.9 - 16 May 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.2.9 can be downloaded from: http://download.koha-community.org/koha-3.02.09.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation IMPORTANT ANNOUNCEMENT CONCERNING 3.2.x EOL ======================================================================== With the release of 3.4.0, the 3.2.x branch is nearing its EOL. After 3.2.10 or 04/15/2011, a motion will be made at the August 2011 general IRC meeting to officially announce EOL for the 3.2.x branch. Please keep this in mind when planning new deployments and upgrades to existing systems. Highlights of 3.2.9 ====================== NOTE: This release is a security release. It is strongly recommended that users apply this upgrade immediately to production systems. If you are installing a new system, please use this version rather than earlier versions. System Requirements ====================== Changes since 3.0: * The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.x. 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, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ 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://www.kohadocs.org/usersguide/apb.html 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.2 is Release Manager: Galen Charlton Documentation Manager: Nicole Engard Translation Manager: Chris Cormack Release Maintainer (3.0.x): Henri-Damien Laurent Release Maintainer (3.2.x): Chris Nighswonger Credits ====================== We thank the following individuals who contributed patches to Koha 3.2.9: Alex Arnaud Jared Camins-Esakov Colin Campbell Fr??d??rick Capovilla Galen Charlton Tomas Cohen Chris Cormack Christophe Croullebois Marcel de Rooy St??phane Delaune Fr??d??ric Demians Ricardo Dias Jonathan Druart Frederic Durand Nicole Engard Magnus Enger Katrin Fischer Srdjan Jankovic Koustubha Kalekoha-preprod at sys-tech.net Henri-Damien Laurent Owen Leonard Matthias Meusburger Sophie Meynieux Chris Nighswonger Paul Poulainroot at lists.nekls.org Robin Sheat Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes tokoha-patches at lists.koha-community.org. The 3.2.x Release Maintainer especially thanks the 3.6 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 680 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.9 on its announced schedule. 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.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Tue May 17 05:28:23 2011 From: nengard at gmail.com (Nicole Engard) Date: Mon, 16 May 2011 20:28:23 -0700 Subject: [Koha-devel] Call for Newsletter Articles Message-ID: The newsletter is published on the 25th of each month, that means I need some content ;) I have no articles as of yet for this newsletter. Please send me your stories (big and small) so I can share the Koha news with everyone. Articles due by the 23rd (your local time). Thanks Nicole From paul.poulain at biblibre.com Tue May 17 14:19:07 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 17 May 2011 14:19:07 +0200 Subject: [Koha-devel] bugzilla old entries Message-ID: <4DD267BB.8060007@biblibre.com> Hello, I've checked what is very old on bugzilla. There are 1603 bugs open as of today. I've added a custom search "very old" displaying bugs that haven't been updated for more than 1 year. That's 295. I feel we will never be able to take care of all those bugs, and many if not most of them are related to problems on now-unmaintained versions of Koha. So i'd like to close all of them and mark them "wontfix". Does anyone think it's a bad idea ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From oleonard at myacpl.org Tue May 17 15:11:23 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 17 May 2011 09:11:23 -0400 Subject: [Koha-devel] bugzilla old entries In-Reply-To: <4DD267BB.8060007@biblibre.com> References: <4DD267BB.8060007@biblibre.com> Message-ID: > I've added a custom search "very old" displaying bugs that haven't been > updated for more than 1 year. That's 295. I don't see your saved search. Did you share it? > I feel we will never be able to take care of all those bugs, and many if > not most of them are related to problems on now-unmaintained versions of > Koha. I don't think we should mark bugs "wontfix" just because they're old. I think many of the bugs might still be valid, whether or not they have the correct version assignment. > So i'd like to close all of them and mark them "wontfix". Does anyone > think it's a bad idea ? I think it is not a good idea. Better to have a bug open and showing up in searches in case someone is looking to file a new one for the same issue. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Tue May 17 15:22:06 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 17 May 2011 15:22:06 +0200 Subject: [Koha-devel] Hacker's corner, week 20 Message-ID: <4DD2767E.5070702@biblibre.com> Hello, Last week has been very busy and active. I don't speak of this mailing list activity, everybody reading this mail is on the list so already know. But the activity also has been huge on bugzilla. 294 mails have been sent by bugzilla this week, Here are the numbers. Patches to sign-off =========== The number of patches to sign-off has been greatly lowered. There are now 91 patches waiting for some sign-off. This week, i'll highlight the 10 oldest bugs : 2246 cri cnighswonger at foundations.edu Label printing doesn't work with Unicode characters 3638 nor colin.campbell at ptfs-europe.com Status of hold not changed when item checked in via SIP2 Interface 3652 cri oleonard at myacpl.org XSS vulnerabilities 3674 nor conan at lugmen.org.ar Creating users with empty password 3731 nor guillaume.hatt at enc.sorbonne.fr overdues csv & windows 3924 min guillaume.hatt at enc.sorbonne.fr useDaysMode problems in french and improve needs 4247 enh jwagner at ptfs.com Import profiles to create items upon MARC import 4268 nor oleonard at myacpl.org Incorrect check of OPACItemsResultsDisplay preference 4513 nor m.de.rooy at rijksmuseum.nl Resetting framework to Default seems impossible 4518 enh nahuel.angelinetti at biblibre... Enhance 2.2 to 3.0 scripts Let's sign-off !!! Patches signed-off =========== 43 patches have been signed off. One of them (5995) is related to a security issue, and has caused 3.2.9 to be released quickly after 3.2.8 Nicole, sorry, you loose your "sign-off-er of the week" badge this week, it's chris that won. Frederic Demian is probably the 2nd. Patches pushed ========= 14 patches have been pushed while 56 patches are waiting for QA to be pushed Happy hacking ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue May 17 15:31:53 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 17 May 2011 15:31:53 +0200 Subject: [Koha-devel] [Koha] Need a user friendly Koha users list In-Reply-To: References: Message-ID: <4DD278C9.50501@biblibre.com> Le 15/05/2011 17:01, Breeding, Marshall a ?crit : > I do hope that any libraries involved with Koha that are not already included in lib-web-cats use this form to submit your information: > http://www.librarytechnology.org/lwc-submit-library.pl > (Please search to be sure it?s not already listed to avoid duplicate entries) > > You can also just drop me an e-mail with the information. Hi Marschall, I think i already told you, but in case... : could it be possible to have the form/libwebcat translated ? (We could do the translation job, it's just a 'is it technically possible') As long as it's in english, you can ignore results from french libraries (except our customer, we fill the register for them), none of them file an english form. (Just FYI: we've asked all our customer to fill the yearly survey, addind a french translation of the form to our mail. Only 3 did it ! ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From oleonard at myacpl.org Tue May 17 15:35:53 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 17 May 2011 09:35:53 -0400 Subject: [Koha-devel] Hacker's corner, week 20 In-Reply-To: <4DD2767E.5070702@biblibre.com> References: <4DD2767E.5070702@biblibre.com> Message-ID: A few comments: > 3652 > cri ? ? oleonard at myacpl.org ? ? XSS vulnerabilities Lots of hard work in that patch, but the transition to Template::Toolkit makes it obsolete. We'll need to re-evaluate what the right solution is now. > 4247 > enh ? ? jwagner at ptfs.com ? ? ? ?Import profiles to create items upon MARC import Sounds interesting, but won't apply since the Harley repo has never been updated. > 4268 > nor ? ? oleonard at myacpl.org ? ? Incorrect check of OPACItemsResultsDisplay A couple of different solutions have been proposed for this one. It would be great to get more eyes on it. > 4518 > enh ? ? nahuel.angelinetti at biblibre... ?Enhance 2.2 to 3.0 scripts We always urge people to upgrade when we hear they're on 2.x. This is a pretty old patch, but it sounds like it's worth looking at! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From Katrin.Fischer at bsz-bw.de Tue May 17 15:37:56 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Tue, 17 May 2011 15:37:56 +0200 Subject: [Koha-devel] bugzilla old entries References: <4DD267BB.8060007@biblibre.com> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD98EF29@Bodensee.bsz-bw.de> Hi Paul, I agree with Owen that we should not mark those old bugs WONTFIX Additionally I think we have do differentiate between bugs and enhancements: For bugs I think the proper way doing it is retesting the bug and updating it. Enhancements need to be revisited. If Koha can still not do what was suggested the bug should be left open. If it's a really bad idea, mark WONTFIX. Getting them off our lists will not solve the problem and if the bug is filed again the original bug reporter won't get any updates about the status. Katrin -----Urspr?ngliche Nachricht----- Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Owen Leonard Gesendet: Di 17.05.2011 15:11 An: Paul Poulain Cc: Koha Devel Betreff: Re: [Koha-devel] bugzilla old entries > I've added a custom search "very old" displaying bugs that haven't been > updated for more than 1 year. That's 295. I don't see your saved search. Did you share it? > I feel we will never be able to take care of all those bugs, and many if > not most of them are related to problems on now-unmaintained versions of > Koha. I don't think we should mark bugs "wontfix" just because they're old. I think many of the bugs might still be valid, whether or not they have the correct version assignment. > So i'd like to close all of them and mark them "wontfix". Does anyone > think it's a bad idea ? I think it is not a good idea. Better to have a bug open and showing up in searches in case someone is looking to file a new one for the same issue. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.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 mjr at phonecoop.coop Wed May 18 01:38:39 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 18 May 2011 00:38:39 +0100 (BST) Subject: [Koha-devel] bugzilla old entries In-Reply-To: <4DD267BB.8060007@biblibre.com> Message-ID: <20110517233839.4CB469EC0B@nail.towers.org.uk> Paul Poulain > I feel we will never be able to take care of all those bugs, and many if > not most of them are related to problems on now-unmaintained versions of > Koha. > So i'd like to close all of them and mark them "wontfix". Does anyone > think it's a bad idea ? I think it's a good idea to reduce the number of bugs. I don't think bulk closing just because they've not been updated in a while is a good move. It's artificial. Here's what I plan to do, so please beat me to it if you want: "so that we can concentrate on 3.6, I'd systematically check and RESOLVE WONTFIX the ~140 bugs reported not against maintained versions and I'd suggest reclassifying the 771 bugs reported against master as reported against the version which immediately follows the date they were reported." Remember, RESOLVED WONTFIX does not mean it isn't a bug: it just means we don't have anyone who will fix it. Someone can always REOPEN it and ASSIGN it to themselves. Hope that helps, -- 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 paul.poulain at biblibre.com Wed May 18 18:10:35 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 18 May 2011 18:10:35 +0200 Subject: [Koha-devel] bugzilla old entries In-Reply-To: <4DD267BB.8060007@biblibre.com> References: <4DD267BB.8060007@biblibre.com> Message-ID: <4DD3EF7B.9090304@biblibre.com> Le 17/05/2011 14:19, Paul Poulain a ?crit : > Hello, > > I've checked what is very old on bugzilla. > > There are 1603 bugs open as of today. > I've added a custom search "very old" displaying bugs that haven't been > updated for more than 1 year. That's 295. > > I feel we will never be able to take care of all those bugs, and many if > not most of them are related to problems on now-unmaintained versions of > Koha. > So i'd like to close all of them and mark them "wontfix". Does anyone > think it's a bad idea ? OK, after a few days thinking of it, I agree it's not a good idea. OTH, I like very much what slef propose. So +1 Should we add this topic to next IRC meeting ? Or we just say "anyone against this idea write here otherwise 'let's do it' " ? -- 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 Thu May 19 08:52:53 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 19 May 2011 06:52:53 +0000 Subject: [Koha-devel] bugzilla old entries In-Reply-To: <4DD3EF7B.9090304@biblibre.com> References: <4DD267BB.8060007@biblibre.com> <4DD3EF7B.9090304@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312CC944@S-MAIL-1B.rijksmuseum.intra> Does that mean that we "close" bugs not related to 3.2.x, 3.4.x and master? Since there is no development anymore on other versions, I would agree. If someone detects that the bug still is alive, (s)he could reopen and file it against the corresponding active release. -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain Verzonden: woensdag 18 mei 2011 18:11 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] bugzilla old entries Le 17/05/2011 14:19, Paul Poulain a ?crit : > Hello, > > I've checked what is very old on bugzilla. > > There are 1603 bugs open as of today. > I've added a custom search "very old" displaying bugs that haven't been > updated for more than 1 year. That's 295. > > I feel we will never be able to take care of all those bugs, and many if > not most of them are related to problems on now-unmaintained versions of > Koha. > So i'd like to close all of them and mark them "wontfix". Does anyone > think it's a bad idea ? OK, after a few days thinking of it, I agree it's not a good idea. OTH, I like very much what slef propose. So +1 Should we add this topic to next IRC meeting ? Or we just say "anyone against this idea write here otherwise 'let's do it' " ? -- 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 robin at catalyst.net.nz Thu May 19 11:12:30 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 19 May 2011 21:12:30 +1200 Subject: [Koha-devel] [PATCH] Bug 6361 - make the packages work with koha 3.4 In-Reply-To: <1305795579-16460-1-git-send-email-robin@catalyst.net.nz> References: <1305795579-16460-1-git-send-email-robin@catalyst.net.nz> Message-ID: <1305796351.2589.11.camel@zarathud> Robin Sheat schreef op do 19-05-2011 om 20:59 [+1200]: > This commit does the following: > * Merge the changelog from the releases of 3.2 > * Adds a command 'koha-upgrade-to-3.4' that does the MARC item splitting > stuff. > * Adds a debconf note to make sure people know that they need to run > the above command. > * Fixes the inclusion of jQuery in the packages. > * Makes build-git-snapshot build packages with a 3.5 version. This patch is to bring the packaging in line with what it needs to be able to do for 3.4. I'm in the process of making a build that will go in the squeeze-dev repository, and would appreciate it if people could test it out for me and let me know if they spot any issues. Even better if you sign off on the patch :) I'd love to get this in before 3.4.1 so that it can be properly packaged. -- 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 ian.walls at bywatersolutions.com Thu May 19 15:21:28 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 19 May 2011 09:21:28 -0400 Subject: [Koha-devel] bugzilla old entries In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312CC944@S-MAIL-1B.rijksmuseum.intra> References: <4DD267BB.8060007@biblibre.com> <4DD3EF7B.9090304@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA312CC944@S-MAIL-1B.rijksmuseum.intra> Message-ID: I'm all for closing bugs that no longer apply, either because they've been patched, or the code has evolved beyond them. Closing bug reports just because they're old or not recently updated doesn't seem right to me. Bug 2389, for example, seems like it's still relevant, even though no work has been done on it in a while. Are we just trying to get the number of 'open' reports down? Or to make some of the other canned searches return more relevant results? I think we should certainly go through the 'very old' list, and mark those that are invalid as invalid, and those that are resolved as resolved. Genuine, still-current problems should have their version updated at the very least (a more detailed entry, patch or test plan would always be welcome). -Ian On Thu, May 19, 2011 at 2:52 AM, Marcel de Rooy wrote: > Does that mean that we "close" bugs not related to 3.2.x, 3.4.x and master? > Since there is no development anymore on other versions, I would agree. > If someone detects that the bug still is alive, (s)he could reopen and file > it against the corresponding active release. > > -----Oorspronkelijk bericht----- > Van: koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain > Verzonden: woensdag 18 mei 2011 18:11 > Aan: koha-devel at lists.koha-community.org > Onderwerp: Re: [Koha-devel] bugzilla old entries > > Le 17/05/2011 14:19, Paul Poulain a ?crit : > > Hello, > > > > I've checked what is very old on bugzilla. > > > > There are 1603 bugs open as of today. > > I've added a custom search "very old" displaying bugs that haven't been > > updated for more than 1 year. That's 295. > > > > I feel we will never be able to take care of all those bugs, and many if > > not most of them are related to problems on now-unmaintained versions of > > Koha. > > So i'd like to close all of them and mark them "wontfix". Does anyone > > think it's a bad idea ? > OK, after a few days thinking of it, I agree it's not a good idea. > OTH, I like very much what slef propose. So +1 > Should we add this topic to next IRC meeting ? Or we just say "anyone > against this idea write here otherwise 'let's do it' " ? > > -- > 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 ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Thu May 19 16:48:36 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 19 May 2011 10:48:36 -0400 Subject: [Koha-devel] bugzilla old entries In-Reply-To: References: <4DD267BB.8060007@biblibre.com> Message-ID: On Tue, May 17, 2011 at 9:11 AM, Owen Leonard wrote: >> I've added a custom search "very old" displaying bugs that haven't been >> updated for more than 1 year. That's 295. I still don't know how you got 295. I've been working from list with the following criteria: * Severity: blocker, critical, major, normal, minor, trivial * Status: NEW, ASSIGNED, REOPENED * Days since bug changed: (is greater than) 365 At the beginning of the week there were 150. Now there are 109. * Some bugs now have patches * Some bugs have been confirmed as still valid bugs in master. * Some bugs have been marked as fixed * Some bugs have been marked invalid That's from one pass through the list, looking for the easy stuff. It should be easy to get through the rest with some more eyes. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From mjr at phonecoop.coop Thu May 19 19:11:22 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 19 May 2011 18:11:22 +0100 (BST) Subject: [Koha-devel] bugzilla old entries In-Reply-To: Message-ID: <20110519171122.65CF99EC0B@nail.towers.org.uk> Ian Walls wrote: > Closing bug reports just because they're old or not recently updated doesn't > seem right to me. Bug 2389, for example, seems like it's still relevant, > even though no work has been done on it in a while. > > Are we just trying to get the number of 'open' reports down? Or to make > some of the other canned searches return more relevant results? How about trying to get the bugs accurate? As far as we know from IRC meetings and list discussions so far, no-one is willing to work on new releases of 3.0 or earlier any more, so those bugs should be marked WONTFIX unless anyone knows better. Having them listed as new, assigned or similar is just misleading for everyone. They are definitely drifting to WONTFIX. No-one is suggesting marking them CLOSED yet. They can be REOPENED if anyone is going to work on them. I don't understand why you wouldn't want most of them marked WONTFIX, even as a temporary measure. As for that example bug 2389, I've noted it's still present and set it to enhancement, which is what it looks like to me. Now it probably won't be reclassified incorrectly by someone skimming. Do that sort of thing or JFFI if you spot them, please. Hope that explains, -- 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 paul.poulain at biblibre.com Mon May 23 14:17:04 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 23 May 2011 14:17:04 +0200 Subject: [Koha-devel] patches with DB change, workflow Message-ID: <4DDA5040.20800@biblibre.com> Hi all, I think there are some things unclear (at least for me ;-) ) about submitting bugs with DB changes. We said various things, I don't know which one is the correct one. * http://wiki.koha-community.org/wiki/Tutorial_for_Updating_Database_Files is the wiki page about this * we spoke of using XXXX in updatedatabase.pl to have te RM pick the right number when needed. * We also spoke of using atomicupdate, and let the RM append to updatedatabase when applying to master. What I see is that updatedatabase.pl changes a lot, making patches including them "does not apply" quite quickly. I'm wondering if it would not be easier to have "atomicupdate" and kohastructure.sql, the RM moving from atomicupdate to updatedatabase when applying. I think it would be easier to sign-off -just run atomicupdate attached to the bug- too. I already have encountered the problem twice today (I work on bugzilla). Your opinion ? -- 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 Mon May 23 14:45:15 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 23 May 2011 12:45:15 +0000 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: <4DDA5040.20800@biblibre.com> References: <4DDA5040.20800@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312CD607@S-MAIL-1B.rijksmuseum.intra> I favor the atomicupdate approach. (Makes testing the db change easier too.) In that case we could do something similar for updating the pref files in 5 to 10 language folders. These files have the same "not apply"-problem. With a few lines of code the RM could move new INSERT statements for prefs from atomicupdate to the pref folders too. Only a convention for naming the db and pref updates would be welcome. Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain Verzonden: maandag 23 mei 2011 14:17 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] patches with DB change, workflow Hi all, I think there are some things unclear (at least for me ;-) ) about submitting bugs with DB changes. We said various things, I don't know which one is the correct one. * http://wiki.koha-community.org/wiki/Tutorial_for_Updating_Database_Files is the wiki page about this * we spoke of using XXXX in updatedatabase.pl to have te RM pick the right number when needed. * We also spoke of using atomicupdate, and let the RM append to updatedatabase when applying to master. What I see is that updatedatabase.pl changes a lot, making patches including them "does not apply" quite quickly. I'm wondering if it would not be easier to have "atomicupdate" and kohastructure.sql, the RM moving from atomicupdate to updatedatabase when applying. I think it would be easier to sign-off -just run atomicupdate attached to the bug- too. I already have encountered the problem twice today (I work on bugzilla). Your opinion ? -- 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 cnighswonger at foundations.edu Mon May 23 14:48:31 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 23 May 2011 08:48:31 -0400 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: <4DDA5040.20800@biblibre.com> References: <4DDA5040.20800@biblibre.com> Message-ID: Hi Paul, On Mon, May 23, 2011 at 8:17 AM, Paul Poulain wrote: > Hi all, > > I think there are some things unclear (at least for me ;-) ) about > submitting bugs with DB changes. > > > * we spoke of using XXXX in updatedatabase.pl to have te RM pick the > right number when needed. > Speaking from the prospective of Release Maintainer, this method works the most consistent for me. I have very few times when a DB update patch using the 3.NN.XXX format does not apply cleanly for me. This includes cases where NN == some subversion other than the current maintenance version. So with this, my workflow goes like this: 1. Apply patch/cherry pick. 2. Adjust rev number. 3. Commit rev number change. 4. Go on to the next patch. On the rare occasion the original patch does not apply cleanly it takes all of about one minute to fixup. So my vote is to use this method unless there is a very compelling reason to do otherwise. Kind Regards, Chris Koha 3.2.x/3.4.x Release Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Tue May 24 05:41:03 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 23 May 2011 23:41:03 -0400 Subject: [Koha-devel] Koha 3.4.1 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.4.1. The package can be retrieved from: http://download.koha-community.org/koha-3.04.01.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.01.tar.gz.MD5 http://download.koha-community.org/koha-3.04.01.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.01.tar.gz.sig Come and get it! RELEASE NOTES FOR KOHA 3.4.1 - 22 May 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.1 can be downloaded from: http://download.koha-community.org/koha-3.04.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.4.1 is a bugfix/maintenance release. Highlights of 3.4.1 ====================== 5995 Glitch with checkauth 6001 batchRebuildBiblioTables.pl crashes when GetMarcBiblio fails. 6257 MARC documentation links cause javascript error 6263 shelf browser doesn't work in 3.4 6265 Search for records linked to an authority not exact in OPAC 6282 HomeOrHoldingBranchReturn syspref missing from .pref file Bugs fixed in 3.4.1 ====================== 2941 Transfers cannot be canceled once initiated. 3543 Spine labels - NLM call numbers not splitting 5445 Acq: No way back to order from z39.50 result page 6153 Imprint subfields displayed out of order on OPAC 6194 Empty Parens on Serials pages 6295 misaligned columns in opac suggestions list 6320 Generate Next button doesn't generate next issue 3202 Creating new "child" category patrons - library not defaulting to the correct branch 6152 Authority-zebra-indexdefs.xsl should indicate it's automatically generated 6218 patron login gets an initial dot added when no first name 6228 Show active currency in system preferences 6330 holds saying on hold 'until' instead of 'since' 6315 depreciation warnings in C4::Serials in new perls 6312 login/password shouldn't be labeled as 'opac' 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.1. Jared Camins-Esakov Colin Campbell Fernando Canizo Galen Charlton Chris Cormack Fr??d??ric Demians Nicole C. Engard Magnus Enger Katrin Fischer Owen Leonard Matthias Meusburger Chris Nighswonger 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 From paul.poulain at biblibre.com Tue May 24 15:12:07 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 24 May 2011 15:12:07 +0200 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: References: <4DDA5040.20800@biblibre.com> Message-ID: <4DDBAEA7.6040006@biblibre.com> Le 23/05/2011 14:48, Chris Nighswonger a ?crit : > So my vote is to use this method unless there is a very compelling > reason to do otherwise. What's happening with http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6328 (see comment 20) is interesting. I think the idea of atomic updates is very interesting. And the workflow/wiki must be updated anyway ! So I vote for atomic updates + updating the wiki to explain very clearly how to test a patch with a DB rev. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From trmurakami at gmail.com Tue May 24 15:29:28 2011 From: trmurakami at gmail.com (Tiago Murakami) Date: Tue, 24 May 2011 10:29:28 -0300 Subject: [Koha-devel] New Batch error Message-ID: Hi, I need a help. I installed a 3.4.0 and upgraded to 3.4.1 today. This is a bug or an error of settings? When I click "New batch", my branch is unselected and when I choose an item to add, I received this mensage: * WARNING:* An error was encountered and items(s) not added, the error was: Branch is not set, you please set your branch before adding items to a batch Please have your system administrator check the error log for details. I tried to set a library again, but not work. Any help? Thanks a lot. -- Tiago Murakami -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue May 24 15:34:48 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 24 May 2011 09:34:48 -0400 Subject: [Koha-devel] New Batch error In-Reply-To: References: Message-ID: > Branch is not set, you please set your branch before adding items to a batch > > I tried to set a library again, but not work. Any help? Are you logged in as a regular user or are you logged in as the mysql user? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From trmurakami at gmail.com Tue May 24 15:50:09 2011 From: trmurakami at gmail.com (Tiago Murakami) Date: Tue, 24 May 2011 10:50:09 -0300 Subject: [Koha-devel] New Batch error In-Reply-To: References: Message-ID: I try with a mysql user and an other account superlibrarian. Tiago On Tue, May 24, 2011 at 10:34 AM, Owen Leonard wrote: > > Branch is not set, you please set your branch before adding items to a > batch > > > > I tried to set a library again, but not work. Any help? > > Are you logged in as a regular user or are you logged in as the mysql user? > > -- Owen > > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > -- Tiago Murakami -------------- next part -------------- An HTML attachment was scrubbed... URL: From altaf.mahmud at gmail.com Tue May 24 16:35:06 2011 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Tue, 24 May 2011 20:35:06 +0600 Subject: [Koha-devel] Z39.50 server authentication Message-ID: Dear community, I've enabled the Z39.50 server in my Koha server following these steps: 1. Edited /etc/koha/koha-conf.xml file and uncommented the publicserver line: tcp:@:9999 And change this line: to It forces Zebra to listen on unix socket (for Koha) and on TCP port 9999 (for external usage). 2. Restarted Zebra server. MARC data can now accessed from my z39.50 server. Now I want to implement the authentication process so that user id and login required to connect to my server. I don't know how to do it, could you please give me an advise? Thank you. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Tue May 24 18:28:57 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 24 May 2011 12:28:57 -0400 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: <4DDBAEA7.6040006@biblibre.com> References: <4DDA5040.20800@biblibre.com> <4DDBAEA7.6040006@biblibre.com> Message-ID: On Tue, May 24, 2011 at 9:12 AM, Paul Poulain wrote: > Le 23/05/2011 14:48, Chris Nighswonger a ?crit : >> So my vote is to use this method unless there is a very compelling >> reason to do otherwise. > What's happening with > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6328 (see comment 20) So should I assume that "does not apply cleanly" in this case is due to the 'XXX' in the version number? If so, as I said, that is a 30 to 60 second fix. But without looking into it further, I'd guess that there were other problems with this patch set which caused it not to apply cleanly and that the DB version number was still only a less than one minute fix with the "other problems" (unrelated to the DB version number) being the real time consumer. > > is interesting. I think the idea of atomic updates is very interesting. And the workflow/wiki must be updated anyway ! I agree that the wiki needs to speak with one tongue regarding whatever work flow is decided upon. :-) Kind Regards, Chris From laurenthdl at alinto.com Wed May 25 07:15:05 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Wed, 25 May 2011 07:15:05 +0200 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: References: <4DDA5040.20800@biblibre.com> Message-ID: <4DDC9059.2000103@alinto.com> Le 23/05/2011 14:48, Chris Nighswonger a ?crit : > Hi Paul, > > On Mon, May 23, 2011 at 8:17 AM, Paul Poulain > wrote: > > Hi all, > > I think there are some things unclear (at least for me ;-) ) about > submitting bugs with DB changes. > > > > > > * we spoke of using XXXX in updatedatabase.pl > to have te RM pick the > right number when needed. > > > > Speaking from the prospective of Release Maintainer, this method works > the most consistent for me. I have very few times when a DB update patch > using the 3.NN.XXX format does not apply cleanly for me. This includes > cases where NN == some subversion other than the current maintenance > version. So with this, my workflow goes like this: > > 1. Apply patch/cherry pick. > 2. Adjust rev number. > 3. Commit rev number change. > 4. Go on to the next patch. > > On the rare occasion the original patch does not apply cleanly it takes > all of about one minute to fixup. > > So my vote is to use this method unless there is a very compelling > reason to do otherwise. OK. When you have something that should apply both to 3.2 and 3.4 (say an index change, or a change on a field (text to varchar or varchar to text or varchar 10 to varchar 255), you number that from which number ?) Do you keep the least number or do you use two different rev numbers ? If you keep both, when upgrading, you will have some unwanted issue raised. If you take the least, then the number of the revision in the master branch is not the correct one, and when ppl upgrade they either will loose some db changes or have duplicate numbers. It can be solved with a kind of "deduplication table". But rather uneasy to implement. Could be also solved with a variable that says... ok if you come from 3.2 then it is that number, 3.4 that other... But upgrade path will have to decide which path you are coming from. I don't have THE solution. I mean I had the problem with 3.0 to 3.2 and the "best way" (in terms of time/development/tests) to cope with it was to store the initial kohaversion and make a test. (see MT2308b on our git.) Keep up the good job Chris. But this is an old issue, and some points were made back in 2010 in a thread named How about a different way of handling database updates http://www.mail-archive.com/koha-devel at lists.koha.org/msg03423.html Problem with patches and contributions more and more numerous will raise that again. My 2 cents. -- Henri-Damien LAURENT From fridolyn.somers at gmail.com Wed May 25 10:07:34 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 25 May 2011 10:07:34 +0200 Subject: [Koha-devel] Z39.50 server authentication In-Reply-To: References: Message-ID: Hie, In our configuration, authentification is managed by "serverinfo" tag in koha-conf.xml : /etc/koha/zebradb/ccl.properties username userpassword Regards, 2011/5/24 Altaf Mahmud > Dear community, > > I've enabled the Z39.50 server in my Koha server following these steps: > > 1. Edited /etc/koha/koha-conf.xml file and uncommented the publicserver > line: > tcp:@:9999 > And change this line: > > to > > It forces Zebra to listen on unix socket (for Koha) and on TCP port 9999 > (for external usage). > > 2. Restarted Zebra server. > > MARC data can now accessed from my z39.50 server. Now I want to implement > the authentication process so that user id and login required to connect to > my server. I don't know how to do it, could you please give me an advise? > > Thank you. > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > > _____________________________________________ > 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 olli-antti.kivilahti at jns.fi Wed May 25 11:01:23 2011 From: olli-antti.kivilahti at jns.fi (Olli-Antti Kivilahti) Date: Wed, 25 May 2011 12:01:23 +0300 Subject: [Koha-devel] Hardware requirements and cluster scalability Message-ID: <4DDCC563.9000501@jns.fi> Good day to everybody at the devel-list. And greetings from Finland! The library of Joensuu has started a project to compare different open source library systems, mainly Koha and Evergreen, with the goal of moving from our current closed source system to open source. We are planning to create a consortium of minimum of a ~20 libraries, but if open ILS are found to be superrior, probably the consortium can easily grow to ~250 libraries with ~5 million articles and ~150 000 transactions/hour. I have been hard pressed to find answers to the hardware requirements of Koha and Evergreen and have been instructed to ask here on devel-list by your library managers. My main interests are the hardware requirements of the said large consortium mainframe. How well does it cluster? What sort of hard disk and ram requirements are there? How many pc units with for example 2GHz cpu, 2Gb RAM do we need? Could every library host their own databases or should they be centralized? What are the average search speeds using simple SELECTs and then complex JOINs. What are the system bottlenecks? Can the OPAC be integrated with Drupal/Liferay so it can be compatible with our new web-services strategy? Are there any publications I could read about these topics? Happy coding! -- Olli-Antti Kivilahti Open Library 2013 Library of Joensuu From nengard at gmail.com Wed May 25 13:33:30 2011 From: nengard at gmail.com (Nicole Engard) Date: Wed, 25 May 2011 06:33:30 -0500 Subject: [Koha-devel] Official Koha Newsletter: Volume 2, Issue 5: May 2011 Message-ID: Below is the text of the newsletter, for active links please visit the Koha site: http://koha-community.org/koha-newsletter-volume-2issue-5-may-2011/ Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 5: May 2011 Table of Contents Koha Developments Koha 3.2.9 Available Koha 3.4.1 Available Koha Community Farmington Sponsors Facebook/Twitter Share Development Standards Organisation of Nigeria implements Koha supported by Projektlink Konsult Ltd. University of Guyana Chooses Koha Koha Tips & Tricks Increase Koha Performance Configure Automatic Receipt Printing Koha Developments Koha 3.2.9 Available by Chris Nighswonger The package can be retrieved from: http://download.koha-community.org/koha-3.02.09.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.09.tar.gz.MD5 http://download.koha-community.org/koha-3.02.09.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.09.tar.gz.sig Come and get it, quick! Read More Koha 3.4.1 Available by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.4.1. The package can be retrieved from: http://download.koha-community.org/koha-3.04.01.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.01.tar.gz.MD5 http://download.koha-community.org/koha-3.04.01.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.01.tar.gz.sig Come and get it! Read More Koha Community Farmington Sponsors Facebook/Twitter Share Development by Hall Bright ByWater Solutions has provided a Facebook and Twitter application for the Farmington Libraries to allow patrons to tweet and facebook what they are reading. When you go into the details VIEW of an item, the patron sees the Facebook and Twitter icons on the right menu where a Hold is placed. See: http://catalog.farmingtonlibraries.org/cgi-bin/koha/opac-detail.pl?biblionumber=161062 By clicking the Facebook ?Like? button, a patron is prompted to log in to Facebook. Then, a patron can write commentary or such and the commentary and the title [with a link to the catalog] appears on their Wall. The library?s address also appears. The Twitter ?Tweet? button also prompts a log in screen and then brings up a customizable message with an automatically generated TinyURL type link back to the catalog. We are still in testing, but we are excited for this customization. Standards Organisation of Nigeria implements Koha supported by Projektlink Konsult Ltd. by Olugbenga Adara The Standards Organisation of Nigeria (SON) Library, established in 1971, has adopted Koha for managing it?s library collections. The SON library has the responsibility to assemble and maintain a collection of standards, normative documents, books and other relevant materials it considers appropriate and relevant for a standards management in Nigeria. The implementation was carried out in conjunction with Projectlink Konsult Limited (PKL) Full details can be found online. University of Guyana Chooses Koha by Sekhar Mallampati University of Guyana (uog.edu.gy), Berbice Campus (South America) has launched it?s Library Automation System Koha on 12th May, 2011. The collection size is around 13000. We are also working on implementing Koha for University?s main campus (Turkeyen) Library which has a collection size of 140000. This is first of it?s kind in the country (Guyana). University of Guyana is the first one to implement this world?s leading Open Source Library Software (Koha) in the Caribbean. We have started helping the National Library of Guyana to start their journey with Koha. University of Guyana, Berbice Campus Library?s ?Online Public Access Catalog (OPAC)? service can be accessed at: http://ugbclibrary.uog.edu.gy Dept. of Software Services has provided technical support for University of Guyana automation project. I am a software engineer and HOD for Dept. of Software Services, University of Guyana. We want to thank you all for this feature-rich product. We have been benefiting from the mailing lists, etc. Koha Tips & Tricks Increase Koha Performance by Fridolyn SOMERS Here is a little technical trick : In koha-conf.xml, the address of the database server is stored : DB_HOST If you use its host name (mysql.mydomaine.com for example), the DNS will be used for each database connection. Using the IP address will pass-by DNS and may increase a little bit the Koha server performance. Configure Automatic Receipt Printing by Koha Community Did you know that you can set Koha to automatically print receipts for circulation? There is a guide on the wiki that will walk you through the process with different printers and browsers. Learn more on the Koha wiki. Newsletter edited by Nicole C. Engard, Koha Documentation Manager. Please send future story ideas to me. From mjr at phonecoop.coop Wed May 25 13:37:36 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 25 May 2011 12:37:36 +0100 (BST) Subject: [Koha-devel] How to gather better popularity data? Message-ID: <20110525113736.2B03B9EC0B@nail.towers.org.uk> We're often asked for better data on who is using Koha. For full disclosure listings, there are good places (like wiki.koha-community.org, when account registration works again) and so-so places (like libwebcats with its incomplete representation of library-support relationships and potential for helping Social Engineering attacks), but what about collecting basic usage data? A side-effect of the use of debian packages is that koha appears on http://popcon.debian.org/ (14 installations) and http://popcon.ubuntu.com/ (3 installations). Do other distributions have similar things? Have many koha package users installed and activated the popularity-contest package? Can we get more data consensually? How should we do this? A question in the web installer/upgrader? Plus a weekly heartbeat cronjob? What data should we ask for? Can we leave it up to libraries how anonymous they will be? Basic return is "Koha in use" with some generated unique identifier, semi-anonymous response adds which country they are in and how many branches they have, full response includes catalogue name? I assume this can go in 3.6. Would the 3.4 RM accept it? Thanks for any feedback, -- 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 fridolyn.somers at gmail.com Wed May 25 13:57:37 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 25 May 2011 13:57:37 +0200 Subject: [Koha-devel] Z39.50 server authentication In-Reply-To: References: Message-ID: No, you can keep it, default Koha configuration seems good in zebra-biblios.cfg : perm.anonymous:ar > perm.ZEBRA_USER:rw > The anonymous user has only read perm. By the way, I think your conf is not correct : > tcp:@:9999 > And change this line: > > to > > I think you should set the listen ref on "pulicserver" : tcp:@:9999 Regards, On Wed, May 25, 2011 at 12:25 PM, Altaf Mahmud wrote: > I mean, do I need to comment out 'perm.anonymous' in zebra-biblios.cfg file > at /etc/koha/zebradb/ directory as LAURENT suggested? > > > On Wed, May 25, 2011 at 4:23 PM, Altaf Mahmud wrote: > >> Hi Fridolyn, In that case do I need to comment out zebra-biblios.cfg file >> in /etc/koha/zebradb/ directory? I just added this tag in koha-conf.xml file >> but it's not working. >> >> Thanks. >> >> >> On Wed, May 25, 2011 at 2:07 PM, Fridolyn SOMERS < >> fridolyn.somers at gmail.com> wrote: >> >>> Hie, >>> >>> In our configuration, authentification is managed by "serverinfo" tag in >>> koha-conf.xml : >>> >>> >>> /etc/koha/zebradb/ccl.properties >>> username >>> userpassword >>> >>> >>> Regards, >>> >>> 2011/5/24 Altaf Mahmud >>> >>>> Dear community, >>>> >>>> I've enabled the Z39.50 server in my Koha server following these steps: >>>> >>>> 1. Edited /etc/koha/koha-conf.xml file and uncommented the publicserver >>>> line: >>>> tcp:@:9999 >>>> And change this line: >>>> >>>> to >>>> >>>> It forces Zebra to listen on unix socket (for Koha) and on TCP port >>>> 9999 (for external usage). >>>> >>>> 2. Restarted Zebra server. >>>> >>>> MARC data can now accessed from my z39.50 server. Now I want to >>>> implement the authentication process so that user id and login required to >>>> connect to my server. I don't know how to do it, could you please give me an >>>> advise? >>>> >>>> Thank you. >>>> >>>> >>>> -- >>>> Altaf Mahmud >>>> System Programmer >>>> Ayesha Abed Library >>>> BRAC University >>>> Bangladesh. >>>> >>>> >>>> _ >>>> 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 >>> >> >> >> >> -- >> Altaf Mahmud >> System Programmer >> Ayesha Abed Library >> BRAC University >> Bangladesh. >> >> > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > -- 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 ian.walls at bywatersolutions.com Wed May 25 14:55:32 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 25 May 2011 08:55:32 -0400 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: <4DDC9059.2000103@alinto.com> References: <4DDA5040.20800@biblibre.com> <4DDC9059.2000103@alinto.com> Message-ID: I think the problem with database revision numbers comes down to something fundamentally structural. Database revision numbers are linear, and are part of the Koha version number. But our development is non-linear; using Git, we work off Directed Acyclic Graphs. There are multiple paths to reach the same destination. Trying to map the more complex DAG of our development down to a linear sequence is the source of this difficulty. So, what we need is to separate the mechanisms. What if we pulled out the database revision out of the version number, and used a hash of some kind to identify the current database structure? The hash could be calculated off the kohastructure.sql, which is where any structural conflicts would arise anyway. I think it'd be safe enough to ignore system preferences and other data, so long as the structure of all the database tables was factored in. This would allow us to apply patches with database revisions without getting 'out of order', as well as allow us to get to the same structure in multiple ways (like we can with code in Git). I suppose the difficulty here would be keeping kohastructure.sql synced with the database revision statements in updatedatabase.pl. Perhaps there's a way to just edit kohastructure.sql, then do a delta to generate the update statements required? Further thoughts? Am I missing something critical (I have this nagging feeling I am). -Ian On Wed, May 25, 2011 at 1:15 AM, LAURENT Henri-Damien wrote: > Le 23/05/2011 14:48, Chris Nighswonger a ?crit : > > Hi Paul, > > > > On Mon, May 23, 2011 at 8:17 AM, Paul Poulain > > wrote: > > > > Hi all, > > > > I think there are some things unclear (at least for me ;-) ) about > > submitting bugs with DB changes. > > > > > > > > > > > > * we spoke of using XXXX in updatedatabase.pl > > to have te RM pick the > > right number when needed. > > > > > > > > Speaking from the prospective of Release Maintainer, this method works > > the most consistent for me. I have very few times when a DB update patch > > using the 3.NN.XXX format does not apply cleanly for me. This includes > > cases where NN == some subversion other than the current maintenance > > version. So with this, my workflow goes like this: > > > > 1. Apply patch/cherry pick. > > 2. Adjust rev number. > > 3. Commit rev number change. > > 4. Go on to the next patch. > > > > On the rare occasion the original patch does not apply cleanly it takes > > all of about one minute to fixup. > > > > So my vote is to use this method unless there is a very compelling > > reason to do otherwise. > OK. > > When you have something that should apply both to 3.2 and 3.4 (say an > index change, or a change on a field (text to varchar or varchar to text > or varchar 10 to varchar 255), you number that from which number ?) Do > you keep the least number or do you use two different rev numbers ? > If you keep both, when upgrading, you will have some unwanted issue raised. > If you take the least, then the number of the revision in the master > branch is not the correct one, and when ppl upgrade they either will > loose some db changes or have duplicate numbers. > It can be solved with a kind of "deduplication table". > But rather uneasy to implement. > Could be also solved with a variable that says... ok if you come from > 3.2 then it is that number, 3.4 that other... But upgrade path will have > to decide which path you are coming from. > > I don't have THE solution. > > I mean I had the problem with 3.0 to 3.2 and the "best way" (in terms of > time/development/tests) to cope with it was to store the initial > kohaversion and make a test. (see MT2308b on our git.) > > Keep up the good job Chris. > > But this is an old issue, and some points were made back in 2010 in a > thread named How about a different way of handling database updates > http://www.mail-archive.com/koha-devel at lists.koha.org/msg03423.html > > Problem with patches and contributions more and more numerous will raise > that again. > > My 2 cents. > -- > Henri-Damien LAURENT > ___ > 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 ALA Booth 732 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 May 25 15:20:32 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 25 May 2011 15:20:32 +0200 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: References: <4DDA5040.20800@biblibre.com> <4DDC9059.2000103@alinto.com> Message-ID: <4DDD0220.6030204@biblibre.com> Le 25/05/2011 14:55, Ian Walls a ?crit : > Further thoughts? Am I missing something critical (I have this > nagging feeling I am). yes, just one: isn't this DAG achieved by the DBIx::Class schema Chris want(ed) to use ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From magnus at enger.priv.no Wed May 25 15:27:57 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 25 May 2011 15:27:57 +0200 Subject: [Koha-devel] How to gather better popularity data? In-Reply-To: <20110525113736.2B03B9EC0B@nail.towers.org.uk> References: <20110525113736.2B03B9EC0B@nail.towers.org.uk> Message-ID: On 25 May 2011 13:37, MJ Ray wrote: > We're often asked for better data on who is using Koha. ?For full > disclosure listings, there are good places (like > wiki.koha-community.org, when account registration works again) and > so-so places (like libwebcats with its incomplete representation of > library-support relationships and potential for helping Social > Engineering attacks), but what about collecting basic usage data? > > A side-effect of the use of debian packages is that koha appears on > http://popcon.debian.org/ (14 installations) and > http://popcon.ubuntu.com/ (3 installations). ?Do other distributions > have similar things? ?Have many koha package users installed and > activated the popularity-contest package? > > Can we get more data consensually? ?How should we do this? ?A > question in the web installer/upgrader? ?Plus a weekly > heartbeat cronjob? > > What data should we ask for? ?Can we leave it up to libraries how > anonymous they will be? ?Basic return is "Koha in use" with some > generated unique identifier, semi-anonymous response adds which > country they are in and how many branches they have, full response > includes catalogue name? > > I assume this can go in 3.6. ?Would the 3.4 RM accept it? > > Thanks for any feedback, Interesting points! Have you seen this RFC? http://wiki.koha-community.org/wiki/Add_a_button_to_the_intranet_for_registering_with_the_Koha_community Best regards, Magnus Enger libriotech.no From laurenthdl at alinto.com Wed May 25 16:00:57 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Wed, 25 May 2011 16:00:57 +0200 Subject: [Koha-devel] Z39.50 server authentication In-Reply-To: References: Message-ID: <4DDD0B99.9010305@alinto.com> Le 25/05/2011 13:57, Fridolyn SOMERS a ?crit : > No, you can keep it, > default Koha configuration seems good in zebra-biblios.cfg : > > perm.anonymous:ar > perm.__ZEBRA_USER:rw > Top posting is not so good to follow the conversation.... What Altaf wanted, from what I read, was to prevent the zebra database to be available for read for the world without authentication. This is why I suggested to do a test commenting the anonymous access in zebra-biblios.cfg. He may also have more than one zebra-biblios.cfg one for publicserver access and one for the biblioserver. But this looks somewhat overkill. That was my 2 cents. Friendly. -- Henri-Damien LAURENT From marshall.breeding at Vanderbilt.Edu Wed May 25 17:06:46 2011 From: marshall.breeding at Vanderbilt.Edu (Breeding, Marshall) Date: Wed, 25 May 2011 10:06:46 -0500 Subject: [Koha-devel] How to gather better popularity data? In-Reply-To: <20110525113736.2B03B9EC0B@nail.towers.org.uk> References: <20110525113736.2B03B9EC0B@nail.towers.org.uk> Message-ID: I would be interested to understand more about what is meant by "... potential for helping Social Engineering attacks". My intent is to accurately and comprehensively represent the libraries that have adopted Koha, as well as the other open source and proprietary automation systems. I'm not aware of any other project with similar objectives. -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of MJ Ray Sent: Wednesday, May 25, 2011 6:38 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] How to gather better popularity data? We're often asked for better data on who is using Koha. For full disclosure listings, there are good places (like wiki.koha-community.org, when account registration works again) and so-so places (like libwebcats with its incomplete representation of library-support relationships and potential for helping Social Engineering attacks), but what about collecting basic usage data? A side-effect of the use of debian packages is that koha appears on http://popcon.debian.org/ (14 installations) and http://popcon.ubuntu.com/ (3 installations). Do other distributions have similar things? Have many koha package users installed and activated the popularity-contest package? Can we get more data consensually? How should we do this? A question in the web installer/upgrader? Plus a weekly heartbeat cronjob? What data should we ask for? Can we leave it up to libraries how anonymous they will be? Basic return is "Koha in use" with some generated unique identifier, semi-anonymous response adds which country they are in and how many branches they have, full response includes catalogue name? I assume this can go in 3.6. Would the 3.4 RM accept it? Thanks for any feedback, -- 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 _____________________________________________ 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 mjr at phonecoop.coop Wed May 25 20:56:11 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 25 May 2011 19:56:11 +0100 (BST) Subject: [Koha-devel] How to gather better popularity data? In-Reply-To: Message-ID: <20110525185611.E02349EC0B@nail.towers.org.uk> Magnus Enger > > Can we get more data consensually? ?How should we do this? ?A > > question in the web installer/upgrader? ?Plus a weekly > > heartbeat cronjob? [...] > Interesting points! > > Have you seen this RFC? > http://wiki.koha-community.org/wiki/Add_a_button_to_the_intranet_for_registering_with_the_Koha_community Probably, but I had forgotten it. Would advertising in the generator meta tag may make it easier for robots to identify and attack libraries who don't upgrade promptly? Putting it in a system preference is a good idea. I think it would be better to ask in the web installer/upgrader because I feel someone installing it is more likely to have permission to notify us than a librarian who simply has permission to view the about page. Does it lose anything by being done at install/upgrade time? The heartbeat would be good for telling us how many of the Koha installations are still alive, without having to try to search for generator tags. Do search engines let you search for them? Hope that explains, -- 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 mjr at phonecoop.coop Wed May 25 21:28:02 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 25 May 2011 20:28:02 +0100 (BST) Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: Message-ID: <20110525192802.0E6599EC0B@nail.towers.org.uk> Breeding, Marshall wrote: > I would be interested to understand more about what is meant by > "... potential for helping Social Engineering attacks". Social engineering is the act of manipulating people into performing actions or divulging confidential information. While similar to a confidence trick or simple fraud, the term typically applies to trickery or deception for the purpose of information gathering, fraud or computer system access; in most cases the attacker never comes face-to-face with the victim... http://en.wikipedia.org/wiki/Social_engineering_(security) Attackers do currently phone people up and trying to convince them that they're an IT support provider. It's on the increase - even the co-op has had a call, which I described on our blog recently in http://www.news.software.coop/kilman-it-services-social-engineering-phone-call-attack/1068/ These attacks are getting more sophisticated. I think it's only a matter of time before the fraud call centres start trying to target customers of particular providers. Library borrower records would be a treasure trove for identity thieves, so it disappoints me that many libraries are made easy to target. Support providers get a bit of publicity by announcing their contracts, but what's in those announcements and listings for the libraries, besides having their backsides hung out in the breeze? Why don't libwebcats and the LTG newswire try to discourage this bad behaviour by the private sector, instead of rewarding it? Is it just that these attacks aren't very widely known among libraries yet? Or is this why it says "Marshall Breeding or other individuals associated with Library Technology Guides are not response[sic] for any damages or losses associated with the use of the lib-web-cats database"? This is part of why I feel an optinally-anonymous popcon-style system would be much more ethical than suggesting libwebcats. Other than that, we get into things like libwebcats's anti-commercial/non-FOSS terms which we've discussed before. (In the few cases where the co-op has a credit link on an OPAC, it's where we know each others' names and there isn't much staff turnover.) Hope that explains, -- 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 marshall.breeding at Vanderbilt.Edu Wed May 25 22:13:05 2011 From: marshall.breeding at Vanderbilt.Edu (Breeding, Marshall) Date: Wed, 25 May 2011 15:13:05 -0500 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: <20110525192802.0E6599EC0B@nail.towers.org.uk> References: <20110525192802.0E6599EC0B@nail.towers.org.uk> Message-ID: A most interesting response. So being listed in the lib-web-cats directory is damaging to a library? And being listed in Koha community's own wiki would not be? It seems to me that libraries gain benefits from being more easily discovered on the Web. In April 2011 alone, for example, there were 90,424 times when someone clicked through from a lib-web-cats entry to a library's Web site or catalog. Altogether there were 2,090,393 page requests in Library Technology Guides in April. I also believe that the Koha community benefits from any resource that documents the ever increasing numbers of libraries adopting the system. It feels odd to be criticized for efforts that I believe provide benefits to the broader library community. Including a disclaimer does not imply that the data are being used unethically. -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of MJ Ray Sent: Wednesday, May 25, 2011 2:28 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Social Engineering, was: How to gather better popularity data? Breeding, Marshall wrote: > I would be interested to understand more about what is meant by "... > potential for helping Social Engineering attacks". Social engineering is the act of manipulating people into performing actions or divulging confidential information. While similar to a confidence trick or simple fraud, the term typically applies to trickery or deception for the purpose of information gathering, fraud or computer system access; in most cases the attacker never comes face-to-face with the victim... http://en.wikipedia.org/wiki/Social_engineering_(security) Attackers do currently phone people up and trying to convince them that they're an IT support provider. It's on the increase - even the co-op has had a call, which I described on our blog recently in http://www.news.software.coop/kilman-it-services-social-engineering-phone-call-attack/1068/ These attacks are getting more sophisticated. I think it's only a matter of time before the fraud call centres start trying to target customers of particular providers. Library borrower records would be a treasure trove for identity thieves, so it disappoints me that many libraries are made easy to target. Support providers get a bit of publicity by announcing their contracts, but what's in those announcements and listings for the libraries, besides having their backsides hung out in the breeze? Why don't libwebcats and the LTG newswire try to discourage this bad behaviour by the private sector, instead of rewarding it? Is it just that these attacks aren't very widely known among libraries yet? Or is this why it says "Marshall Breeding or other individuals associated with Library Technology Guides are not response[sic] for any damages or losses associated with the use of the lib-web-cats database"? This is part of why I feel an optinally-anonymous popcon-style system would be much more ethical than suggesting libwebcats. Other than that, we get into things like libwebcats's anti-commercial/non-FOSS terms which we've discussed before. (In the few cases where the co-op has a credit link on an OPAC, it's where we know each others' names and there isn't much staff turnover.) Hope that explains, -- 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 _______________________________________________ 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 skushner at mtpl.org Wed May 25 22:59:43 2011 From: skushner at mtpl.org (Scott Kushner) Date: Wed, 25 May 2011 16:59:43 -0400 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: References: <20110525192802.0E6599EC0B@nail.towers.org.uk> Message-ID: <3F5DBA7C1433624D870AF4F965358FD660E96A@exchange.mplmain.mtpl.org> I wouldn't take the opinion of one individual (including myself) as representing the view of the "community". Scott Kushner Information Systems Librarian Middletown Public Library -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Breeding, Marshall Sent: Wednesday, May 25, 2011 4:13 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Social Engineering, was: How to gather better popularity data? A most interesting response. So being listed in the lib-web-cats directory is damaging to a library? And being listed in Koha community's own wiki would not be? It seems to me that libraries gain benefits from being more easily discovered on the Web. In April 2011 alone, for example, there were 90,424 times when someone clicked through from a lib-web-cats entry to a library's Web site or catalog. Altogether there were 2,090,393 page requests in Library Technology Guides in April. I also believe that the Koha community benefits from any resource that documents the ever increasing numbers of libraries adopting the system. It feels odd to be criticized for efforts that I believe provide benefits to the broader library community. Including a disclaimer does not imply that the data are being used unethically. -marshall Marshall Breeding Editor, Library Technology Guides http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of MJ Ray Sent: Wednesday, May 25, 2011 2:28 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Social Engineering, was: How to gather better popularity data? Breeding, Marshall wrote: > I would be interested to understand more about what is meant by "... > potential for helping Social Engineering attacks". Social engineering is the act of manipulating people into performing actions or divulging confidential information. While similar to a confidence trick or simple fraud, the term typically applies to trickery or deception for the purpose of information gathering, fraud or computer system access; in most cases the attacker never comes face-to-face with the victim... http://en.wikipedia.org/wiki/Social_engineering_(security) Attackers do currently phone people up and trying to convince them that they're an IT support provider. It's on the increase - even the co-op has had a call, which I described on our blog recently in http://www.news.software.coop/kilman-it-services-social-engineering-phon e-call-attack/1068/ These attacks are getting more sophisticated. I think it's only a matter of time before the fraud call centres start trying to target customers of particular providers. Library borrower records would be a treasure trove for identity thieves, so it disappoints me that many libraries are made easy to target. Support providers get a bit of publicity by announcing their contracts, but what's in those announcements and listings for the libraries, besides having their backsides hung out in the breeze? Why don't libwebcats and the LTG newswire try to discourage this bad behaviour by the private sector, instead of rewarding it? Is it just that these attacks aren't very widely known among libraries yet? Or is this why it says "Marshall Breeding or other individuals associated with Library Technology Guides are not response[sic] for any damages or losses associated with the use of the lib-web-cats database"? This is part of why I feel an optinally-anonymous popcon-style system would be much more ethical than suggesting libwebcats. Other than that, we get into things like libwebcats's anti-commercial/non-FOSS terms which we've discussed before. (In the few cases where the co-op has a credit link on an OPAC, it's where we know each others' names and there isn't much staff turnover.) Hope that explains, -- 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 _ 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/ From robin at catalyst.net.nz Thu May 26 01:11:52 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 26 May 2011 11:11:52 +1200 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: References: <20110525192802.0E6599EC0B@nail.towers.org.uk> Message-ID: <1306365112.2375.35.camel@zarathud> Breeding, Marshall schreef op wo 25-05-2011 om 15:13 [-0500]: > It feels odd to be criticized for efforts that I believe provide > benefits to the broader library community. Including a disclaimer > does not imply that the data are being used unethically. This particular risk is always present in any situation where you have something that says "person/organisation A is using software X." Personally, I think the benefit far outweighs the risk. -- 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 colin.campbell at ptfs-europe.com Thu May 26 12:24:02 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 26 May 2011 11:24:02 +0100 Subject: [Koha-devel] patches with DB change, workflow In-Reply-To: References: <4DDA5040.20800@biblibre.com> <4DDC9059.2000103@alinto.com> Message-ID: <4DDE2A42.7080004@ptfs-europe.com> On 25/05/11 13:55, Ian Walls wrote: > I think the problem with database revision numbers comes down to something > fundamentally structural. Database revision numbers are linear, and are > part of the Koha version number. But our development is non-linear; using > Git, we work off Directed Acyclic Graphs. From Ism at kis.in Thu May 26 12:44:23 2011 From: Ism at kis.in (ISM KIS) Date: Thu, 26 May 2011 16:14:23 +0530 Subject: [Koha-devel] Koha 3.4.1 upgarde - failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) In-Reply-To: References: Message-ID: <4DDE7C2C.D759.006F.0@kis.in> I am still in the process of upgrading our Koha from 3.00.06 to 3.4.1 Installation is ok. I could import the data from 3.0.6 and did the database update from the :8080 interface. But then when I run the script to remove the biblioitems I get the following error message: koha34:/opt/kohaclone/misc/maintenance # perl remove_items_from_biblioitems.pl --run DBI connect('dbname=koha;host=localhost;port=3306','kohaadmin',...) failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) at /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692 Access denied for user 'kohaadmin'@'localhost' (using password: YES) at /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692. What does that mean? ( By the way: I' m able to access mysql -ukohaadmin -pxxxxx ) Any ideas? Rudy Wuthrich Kodaikanal International School From oleonard at myacpl.org Thu May 26 14:28:37 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 26 May 2011 08:28:37 -0400 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: <1306365112.2375.35.camel@zarathud> References: <20110525192802.0E6599EC0B@nail.towers.org.uk> <1306365112.2375.35.camel@zarathud> Message-ID: 2011/5/25 Robin Sheat : > Breeding, Marshall schreef op wo 25-05-2011 om 15:13 [-0500]: >> It feels odd to be criticized for efforts that I believe provide >> benefits to the broader library community. ?Including a disclaimer >> does not imply that the data are being used unethically. > > This particular risk is always present in any situation where you have > something that says "person/organisation A is using software X." > Personally, I think the benefit far outweighs the risk. The Nelsonville Public Library was the first public library in the US to use Koha. I considered it a privilege to be able to tell others about our experience and encourage them to make the same switch. Having that information available to all was a benefit to us and to Koha. Anyone can usually find out what automation system a library is using by going to their web site. I don't see how eliminating lib-web-cats listings is going to make anyone safer. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From ian.walls at bywatersolutions.com Thu May 26 15:37:55 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 26 May 2011 09:37:55 -0400 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: References: <20110525192802.0E6599EC0B@nail.towers.org.uk> <1306365112.2375.35.camel@zarathud> Message-ID: I talked with MJ a bit in Koha IRC yesterday to get a better understanding of his concerns. While there are theoretical exploits of the data found in libwebcats, I don't feel as though the site is putting anyone at particular risk. As Owen points out, most of this info can be found on many libraries websites, so it's already out there. And the legitimate uses of this information far exceed the potential exploits. ANY information can be used for evil. In my opinion, the responsibility for the ethical usage of knowledge rests not with the content provider, but with the individual his/herself. Marshall, thank you for your work on libwebcats. It's a valuable tool. There are still some improvements to be made, from my perspective, but it's definitely better that it exists than not. Cheers, -Ian On Thu, May 26, 2011 at 8:28 AM, Owen Leonard wrote: > 2011/5/25 Robin Sheat : > > Breeding, Marshall schreef op wo 25-05-2011 om 15:13 [-0500]: > >> It feels odd to be criticized for efforts that I believe provide > >> benefits to the broader library community. Including a disclaimer > >> does not imply that the data are being used unethically. > > > > This particular risk is always present in any situation where you have > > something that says "person/organisation A is using software X." > > Personally, I think the benefit far outweighs the risk. > > The Nelsonville Public Library was the first public library in the US > to use Koha. I considered it a privilege to be able to tell others > about our experience and encourage them to make the same switch. > Having that information available to all was a benefit to us and to > Koha. > > Anyone can usually find out what automation system a library is using > by going to their web site. I don't see how eliminating lib-web-cats > listings is going to make anyone safer. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.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 ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjr at phonecoop.coop Thu May 26 20:44:59 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 26 May 2011 19:44:59 +0100 (BST) Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: Message-ID: <20110526184459.3A94D9EC0B@nail.towers.org.uk> Breeding, Marshall wrote: > A most interesting response. So being listed in the lib-web-cats > directory is damaging to a library? And being listed in Koha > community's own wiki would not be? [...] Being listed with provider details in lib-web-cats increases the security risk to a library. The same is true of the wiki, so I suggested an optionally-anonymous popcon-style system which would not necessarily carry that risk. It would also provide better information about our effects than the subset who accept the increased risk of lib-web-cats. Going by discussions on IRC, it seems that many public libraries feel that freedom of information is more important than this security measure. Also, the US in general has a much weaker approach to privacy than Europe (which I suspected and was part of why I destroyed my dollar credit card when I returned home!) [...] > It feels odd to be criticized for efforts that I believe provide > benefits to the broader library community. Including a disclaimer > does not imply that the data are being used unethically. So what's the disclaimer there for? I wondered if it was because a risk of damage from unethical use wasn't news to you. There are also the other problems of lib-web-cats we've discussed before like not being free software or open data, the product/supplier confusion and not showing which PTFS-supported libraries (if any) use Koha and which use the Liblime ILS which reportedly forked from Koha before 3.2. Anyway, I find it odd whenever library community resources have restrictions on commerce, freedom or openness. Even odder when their promoters appear all hurt when social enterprises, libertarians or horizontalists suggest developing nicer alternatives. Hope that clarifies, -- 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 Thu May 26 21:01:52 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 26 May 2011 20:01:52 +0100 (BST) Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: Message-ID: <20110526190152.AB04A9EC0B@nail.towers.org.uk> Ian Walls wrote: > I talked with MJ a bit in Koha IRC yesterday to get a better understanding > of his concerns. While there are theoretical exploits of the data found in > libwebcats, I don't feel as though the site is putting anyone at particular > risk. As Owen points out, most of this info can be found on many libraries > websites, so it's already out there. [...] The exploits are not theoretical. Organisations are under attack. Only the use of libwebcats as an information source is guesswork. Supplier information isn't on the websites of most libraries supported by the co-op, in part for this reason. > ANY information can be used for evil. In my opinion, the responsibility for > the ethical usage of knowledge rests not with the content provider, but with > the individual his/herself. So why not post usernames and passwords publicly, then? Or run an open mail relay? After all, responsibility rests with the individual attacker. And that's why we don't do it: attackers are irresponsible scoundrels and we should take reasonable steps to defend ourselves. Hope that explains, -- 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 Vanderbilt.Edu Thu May 26 22:42:02 2011 From: marshall.breeding at Vanderbilt.Edu (Breeding, Marshall) Date: Thu, 26 May 2011 15:42:02 -0500 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: <20110526184459.3A94D9EC0B@nail.towers.org.uk> References: <20110526184459.3A94D9EC0B@nail.towers.org.uk> Message-ID: I'm not sure I want to keep this thread alive, but here goes. If you believe that being listed in a directory or wiki of any sort is dangerous, then you are relying on security through obscurity, with is no real security at all. I believe that libraries have vital interests in having users find them on the Web. I can think of nothing more damaging to libraries than insisting that they obscure their Web presence by restricting the pathways that lead users to their Web sites and catalogs. It is also in the interest of persons who work in libraries to know the automation systems used by their peers so that they can make well-informed decisions regarding technology strategies. An anonymous Popularity Contest daemon such as used in Debian would not necessarily provide data that would help libraries considering or running Koha to find peer sites for comparison. It would also not be a reliable indicator of number of libraries that actually use Koha. If it's optional, then the numbers would be under-reported. It would also include the large number of Koha instances that are used for development and evaluation in addition to those that actually run in production in libraries. It would also not include the libraries that use Koha within a restricted intranet, or in local networks that have not access to the Internet, which is common in the developing world. Such a technical approach is helpful with an OS where you want to measure overall deployment; it's different for automation software where you care more about what libraries use it in production. (This is in response to the IRC comment that I should have compared lib-web-cats to popcon and not the wiki.) I've put in thousands of hours of work on lib-web-cats since it was initially created in 1995 and launched on the Web in 1977. The views of one individual should not undermine this project. It's not helpful to try to convince libraries that they should isolate themselves on the Web. That, to me, contradicts the spirit of engagement that is vital to the mission of libraries today. And that is my key interest. So I'm pretty agnostic when it comes to open source vs. proprietary or any given library automation product. I think that libraries have an interest in the success of all the competing models, products, and projects. Open source ILS products such as Koha provide important alternatives for libraries, and have influenced proprietary systems to be more open. I know that the philosophy of open source prevails on this list, and I know that my views and projects don't meet all the litmus tests. But that does not mean that I don't have the same respect for this approach as any other. I have been involved in open source projects, such as OLE. I get a sense from the discussions on IRC that at least some think I'm against the project in some way, which is not the case. It's interesting that I'm criticized by those involved with proprietary systems as being slanted toward the open source products, and that the open source advocates see me as favoring proprietary products and companies. In the end, I think it's all about finding ways to help libraries, which I think is the value we all share. -marshall -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of MJ Ray Sent: Thursday, May 26, 2011 1:45 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Social Engineering, was: How to gather better popularity data? Breeding, Marshall wrote: > A most interesting response. So being listed in the lib-web-cats > directory is damaging to a library? And being listed in Koha > community's own wiki would not be? [...] Being listed with provider details in lib-web-cats increases the security risk to a library. The same is true of the wiki, so I suggested an optionally-anonymous popcon-style system which would not necessarily carry that risk. It would also provide better information about our effects than the subset who accept the increased risk of lib-web-cats. Going by discussions on IRC, it seems that many public libraries feel that freedom of information is more important than this security measure. Also, the US in general has a much weaker approach to privacy than Europe (which I suspected and was part of why I destroyed my dollar credit card when I returned home!) [...] > It feels odd to be criticized for efforts that I believe provide > benefits to the broader library community. Including a disclaimer > does not imply that the data are being used unethically. So what's the disclaimer there for? I wondered if it was because a risk of damage from unethical use wasn't news to you. There are also the other problems of lib-web-cats we've discussed before like not being free software or open data, the product/supplier confusion and not showing which PTFS-supported libraries (if any) use Koha and which use the Liblime ILS which reportedly forked from Koha before 3.2. Anyway, I find it odd whenever library community resources have restrictions on commerce, freedom or openness. Even odder when their promoters appear all hurt when social enterprises, libertarians or horizontalists suggest developing nicer alternatives. Hope that clarifies, -- 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/ From gmcharlt at gmail.com Fri May 27 00:51:47 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Thu, 26 May 2011 18:51:47 -0400 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: References: <20110526184459.3A94D9EC0B@nail.towers.org.uk> Message-ID: Hi, On Thu, May 26, 2011 at 4:42 PM, Breeding, Marshall wrote: > I believe that libraries have vital interests in having users find them on the Web. ?I can > think of nothing more damaging to libraries than insisting that they obscure their Web > presence by restricting the pathways that lead users to their Web sites and catalogs. > It is also in the interest of persons who work in libraries to know the automation > systems used by their peers so that they can make well-informed decisions > regarding technology strategies. And of course, part of that decision-making includes evaluating providers of services for the technology. This is particularly important for open source ILSs. For most proprietary ILSs, you can get support only from its creator and possibly some country-specific or library-type-specific resellers. There is a much broader ecosystem of support for open source ILSs, so if a library has decided to adopt Koha, they then have a choice of deciding whether to use a provider's services, and if so, which one. Knowing who is using what provider (and not just relying on the references supplied by the provider) gives libraries more information with which to make their procurement decisions. In my opinion, the benefits of that information alone outweigh any theoretical security risk. If there's a major security glitch in Koha, it would affect lots of Koha users, irrespective of whoever is supporting or hosting them. If there's a major security glitch that is peculiar to a particular provider's implementation of Koha? Well, frankly that is information that should be known broadly within the library community, not obscured. As I'm sure is the case with most regular users of lib-web-cats, there is some data that I wish was recorded that isn't, and some data that I wish was recorded differently. But I do consider it a very valuable resource and I, for one, thank Marshall for all of the effort he's put into it over the years. > An anonymous Popularity Contest daemon such as used in Debian would not necessarily provide > data that would help libraries considering or running Koha to find peer sites for comparison. ?It > would also not be a reliable indicator of number of libraries that actually use Koha. ?If it's optional, > then the numbers would be under-reported. ?It would also include the large number of Koha > instances that are used for development and evaluation in addition to those that actually > run in production in libraries. ?It would also not include the libraries that use Koha within a > restricted intranet, or in local networks that have not access to the Internet, which is common > in the developing world. ?Such a technical approach is helpful with an OS where you want > to measure overall deployment; it's different for automation software where you care > more about what libraries use it in production. ?(This is in response to the IRC comment > that I should have compared lib-web-cats to popcon and not the wiki.) Well, it's not an either-or situation. A popcon-like system would provide data that would be of immense use to Koha developers. Very few libraries are likely to update their lib-web-cats entry every time they do a minor release upgrade, for example, but a popcon would let us know to a rough degree how frequently those upgrades do occur, what platforms seem to be the most commonly used, and so forth. I view a popcon as a useful complement to directories like the wiki and lib-web-cats. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From glawson at rhcl.org Fri May 27 01:12:00 2011 From: glawson at rhcl.org (G. Laws) Date: Thu, 26 May 2011 18:12:00 -0500 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: References: <20110526184459.3A94D9EC0B@nail.towers.org.uk> Message-ID: <4DDEDE40.2050505@rhcl.org> Rather against my better judgment, I offer the following observations: 1. Under the State of Missouri (USA) sunshine laws, the public has a right of access to just about every non-personnel record we have. That would include all expenditures of public funds for things like our ILS and contracts we have with our support vendors, and thus there is a public right to know this information. While you might argue that not publicizing this information on the Internet would offer some minor obstacles to a bot herder in Moscow, any member of the public here could get the information and post it publicly, and they probably have. 2. We are required by our board of directors to do monthly written reports of all significant activity, which would obviously include mentioning Koha by name and issues relating to our support team, whenever that was a news-worthy item (at time of purchase, etc). Those board reports are also publicly available. 3. Viewing the page source of our OPAC and several belonging to NEKLS shows the ILS name right in the page source. Certainly the word Koha could be removed from the HTML source, but I'll bet there are a number of general Koha OPAC characteristics that would typify Koha, and surely many experienced people could look at an OPAC web page, or a search results page, and immediately identify the ILS. I can some of the time for Koha and Sirsi. It would require a lot of bleach to sanitize the code sufficiently to hide the underlying ILS. The same applies to an .odt file or an image that hasn't had the metadata scrubbed from it. I don't believe that there is any meaningful way to obscure the ILS from an experienced person looking for that information. Our library is quite happy to let everyone know we are running a world-class ILS, and pleased to have a hash mark recorded for us on the ILS list. Greg -- Greg Lawson Rolling Hills Consolidated Library 1912 N. Belt Highway St. Joseph, MO 64506 ----------------------------------- On 05/26/2011 03:42 PM, Breeding, Marshall wrote: > I'm not sure I want to keep this thread alive, but here goes. > > If you believe that being listed in a directory or wiki of any sort is dangerous, then you are relying on security through obscurity, with is no real security at all. > > I believe that libraries have vital interests in having users find them on the Web. I can think of nothing more damaging to libraries than insisting that they obscure their Web presence by restricting the pathways that lead users to their Web sites and catalogs. It is also in the interest of persons who work in libraries to know the automation systems used by their peers so that they can make well-informed decisions regarding technology strategies. > > An anonymous Popularity Contest daemon such as used in Debian would not necessarily provide data that would help libraries considering or running Koha to find peer sites for comparison. It would also not be a reliable indicator of number of libraries that actually use Koha. If it's optional, then the numbers would be under-reported. It would also include the large number of Koha instances that are used for development and evaluation in addition to those that actually run in production in libraries. It would also not include the libraries that use Koha within a restricted intranet, or in local networks that have not access to the Internet, which is common in the developing world. Such a technical approach is helpful with an OS where you want to measure overall deployment; it's different for automation software where you care more about what libraries use it in production. (This is in response to the IRC comment that I should have compared lib-web-cats to popcon and not t > he wiki.) > > I've put in thousands of hours of work on lib-web-cats since it was initially created in 1995 and launched on the Web in 1977. The views of one individual should not undermine this project. It's not helpful to try to convince libraries that they should isolate themselves on the Web. That, to me, contradicts the spirit of engagement that is vital to the mission of libraries today. And that is my key interest. > > So I'm pretty agnostic when it comes to open source vs. proprietary or any given library automation product. I think that libraries have an interest in the success of all the competing models, products, and projects. Open source ILS products such as Koha provide important alternatives for libraries, and have influenced proprietary systems to be more open. I know that the philosophy of open source prevails on this list, and I know that my views and projects don't meet all the litmus tests. But that does not mean that I don't have the same respect for this approach as any other. I have been involved in open source projects, such as OLE. I get a sense from the discussions on IRC that at least some think I'm against the project in some way, which is not the case. > > It's interesting that I'm criticized by those involved with proprietary systems as being slanted toward the open source products, and that the open source advocates see me as favoring proprietary products and companies. > > In the end, I think it's all about finding ways to help libraries, which I think is the value we all share. > > -marshall > > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of MJ Ray > Sent: Thursday, May 26, 2011 1:45 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Social Engineering, was: How to gather better popularity data? > > Breeding, Marshall wrote: >> A most interesting response. So being listed in the lib-web-cats >> directory is damaging to a library? And being listed in Koha >> community's own wiki would not be? [...] > Being listed with provider details in lib-web-cats increases the security risk to a library. The same is true of the wiki, so I suggested an optionally-anonymous popcon-style system which would not necessarily carry that risk. > > It would also provide better information about our effects than the subset who accept the increased risk of lib-web-cats. > > Going by discussions on IRC, it seems that many public libraries feel that freedom of information is more important than this security measure. Also, the US in general has a much weaker approach to privacy than Europe (which I suspected and was part of why I destroyed my dollar credit card when I returned home!) > > [...] >> It feels odd to be criticized for efforts that I believe provide >> benefits to the broader library community. Including a disclaimer >> does not imply that the data are being used unethically. > So what's the disclaimer there for? I wondered if it was because a risk of damage from unethical use wasn't news to you. > > There are also the other problems of lib-web-cats we've discussed before like not being free software or open data, the product/supplier confusion and not showing which PTFS-supported libraries (if any) use Koha and which use the Liblime ILS which reportedly forked from Koha before 3.2. > > Anyway, I find it odd whenever library community resources have restrictions on commerce, freedom or openness. Even odder when their promoters appear all hurt when social enterprises, libertarians or horizontalists suggest developing nicer alternatives. > > Hope that clarifies, > -- > 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/ > > _______________________ > 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 robin at catalyst.net.nz Fri May 27 04:01:25 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 27 May 2011 14:01:25 +1200 Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: <4DDEDE40.2050505@rhcl.org> References: <20110526184459.3A94D9EC0B@nail.towers.org.uk> <4DDEDE40.2050505@rhcl.org> Message-ID: <1306461685.2375.63.camel@zarathud> G. Laws schreef op do 26-05-2011 om 18:12 [-0500]: > I don't believe that there is any meaningful way to obscure the ILS > from > an experienced person looking for that information. I'm being a bit too pedantic, but that's not the point. There are many things that are fine to be known for an individual, but have a problem when that knowledge is aggregated. (In intelligence circles, it's quite possible for a document that's built from only public sources to be classified.) Software is one of those. If you want to attack all Koha system, it's harder to find out who the victims would be by going to each library and seeing if they run Koha then by going to a central list and looking them up there. That said, risk is is not a binary situation. Yes, there is risk by centralising all that information. But I think it's a small risk compared to the gains from doing so. There's a risk to me by me telling you my phone number, or being in the phone book. But I do it anyway. There's a risk of getting lured into a phishing attack by releasing my email address (which then gets aggregated onto spam lists), but I do it anyway. I think the risk of being in libwebcats is so very minor that it's not worth belabouring, especially when compared to the benefits gained by aggregating all the data that Marshall does. Especially because I can give you a URL that will give you many more Koha catalogues than libwebcats tracks, in a less convenient way for users, but about as useful for attackers: http://www.google.com/webhp?hl=nl#q=intitle:%22Koha+Online+Catalog%22&hl=nl&site=webhp&prmd=ivns&ei=GgXfTf6pNu_SiAKMmdT0Cg&start=10&sa=N&bav=on.2,or.r_gc.r_pw.&fp=4f5adfb52970213d&biw=1678&bih=979 (also: congratulations Middletown Township Public Library, you seem to have the most popular Koha OPAC out there :) -- 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 dschust1 at gmail.com Thu May 26 15:49:24 2011 From: dschust1 at gmail.com (David Schuster) Date: Thu, 26 May 2011 08:49:24 -0500 Subject: [Koha-devel] Coming to ALA? Join the social gathering! See attached flyer Message-ID: Saturday evening June 25th 8-11 - rsvp requested to terlaga at biblio.org -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2011-ALA-open-source-party.doc Type: application/msword Size: 60928 bytes Desc: not available URL: From fridolyn.somers at gmail.com Fri May 27 10:25:28 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 27 May 2011 10:25:28 +0200 Subject: [Koha-devel] Koha 3.4.1 upgarde - failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) In-Reply-To: <4DDE7C2C.D759.006F.0@kis.in> References: <4DDE7C2C.D759.006F.0@kis.in> Message-ID: Check if kohaadmin can access (via mysql -u -p -D) the Koha database. Regards, On Thu, May 26, 2011 at 12:44 PM, ISM KIS wrote: > I am still in the process of upgrading our Koha from 3.00.06 to 3.4.1 > > Installation is ok. I could import the data from 3.0.6 and did the database > update from the :8080 interface. > > But then when I run the script to remove the biblioitems I get the > following error message: > > koha34:/opt/kohaclone/misc/maintenance # perl > remove_items_from_biblioitems.pl --run > DBI connect('dbname=koha;host=localhost;port=3306','kohaadmin',...) failed: > Access denied for user 'kohaadmin'@'localhost' (using password: YES) at > /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692 > Access denied for user 'kohaadmin'@'localhost' (using password: YES) at > /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692. > > What does that mean? > ( By the way: I' m able to access mysql -ukohaadmin -pxxxxx ) > > Any ideas? > > Rudy Wuthrich > Kodaikanal International School > > _______________________________________________ > 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 magnus at enger.priv.no Fri May 27 14:46:31 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 27 May 2011 14:46:31 +0200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations Message-ID: Hi! I recently built my first debian package, based on the 3.4.x branch from git, and with the addition of having installed translations for the Nordic languages. (I'll write up the process of doing that on the wiki, once I'm sure I have the correct steps.) I used the Perl version of build-git-snapshot provided by attachment 4007 from bug 5602 to build the packages: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5602 (I'll sign off on the patch once I see the resulting package working, I promise! ;-) After installing the package and creating a library I noticed that a couple of CSS files are missing from the OPAC when it is viewed in any language other then English, making it look weird: http://esme.priv.bibkat.no/ Firebug tells me these two files can not be found, when the language is not English: http://esme.priv.bibkat.no/opac-tmpl/prog/en/lib/yui/reset-fonts-grids.css - 404 Not Found http://esme.priv.bibkat.no/opac-tmpl/prog/en/lib/yui/skin.css - 404 Not Found But when I view the front page in English, those two files are found, but from a different path: http://esme.priv.bibkat.no/opac-tmpl/prog/en/css/reset-fonts-grids.css - 200 OK http://esme.priv.bibkat.no/opac-tmpl/prog/en/css/skin.css - 200 OK The contents of the css-folders for the two languages are quite different: http://esme.priv.bibkat.no/opac-tmpl/prog/en/css/ [TXT] colors.css 05-May-2011 20:59 0 [TXT] hierarchy.css 05-May-2011 20:59 1.5K [IMG] menu-button-arrow-disabled.png 22-May-2011 14:59 173 [IMG] menu-button-arrow.png 22-May-2011 14:59 173 [TXT] opac.css 22-May-2011 14:59 34K [TXT] print.css 05-May-2011 20:59 3.1K [TXT] reset-fonts-grids.css 22-May-2011 14:59 5.0K [TXT] sanop.css 05-May-2011 20:59 28K [TXT] sco.css 22-May-2011 14:59 4.0K [TXT] skin.css 22-May-2011 14:59 84K [IMG] split-button-arrow-active.png 22-May-2011 14:59 280 [IMG] split-button-arrow-disabled.png 22-May-2011 14:59 185 [IMG] split-button-arrow-focus.png 22-May-2011 14:59 185 [IMG] split-button-arrow-hover.png 22-May-2011 14:59 185 [IMG] split-button-arrow.png 22-May-2011 14:59 185 [IMG] sprite.png 22-May-2011 14:59 3.0K (The en folder in the demo on mykoha.co.nz is identical to the folder above: http://demo.mykoha.co.nz/opac-tmpl/prog/en/css/ ) http://esme.priv.bibkat.no/opac-tmpl/prog/nb-NO/css/ [TXT] colors.css 22-May-2011 08:34 0 [TXT] hierarchy.css 22-May-2011 08:34 1.5K [TXT] opac.css 22-May-2011 08:34 34K [TXT] print.css 22-May-2011 08:34 3.1K [TXT] sanop.css 22-May-2011 08:34 28K [TXT] sco.css 22-May-2011 08:34 4.0K The contents of the lib/yui directory are also different on a regular dev install: http://sksk.bibkat.no/opac-tmpl/prog/en/lib/yui/ (5 CSS files, 3 directories, 1 PNG) and a packaged install: http://esme.priv.bibkat.no/opac-tmpl/prog/en/lib/yui/ (lots of directories, no CSS, no PNG) http://demo.mykoha.co.nz/opac-tmpl/prog/en/lib/yui/ On a non-package (dev) install the contents of the corresponding folders are the same for en and nb-NO - and they are the same as the 6 files listed for nb-NO above. http://sksk.bibkat.no/opac-tmpl/prog/en/css/ http://sksk.bibkat.no/opac-tmpl/prog/nb-NO/css/ On a working non-package (dev) installation the files are taken from the en folder, where they are indeed to be found: http://sksk.bibkat.no/opac-tmpl/prog/en/lib/yui/ http://sksk.bibkat.no/opac-tmpl/prog/nb-NO/lib/yui/ On the virtual machine where I built the package, the contents of the two css-directories are also the same, and they are the 6 files listed for nb-NO above. Looks to me like the packaging/packages is doing some rearranging of the CSS files that only works for the English templates and not for templates translated into other languages? Are there any package gurus out there who are able to see what is going on? Best regards, Magnus Enger libriotech.no From conan at lugmen.org.ar Fri May 27 19:33:48 2011 From: conan at lugmen.org.ar (Fernando L. Canizo) Date: Fri, 27 May 2011 14:33:48 -0300 Subject: [Koha-devel] =?utf-8?q?SpamRe=3AFW=3A_Code_simplicity_documen?= =?utf-8?q?t?= In-Reply-To: <4DCAA9A7.9090709@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA3124EC89@S-MAIL-1B.rijksmuseum.intra> <4DCAA9A7.9090709@biblibre.com> Message-ID: <20110527143348.a4ba3233.conan@lugmen.org.ar> On Wed, 11 May 2011 17:22:15 +0200, Paul Poulain wrote: > PS : challenge: who is interested in signing BZ6328 i just > submitted ? I feel no-one, as it's related to fines in days, and it > seems it's something strange to US/NZ and many countries. I'll be happy to signoff that one since we also use fine in days here in Argentina. Off course, once we fix the stuff I reported yesterday. However I agree that the signoff process needs to be relaxed a little. I'm very new here and I've seen devs reworking on an already fixed bug because it doesn't apply anymore, because nobody signed-it-off on time. Currently it's hard for some developers to signoff something they don't care about. Trivial stuff, ok, but what if you need a more complicated setup than usual? We can use other ideas in conjunction as well, like having assigned people to sign off each area. I'll contribute one another: to have sign-off fests every now and then. Maybe once/twice a month? -- Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/ GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++ From mjr at phonecoop.coop Sat May 28 00:40:13 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 27 May 2011 23:40:13 +0100 (BST) Subject: [Koha-devel] Social Engineering, was: How to gather better popularity data? In-Reply-To: Message-ID: <20110527224013.CB2729EC0B@nail.towers.org.uk> Breeding, Marshall wrote: > If you believe that being listed in a directory or wiki of any sort > is dangerous, then you are relying on security through obscurity, > with is no real security at all. I'm not sure I can convey this any more clearly: I am not arguing against all listing (although I believe it should be a matter of choice), but I am arguing against listing details which can be used for fraudulent authentication. I even put that bit in bold in the last email, so I'm surprised anyone's missing it still. It feels a bit like wilful misunderstanding for the sake of an argument. Would someone like to try calling up libraries from lib-web-cats, pretending to be from their provider and see if they can get a staff login? I'm hoping public-sector libraries will have some protocol defence, as they should expect to work under freedom of information, but there's plenty more in there. I think library staff might be better at choosing the right words to convince other library staff... > I believe that libraries have vital interests in having users find > them on the Web. [...] I'm pretty sceptical that many users find libraries through lib-web-cats. > also in the interest of persons who work in libraries to know the > automation systems used by their peers so that they can make > well-informed decisions regarding technology strategies. I'm not so sure about that (I've met peer-use requirements in procurement and that's a barrier to innovation) but basically the more information the more easily the better. I really don't think lib-web-cats is a viable alternative to a popcon, especially as it currently stands. It includes too much of some data and not enough of others and the terms are non-FOSS. > I've put in thousands of hours of work on lib-web-cats since it was > initially created in 1995 and launched on the Web in 1977. The > views of one individual should not undermine this project. (I'm assuming that's a typing error, rather than time travel. ;-) ) Not undermine, but maybe convince you to fix it. So you've put in thousands of hours: what's going to happen when you're no longer able to? Will it stagnate and die, like so many other web projects I've seen since I started in 1994? That'll be tragic. > It's not helpful to try to convince libraries that they should > isolate themselves on the Web. Which isn't what I'm trying to do. I'm saying don't expect everyone to stand naked in the wrong neighbourhood. > That, to me, contradicts the spirit of engagement that is vital to > the mission of libraries today. And that is my key interest. I'm suggesting connecting more libraries to the project and yet I'm against "the spirit of engagement" because I don't want it done through lib-web-cats? Wow. Really. Wow. > [...] I get a sense from the discussions on IRC that at least some > think I'm against the project in some way, which is not the case. So hopefully non-Koha libraries won't be listed as Koha, and Product and Provider will be split in the near future. ;-) After all, Koha's only had multiple providers for about a decade, so it'd be nice to see FOSS ILSes fit in lib-web-cats properly, instead of being shoehorned through proprietary ILS concepts. Hope that explains, -- 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 Mon May 30 01:05:19 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 30 May 2011 11:05:19 +1200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: References: Message-ID: <1306710319.2375.91.camel@zarathud> Magnus Enger schreef op vr 27-05-2011 om 14:46 [+0200]: > Looks to me like the packaging/packages is doing some rearranging of > the CSS files that only works for the English templates and not for > templates translated into other languages? Are there any package gurus > out there who are able to see what is going on? From the debian/rules file: rm -r $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui ln -s /usr/share/javascript/yui $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui and then a bunch of installs of css and png files into ...-tmp/prog/en/css. Perhaps this is what you're seeing that causes things to lay out differently. Also, did you add in the patch on bug 6361? It won't affect this, but should make things in general work a bit better in 3.4. -- 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 fridolyn.somers at gmail.com Mon May 30 10:34:18 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 30 May 2011 10:34:18 +0200 Subject: [Koha-devel] Koha 3.4.1 upgarde - failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) In-Reply-To: <4DDFB5A4.D359.006F.0@kis.in> References: <4DDE7C2C.D759.006F.0@kis.in> <4DDFB5A4.D359.006F.0@kis.in> Message-ID: Hie, Database name, host, port, user ... are stored into Koha main configuration file koha-conf.xml (mostly in /etc/koha/) look at the end of the XML. On Fri, May 27, 2011 at 11:01 AM, ISM KIS wrote: > Yes, I can access mysql -u -p -Dkoha > Where does remove_items_from_biblioitems.pl --run take the username and > password from? > > Rudy > > > >>> Fridolyn SOMERS 5/27/2011 1:55 PM >>> > Check if kohaadmin can access (via mysql -u -p -D) the Koha > database. > > Regards, > > On Thu, May 26, 2011 at 12:44 PM, ISM KIS wrote: > > > I am still in the process of upgrading our Koha from 3.00.06 to 3.4.1 > > > > Installation is ok. I could import the data from 3.0.6 and did the > database > > update from the :8080 interface. > > > > But then when I run the script to remove the biblioitems I get the > > following error message: > > > > koha34:/opt/kohaclone/misc/maintenance # perl > > remove_items_from_biblioitems.pl --run > > DBI connect('dbname=koha;host=localhost;port=3306','kohaadmin',...) > failed: > > Access denied for user 'kohaadmin'@'localhost' (using password: YES) at > > /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692 > > Access denied for user 'kohaadmin'@'localhost' (using password: YES) at > > /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692. > > > > What does that mean? > > ( By the way: I' m able to access mysql -ukohaadmin -pxxxxx ) > > > > Any ideas? > > > > Rudy Wuthrich > > Kodaikanal International School > > > > _______________________________________________ > > 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 > > -- 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 fridolyn.somers at gmail.com Mon May 30 11:05:51 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 30 May 2011 11:05:51 +0200 Subject: [Koha-devel] Koha 3.4.1 upgarde - failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) In-Reply-To: <4DE3A8EE.D759.006F.0@kis.in> References: <4DDE7C2C.D759.006F.0@kis.in> <4DDFB5A4.D359.006F.0@kis.in> <4DE3A8EE.D759.006F.0@kis.in> Message-ID: Your welcome. On Mon, May 30, 2011 at 10:56 AM, ISM KIS wrote: > Yes, thanks, got it. > There was a spelling mistake for the password in the .xml > > I guess I installed it too many times. > The remove_items_from_biblioitems.pl is now running. > > Thanks again for pointing me to the right file. > > Rudy Wuthrich > > > >>> Fridolyn SOMERS 5/30/2011 2:04 PM >>> > Hie, > > Database name, host, port, user ... > are stored into Koha main configuration file koha-conf.xml (mostly in > /etc/koha/) > look at the end of the XML. > > On Fri, May 27, 2011 at 11:01 AM, ISM KIS wrote: > > > Yes, I can access mysql -u -p -Dkoha > > Where does remove_items_from_biblioitems.pl --run take the username and > > password from? > > > > Rudy > > > > > > >>> Fridolyn SOMERS 5/27/2011 1:55 PM >>> > > Check if kohaadmin can access (via mysql -u -p -D) the Koha > > database. > > > > Regards, > > > > On Thu, May 26, 2011 at 12:44 PM, ISM KIS wrote: > > > > > I am still in the process of upgrading our Koha from 3.00.06 to 3.4.1 > > > > > > Installation is ok. I could import the data from 3.0.6 and did the > > database > > > update from the :8080 interface. > > > > > > But then when I run the script to remove the biblioitems I get the > > > following error message: > > > > > > koha34:/opt/kohaclone/misc/maintenance # perl > > > remove_items_from_biblioitems.pl --run > > > DBI connect('dbname=koha;host=localhost;port=3306','kohaadmin',...) > > failed: > > > Access denied for user 'kohaadmin'@'localhost' (using password: YES) > at > > > /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692 > > > Access denied for user 'kohaadmin'@'localhost' (using password: YES) > at > > > /opt/kohaclone/koha-tmpl/lib/C4/Context.pm line 692. > > > > > > What does that mean? > > > ( By the way: I' m able to access mysql -ukohaadmin -pxxxxx ) > > > > > > Any ideas? > > > > > > Rudy Wuthrich > > > Kodaikanal International School > > > > > > ___________________________________________ > > > 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 > > > > > > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > -- 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 Mon May 30 16:31:01 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 30 May 2011 10:31:01 -0400 Subject: [Koha-devel] Koha 3.2.x Roadmap Update Message-ID: Hi all, With the release of 3.2.10 fast approaching, there are a couple of things our attention needs to be drawn to: 1. Pending any consensus otherwise a the July 2011 IRC meeting, 3.2.10 will be the final release of the 3.2.x branch, and 3.2.x will be EOL after that point. 2. If you have bugfixes you want to go into 3.2.10, please be sure to get those into master before the string freeze date of 1 June 2011. That is two days away. I will push changes which do not affect strings up to the day before the release on 15 June 2011. 3. No bugfixes made to TT templates have been pushed to 3.2.x for obvious reasons. If you have a template change you want pushed into 3.2.x, you will have to submit a patch directly against 3.2.x and flag it with [3.2.x] in the subject line. Thanks for everyone's work in making 3.2.x the first of what we hope are many successes in timed releases! Kind Regards, Chris Nighswonger Koha 3.2.x/3.4.x Release Maintainer From conan at lugmen.org.ar Tue May 31 19:32:30 2011 From: conan at lugmen.org.ar (Fernando L. Canizo) Date: Tue, 31 May 2011 14:32:30 -0300 Subject: [Koha-devel] =?utf-8?q?SpamRe=3AHardware_requirements_and_clu?= =?utf-8?q?ster_scalability?= In-Reply-To: <4DDCC563.9000501@jns.fi> References: <4DDCC563.9000501@jns.fi> Message-ID: <20110531143230.87ea8936.conan@lugmen.org.ar> On Wed, 25 May 2011 12:01:23 +0300, Olli-Antti Kivilahti wrote: > ...We > are planning to create a consortium of minimum of a ~20 libraries, > I have been hard pressed to find answers to the hardware requirements > of Koha and Evergreen and have been instructed to ask here on > devel-list by your library managers. I cannot answer your hardware questions yet, maybe in a month. But surely by then you'll have your answer. But I can comment on this: > Could every library host their > own databases or should they be centralized? If you have data centralized then your libraries would have to share some common policies among ALL libraries. AFAIK there's no bibliographic/system separation in koha, so you cannot have a separate centralized database for your bibliographic data and individual databases for the rest of the stuff. Here (UNCuyo, Mendoza, Argentina) we're about to implement a centralized koha for ~20 libraries, but all of them share the same rules, they must obey a central organism which dictates the policies. I believe trying to centralize data from libraries which have separate rules might give you major headaches. -- Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/ GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++ From tomascohen at gmail.com Tue May 31 21:00:56 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 31 May 2011 16:00:56 -0300 Subject: [Koha-devel] Super-tiny script to check for record errors before upgrading to 3.4.x Message-ID: Hi, being back to work after a few weeks abroad is a bit difficult, but here I am. Back to koha, and back to Perl suff. We are just planning our upgrade to 3.4 and face the problem that our install base (+30 libraries/koha deploys and growing) has several enconding (and posibly other) problems carried from the initial migration from different sources and encodings. Those problems obviously arise now that we have to access all the records to remove holdings information from them, and running remove_items_from_biblioitems.pl waiting for it to fail and discover "where" it failed is not suitable for us. So... I managed to get a script to tell me which records are "problematic" in the sense koha defines problematic. I'd like some other dev to take a look at it to check it. It can be obviously beautified and improved. There's a link here so anyone can read it: http://blogs.unc.edu.ar/koha/lang/en/2011/05/31/migracion-a-3-4-surgen-problemas-con-registrosmigration-to-3-4-record-problems-arise/ Thanks in advance To+ From shirleysue at gmail.com Fri May 27 19:25:32 2011 From: shirleysue at gmail.com (Shirley Lew) Date: Fri, 27 May 2011 10:25:32 -0700 Subject: [Koha-devel] Access 2011: Registration is now open Message-ID: Registration is now open for the Access 2011 Conference, to be held October 19-22 in Vancouver, British Columbia. See http://access2011.library.ubc.ca/registration/ for more details. Some other goodies now available on the conference website include a preliminary schedule, information on the preconference event "Open Source for Library Decision Makers," information on social events, and a link to the Hyatt's room reservation form. We're also accepting suggestions for the Hackfest (http://access2011.library.ubc.ca/hackfest/). The organizing committee gratefully acknowledges the following sponsors for their kind support (in alphabetical order): GOLD: Canadiana.org, Gibson Library Connections, Serials Solutions, Simon Fraser University Library, University of British Columbia, University of Victoria SILVER: Discovery Garden, Equinox Software, OCLC Digital Collection Services BRONZE: Andornot Consulting, BC Electronic Library Network, BC Libraries Cooperative, Dell Canada, Innovative Interfaces, Microcom, Relais International, Richmond Public Library, Vancouver Community College. On behalf of the organizing committee, Shirley Shirley Lew Coordinator, Library Systems Vancouver Community College 250 West Pender, Vancouver, BC, V6B 1S9 604.443.8519 | slew at vcc.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From ymarishev at ptsecurity.ru Tue May 31 09:33:31 2011 From: ymarishev at ptsecurity.ru (Yury Marishev) Date: Tue, 31 May 2011 07:33:31 +0000 Subject: [Koha-devel] Koha Library Software Message-ID: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> Dear sirs, We have detected a vulnerabilities in Koha Library Software. Please contact us to obtain the details. Our disclosure policy is available here: http://en.securitylab.ru/lab/disclosure-policy.php Kind regards, Yuriy Marishev Security Engineer Positive Technologies Tel: +007 (495) 744-0144 Fax: +007 (495) 744-0187 ymarishev at ptsecurity.ru www.ptsecurity.com en.securitylab.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: