From M.de.Rooy at rijksmuseum.nl Wed May 2 14:10:14 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 2 May 2012 12:10:14 +0000 Subject: [Koha-devel] Bugzilla component categories Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> Hi all, Recently we discussed in the QA team to make the default QA contact empty. (Ian cleared this field for all components now [for new reports].) In the process the QA team member that starts QA on a report now, enters his name in the QA contact field. This informs reporter, patch writer, etc. that QA started and is also helpful for other QA team members in order to prevent duplication of work. My question now is: Should we do something similar with the default Assignee per component? In practice, the current default assignees will (most of the time) not be working on reports entered by someone else. Having someone in the Assignee field who is not working on that report, could be a misleading signal for an unaware Bugzilla user. If the default assignee wants to be informed on reports of that category, moving him/her to the default CC list of that component would perhaps be better? The current default assignees are (for one or more components): nengard at gmail.com henridamien at koha-fr.org gmcharlt at gmail.com oleonard at myacpl.org chris at bigballofwax.co.nz kyle.m.hall at gmail.com koha.sekjal at gmail.com frederic at tamil.fr cnighswonger at foundations.edu robin at catalyst.net.nz colin.campbell at ptfs-europe.com paul.poulain at biblibre.com wizzyrea at gmail.com Would you agree with this move? (We need of course consensus before doing so.) Would you like to be added as default CC for one or more components? Please respond. Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Wed May 2 14:25:11 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 2 May 2012 08:25:11 -0400 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> Message-ID: > Having someone in > the Assignee field who is not working on that report, could be a misleading > signal for an unaware Bugzilla user. I like being the default assignee for OPAC, browser compatibility, and template bugs, and I make every effort to try to address those bugs. What might be nice is if it was understood that if I remove myself from the bug assignment it means it's *not* something I'm going to work on. I find it difficult to track bugs based on whether I'm CC'ed because that's often not a meaningful indicator of my involvement with the bug. I'm subscribed to the bugs mailing list because I like to read new bug reports, but I'm not subscribed to any Bugzilla emails (in Bugzilla preferences) because I don't like getting duplicate notices. I'm assuming that would have to change if I wanted to know when I was automatically CC'ed on a new bug? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From M.de.Rooy at rijksmuseum.nl Wed May 2 14:36:27 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 2 May 2012 12:36:27 +0000 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra>, Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF431DA@S-MAIL-1B.rijksmuseum.intra> Thanks. Your case could be the exception proving the rule ;) Since you address such bugs, I think you should stay default assignee. ________________________________________ Van: Owen Leonard [oleonard at myacpl.org] Verzonden: woensdag 2 mei 2012 14:25 To: Marcel de Rooy Cc: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Bugzilla component categories > Having someone in > the Assignee field who is not working on that report, could be a misleading > signal for an unaware Bugzilla user. I like being the default assignee for OPAC, browser compatibility, and template bugs, and I make every effort to try to address those bugs. What might be nice is if it was understood that if I remove myself from the bug assignment it means it's *not* something I'm going to work on. I find it difficult to track bugs based on whether I'm CC'ed because that's often not a meaningful indicator of my involvement with the bug. I'm subscribed to the bugs mailing list because I like to read new bug reports, but I'm not subscribed to any Bugzilla emails (in Bugzilla preferences) because I don't like getting duplicate notices. I'm assuming that would have to change if I wanted to know when I was automatically CC'ed on a new bug? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From Katrin.Fischer at bsz-bw.de Wed May 2 15:11:04 2012 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Wed, 2 May 2012 15:11:04 +0200 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF431DA@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra>, <809BE39CD64BFD4EB9036172EBCCFA310DF431DA@S-MAIL-1B.rijksmuseum.intra> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD01F6B584@Bodensee.bsz-bw.de> Hi Marcel, +1 I was going to propose something similar at the next IRC meeting. I think our current system of default assignees does not really work (with a few exceptions) and your idea to leave the field empty will end a lot of confusion. I was also wondering how bug wranglers could be involved here. We can not 'assign' bugs to someone, but perhaps we could try to improve the bug reports so it's easier to work on them? Confirming the problem, asking questions where information is missing and add/correct information given by the bug reporter. Katrin > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Marcel de Rooy > Sent: Wednesday, May 02, 2012 2:36 PM > To: Owen Leonard > Cc: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Bugzilla component categories > > Thanks. Your case could be the exception proving the rule ;) Since you > address such bugs, I think you should stay default assignee. > ________________________________________ > Van: Owen Leonard [oleonard at myacpl.org] > Verzonden: woensdag 2 mei 2012 14:25 > To: Marcel de Rooy > Cc: koha-devel at lists.koha-community.org > Onderwerp: Re: [Koha-devel] Bugzilla component categories > > > Having someone in > > the Assignee field who is not working on that report, could be a > > misleading signal for an unaware Bugzilla user. > > I like being the default assignee for OPAC, browser compatibility, and > template bugs, and I make every effort to try to address those bugs. > What might be nice is if it was understood that if I remove myself from the > bug assignment it means it's *not* something I'm going to work on. > > I find it difficult to track bugs based on whether I'm CC'ed because that's > often not a meaningful indicator of my involvement with the bug. I'm > subscribed to the bugs mailing list because I like to read new bug reports, > but I'm not subscribed to any Bugzilla emails (in Bugzilla preferences) > because I don't like getting duplicate notices. > I'm assuming that would have to change if I wanted to know when I was > automatically CC'ed on a new bug? > > -- 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/ > From cnighswonger at foundations.edu Wed May 2 15:44:35 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 2 May 2012 09:44:35 -0400 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> Message-ID: On Wed, May 2, 2012 at 8:10 AM, Marcel de Rooy wrote: > > My question now is: Should we do something similar with the default > Assignee per component? In practice, the current default assignees will > (most of the time) not be working on reports entered by someone else. > Having someone in the Assignee field who is not working on that report, > could be a misleading signal for an unaware Bugzilla user. If the default > assignee wants to be informed on reports of that category, moving him/her > to the default CC list of that component would perhaps be better? > Like Owen, I try to address most label/card related bugs of which I am the default assignee. I am not convinced that blanking the default assignee would result in much good. Probably a better move would be to encourage developers who decide to work on a bug to do two things: 1. Click the "take" link next to the assignee field. 2. Set the status to "Assigned." Probably any current confusion is due to one of two things: 1. Bugs currently being worked on, but the developer doing the work has failed to do the two things mentioned above. 2. Lack of understanding on the "unaware Bugzilla user's" part which is better remedied by becoming "aware" of how bugzilla works rather than trying to build a better mouse trap. If things were really this difficult, I suspect that Bugzilla would be swamped with enhancement requests or out of business, one. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From lrea at nekls.org Wed May 2 16:11:01 2012 From: lrea at nekls.org (Liz Rea) Date: Wed, 2 May 2012 09:11:01 -0500 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> Message-ID: <6F738E50-ADEA-418A-88C2-5D8D02DDC1D7@nekls.org> I'll keep my default assignment for Website issues. :) Liz Rea lrea at nekls.org On May 2, 2012, at 7:10 AM, Marcel de Rooy wrote: > Hi all, > > Recently we discussed in the QA team to make the default QA contact empty. (Ian cleared this field for all components now [for new reports].) In the process the QA team member that starts QA on a report now, enters his name in the QA contact field. This informs reporter, patch writer, etc. that QA started and is also helpful for other QA team members in order to prevent duplication of work. > > My question now is: Should we do something similar with the default Assignee per component? In practice, the current default assignees will (most of the time) not be working on reports entered by someone else. Having someone in the Assignee field who is not working on that report, could be a misleading signal for an unaware Bugzilla user. If the default assignee wants to be informed on reports of that category, moving him/her to the default CC list of that component would perhaps be better? > > The current default assignees are (for one or more components): > nengard at gmail.com > henridamien at koha-fr.org > gmcharlt at gmail.com > oleonard at myacpl.org > chris at bigballofwax.co.nz > kyle.m.hall at gmail.com > koha.sekjal at gmail.com > frederic at tamil.fr > cnighswonger at foundations.edu > robin at catalyst.net.nz > colin.campbell at ptfs-europe.com > paul.poulain at biblibre.com > wizzyrea at gmail.com > Would you agree with this move? (We need of course consensus before doing so.) > Would you like to be added as default CC for one or more components? > Please respond. > Thanks, > > Marcel > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: email_signature.jpeg Type: image/jpeg Size: 4862 bytes Desc: not available URL: From Katrin.Fischer at bsz-bw.de Wed May 2 16:51:52 2012 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Wed, 2 May 2012 16:51:52 +0200 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD01F6B5CF@Bodensee.bsz-bw.de> Perhaps the answer is to blank only those modules, where the default assignee does not say he/she wants to keep it? This way we will start again from a clean state and can add new module maintainers later on if someone volunteers. Katrin From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Chris Nighswonger Sent: Wednesday, May 02, 2012 3:45 PM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Bugzilla component categories On Wed, May 2, 2012 at 8:10 AM, Marcel de Rooy wrote: My question now is: Should we do something similar with the default Assignee per component? In practice, the current default assignees will (most of the time) not be working on reports entered by someone else. Having someone in the Assignee field who is not working on that report, could be a misleading signal for an unaware Bugzilla user. If the default assignee wants to be informed on reports of that category, moving him/her to the default CC list of that component would perhaps be better? Like Owen, I try to address most label/card related bugs of which I am the default assignee. I am not convinced that blanking the default assignee would result in much good. Probably a better move would be to encourage developers who decide to work on a bug to do two things: 1. Click the "take" link next to the assignee field. 2. Set the status to "Assigned." Probably any current confusion is due to one of two things: 1. Bugs currently being worked on, but the developer doing the work has failed to do the two things mentioned above. 2. Lack of understanding on the "unaware Bugzilla user's" part which is better remedied by becoming "aware" of how bugzilla works rather than trying to build a better mouse trap. If things were really this difficult, I suspect that Bugzilla would be swamped with enhancement requests or out of business, one. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed May 2 16:54:24 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 2 May 2012 14:54:24 +0000 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD01F6B5CF@Bodensee.bsz-bw.de> References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> , <028B1A54D03E7B4482CDCA4EC8F06BFD01F6B5CF@Bodensee.bsz-bw.de> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF43272@S-MAIL-1B.rijksmuseum.intra> It is great that some of the default assignees already stood up for their categories! Probably we can still wait a while and then ask the other ones if they still want to remain listed as assignees or be moved to CC? ________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Fischer, Katrin [Katrin.Fischer at bsz-bw.de] Verzonden: woensdag 2 mei 2012 16:51 To: Chris Nighswonger; koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Bugzilla component categories Perhaps the answer is to blank only those modules, where the default assignee does not say he/she wants to keep it? This way we will start again from a clean state and can add new module maintainers later on if someone volunteers. Katrin From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Chris Nighswonger Sent: Wednesday, May 02, 2012 3:45 PM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Bugzilla component categories On Wed, May 2, 2012 at 8:10 AM, Marcel de Rooy > wrote: My question now is: Should we do something similar with the default Assignee per component? In practice, the current default assignees will (most of the time) not be working on reports entered by someone else. Having someone in the Assignee field who is not working on that report, could be a misleading signal for an unaware Bugzilla user. If the default assignee wants to be informed on reports of that category, moving him/her to the default CC list of that component would perhaps be better? Like Owen, I try to address most label/card related bugs of which I am the default assignee. I am not convinced that blanking the default assignee would result in much good. Probably a better move would be to encourage developers who decide to work on a bug to do two things: 1. Click the "take" link next to the assignee field. 2. Set the status to "Assigned." Probably any current confusion is due to one of two things: 1. Bugs currently being worked on, but the developer doing the work has failed to do the two things mentioned above. 2. Lack of understanding on the "unaware Bugzilla user's" part which is better remedied by becoming "aware" of how bugzilla works rather than trying to build a better mouse trap. If things were really this difficult, I suspect that Bugzilla would be swamped with enhancement requests or out of business, one. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic at tamil.fr Wed May 2 17:01:28 2012 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Wed, 02 May 2012 17:01:28 +0200 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF43272@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> , <028B1A54D03E7B4482CDCA4EC8F06BFD01F6B5CF@Bodensee.bsz-bw.de> <809BE39CD64BFD4EB9036172EBCCFA310DF43272@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4FA14C48.2030502@tamil.fr> > Probably we can still wait a while and then ask the other ones if they > still want to remain listed as assignees or be moved to CC? For me, CC is enough. From robin at catalyst.net.nz Thu May 3 01:42:27 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 03 May 2012 11:42:27 +1200 Subject: [Koha-devel] Bugzilla component categories In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310DF421C1@S-MAIL-1B.rijksmuseum.intra> Message-ID: <1336002147.2166.100.camel@zarathud> Marcel de Rooy schreef op wo 02-05-2012 om 12:10 [+0000]: > If the default assignee wants to be informed on reports of that > category, moving him/her to the default CC list of that component > would perhaps be better? I'd like to remain on the packages. It doesn't bother me whether it's CC or default assignee, but seeing them would be useful. -- 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 M.de.Rooy at rijksmuseum.nl Thu May 3 09:52:18 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 3 May 2012 07:52:18 +0000 Subject: [Koha-devel] Bug 5572 (refinements to function merge sub merge in C4::AuthoritiesMarc) Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF43746@S-MAIL-1B.rijksmuseum.intra> Hi, This patch from Janusz Kaczmarek dates from Jan 3, 2011 already. And still needs signoff. I have marked it as In Discussion now, hoping for some feedback from you. Please have a look at the report and patch. Do you agree that subfields at the biblio side should be cleared for an active empty authority subfield? Or could that result in unexpected data loss too easily? What is your opinion? Other QA team members are also welcome to respond. Thanks for doing so, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Thu May 3 13:35:58 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Thu, 3 May 2012 07:35:58 -0400 Subject: [Koha-devel] Bug 5572 (refinements to function merge sub merge in C4::AuthoritiesMarc) In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF43746@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310DF43746@S-MAIL-1B.rijksmuseum.intra> Message-ID: Marcel, Please have a look at the report and patch.**** > > Do you agree that subfields at the biblio side should be cleared for an > active empty authority subfield? Or could that result in unexpected data > loss too easily? > I am very uncomfortable with this patch. Relator terms (subfield $e) should not be filled in in MARC21 authorities, but should be used in controlled headings in bibliographic records. I commented on the bug to this effect, but Janusz hasn't had a chance to respond yet. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire.hernandez at biblibre.com Thu May 3 14:16:28 2012 From: claire.hernandez at biblibre.com (Claire Hernandez) Date: Thu, 03 May 2012 14:16:28 +0200 Subject: [Koha-devel] Solr demo - current BibLibre solr and stetienne devs (updated) Message-ID: <4FA2771C.5070602@biblibre.com> Hi all, I updated the solr-demo install. We provided it for kohacon11 demo but it seems it could be usefull sometimes. This is the current stetienne version (solr devs + acquisitions and serials you can find here with "STE" library code https://docs.google.com/a/biblibre.com/spreadsheet/ccc?key=0AuZF5Y_c4pIxdHE3S0RXMjJqSzZ3d1BVUmxpRnRVUUE#gid=0 ) Professional interface is here: http://solr-demo.biblibre.com There is a "demo" account, you could see for example the current admin interface for indexes preferences http://solr-demo.biblibre.com/cgi-bin/koha/solr/indexes.pl We are re-doing work for the future abstract layer. I will setup a new install to show what we have. Stay tuned :) Claire; (other close subject: you can see the progress for april month for rebase work at BibLibre: https://docs.google.com/a/biblibre.com/spreadsheet/ccc?key=0AuZF5Y_c4pIxdHE3S0RXMjJqSzZ3d1BVUmxpRnRVUUE#gid=11) -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire.hernandez at biblibre.com Thu May 3 15:34:15 2012 From: claire.hernandez at biblibre.com (Claire Hernandez) Date: Thu, 03 May 2012 15:34:15 +0200 Subject: [Koha-devel] [Koha] Solr demo - current BibLibre solr and stetienne devs (updated) In-Reply-To: <4FA2771C.5070602@biblibre.com> References: <4FA2771C.5070602@biblibre.com> Message-ID: <4FA28957.2090707@biblibre.com> The opac url is here: http://catalogue.solr-demo.biblibre.com/ Type *:* in search input to find all biblios! Claire; On 03/05/2012 14:16, Claire Hernandez wrote: > Hi all, > > I updated the solr-demo install. We provided it for kohacon11 demo but > it seems it could be usefull sometimes. > > This is the current stetienne version (solr devs + acquisitions and > serials you can find here with "STE" library code > https://docs.google.com/a/biblibre.com/spreadsheet/ccc?key=0AuZF5Y_c4pIxdHE3S0RXMjJqSzZ3d1BVUmxpRnRVUUE#gid=0 > ) > > Professional interface is here: http://solr-demo.biblibre.com > > There is a "demo" account, you could see for example the current admin > interface for indexes preferences > http://solr-demo.biblibre.com/cgi-bin/koha/solr/indexes.pl > > We are re-doing work for the future abstract layer. I will setup a new > install to show what we have. Stay tuned :) > > Claire; > > (other close subject: you can see the progress for april month for > rebase work at BibLibre: > https://docs.google.com/a/biblibre.com/spreadsheet/ccc?key=0AuZF5Y_c4pIxdHE3S0RXMjJqSzZ3d1BVUmxpRnRVUUE#gid=11) > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha From psm_vu at india.com Fri May 4 13:09:10 2012 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Fri, 4 May 2012 11:09:10 +0000 (UTC) Subject: [Koha-devel] Guided report in Koha 3.8.0 Message-ID: <2118979126.1570.1336129750881.JavaMail.tomcat@be08> An HTML attachment was scrubbed... URL: From dpavlin at rot13.org Fri May 4 14:06:16 2012 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Fri, 4 May 2012 14:06:16 +0200 Subject: [Koha-devel] Feedback from staff with plack? In-Reply-To: <4FA3ACEC.2030200@biblibre.com> References: <4FA3ACEC.2030200@biblibre.com> Message-ID: <20120504120616.GB4121@rot13.org> On Fri, May 04, 2012 at 12:18:20PM +0200, Paul Poulain wrote: > Hi Dobrica, > > You said during the hackfest that you wanted to plackify staff interface > after the hackfest. Did you make it ? Do you have some feedback to give > to us ? With all patches from hackfest and aftewards, staff interface works quite well. To be honest, I used plack for all my development ever since with great success :-) Just this week I found small problem with Z39.50 copy cataloguing which mungles encodig. This is somewhat important beacuse we are in persistant enviroment and once encoding gets corrupted it stays this way. I will investigate this more and submit approriate bug. I still haven't put plack staff interface in production at our library, but I do intend to do it before KohaCon 2012 so I can report my expiriences. > Thanks for this feedback ! Sorry for silence, I was quite busy lately. -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From julian.maurice at biblibre.com Fri May 4 16:38:43 2012 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 04 May 2012 16:38:43 +0200 Subject: [Koha-devel] MARC::Record, record length and leader In-Reply-To: <4F85357B.2090207@biblibre.com> References: <4F8441B6.9010502@biblibre.com> <4F844C2F.3060806@biblibre.com> <4F85357B.2090207@biblibre.com> Message-ID: <4FA3E9F3.8070803@biblibre.com> Le 11/04/2012 09:40, Julian Maurice a ?crit : > It's not really about ISO-2709 format (afaik, MARCXML has the same > problem, leader must be 24 characters long), it's about MARC. And we are > using it internally through MARC::Record. > As we already have invalid MARC records (ie. longer than 99999 bytes), > and we want to keep the records as is, I think we should at least have a > well-formed (but invalid) leader with first five characters being > '99999', since sixth character will never be read to get the record > length anyway. > What do you think? In order to close this discussion, I created a ticket on rt.cpan.org (https://rt.cpan.org/Public/Bug/Display.html?id=76990) and attached a patch to force record length to not be greater than 99999 in the leader. -- Julian Maurice BibLibre From trmurakami at gmail.com Mon May 7 16:55:30 2012 From: trmurakami at gmail.com (Tiago Murakami) Date: Mon, 7 May 2012 11:55:30 -0300 Subject: [Koha-devel] Brasilian portuguese is near complete Message-ID: Hi, The translation of version 3.8 is near complete.?I would be happy?if you could?cite my?name and that of?Rafael?Saad?in?about?Koha. Thanks. -- Tiago Murakami Librarian Biblioteca P?blica Municipal Manuel Bandeira S?o Bernardo do Campo - S?o Paulo - Brasil From gmc at esilibrary.com Mon May 7 17:30:03 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Mon, 7 May 2012 11:30:03 -0400 Subject: [Koha-devel] MARC::Record, record length and leader In-Reply-To: <4FA3E9F3.8070803@biblibre.com> References: <4F8441B6.9010502@biblibre.com> <4F844C2F.3060806@biblibre.com> <4F85357B.2090207@biblibre.com> <4FA3E9F3.8070803@biblibre.com> Message-ID: Hi, On May 4, 2012, at 10:38 AM, Julian Maurice wrote: > In order to close this discussion, I created a ticket on rt.cpan.org (https://rt.cpan.org/Public/Bug/Display.html?id=76990) and attached a patch to force record length to not be greater than 99999 in the leader. This would have the effect of having MARC::Record output invalid records that we *know* are invalid. There's no way around it -- an ISO2709 blob can be no longer than 99999 octets, and a strict parser (a couple of which do exist in the wild) would drop records where the Leader/05 does not match the length of the record as determined by the location of the record terminator character. I'm much more inclined to accept a patch to MARC::Record that introduces a more forgiving input parsing mode. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From paul.poulain at biblibre.com Mon May 7 21:56:00 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 07 May 2012 21:56:00 +0200 Subject: [Koha-devel] rel_3_10 version created on bugzilla / usage of rel_3_8 changed Message-ID: <4FA828D0.2040206@biblibre.com> Hello koha-devel, As Koha 3.8 is now released, I've created rel_3_10 that I'll use for all enhancements I'll push for next major release. 3.10 is "reserved use" for the Release Manager, don't use it please. If you find a bug in "master", use "master" version. If you find a bug in a stable version, use the "version" you're running. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From jcamins at cpbibliography.com Tue May 8 18:29:15 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Tue, 8 May 2012 12:29:15 -0400 Subject: [Koha-devel] Koha 3.6 string freeze Message-ID: Greetings, international Koha community! As you may know, I was elected as Release Maintainer for the 3.6.x branch for the Koha 3.10 release cycle. Well, the time has come to do some releasing! Over the weekend I cherry-picked all candidates for inclusion in the 3.6.x into a new branch: 3.6.x-maint/testing. I encourage you to test that branch out, and try to shake out any bugs that there may be. Tomorrow I will be cherry-picking commits into the existing 3.6.x branch for the Koha 3.6.5 release. With the exception of high priority patches, only those commits that were incorporated into Master on or before April 12 will be considered for inclusion. The 3.6.x branch will then enter string freeze on May 10 at 16:00 UTC to give the translation teams time to work their magic. Koha 3.6.5 will be released on May 24. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abesottedphoenix at yahoo.com Tue May 8 19:32:29 2012 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Tue, 8 May 2012 10:32:29 -0700 (PDT) Subject: [Koha-devel] KohaCon 2013 Wiki Reminder Message-ID: <1336498349.40544.YahooMailNeo@web114719.mail.gq1.yahoo.com> Salvete! ??? A while back, a mess of folks expressed interest over the listserv in bidding for KohaCon 2013. This is great. :) What is not great is that the folks that proclaimed their love of hosting over the listserv do not match with this wiki page: http://wiki.koha-community.org/wiki/Kohacon2013 ??? So if you're earnest, please edit it, and soonish that way we can generate a proper ballot. Cheers, Brooke From chris at bigballofwax.co.nz Wed May 9 00:31:25 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 9 May 2012 10:31:25 +1200 Subject: [Koha-devel] Koha 3.6 string freeze In-Reply-To: References: Message-ID: On 9 May 2012 04:29, Jared Camins-Esakov wrote: > Greetings, international Koha community! > > As you may know, I was elected as Release Maintainer for the 3.6.x branch > for the Koha 3.10 release cycle. Well, the time has come to do some > releasing! Over the weekend I cherry-picked all candidates for inclusion in > the 3.6.x into a new branch: 3.6.x-maint/testing. I encourage you to test > that branch out, and try to shake out any bugs that there may be. Tomorrow I > will be cherry-picking commits into the existing 3.6.x branch for the Koha > 3.6.5 release. With the exception of high priority patches, only those > commits that were incorporated into Master on or before April 12 will be > considered for inclusion. The 3.6.x branch will then enter string freeze on > May 10 at 16:00 UTC to give the translation teams time to work their magic. > Koha 3.6.5 will be released on May 24. > And as Release Maintainer, I'd like to announce a string freeze for Koha 3.8.1 on the 15th of May (NZST :)) with a goal of releasing on the 22nd. Currently there are not many string changes from 3.8.0, so translating now would not be a bad thing :) Chris From julian.maurice at biblibre.com Wed May 9 09:23:58 2012 From: julian.maurice at biblibre.com (Julian Maurice) Date: Wed, 09 May 2012 09:23:58 +0200 Subject: [Koha-devel] MARC::Record, record length and leader In-Reply-To: References: <4F8441B6.9010502@biblibre.com> <4F844C2F.3060806@biblibre.com> <4F85357B.2090207@biblibre.com> <4FA3E9F3.8070803@biblibre.com> Message-ID: <4FAA1B8E.5050508@biblibre.com> Le 07/05/2012 17:30, Galen Charlton a ?crit : > Hi, Hi! > > On May 4, 2012, at 10:38 AM, Julian Maurice wrote: >> In order to close this discussion, I created a ticket on rt.cpan.org (https://rt.cpan.org/Public/Bug/Display.html?id=76990) and attached a patch to force record length to not be greater than 99999 in the leader. > > This would have the effect of having MARC::Record output invalid records that we *know* are invalid. There's no way around it -- an ISO2709 blob can be no longer than 99999 octets, and a strict parser (a couple of which do exist in the wild) would drop records where the Leader/05 does not match the length of the record as determined by the location of the record terminator character. Actually, MARC::Record will always output invalid records if they're longer than 99999 bytes. But with the patch, at least the leader is well-formed (24 chars long). > > I'm much more inclined to accept a patch to MARC::Record that introduces a more forgiving input parsing mode. > What do you mean by "a more **forgiving** input parsing mode" ? -- Julian Maurice BibLibre From paul.poulain at biblibre.com Wed May 9 10:33:10 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 09 May 2012 10:33:10 +0200 Subject: [Koha-devel] Sharing news about KohaCon12 Message-ID: <4FAA2BC6.2080608@biblibre.com> Hello koha-devel, Just to share: 6 ppl of BibLibre comes at the KohaCon. We should arrive on monday 4th and leave on tuesday, 12th. We will stay at > StayEdinburgh - West End Apartments > 11 Brandfield Street Haymarket > Edinburgh -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From samuel.desseaux at ecp.fr Wed May 9 11:41:47 2012 From: samuel.desseaux at ecp.fr (Samuel desseaux) Date: Wed, 09 May 2012 11:41:47 +0200 Subject: [Koha-devel] error while creating notices Message-ID: <4FAA3BDB.9090907@ecp.fr> Hi, Something strange: i creat my notice, my examplar and when i want to record, i've the following error Software error: Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 So, i try to understand *problem of encoding in the title tag ? Maybe but, just before, i've added a record without any problems and when i look parameters for encoding characters (mysql and apache), it's ok. *problem of version ? I use debian package (as we are in a period of tests) and my version is 3.07 I join the logs of koha, if it can help Best regards samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: koha-error.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 350 bytes Desc: not available URL: From paul.poulain at biblibre.com Wed May 9 11:59:56 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 09 May 2012 11:59:56 +0200 Subject: [Koha-devel] error while creating biblio In-Reply-To: <4FAA3BDB.9090907@ecp.fr> References: <4FAA3BDB.9090907@ecp.fr> Message-ID: <4FAA401C.1090502@biblibre.com> Hi Samuel, Just FYI = "notice" is a frenchism. In english, it's biblio The term "notice" in english means "notifications" in french (note that a lot of ppl does the mistake, you're not the first nor the last) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From samuel.desseaux at ecp.fr Wed May 9 12:06:16 2012 From: samuel.desseaux at ecp.fr (Samuel desseaux) Date: Wed, 09 May 2012 12:06:16 +0200 Subject: [Koha-devel] error while creating biblio In-Reply-To: <4FAA401C.1090502@biblibre.com> References: <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> Message-ID: <4FAA4198.5090708@ecp.fr> Le 09/05/2012 11:59, Paul Poulain a ?crit : > Hi Samuel, > > Just FYI = "notice" is a frenchism. In english, it's biblio > The term "notice" in english means "notifications" in french > > (note that a lot of ppl does the mistake, you're not the first nor the last) > > ouups, yes, i've forgotten the good translation ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 350 bytes Desc: not available URL: From samuel.desseaux at ecp.fr Wed May 9 14:24:41 2012 From: samuel.desseaux at ecp.fr (Samuel desseaux) Date: Wed, 09 May 2012 14:24:41 +0200 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <4FAA401C.1090502@biblibre.com> References: <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> Message-ID: <4FAA6209.2080704@ecp.fr> Hello, In order to illustrate my problem (i've the following error when i want to add a biblio: " Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 I join to this e-mail 2 examples of biblio which give this error Best regards samuel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bib-23.marcxml Type: text/xml Size: 2741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bib-27.marcxml Type: text/xml Size: 2778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 350 bytes Desc: not available URL: From tajoli at cilea.it Wed May 9 14:38:32 2012 From: tajoli at cilea.it (Zeno Tajoli) Date: Wed, 09 May 2012 14:38:32 +0200 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <4FAA6209.2080704@ecp.fr> References: <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> <4FAA6209.2080704@ecp.fr> Message-ID: <4FAA6548.1020401@cilea.it> Hi, Il 09/05/2012 14:24, Samuel desseaux ha scritto: > In order to illustrate my problem (i've the following error when i want > to add a biblio: " > > Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 > > I join to this e-mail 2 examples of biblio which give this error in your biblio n.23 try to not use accented chars in tag 200 subfield g Cheers Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer From fridolyn.somers at gmail.com Wed May 9 14:57:05 2012 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 9 May 2012 14:57:05 +0200 Subject: [Koha-devel] error while creating notices In-Reply-To: <4FAA3BDB.9090907@ecp.fr> References: <4FAA3BDB.9090907@ecp.fr> Message-ID: Hie, I scanned your logs. Your main problem, I think, is : addbiblio.pl: Use of uninitialized value $result in split at /usr/share/koha/lib/C4/.pm line 150 I think you defined a autocreation of authorities and that you have a problem with Zebra server for authorities. Is it runnning well for biblio ? On Wed, May 9, 2012 at 11:41 AM, Samuel desseaux wrote: > ** > Hi, > > Something strange: i creat my notice, my examplar and when i want to > record, i've the following error > > Software error: > > Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 > > > > > > > > > So, i try to understand > > *problem of encoding in the title tag ? Maybe but, just before, i've added > a record without any problems and when i look parameters for encoding > characters (mysql and apache), it's ok. > > *problem of version ? I use debian package (as we are in a period of > tests) and my version is 3.07 > > > > I join the logs of koha, if it can help > > Best regards > > samuel > > _______________________________________________ > 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 fridolyn.somers at gmail.com Marsillargues - France -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From samuel.desseaux at ecp.fr Wed May 9 15:02:34 2012 From: samuel.desseaux at ecp.fr (Samuel desseaux) Date: Wed, 09 May 2012 15:02:34 +0200 Subject: [Koha-devel] error while creating notices In-Reply-To: References: <4FAA3BDB.9090907@ecp.fr> Message-ID: <4FAA6AEA.6060105@ecp.fr> Hi! I have to look at my configuration of zebra because i've this error ./rebuild_zebra.pl -r -d -b15:00:23-09/05 zebraidx(32338) [warn] Record didn't contain match fields in (bib1,Local-number) when i do with nozebra, it works very well. Do you think autocreation of authorities is a bad idea? Le 09/05/2012 14:57, Fridolyn SOMERS a ?crit : > Hie, > > I scanned your logs. > Your main problem, I think, is : > addbiblio.pl : Use of uninitialized value $result in split at /usr/share/koha/lib/C4/.pm line 150 > > > I think you defined a autocreation of authorities and that you have a > problem with Zebra server for authorities. > > Is it runnning well for biblio ? > > On Wed, May 9, 2012 at 11:41 AM, Samuel desseaux > > wrote: > > Hi, > > Something strange: i creat my notice, my examplar and when i want > to record, i've the following error > > > Software error: > > Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 > > > > > > > > > > So, i try to understand > > *problem of encoding in the title tag ? Maybe but, just before, > i've added a record without any problems and when i look > parameters for encoding characters (mysql and apache), it's ok. > > *problem of version ? I use debian package (as we are in a period > of tests) and my version is 3.07 > > > > I join the logs of koha, if it can help > > Best regards > > samuel > > _______________________________________________ > 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 > fridolyn.somers at gmail.com > Marsillargues - France > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 350 bytes Desc: not available URL: From fridolyn.somers at gmail.com Wed May 9 16:26:57 2012 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 9 May 2012 16:26:57 +0200 Subject: [Koha-devel] error while creating notices In-Reply-To: <4FAA6AEA.6060105@ecp.fr> References: <4FAA3BDB.9090907@ecp.fr> <4FAA6AEA.6060105@ecp.fr> Message-ID: Hie, I think NoZebra is ment to disapear soon, do not use it. Autocreation of authorities should work, it is a long existing feature. Does your search page work (with Zebra) ? > Record didn't contain match fields in (bib1,Local-number) I may check that Local-number index is well configured in Zebra : in record.abs, the marc field containing the biblionumber should be indexed with Local-number. On Wed, May 9, 2012 at 3:02 PM, Samuel desseaux wrote: > ** > Hi! > > I have to look at my configuration of zebra because i've this error > > ./rebuild_zebra.pl -r -d -b15:00:23-09/05 zebraidx(32338) [warn] Record > didn't contain match fields in (bib1,Local-number) > > when i do with nozebra, it works very well. > > Do you think autocreation of authorities is a bad idea? > > > > > > Le 09/05/2012 14:57, Fridolyn SOMERS a ?crit : > > Hie, > > I scanned your logs. > Your main problem, I think, is : > > addbiblio.pl: Use of uninitialized value $result in split at /usr/share/koha/lib/C4/.pm line 150 > > > > I think you defined a autocreation of authorities and that you have a > problem with Zebra server for authorities. > > Is it runnning well for biblio ? > > On Wed, May 9, 2012 at 11:41 AM, Samuel desseaux wrote: > >> Hi, >> >> Something strange: i creat my notice, my examplar and when i want to >> record, i've the following error >> >> Software error: >> >> Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2919 >> >> >> >> >> >> >> >> >> >> So, i try to understand >> >> *problem of encoding in the title tag ? Maybe but, just before, i've >> added a record without any problems and when i look parameters for encoding >> characters (mysql and apache), it's ok. >> >> *problem of version ? I use debian package (as we are in a period of >> tests) and my version is 3.07 >> >> >> >> I join the logs of koha, if it can help >> >> Best regards >> >> samuel >> >> _______________________________________________ >> 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 > fridolyn.somers at gmail.com > Marsillargues - France > > > > -- Fridolyn SOMERS fridolyn.somers at gmail.com Marsillargues - France -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.poulain at biblibre.com Wed May 9 16:37:40 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 09 May 2012 16:37:40 +0200 Subject: [Koha-devel] error while creating notices In-Reply-To: <4FAA6AEA.6060105@ecp.fr> References: <4FAA3BDB.9090907@ecp.fr> <4FAA6AEA.6060105@ecp.fr> Message-ID: <4FAA8134.9070400@biblibre.com> Le 09/05/2012 15:02, Samuel desseaux a ?crit : > Hi! > > I have to look at my configuration of zebra because i've this error > > ./rebuild_zebra.pl -r -d -b15:00:23-09/05 zebraidx(32338) [warn] Record > didn't contain match fields in (bib1,Local-number) this one is pretty easy (once you know...) It means the record don't have the "Local-number", that is used by zebra as identifier. There are 2 options: * the biblionumber is not in your record (quite impossible unless you've made a lot of changes to your frameworks) * your zebra configuration think it's in a field, while it is in another. Suggestion : * look at your record.abs file and search which field is supposed to be for Local-number * yaz-marcdump a record, and look in the field record.abs said. If you have nothing, look where is the Local-number hidden in your record. Update record.abs accordingly (or update your Koha, but it's easier/probably safer to update zebra config file) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.a at aandc.org Wed May 9 16:47:40 2012 From: paul.a at aandc.org (Paul) Date: Wed, 09 May 2012 10:47:40 -0400 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <4FAA6548.1020401@cilea.it> References: <4FAA6209.2080704@ecp.fr> <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> <4FAA6209.2080704@ecp.fr> Message-ID: <5.2.1.1.2.20120509104411.038ad7d8@localhost> At 02:38 PM 5/9/2012 +0200, Zeno Tajoli wrote: >Il 09/05/2012 14:24, Samuel desseaux ha scritto: > > I join to this e-mail 2 examples of biblio which give this error > >in your biblio n.23 try to not use accented chars in tag 200 subfield g Just for my own edification, what is "tag 200" in Marc21? (from the attached biblios, the record appears to be based on www.loc.gov/MARC21/slim which does not contain a 200.) Thanks - Paul From jcamins at cpbibliography.com Wed May 9 16:51:11 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 9 May 2012 10:51:11 -0400 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <5.2.1.1.2.20120509104411.038ad7d8@localhost> References: <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> <4FAA6209.2080704@ecp.fr> <4FAA6548.1020401@cilea.it> <5.2.1.1.2.20120509104411.038ad7d8@localhost> Message-ID: Paul, On Wed, May 9, 2012 at 10:47 AM, Paul wrote: > At 02:38 PM 5/9/2012 +0200, Zeno Tajoli wrote: > >> Il 09/05/2012 14:24, Samuel desseaux ha scritto: >> > I join to this e-mail 2 examples of biblio which give this error >> >> in your biblio n.23 try to not use accented chars in tag 200 subfield g >> > > Just for my own edification, what is "tag 200" in Marc21? (from the > attached biblios, the record appears to be based on > www.loc.gov/MARC21/slim which does not contain a 200.) > The record is question is in UNIMARC, not MARC21. You can see the UNIMARC standard at http://www.ifla.org/en/publications/unimarc-formats-and-related-documentation Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed May 9 16:51:45 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 09 May 2012 16:51:45 +0200 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <5.2.1.1.2.20120509104411.038ad7d8@localhost> References: <4FAA6209.2080704@ecp.fr> <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> <4FAA6209.2080704@ecp.fr> <5.2.1.1.2.20120509104411.038ad7d8@localhost> Message-ID: <4FAA8481.9050001@biblibre.com> Le 09/05/2012 16:47, Paul a ?crit : > At 02:38 PM 5/9/2012 +0200, Zeno Tajoli wrote: >> Il 09/05/2012 14:24, Samuel desseaux ha scritto: >> > I join to this e-mail 2 examples of biblio which give this error >> >> in your biblio n.23 try to not use accented chars in tag 200 subfield g > > Just for my own edification, what is "tag 200" in Marc21? (from the > attached biblios, the record appears to be based on > www.loc.gov/MARC21/slim which does not contain a 200.) It doesn't exist. But Samuel is french, and, as 99% of french libraries don't use MARC21, but UNIMARC. And in UNIMARC, 200 contains very not[*] important informations : the title and the author ! [*] (kidding) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From info at AandC.org Wed May 9 18:18:30 2012 From: info at AandC.org (Archives and Collections Society) Date: Wed, 09 May 2012 12:18:30 -0400 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <4FAA8481.9050001@biblibre.com> References: <5.2.1.1.2.20120509104411.038ad7d8@localhost> <4FAA6209.2080704@ecp.fr> <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> <4FAA6209.2080704@ecp.fr> <5.2.1.1.2.20120509104411.038ad7d8@localhost> Message-ID: <5.2.1.1.2.20120509121335.038ad7d8@localhost> At 04:51 PM 5/9/2012 +0200, Paul Poulain wrote: >Le 09/05/2012 16:47, Paul a ?crit : > > At 02:38 PM 5/9/2012 +0200, Zeno Tajoli wrote: > >> Il 09/05/2012 14:24, Samuel desseaux ha scritto: > >> > I join to this e-mail 2 examples of biblio which give this error > >> > >> in your biblio n.23 try to not use accented chars in tag 200 subfield g > > > > Just for my own edification, what is "tag 200" in Marc21? (from the > > attached biblios, the record appears to be based on > > www.loc.gov/MARC21/slim which does not contain a 200.) >It doesn't exist. >But Samuel is french, and, as 99% of french libraries don't use MARC21, >but UNIMARC. >And in UNIMARC, 200 contains very not[*] important informations : the >title and the author ! Yup agreed (we have worked extensively with Isabelle Nadolny on the UNIMARC at z3950.bnf.fr) but I was querying whether the xml record header referencing specifically MARC21/slim could be a source of problems. Amiti?s [l'autre] Paul From paul.a at aandc.org Wed May 9 18:43:20 2012 From: paul.a at aandc.org (Paul) Date: Wed, 09 May 2012 12:43:20 -0400 Subject: [Koha-devel] error while creating biblio(part 2) Message-ID: <5.2.1.1.2.20120509124304.047e97f8@localhost> At 04:51 PM 5/9/2012 +0200, Paul Poulain wrote: >Le 09/05/2012 16:47, Paul a ?crit : > > At 02:38 PM 5/9/2012 +0200, Zeno Tajoli wrote: > >> Il 09/05/2012 14:24, Samuel desseaux ha scritto: > >> > I join to this e-mail 2 examples of biblio which give this error > >> > >> in your biblio n.23 try to not use accented chars in tag 200 subfield g > > > > Just for my own edification, what is "tag 200" in Marc21? (from the > > attached biblios, the record appears to be based on > > www.loc.gov/MARC21/slim which does not contain a 200.) >It doesn't exist. >But Samuel is french, and, as 99% of french libraries don't use MARC21, >but UNIMARC. >And in UNIMARC, 200 contains very not[*] important informations : the >title and the author ! Yup agreed (we have worked extensively with Isabelle Nadolny on the UNIMARC at z3950.bnf.fr) but I was querying whether the xml record header referencing specifically MARC21/slim could be a source of problems. Amiti?s [l'autre] Paul _______________________________________________ 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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. , and From mdhafen at tech.washk12.org Wed May 9 18:55:30 2012 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Wed, 9 May 2012 10:55:30 -0600 Subject: [Koha-devel] MARC::Record, record length and leader In-Reply-To: <4FAA1B8E.5050508@biblibre.com> References: <4F8441B6.9010502@biblibre.com> <4F844C2F.3060806@biblibre.com> <4F85357B.2090207@biblibre.com> <4FA3E9F3.8070803@biblibre.com> <4FAA1B8E.5050508@biblibre.com> Message-ID: I think there is not a more forgiving parser. The ISO2709 spec breaks when a record reaches 100000 octets. I don't see any way around that in the parser. The best solution I can come up with, if you want to hold to the spec, is to create a seperate ISO2709 blob with a logical link to the first when a record reaches 100000 octets. I don't know if that could be implemented in the parser though. I think that any other way will result in either a broken record or a broken parser. On Wed, May 9, 2012 at 1:23 AM, Julian Maurice wrote: > Le 07/05/2012 17:30, Galen Charlton a ?crit : > >> Hi, >> > > Hi! > > > >> On May 4, 2012, at 10:38 AM, Julian Maurice wrote: >> >>> In order to close this discussion, I created a ticket on rt.cpan.org ( >>> https://rt.cpan.org/Public/**Bug/Display.html?id=76990) >>> and attached a patch to force record length to not be greater than 99999 in >>> the leader. >>> >> >> This would have the effect of having MARC::Record output invalid records >> that we *know* are invalid. There's no way around it -- an ISO2709 blob >> can be no longer than 99999 octets, and a strict parser (a couple of which >> do exist in the wild) would drop records where the Leader/05 does not match >> the length of the record as determined by the location of the record >> terminator character. >> > > Actually, MARC::Record will always output invalid records if they're > longer than 99999 bytes. But with the patch, at least the leader is > well-formed (24 chars long). > > > >> I'm much more inclined to accept a patch to MARC::Record that introduces >> a more forgiving input parsing mode. >> >> > What do you mean by "a more **forgiving** input parsing mode" ? > > > -- > Julian Maurice > BibLibre > ______________________________**_________________ > Koha-devel mailing list > Koha-devel at lists.koha-**community.org > http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.**org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From koha.sekjal at gmail.com Thu May 10 02:47:33 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Wed, 9 May 2012 20:47:33 -0400 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: References: Message-ID: RFC up on the wiki: http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC It's pretty rough... I got about 2 hours of it written yesterday, then my IP changed and I lost all my text when trying to submit. This rewrite is simplified, with the hopes of expanding further later. Another element I'm not sure how best to factor in: language. Especially for HTML blocks, it'd be handy to have a way to provide multiple options depending on the user's language. This isn't universally applicable to all preferences, only text-based values... thoughts? -Ian On Thu, Mar 22, 2012 at 3:46 PM, Ian Walls wrote: > Chris, > > > I'm seeing the Contextual Preferences Engine (CPE) as a replacement to the > issuingrules and related tables, first and foremost. It would be put in > place, then be migrated into slowly over time by developers, since > switching the subroutine calls from issuingrules and sysprefs to the CPE > would be a good level change in a lot of different places. Users would not > be able to contextualize a syspref on their own from the staff client; it > would need to be a separate enhancement. The CPE just provides a unified > platform for the developers to work with, making adding new > context-sensitive behaviours easier to code. > > One major bonus is that each rule is granular and independent of other > rules. Instead of having to maintain a huge circ matrix of rules and > exceptions and exceptions to exceptions, you define you base case, then the > few things that are different can be made different. The tester page will > let you quickly confirm which rules you'll be getting in any given > situation, so if there is any unexpected behaviour, you can trace it out. > > Rough implementation plan: > > Create new table in DB > Create interface to manipulate values in table (get basics of templates > and subroutines in place) > Create interface to test which rules are applied to any given combo of > Branch, Patron and Itemtype > > --- Up to here can be done behind the scenes without changing any other > part of Koha --- > > Migrate over issuing rules > Spruce up interface now that there is data > Begin changing Circ subroutines to use CPE instead of smart rules > Migrate over some sysprefs that need further contextualization (see bug > for some that have been identified) > > --- much later --- > > Drop the smart rules pages and database tables once the migration is > complete and stable. > > > > The first section could be completed by June very easily; that'd give us > the CPE framework to work in, and it'd just be a matter of changing system > calls to use it instead of whatever they're currently using. If that code > is committed to master, then your need for per-branch SCO settings could be > handled quickly before August. It would still need to wait until the next > release in October before it's part of stable, but so would any kind of > change like this. > > I hope this makes sense. As I said, any assistance, either in design, > implementation or both, is welcome. I've been meaning to do this for a > long while, but other things (like testing Hourly Loans) have taken > priority recently. I'd love to have this in place for 3.10, to some degree > or another. > > Cheers, > > > -Ian > > > On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger < > cnighswonger at foundations.edu> wrote: > >> Hi Ian, >> >> On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls wrote: >> >>> Chris, >>> >>> >>> I've been meaning to write a Contextual Preferences Engine for Koha for >>> a while now, to solve the problems we have with the Circ Matrix, as well as >>> with global sysprefs that should really be more configurable. >>> >>> The idea is that it will be a DB table with 5 main columns: Branch, >>> Patron Category, Item Type, Key and Value. Any of the first 3 can be a >>> specific value or "default". If a contextual preference doesn't make sense >>> to factor in one of the 3 values, it'll be ignored. >>> >>> >> Is the goal is to allow any or a defined set of system preferences to be >> "contextualized" based on branch, patron category, and/or item type? >> >> >>> This, along with a rewritten editor and rules tester tool, would solve a >>> bunch of our customizability problems in one go, without necessarily >>> introducing too much complexity for users (provided we make a good >>> interface). >>> >>> >> Agreed. >> >> >>> I hope to have a patch for this started after 3.8 releases (and all our >>> DB revs are stable for a while). Any help would be welcomed. >>> >> >> Sounds good. I need this functionality to be in place by August of this >> year, so I'm very interested in getting started as soon as possible. I will >> be carving out time during my workday for it over the next several months. >> >> Kind Regards, >> Chris >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Thu May 10 06:16:14 2012 From: mtj at kohaaloha.com (Mason James) Date: Thu, 10 May 2012 16:16:14 +1200 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: References: Message-ID: hi All i've just noticed all 3.6 (and 3.8) manuals are missing, here... http://download.koha-community.org/manual_pdf/ is there anything i can do to help fix this issue? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From paul.poulain at biblibre.com Thu May 10 09:15:07 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 10 May 2012 09:15:07 +0200 Subject: [Koha-devel] error while creating biblio(part 2) In-Reply-To: <5.2.1.1.2.20120509121335.038ad7d8@localhost> References: <5.2.1.1.2.20120509104411.038ad7d8@localhost> <4FAA6209.2080704@ecp.fr> <4FAA3BDB.9090907@ecp.fr> <4FAA401C.1090502@biblibre.com> <4FAA6209.2080704@ecp.fr> <5.2.1.1.2.20120509104411.038ad7d8@localhost> <5.2.1.1.2.20120509121335.038ad7d8@localhost> Message-ID: <4FAB6AFB.90901@biblibre.com> Le 09/05/2012 18:18, Archives and Collections Society a ?crit : > Yup agreed (we have worked extensively with Isabelle Nadolny on the > UNIMARC at z3950.bnf.fr) but I was querying whether the xml record > header referencing specifically MARC21/slim could be a source of problems. afaik, the "marc21" header is a language abuse. It express the technical organisation of the XML file, which is exactly the same as for UNIMARC21. The semantic (MARC21 or UNIMARC content) is not written anywhere. In MARC::Record, you have the same kind of problem. When you call ->as_usmarc(), you're saying iso2709, not to USMARC ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Thu May 10 09:18:21 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 10 May 2012 09:18:21 +0200 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: References: Message-ID: <4FAB6BBD.40108@biblibre.com> Le 10/05/2012 02:47, Ian Walls a ?crit : > RFC up on the wiki: > It's pretty rough... I got about 2 hours of it written yesterday, then > my IP changed and I lost all my text when trying to submit. do you know the Firefox extension called Lazarus ? It's pretty usefull for this kind of problem... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ruth at bywatersolutions.com Thu May 10 09:46:49 2012 From: ruth at bywatersolutions.com (Ruth Bavousett) Date: Thu, 10 May 2012 10:46:49 +0300 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: References: Message-ID: Ian, Looking at your RFC, extending this onto language-centric sysprefs for the block-HTML stuff would be pretty easy; add a column "language" to the table you propose. For things like circ rules, it would be NULL, as language is not a factor there...and for the blocks of HTML, some of your columns (like itemtype) would be NULL. +1 for this new table. *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software Headquarters: Santa Barbara, CA Office: Lawrence, KS Phone/Fax (888)900-8944 http://bywatersolutions.com ruth at bywatersolutions.com On Thu, May 10, 2012 at 3:47 AM, Ian Walls wrote: > RFC up on the wiki: > http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC > > It's pretty rough... I got about 2 hours of it written yesterday, then my > IP changed and I lost all my text when trying to submit. This rewrite is > simplified, with the hopes of expanding further later. > > Another element I'm not sure how best to factor in: language. Especially > for HTML blocks, it'd be handy to have a way to provide multiple options > depending on the user's language. This isn't universally applicable to all > preferences, only text-based values... thoughts? > > > -Ian > > On Thu, Mar 22, 2012 at 3:46 PM, Ian Walls wrote: > >> Chris, >> >> >> I'm seeing the Contextual Preferences Engine (CPE) as a replacement to >> the issuingrules and related tables, first and foremost. It would be put >> in place, then be migrated into slowly over time by developers, since >> switching the subroutine calls from issuingrules and sysprefs to the CPE >> would be a good level change in a lot of different places. Users would not >> be able to contextualize a syspref on their own from the staff client; it >> would need to be a separate enhancement. The CPE just provides a unified >> platform for the developers to work with, making adding new >> context-sensitive behaviours easier to code. >> >> One major bonus is that each rule is granular and independent of other >> rules. Instead of having to maintain a huge circ matrix of rules and >> exceptions and exceptions to exceptions, you define you base case, then the >> few things that are different can be made different. The tester page will >> let you quickly confirm which rules you'll be getting in any given >> situation, so if there is any unexpected behaviour, you can trace it out. >> >> Rough implementation plan: >> >> Create new table in DB >> Create interface to manipulate values in table (get basics of templates >> and subroutines in place) >> Create interface to test which rules are applied to any given combo of >> Branch, Patron and Itemtype >> >> --- Up to here can be done behind the scenes without changing any other >> part of Koha --- >> >> Migrate over issuing rules >> Spruce up interface now that there is data >> Begin changing Circ subroutines to use CPE instead of smart rules >> Migrate over some sysprefs that need further contextualization (see bug >> for some that have been identified) >> >> --- much later --- >> >> Drop the smart rules pages and database tables once the migration is >> complete and stable. >> >> >> >> The first section could be completed by June very easily; that'd give us >> the CPE framework to work in, and it'd just be a matter of changing system >> calls to use it instead of whatever they're currently using. If that code >> is committed to master, then your need for per-branch SCO settings could be >> handled quickly before August. It would still need to wait until the next >> release in October before it's part of stable, but so would any kind of >> change like this. >> >> I hope this makes sense. As I said, any assistance, either in design, >> implementation or both, is welcome. I've been meaning to do this for a >> long while, but other things (like testing Hourly Loans) have taken >> priority recently. I'd love to have this in place for 3.10, to some degree >> or another. >> >> Cheers, >> >> >> -Ian >> >> >> On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger < >> cnighswonger at foundations.edu> wrote: >> >>> Hi Ian, >>> >>> On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls wrote: >>> >>>> Chris, >>>> >>>> >>>> I've been meaning to write a Contextual Preferences Engine for Koha for >>>> a while now, to solve the problems we have with the Circ Matrix, as well as >>>> with global sysprefs that should really be more configurable. >>>> >>>> The idea is that it will be a DB table with 5 main columns: Branch, >>>> Patron Category, Item Type, Key and Value. Any of the first 3 can be a >>>> specific value or "default". If a contextual preference doesn't make sense >>>> to factor in one of the 3 values, it'll be ignored. >>>> >>>> >>> Is the goal is to allow any or a defined set of system preferences to be >>> "contextualized" based on branch, patron category, and/or item type? >>> >>> >>>> This, along with a rewritten editor and rules tester tool, would solve >>>> a bunch of our customizability problems in one go, without necessarily >>>> introducing too much complexity for users (provided we make a good >>>> interface). >>>> >>>> >>> Agreed. >>> >>> >>>> I hope to have a patch for this started after 3.8 releases (and all our >>>> DB revs are stable for a while). Any help would be welcomed. >>>> >>> >>> Sounds good. I need this functionality to be in place by August of this >>> year, so I'm very interested in getting started as soon as possible. I will >>> be carving out time during my workday for it over the next several months. >>> >>> Kind Regards, >>> Chris >>> >> >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.desseaux at ecp.fr Thu May 10 10:43:27 2012 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Thu, 10 May 2012 10:43:27 +0200 Subject: [Koha-devel] marc import/need help Message-ID: <4FAB7FAF.7020404@ecp.fr> Hello I'm trying to convert data in marc format ( a big challenge because our old ILS doesn't respect unimarc): in marc edit, when i have this error "undefined error reported, error number -99" what does it means ? I join to this mail an excel file of my data. Best regards samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: essai1.xls Type: application/octet-stream Size: 138240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 326 bytes Desc: not available URL: From nengard at gmail.com Thu May 10 13:59:47 2012 From: nengard at gmail.com (Nicole Engard) Date: Thu, 10 May 2012 07:59:47 -0400 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: References: Message-ID: There are no PDFs of the 3.6 or 3.8 manual. There were issues with the script that generated PDFs (as far as I know) and so they aren't running anymore. Nicole On Thu, May 10, 2012 at 12:16 AM, Mason James wrote: > hi All > > i've just noticed all 3.6 (and 3.8) manuals are missing, here... > ?http://download.koha-community.org/manual_pdf/ > > is there anything i can do to help fix this issue? > > > _______________________________________________ > 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 nengard at gmail.com Thu May 10 14:00:50 2012 From: nengard at gmail.com (Nicole Engard) Date: Thu, 10 May 2012 08:00:50 -0400 Subject: [Koha-devel] marc import/need help In-Reply-To: <4FAB7FAF.7020404@ecp.fr> References: <4FAB7FAF.7020404@ecp.fr> Message-ID: This might help: http://manual.koha-community.org/3.6/en/marceditexcel.html Nicole On Thu, May 10, 2012 at 4:43 AM, Samuel Desseaux wrote: > Hello > > > I'm trying to convert data in marc format ( a big challenge because our ?old > ILS doesn't respect unimarc): in marc edit, when i have this error > "undefined error reported, error number -99" what does it means ? > > I join to this mail an excel file of my data. > > Best regards > > samuel > > _______________________________________________ > 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 10 14:15:53 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 10 May 2012 14:15:53 +0200 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: References: Message-ID: <4FABB179.3060500@biblibre.com> Le 10/05/2012 02:47, Ian Walls a ?crit : > RFC up on the wiki: > http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC A question: do we really need a new table ? I think that the systempreference table can be extended with those columns, with a rule saying "branchcode/categorycode/itemtype = empty => default value" For example: variable | branchcode | value LibraryName | | "Welcome to the union catalog" LibraryName |BRANCH1| "Welcome to branch 1, a library of the union catalog" The C4::Context->preference("LibraryName") would then be: SELECT * FROM systempreference WHERE variable="LibraryName" and branchcode=? if (fetchrow is empty) { return the result of SELECT * FROM systempreference WHERE variable="LibraryName" and branchcode IS NULL } -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From psm_vu at india.com Thu May 10 16:15:25 2012 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Thu, 10 May 2012 14:15:25 +0000 (UTC) Subject: [Koha-devel] Guided report in Koha 3.8.0 Message-ID: <690095148.4097.1336659325263.JavaMail.tomcat@be01> An HTML attachment was scrubbed... URL: From koha.sekjal at gmail.com Thu May 10 17:04:58 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Thu, 10 May 2012 11:04:58 -0400 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: <4FABB179.3060500@biblibre.com> References: <4FABB179.3060500@biblibre.com> Message-ID: Paul, Creating a new table allows us to develop this in parallel and commit progress incrementally without risking damage to the existing system (until we're ready to do the swapover, that is). It also forces us to review the subroutines that access this table, and make them clean in the Koha namespace. I think building new would be better here than modifying what we already have, since C4::Circulation is already pretty messy. Cheers, -Ian On Thu, May 10, 2012 at 8:15 AM, Paul Poulain wrote: > Le 10/05/2012 02:47, Ian Walls a ?crit : > > RFC up on the wiki: > > http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC > A question: do we really need a new table ? > I think that the systempreference table can be extended with those > columns, with a rule saying "branchcode/categorycode/itemtype = empty => > default value" > > For example: > variable | branchcode | value > LibraryName | | "Welcome to the union catalog" > LibraryName |BRANCH1| "Welcome to branch 1, a library of the union catalog" > > The C4::Context->preference("LibraryName") would then be: > > SELECT * FROM systempreference WHERE variable="LibraryName" and > branchcode=? > if (fetchrow is empty) { > return the result of SELECT * FROM systempreference WHERE > variable="LibraryName" and branchcode IS NULL > } > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu May 10 17:53:51 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 10 May 2012 17:53:51 +0200 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: References: <4FABB179.3060500@biblibre.com> Message-ID: <4FABE48F.80702@biblibre.com> Le 10/05/2012 17:04, Ian Walls a ?crit : > Paul, > > > Creating a new table allows us to develop this in parallel and commit > progress incrementally without risking damage to the existing system > (until we're ready to do the swapover, that is). does the new table REPLACE the systempreference one or is it added ? (If it's a replacement, then I'm OK) > It also forces us to > review the subroutines that access this table, and make them clean in > the Koha namespace. I think building new would be better here than > modifying what we already have, since C4::Circulation is already pretty > messy. Unless i'm missing something, the accessor to preferences is centralized in C4::Context, and I don't see the relation to C4::Circulation. I agree that the switch to Koha namespace is a valid reason, but we must plan & define it clearly & with as many details as possible. Probably a topic for the hackfest next month... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From koha.sekjal at gmail.com Thu May 10 18:05:23 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Thu, 10 May 2012 12:05:23 -0400 Subject: [Koha-devel] Branch Specific System Preferences In-Reply-To: <4FABE48F.80702@biblibre.com> References: <4FABB179.3060500@biblibre.com> <4FABE48F.80702@biblibre.com> Message-ID: This table could, theoretically, completely replace systempreferences. I'm not sure that's the best idea... but I can't really say why. If something should truly be global, then it could just be NULL/NULL/NULL for the context. We're going to be supplying context-sensitive keys in the each time we call, anyway, so we just won't for global things, or we won't supply itemtype for things that are univeral for item type, etc. I think that it should, however, completely replace issuingrules, and that's where I'm thinking most of the C4/Circulation changes would come in. -Ian On Thu, May 10, 2012 at 11:53 AM, Paul Poulain wrote: > Le 10/05/2012 17:04, Ian Walls a ?crit : > > Paul, > > > > > > Creating a new table allows us to develop this in parallel and commit > > progress incrementally without risking damage to the existing system > > (until we're ready to do the swapover, that is). > does the new table REPLACE the systempreference one or is it added ? > (If it's a replacement, then I'm OK) > > > It also forces us to > > review the subroutines that access this table, and make them clean in > > the Koha namespace. I think building new would be better here than > > modifying what we already have, since C4::Circulation is already pretty > > messy. > > Unless i'm missing something, the accessor to preferences is centralized > in C4::Context, and I don't see the relation to C4::Circulation. > > I agree that the switch to Koha namespace is a valid reason, but we must > plan & define it clearly & with as many details as possible. Probably a > topic for the hackfest next month... > > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Thu May 10 18:09:51 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Thu, 10 May 2012 12:09:51 -0400 Subject: [Koha-devel] Koha 3.6 string freeze In-Reply-To: References: Message-ID: Greetings, international Koha community! As promised, Koha 3.6.5 entered string freeze 8 minutes ago, at 16:00 UTC. Thank you in advance to the Koha translation team, and all their hard work. Koha 3.6.5 will be released on May 24. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arslanone at gmail.com Thu May 10 19:25:09 2012 From: arslanone at gmail.com (Arslan Farooq) Date: Thu, 10 May 2012 22:25:09 +0500 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals Message-ID: Hi Nicole Can we have the option to download the whole manual (HTML files) as an archive? That will allow us to download the whole thing and memorize it offline (say, when electricity is out). You may set up a script that periodically deletes the zip and creates a new one (so that the zip is always latest). -- arslan > ---------- Forwarded message ---------- > From:?Nicole Engard > To:?Mason James > Cc:?koha-devel at lists.koha-community.org > Date:?Thu, 10 May 2012 07:59:47 -0400 > Subject:?Re: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals > There are no PDFs of the 3.6 or 3.8 manual. There were issues with the > script that generated PDFs (as far as I know) and so they aren't > running anymore. > > Nicole From nengard at gmail.com Thu May 10 19:39:18 2012 From: nengard at gmail.com (Nicole Engard) Date: Thu, 10 May 2012 13:39:18 -0400 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: References: Message-ID: I don't manage the scripts that turn the XML that I write in to HTML or PDF. I'm not sure what those scripts can do. Nicole On Thu, May 10, 2012 at 1:25 PM, Arslan Farooq wrote: > Hi Nicole > > Can we have the option to download the whole manual (HTML files) as an > archive? That will allow us to download the whole thing and memorize > it offline (say, when electricity is out). > > You may set up a script that periodically deletes the zip and creates > a new one (so that the zip is always latest). > > -- arslan > >> ---------- Forwarded message ---------- >> From:?Nicole Engard >> To:?Mason James >> Cc:?koha-devel at lists.koha-community.org >> Date:?Thu, 10 May 2012 07:59:47 -0400 >> Subject:?Re: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals > >> There are no PDFs of the 3.6 or 3.8 manual. There were issues with the >> script that generated PDFs (as far as I know) and so they aren't >> running anymore. >> >> Nicole From cnighswonger at foundations.edu Thu May 10 21:43:14 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 May 2012 15:43:14 -0400 Subject: [Koha-devel] Multi-branch SCO [Was: Re: Branch Specific System Preferences] Message-ID: Hi David, On Thu, May 10, 2012 at 12:38 PM, David Schuster wrote: > I'm a little confused by this comment. We do self checkout - but have a > generic user for each branch that they use to login the SCO module. It > then checks out books as if they are at that branch. What part of that > doesn't work? I'm a little confused... > > I'm not sure what version you're using, but in the current master the following sysprefs define the user for the SCO module: AutoSelfCheckAllowed AutoSelfCheckID AutoSelfCheckPass Unfortunately there is only room there for a single user tied to a single branch. This results (for us at least) in all books checked out in the SCO module appearing under the branch of the user listed in these sysprefs. If there is workaround, I'd love to know it while we are in the process of making the SCO module truly multi-branch. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu May 10 22:02:20 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 May 2012 16:02:20 -0400 Subject: [Koha-devel] Multi-branch SCO [Was: Re: Branch Specific System Preferences] In-Reply-To: References: Message-ID: On Thu, May 10, 2012 at 3:54 PM, David Schuster wrote: > OK here is how we have it setup, and I just verified it still works that > way with 3.06.04. > > AutoSelfCheckAllowd - Don't Allow > > The librarian logs into the sco using a "user" setup as lmsxxx/password - > xxx is the location > > All transactions there are associated with the user's location. > > Granted that forces you to setup 67 users and someone has to open that up, > but it has been working well for us for 4 years. > > Does that make sense? I don't want to auto login as you note somehow the > system needs to know where you are from to track stats and route books > correctly. > > This is too easy to be true.... ;-) Let me see if I understand correctly: At Branch A: 1. Log into the staff client using Branch A's SCO account. 2. Navigate to the sco interface. At Branch B: 1. Log into the staff client using Branch B's SCO account. 2. Navigate to the sco interface. Please tell me it works this way and save me lots of hours of coding... ;-) Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From koha.sekjal at gmail.com Thu May 10 22:12:33 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Thu, 10 May 2012 16:12:33 -0400 Subject: [Koha-devel] Multi-branch SCO [Was: Re: Branch Specific System Preferences] In-Reply-To: References: Message-ID: Chris, If you don't specify the SCO user in the sysprefs, you have to manually log in as that user on the workstations you are designating as SCO. This is then subject to timeout, I believe. So, if you don't mind maintaining the distinct logins on your workstations manually, you're in good shape, no new code required. It would only be a project if you wanted to enable auto-login for that set of users. -Ian On Thu, May 10, 2012 at 4:02 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > On Thu, May 10, 2012 at 3:54 PM, David Schuster wrote: > >> OK here is how we have it setup, and I just verified it still works that >> way with 3.06.04. >> >> AutoSelfCheckAllowd - Don't Allow >> >> The librarian logs into the sco using a "user" setup as lmsxxx/password >> - xxx is the location >> >> All transactions there are associated with the user's location. >> >> Granted that forces you to setup 67 users and someone has to open that >> up, but it has been working well for us for 4 years. >> >> Does that make sense? I don't want to auto login as you note somehow the >> system needs to know where you are from to track stats and route books >> correctly. >> >> > This is too easy to be true.... ;-) Let me see if I understand correctly: > > At Branch A: > > 1. Log into the staff client using Branch A's SCO account. > 2. Navigate to the sco interface. > > At Branch B: > > 1. Log into the staff client using Branch B's SCO account. > 2. Navigate to the sco interface. > > Please tell me it works this way and save me lots of hours of coding... ;-) > > Kind Regards, > Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu May 10 23:16:27 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 10 May 2012 17:16:27 -0400 Subject: [Koha-devel] Multi-branch SCO [Was: Re: Branch Specific System Preferences] In-Reply-To: References: Message-ID: On Thu, May 10, 2012 at 4:12 PM, Ian Walls wrote: > > Chris, > > > If you don't specify the SCO user in the sysprefs, you have to manually log in as that user on the workstations you are designating as SCO. This is then subject to timeout, I believe. > > So, if you don't mind maintaining the distinct logins on your workstations manually, you're in good shape, no new code required. It would only be a project if you wanted to enable auto-login for that set of users. > > 'WebBasedSelfCheckTimeout' currently sets the timeout of the SCO account. On our system we have this set to match 'timeout,' so the timeout is not an issue in our case. This actually looks like an appealing workaround to our "issue." That said, I'm still on-board for the branch-specific prefs, etc. work. Kind Regards, Chris > > > On Thu, May 10, 2012 at 4:02 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: >> >> On Thu, May 10, 2012 at 3:54 PM, David Schuster wrote: >>> >>> OK here is how we have it setup, and I just verified it still works that way with 3.06.04. >>> >>> AutoSelfCheckAllowd - Don't Allow >>> >>> The librarian logs into the sco using a "user" setup as lmsxxx/password - xxx is the location >>> >>> All transactions there are associated with the user's location. >>> >>> Granted that forces you to setup 67 users and someone has to open that up, but it has been working well for us for 4 years. >>> >>> Does that make sense? I don't want to auto login as you note somehow the system needs to know where you are from to track stats and route books correctly. >>> >> >> This is too easy to be true.... ;-) Let me see if I understand correctly: >> >> At Branch A: >> >> 1. Log into the staff client using Branch A's SCO account. >> 2. Navigate to the sco interface. >> >> At Branch B: >> >> 1. Log into the staff client using Branch B's SCO account. >> 2. Navigate to the sco interface. >> >> Please tell me it works this way and save me lots of hours of coding... ;-) >> >> Kind Regards, >> Chris >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Thu May 10 23:52:27 2012 From: mtj at kohaaloha.com (Mason James) Date: Fri, 11 May 2012 09:52:27 +1200 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: References: Message-ID: <4F2DC0F5-709A-43A1-BDF9-1B859B1227D7@kohaaloha.com> On 2012-05-11, at 5:39 AM, Nicole Engard wrote: > I don't manage the scripts that turn the XML that I write in to HTML > or PDF. I'm not sure what those scripts can do. is there a git repo for the xml files? - i'm still keen to take a look... From nengard at gmail.com Thu May 10 23:56:36 2012 From: nengard at gmail.com (Nicole Engard) Date: Thu, 10 May 2012 17:56:36 -0400 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: <4F2DC0F5-709A-43A1-BDF9-1B859B1227D7@kohaaloha.com> References: <4F2DC0F5-709A-43A1-BDF9-1B859B1227D7@kohaaloha.com> Message-ID: Here you go: http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Nicole On Thu, May 10, 2012 at 5:52 PM, Mason James wrote: > > On 2012-05-11, at 5:39 AM, Nicole Engard wrote: > >> I don't manage the scripts that turn the XML that I write in to HTML >> or PDF. I'm not sure what those scripts can do. > > > is there a git repo for the xml files? - i'm still keen to take a look... > > From chris at bigballofwax.co.nz Fri May 11 00:12:34 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 11 May 2012 10:12:34 +1200 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: <4F2DC0F5-709A-43A1-BDF9-1B859B1227D7@kohaaloha.com> References: <4F2DC0F5-709A-43A1-BDF9-1B859B1227D7@kohaaloha.com> Message-ID: On 11 May 2012 09:52, Mason James wrote: > > On 2012-05-11, at 5:39 AM, Nicole Engard wrote: > >> I don't manage the scripts that turn the XML that I write in to HTML >> or PDF. I'm not sure what those scripts can do. > > > is there a git repo for the xml files? - i'm still keen to take a look... > Of course :) http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary They are also tested by jenkins http://jenkins.koha-community.org/job/Koha_Docs/ Chris From chris at bigballofwax.co.nz Fri May 11 02:06:10 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 11 May 2012 12:06:10 +1200 Subject: [Koha-devel] Guided report in Koha 3.8.0 In-Reply-To: <2118979126.1570.1336129750881.JavaMail.tomcat@be08> References: <2118979126.1570.1336129750881.JavaMail.tomcat@be08> Message-ID: On 4 May 2012 23:09, Partha Mukhopadhyay wrote: > Dear all > > Thanks for a great new look (Staff interface in particular) in Koha 3.8.0. I > upgraded immediatetly on 25th April from Koha 3.6.4. Everything is running > smoothly except Guided report generation (Reports > Guided report). After a > few initial screens (to be specific upto the sum option page) it is going > blank (the next screen should come with "sort by field" option) and we can't > progress further. Please check. > > I tested with SQL report also and it's working nicely. > Hi A patch for this is at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8072 and if it makes it past QA will be in the 3.8.1 release Chris From paul.poulain at biblibre.com Fri May 11 11:11:52 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 11 May 2012 11:11:52 +0200 Subject: [Koha-devel] jquery upgraded on master branch Message-ID: <4FACD7D8.70807@biblibre.com> Hello koha-devel, I just pushed a patch to upgrade jquery to version 1.7.2 (from 1.3.2) It has been tested, but some side effect are always possible. So if you find strange javascript behaviour, go to bug 5184, or think of this upgrade ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From julian.maurice at biblibre.com Fri May 11 12:17:14 2012 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 11 May 2012 12:17:14 +0200 Subject: [Koha-devel] Localization of Perl strings in Koha Message-ID: <4FACE72A.6070503@biblibre.com> Hi, a discussion has started in bug 8044 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8044) about localization in Koha. But I want to include in this discussion the maximum number of people. Summary of the discussion: I proposed a patch that uses Locale::Maketext. You can see an example of use in the 2nd patch attached to the bug, but here is a code sample: use Koha::I18N; use CGI; my $cgi = new CGI; my $lh = Koha::I18N->get_handle_from_context($cgi, 'intranet'); $lh->maketext("A localized string with parameter: [_1]", $some_scalar); Then, Fr?d?ric D?mians suggested to use Locale::TextDomain instead of Locale::Maketext (some advantages are listed in bug comments) There is also a discussion about how we can handle templates translation with a translation framework like Locale::Maketext or Locale::TextDomain. This is not the topic of bug 8044, but a global discussion now is certainly better than choosing a direction now and then taking the opposite direction in a few months. First, we have to make a decision about the module to use. If you know well the two modules, please join the discussion! Next, the patch is only a 'first draft': PO files are in a new directory locale/, and the script that updates PO files is in locale directory too. I don't know where is the best place to put them in order to integrate well with Koha. So any suggestions are welcomed. If you have any other suggestion, please feel free to contribute :) -- Julian Maurice BibLibre From mjr at phonecoop.coop Fri May 11 12:25:54 2012 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 11 May 2012 11:25:54 +0100 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: Message-ID: Nicole > There are no PDFs of the 3.6 or 3.8 manual. There were issues with the > script that generated PDFs (as far as I know) and so they aren't > running anymore. Are those issues recorded anywhere, so people can try fixing? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From nengard at gmail.com Fri May 11 15:23:31 2012 From: nengard at gmail.com (Nicole Engard) Date: Fri, 11 May 2012 09:23:31 -0400 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: References: Message-ID: On Fri, May 11, 2012 at 6:25 AM, MJ Ray wrote: > Are those issues recorded anywhere, so people can try fixing? MJ I can ask around - but like I said, I'm not the right person to be answering these questions :) I update the XML, push the patches, and they automagically post to the web in HTML :) Nicole From koha.sekjal at gmail.com Fri May 11 15:24:52 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Fri, 11 May 2012 09:24:52 -0400 Subject: [Koha-devel] Guided report in Koha 3.8.0 In-Reply-To: References: <2118979126.1570.1336129750881.JavaMail.tomcat@be08> Message-ID: Bug 8072 is now Passed QA, and can be added to the 3.8.1 release at the Release Maintainers discretion. -Ian On Thu, May 10, 2012 at 8:06 PM, Chris Cormack wrote: > On 4 May 2012 23:09, Partha Mukhopadhyay wrote: > > Dear all > > > > Thanks for a great new look (Staff interface in particular) in Koha > 3.8.0. I > > upgraded immediatetly on 25th April from Koha 3.6.4. Everything is > running > > smoothly except Guided report generation (Reports > Guided report). > After a > > few initial screens (to be specific upto the sum option page) it is going > > blank (the next screen should come with "sort by field" option) and we > can't > > progress further. Please check. > > > > I tested with SQL report also and it's working nicely. > > > Hi > > A patch for this is at > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8072 and if > it makes it past QA will be in the 3.8.1 release > > 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 magnus at enger.priv.no Fri May 11 18:10:05 2012 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 11 May 2012 18:10:05 +0200 Subject: [Koha-devel] missing pdf files for Koha 3.6 and 3.8 manuals In-Reply-To: References: Message-ID: On 11 May 2012 15:23, Nicole Engard wrote: > On Fri, May 11, 2012 at 6:25 AM, MJ Ray wrote: >> Are those issues recorded anywhere, so people can try fixing? > > MJ I can ask around - but like I said, I'm not the right person to be > answering these questions :) I update the XML, push the patches, and > they automagically post to the web in HTML :) If someone is going to mess around with things in this area, could they please consider setting up an automated conversion to ePub format too? With dbtoepub it's as simple as this: $ dbtoepub -o /path/to/manual.epub /path/to/manual-in-git/en/manual.xml I have an old demo here: http://div.libriotech.no/kohaebook/ I have not found a good way to convert to .mobi yet, so please disregard those parts. Best regards, Magnus Enger libriotech.no From psm_vu at india.com Mon May 14 09:57:54 2012 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Mon, 14 May 2012 07:57:54 +0000 (UTC) Subject: [Koha-devel] Guided report in Koha 3.8.0 In-Reply-To: References: <2118979126.1570.1336129750881.JavaMail.tomcat@be08> , Message-ID: <1657990014.7450.1336982274346.JavaMail.tomcat@be11> An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Mon May 14 23:56:37 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 15 May 2012 09:56:37 +1200 Subject: [Koha-devel] Koha 3.8.1 entering string freeze Message-ID: Hi All As promised, the 3.8.x branch has entered string freeze in preparation for the 3.8.1 release next week. "So?" you ask, "What does this mean for me?" Are you a developer? - If so just be aware I will only be pushing patches that do not contain changes to any of the translatable strings from now until the release. Are you a translator? - Once the translation manager emails to say the po files are updated, you are clear to translate your hearts out. Are you a Koha user? - If you have the skills or know someone who does, check out the 3.8.x and do some testing on it, that would be awesome. Are you a brewer? - I quite like a nice IPA Chris From danielg.koha at gmail.com Tue May 15 21:26:52 2012 From: danielg.koha at gmail.com (Daniel Grobani) Date: Tue, 15 May 2012 12:26:52 -0700 Subject: [Koha-devel] Call for News for the May Newsletter Message-ID: Dear Koha Kommunitarians, I'm harvesting news for the May newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani From karamqubsi at gmail.com Wed May 16 14:15:53 2012 From: karamqubsi at gmail.com (Karam Qubsi) Date: Wed, 16 May 2012 15:15:53 +0300 Subject: [Koha-devel] Multi-Lingual SQL & User Defined Parameters Message-ID: Hi Dear Mr Massoud , Dear all, I think this will be very helpful for the people who don't want to use the English interface in Koha , and as you say when we finish translating koha 3.8 to Arabic ( very soon inshaallah) , we will have problems with the people who want to use koha in Arabic and english in the same time e.g: May be some Arab librarian prefer to use koha English interface for the staff client , and in the case that we've used the translated sql files (that your company provided it to us) for the marc21 the Arab librarian who want to use the English interface will have a problem because all the staff client will be in english except for the marc records and if we use the English version of the marc21 sql files the problem will be that the Arab librarian who will use the Arabic interface will see the marc fields in english so if we want to use arabic interface we have to use arabic sql files for marc is it possible to make something like armarc as we have normarc in the SQL structure ?! it's not a standard we don't really have 'armarc' and it is not a solution so the library chose its Marc flavor and all the librarian in that library will be forced to use this armarc , but will help to make the installation of the translated Arabic marc more easier and for the preferences description is included in the po files but the preferences still in English (the main term ) maybe the best solution is to make all the strings in koha included in the po files I don't have deep technical background but this will be more flexible for koha users all over the world for other languages not only for the Arabic language wish you will be able to do that for all the koha community :) thanks a lot for you Mr Massoud and thanks you all in Koha community for helping us :D Karam Qubsi Koha Arab Translating Team http://koha.wikibrary.org/ Wikibrary for Arab Librarians http://wikibrary.org > Date: Wed, 16 May 2012 09:00:57 +0300 > From: Massoud Alshareef > Subject: [Koha-translate] Multi-Lingual SQL & User Defined Parameters > To: koha-devel at lists.katipo.co.nz, koha at lists.katipo.co.nz, > ? ? ? ?koha-translate at lists.koha-community.org > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > I have asked a question about two years ago about when we can have Koha > support of Multi-Lingual SQL files (used for marc21/Auth fields description > in the Staff client) and Multi-Lingual users defined parameters (used for > describing items/ libraries & groups/ locations/ patrons categories/ etc), > and the answer from Koha development then was that it is > under consideration but not in the development pipelines yet, as it will > require some re-structuring in Koha system databases and controls. That > means, Koha will remain a single language in these areas. > > With Koha 3.6 release, I noticed the inclusion of "Spanish translation for > SQL files" in the INTERNATIONALIZATION enhancement section. Does this mean > that Spanish Koha, or any non-English Koha, now has both Spanish and > English SQL files, where Koha users can switch between more than one > language when, for instance, editing marc records in the staff client ? > > Koha Preferences description used to be in SQL files, which means a single > language prefers, and then moved into PO files format with 3.2 release (I > think) and thus Preferences became multi-lingual since then. > > Thank you Koha development for elaborating on the issue of having a fully > bilingual Koha. > > BTW, Arabic Koha 3.8 is now on the fast-lanes translation speed to be > completed within 3-4 weeks. > See Arabic Koha 3.8 OPAC demo site on > http://176.34.184.60/cgi-bin/koha/opac-search.pl?q=%D8%B9%D9%84%D9%85 > > Thanks > Massoud M. AlShareef, > > The world of achievement has always belonged to the optimist! > > KnowledgeWare Technologies > (P.O. Box 230-312) > Riyadh 11321, Saudi Arabia > Cel: +966 505 307 267 > massoud at kwareict.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > From paul.poulain at biblibre.com Wed May 16 14:27:36 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 16 May 2012 14:27:36 +0200 Subject: [Koha-devel] sandbox system Message-ID: <4FB39D38.4080702@biblibre.com> Hello koha-devel, I just pushed a few minuts ago the 1st version of the sandbox scripts I've developped and that is available to facilitate testing of Koha patches. You'll find everything, including some installation notes at http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary (git clone git://git.koha-community.org/contrib/global.git contrib, in the sandbox directory) PS: if you want to improve my scripts, you're welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From tdavis at uttyler.edu Wed May 16 18:00:11 2012 From: tdavis at uttyler.edu (Elliott Davis) Date: Wed, 16 May 2012 16:00:11 +0000 Subject: [Koha-devel] Koha Calendar Message-ID: <7E2623294CB09249AA51272D2782A4F0A46B9B@CATBERT.info.uttyler.edu> As I'm sure everybody running master has realized, bug 5549 introduced a new module Koha::Calendar. After digging around in the module I realized that the table special_holidays had separate columns for year, month, and date. I am wondering what the rationale is behind this decision. If it was simply I preference I would like to propose that we move it to replace the 3 current columns with a timestamp so that the calendar can take advantage of setting open and closed hours and fining for hourly based items accordingly. Elliott Davis Library Systems Analyst Robert R. Muntz Library [Description: Telephone]903.565.5542 [Description: Envelope]tdavis at uttyler.edu [Description: Chrome]http://library.uttyler.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 700 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.png Type: image/png Size: 863 bytes Desc: image008.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.png Type: image/png Size: 1088 bytes Desc: image009.png URL: From gmc at esilibrary.com Wed May 16 20:57:58 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Wed, 16 May 2012 14:57:58 -0400 Subject: [Koha-devel] Koha Calendar In-Reply-To: <7E2623294CB09249AA51272D2782A4F0A46B9B@CATBERT.info.uttyler.edu> References: <7E2623294CB09249AA51272D2782A4F0A46B9B@CATBERT.info.uttyler.edu> Message-ID: <63BD7E53-AE91-454F-A364-A53D19395711@esilibrary.com> Hi Elliott, On May 16, 2012, at 12:00 PM, Elliott Davis wrote: > As I?m sure everybody running master has realized, bug 5549 introduced a new module Koha::Calendar. After digging around in the module I realized that the table special_holidays had separate columns for year, month, and date. I am wondering what the rationale is behind this decision. If it was simply I preference I would like to propose that we move it to replace the 3 current columns with a timestamp so that the calendar can take advantage of setting open and closed hours and fining for hourly based items accordingly. The table special_holidays itself currently just sets closed days, but just using a date field rather than year/month/day seems reasonable. I'm less sure about using a timestamp field; if we extend special_holidays to cover not just closures but alternative opening and closing times, I think it might be better to use two time fields to set the opening and closing times, e.g. special_holidays: the_date date open_time time close_time time is_open_at_all boolean Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From obtim123 at gmail.com Mon May 21 16:16:09 2012 From: obtim123 at gmail.com (Tim O'brien) Date: Mon, 21 May 2012 17:16:09 +0300 Subject: [Koha-devel] Public IP for Koha Message-ID: Hi, I manage to intall koha 3.6. My institution has four branch libraries and i wanted to use public IP so that the other three branches can access the system. I am thinking of using public IP for these purpose. Kindly advice me: the risks and if there are better options. Regards, O'brien -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at gmail.com Mon May 21 18:17:08 2012 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 21 May 2012 18:17:08 +0200 Subject: [Koha-devel] Public IP for Koha In-Reply-To: References: Message-ID: Hie, Personnaly, I strongly recommand not to use a public access on intranet. Can't you set up a VPN between your 4 branches libs ? It is the most secured network solution. Less secured solution is a reverse-proxy. Best regards, On Mon, May 21, 2012 at 4:16 PM, Tim O'brien wrote: > Hi, > I manage to intall koha 3.6. My institution has four branch libraries and > i wanted to use public IP so that the other three branches can access the > system. I am thinking of using public IP for these purpose. Kindly advice > me: the risks and if there are better options. > Regards, > O'brien > > _______________________________________________ > 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 fridolyn.somers at gmail.com Marsillargues - France -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.poulain at biblibre.com Mon May 21 18:26:33 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 21 May 2012 18:26:33 +0200 Subject: [Koha-devel] Public IP for Koha In-Reply-To: References: Message-ID: <4FBA6CB9.4080304@biblibre.com> Le 21/05/2012 18:17, Fridolyn SOMERS a ?crit : > Hie, > > Personnaly, I strongly recommand not to use a public access on intranet. Agreed, but you can also achieve that by using a virtual host configured to listen only on your staff interface (you need a static IP for your library though). that's how we do for most of our hosted customers afaik. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Mon May 21 19:38:58 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 21 May 2012 13:38:58 -0400 Subject: [Koha-devel] Proposed QA Enhancements Message-ID: I am making two proposals that will help "tighten" up our QA procedures a bit in order to facilitate clarity and transparency in our patch submission/acceptance workflow. Currently the workflow is described in the wiki here: http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow#Steps 1. I propose that we modify step 5 to read: "The patch is checked and signed-off by the QA team member. Then the bug status is set to Passed QA" This will ensure that we have clarity that the patch was, indeed, touched by a member of the QA team, as well as increasing the accuracy of QA stats in git. 2. I propose that the RM be the QA of last resort. At present the stats show that the RM is doing the majority of the QA'ing. "Last resort" is a condition evoked by all members of the current QA team acknowledging that no one among them has the time, etc. to do QA on a particular patch the RM feels needs to be pushed OR by a bug remaining in the "Signed Off" status beyond a fixed time period of four weeks. This mechanism would address concerns of bug stagnation by allowing ample time for QA members to at least glance at a bug and determine of they do or do not have time to give to that bug as well as having a catch mechanism for bugs falling through w/o notice. Here are some statistics on sign-offs by the currently listed QA team for commits between the 3.6.0 and 3.8.0 tags: NOTE: 100% of our patches have the minimum required 1 sign-off by any community member Total commits: 1086 Sign-offs by QA Team members: Marcel de Rooy - 43 Jonathan Druart - 5 Paul Poulain - 538 Ian Walls - 25 Total commits w/sign-off by a QA team member: 611 OR 56.3% Total commits w/sign-off by RM: 538 OR 49.5% Total commits w/sign-off by non-RM QA member: 73 OR 6.7% These figures reasonably agree with the stats posted here: http://blog.bigballofwax.co.nz/2012/04/24/statistics-for-koha-3-8-0/ You may reproduce them on your local git repo master branch by using variations of the following: git log --grep="^Signed-off-by: " --no-merges --oneline 52c666edce42..5c32a9f811d | wc -l Lets have some discussion on the two proposals above, and I'll put them on the agenda for the next IRC meeting to be voted on. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Mon May 21 19:52:22 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Mon, 21 May 2012 13:52:22 -0400 Subject: [Koha-devel] Proposed QA Enhancements In-Reply-To: References: Message-ID: <1FCF71A4-C5BA-4827-A3BF-7C7AC2975C41@esilibrary.com> Hi, On May 21, 2012, at 1:38 PM, Chris Nighswonger wrote: > 1. I propose that we modify step 5 to read: > > "The patch is checked and signed-off by the QA team member. Then the bug status is set to Passed QA" > > This will ensure that we have clarity that the patch was, indeed, touched by a member of the QA team, as well as increasing the accuracy of QA stats in git. +1 -- this seems like a obvious procedure documentation fix, hopefully one that just more clearly describes existing practice. > 2. I propose that the RM be the QA of last resort. At present the stats show that the RM is doing the majority of the QA'ing. "Last resort" is a condition evoked by all members of the current QA team acknowledging that no one among them has the time, etc. to do QA on a particular patch the RM feels needs to be pushed OR by a bug remaining in the "Signed Off" status beyond a fixed time period of four weeks. This mechanism would address concerns of bug stagnation by allowing ample time for QA members to at least glance at a bug and determine of they do or do not have time to give to that bug as well as having a catch mechanism for bugs falling through w/o notice. [snip] > Total commits w/sign-off by non-RM QA member: 73 OR 6.7% These go hand-in-hand. I agree that reducing the QA burden the RM is a good thing, but in order for that to happen, I think one question that needs an answer first is how do we increase the size of the QA team? Or to phrase it more broadly, what can we do to encourage more people to do QA, whether or not the current QA structure is used as is or changed? Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From chris at bigballofwax.co.nz Mon May 21 23:32:25 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 22 May 2012 09:32:25 +1200 Subject: [Koha-devel] Koha 3.8.1 released Message-ID: The Koha release team is happy to announce the release of Koha 3.8.1 This is a stable release and contains bugfixes as well as updated translations. You can download it at http://download.koha-community.org/ Go forth, download, and enjoy :) RELEASE NOTES FOR KOHA 3.8.1 21 May 2012 ======================================================================== 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.8.1 can be downloaded from: http://download.koha-community.org/koha-3.08.01.tar.gz Installation instructions can be found: in the INSTALL files that come in the tarball Koha 3.8.1 is a bugfix/maintenance release. Highlights of 3.8.1 ====================== 7924 critical Fix handling of command line arguments in koha-remove 7998 critical 3.8 UI cleanup, tweaks to new styles 8035 critical bibs with comments show an error in opac 8072 critical reports wizard dies 8077 critical overdues with fines won't run 3969 major Budget Search Doesn't Work 7984 major Fix the upload_local_cover_images permission 8002 major Can't add patron attribute type in newer installation 8027 major Wrong order for parameters in Z39.50 SQL INSERT Bugs fixed in 3.8.1 ====================== 2399 normal All status fields in the item edit interface offer two blank/null entries per dropdown instead of one 3413 normal repeatable tickbox not sticking 1st time round 6335 normal Branch not set consistently in all SIP transactions 7604 normal Link on basket group name for closed basket groups is broken 7722 normal Insidious problem with searching 7820 normal Missing packages from install_misc/debian.packages 7842 normal Inconsistencies in Notices interface 7982 normal Typo in moremember-receipt.tt 8020 normal Prepare debian packages for 3.8 release 8022 normal Permissions test doesn't check all languages 8025 normal Patron attribute not selected if value is zero 8045 normal Problems on Due date when checking in 8084 normal Suspend Until not set on by suspend button 5345 enhancement DataTables in Koha 5549 enhancement Hourly Loans 7178 enhancement Improve order item creation 7213 enhancement Document /svc/ HTTP API and provide example command-line client 7647 enhancement Checkout History Sort 7849 enhancement Instant Fine Calculation at Checkin 7870 enhancement Replace itemnumber by barcode in links of patron modification log 7903 enhancement add an ordernumber column in orders history table 7990 enhancement bad html attribute into aqplan.tt : styl= insted of style= 8001 enhancement Add some styling to the tags to allow them to be distinctive System requirements ====================== Changes since 3.6: * No new system requirements Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.8/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: the following languages: * French (100%) * Spanish (100%) * German (100%) * Chinese -Taiwan- (97%, OPAC 100%) * Italian (86%, OPAC 100%) * Danish (81%) * Portuguese (79%) * French -canada- (76%) * English -nz- (76%) * Greek (74%) * Norwegian (73%) 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.8 is Release Manager: Paul Poulain Documentation Manager: Nicole C Engard Translation Manager: Fr?d?ric Demians QA Manager: Ian Walls QA team: Marcel de Rooy , Jonathan Druart Bug Wranglers: Katrin Fischer, Magnus Enger Release Maintainer (3.4.x): Chris Nighswonger Release Maintainer (3.6.x): Jared Camins-Esakov Release Maintainer (3.8.x): Chris Cormack Credits ====================== We thank the following individuals who contributed patches to Koha 3.8.1. 2 Jared Camins-Esakov 3 Colin Campbell 8 Chris Cormack 2 St?phane Delaune 7 Jonathan Druart 4 Magnus Enger 6 Katrin Fischer 4 Kyle M Hall 2 Srdjan Jankovic 4 Owen Leonard 1 Julian Maurice 1 Chris Nighswonger 1 Dobrica Pavlinusic 4 Paul Poulain 2 Liz Rea 2 Marcel de Rooy 3 Adrien Saurat 3 Robin Sheat 2 Lyon3 Team 2 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.8.x (i.e., this version of Koha and future bugfix releases) is 3.8.x. The next major feature release of Koha will be Koha 3.10.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 cnighswonger at foundations.edu Tue May 22 00:27:32 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 21 May 2012 18:27:32 -0400 Subject: [Koha-devel] Koha 3.8.1 released In-Reply-To: References: Message-ID: Huzza! On Mon, May 21, 2012 at 5:32 PM, Chris Cormack wrote: > The Koha release team is happy to announce the release of Koha 3.8.1 > > This is a stable release and contains bugfixes as well as updated > translations. > > You can download it at > > http://download.koha-community.org/ > > Go forth, download, and enjoy :) > > > RELEASE NOTES FOR KOHA 3.8.1 > 21 May 2012 > ======================================================================== > > 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.8.1 can be downloaded from: > > http://download.koha-community.org/koha-3.08.01.tar.gz > > Installation instructions can be found: > > in the INSTALL files that come in the tarball > > Koha 3.8.1 is a bugfix/maintenance release. > > Highlights of 3.8.1 > ====================== > > 7924 critical Fix handling of command line arguments in > koha-remove > 7998 critical 3.8 UI cleanup, tweaks to new styles > 8035 critical bibs with comments show an error in opac > 8072 critical reports wizard dies > 8077 critical overdues with fines won't run > 3969 major Budget Search Doesn't Work > 7984 major Fix the upload_local_cover_images permission > 8002 major Can't add patron attribute type in newer > installation > 8027 major Wrong order for parameters in Z39.50 SQL INSERT > > > Bugs fixed in 3.8.1 > ====================== > > 2399 normal All status fields in the item edit interface offer > two > blank/null entries per dropdown instead of one > 3413 normal repeatable tickbox not sticking 1st time round > 6335 normal Branch not set consistently in all SIP transactions > 7604 normal Link on basket group name for closed basket groups > is broken > 7722 normal Insidious problem with searching > 7820 normal Missing packages from install_misc/debian.packages > 7842 normal Inconsistencies in Notices interface > 7982 normal Typo in moremember-receipt.tt > 8020 normal Prepare debian packages for 3.8 release > 8022 normal Permissions test doesn't check all languages > 8025 normal Patron attribute not selected if value is zero > 8045 normal Problems on Due date when checking in > 8084 normal Suspend Until not set on by suspend button > 5345 enhancement DataTables in Koha > 5549 enhancement Hourly Loans > 7178 enhancement Improve order item creation > 7213 enhancement Document /svc/ HTTP API and provide example > command-line client > 7647 enhancement Checkout History Sort > 7849 enhancement Instant Fine Calculation at Checkin > 7870 enhancement Replace itemnumber by barcode in links of patron > modification log > 7903 enhancement add an ordernumber column in orders history table > 7990 enhancement bad html attribute into aqplan.tt : styl= insted > of style= > 8001 enhancement Add some styling to the tags to allow them to be > distinctive > > > System requirements > ====================== > > Changes since 3.6: > > * No new system requirements > > > Documentation > ====================== > > As of Koha 3.2, the Koha manual is now maintained in DocBook. The > home page for Koha documentation is > > http://koha-community.org/documentation/ > > As of the date of these release notes, only the English version of the > Koha manual is available: > > http://manual.koha-community.org/3.8/en/ > > The Git repository for the Koha manual can be found at > > http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary > > Translations > ====================== > > Complete or near-complete translations of the OPAC and staff > interface are available in this release for the following languages: > > the following languages: > * French (100%) > * Spanish (100%) > * German (100%) > * Chinese -Taiwan- (97%, OPAC 100%) > * Italian (86%, OPAC 100%) > * Danish (81%) > * Portuguese (79%) > * French -canada- (76%) > * English -nz- (76%) > * Greek (74%) > * Norwegian (73%) > > 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.8 is > > Release Manager: Paul Poulain > Documentation Manager: Nicole C Engard > Translation Manager: Fr?d?ric Demians > QA Manager: Ian Walls > QA team: Marcel de Rooy , > Jonathan Druart > Bug Wranglers: Katrin Fischer, Magnus Enger > > Release Maintainer (3.4.x): Chris Nighswonger < > cnighswonger at foundations.edu> > Release Maintainer (3.6.x): Jared Camins-Esakov < > jcamins at cpbibliography.com> > Release Maintainer (3.8.x): Chris Cormack > > > Credits > ====================== > > We thank the following individuals who contributed patches to > Koha 3.8.1. > > 2 Jared Camins-Esakov > 3 Colin Campbell > 8 Chris Cormack > 2 St?phane Delaune > 7 Jonathan Druart > 4 Magnus Enger > 6 Katrin Fischer > 4 Kyle M Hall > 2 Srdjan Jankovic > 4 Owen Leonard > 1 Julian Maurice > 1 Chris Nighswonger > 1 Dobrica Pavlinusic > 4 Paul Poulain > 2 Liz Rea > 2 Marcel de Rooy > 3 Adrien Saurat > 3 Robin Sheat > 2 Lyon3 Team > 2 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.8.x (i.e., this version of Koha and future bugfix > releases) is 3.8.x. > > The next major feature release of Koha will be Koha 3.10.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 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Tue May 22 10:40:22 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 May 2012 10:40:22 +0200 Subject: [Koha-devel] Proposed QA Enhancements In-Reply-To: References: Message-ID: <4FBB50F6.2060905@biblibre.com> Le 21/05/2012 19:38, Chris Nighswonger a ?crit : > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow#Steps > > 1. I propose that we modify step 5 to read: > > "The patch is checked and signed-off by the QA team member. Then the bug > status is set to Passed QA" Something I made during the 3.8 release was to add many things to the coding guidelines. My preference goes to QA rules that are clearly defined and explained. That will help QAing a lot, and "anyone" with a good Koha experience, and some time to dedicate should/could do it. I agree that we *must* have a functional AND a technical review of every patch, the 2 steps are different. > This will ensure that we have clarity that the patch was, indeed, > touched by a member of the QA team, as well as increasing the accuracy > of QA stats in git. Most QA is done in bugzilla only: when a patch is QAed, it's not signed-off & git bz attach most of the time. (that's also why your numbers below are meaningless : Ian has not made only 25 QA or joubu 5 ! OTOH, when I, as RM, push a patch, I always add my signature, that can be as RM or QA) > 2. I propose that the RM be the QA of last resort. At present the stats > show that the RM is doing the majority of the QA'ing. As I just wrote, I don't do the majority of QA, (even if I agree I do a lot) As I've said previously, as RM, I dedicate more than half of my time to this task. I think that we could have someone dedicated full time to QA and someone dedicated full time to sign-off. And until we won't... we will face this kind of trouble. Our workflow is good, but require a large effort we collectively fail to "pay" until now. [ off-topic: BibLibre dedicate a lot of resources to Koha (see statistics on chris_c blog. A lot being "self-sponsored") and can't dedicate more. I think everybody should ask himself seriously "What did I do for Koha last week, what will I do next week ?" ] > "Last resort" is a > condition evoked by all members of the current QA team acknowledging > that no one among them has the time, etc. to do QA on a particular patch > the RM feels needs to be pushed OR by a bug remaining in the "Signed > Off" status beyond a fixed time period of four weeks. +1 (and it's already done that way in fact : as member of the QA team, I always order by date when I QA, and start by the oldest patches. I've suggested to change the default order to date, but the idea has not been approved) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chrisc at catalyst.net.nz Tue May 22 10:51:15 2012 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 22 May 2012 20:51:15 +1200 Subject: [Koha-devel] Proposed QA Enhancements In-Reply-To: <4FBB50F6.2060905@biblibre.com> References: <4FBB50F6.2060905@biblibre.com> Message-ID: <20120522085115.GQ31982@rorohiko.wgtn.cat-it.co.nz> * Paul Poulain (paul.poulain at biblibre.com) wrote: > Le 21/05/2012 19:38, Chris Nighswonger a ?crit : > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow#Steps > > > > 1. I propose that we modify step 5 to read: > > > > "The patch is checked and signed-off by the QA team member. Then the bug > > status is set to Passed QA" > Something I made during the 3.8 release was to add many things to the > coding guidelines. My preference goes to QA rules that are clearly > defined and explained. That will help QAing a lot, and "anyone" with a > good Koha experience, and some time to dedicate should/could do it. > > I agree that we *must* have a functional AND a technical review of every > patch, the 2 steps are different. > > > This will ensure that we have clarity that the patch was, indeed, > > touched by a member of the QA team, as well as increasing the accuracy > > of QA stats in git. > Most QA is done in bugzilla only: when a patch is QAed, it's not > signed-off & git bz attach most of the time. > (that's also why your numbers below are meaningless : Ian has not made > only 25 QA or joubu 5 ! OTOH, when I, as RM, push a patch, I always add > my signature, that can be as RM or QA) That's what Chris N was asking for, that a sign off is added when the patch is tested, it must have been applied and tested, so why not sign off and attach it back on the bug at the same time as changing the bug status. > > > 2. I propose that the RM be the QA of last resort. At present the stats > > show that the RM is doing the majority of the QA'ing. > As I just wrote, I don't do the majority of QA, (even if I agree I do a lot) > > As I've said previously, as RM, I dedicate more than half of my time to > this task. > I think that we could have someone dedicated full time to QA and someone > dedicated full time to sign-off. And until we won't... we will face this > kind of trouble. Our workflow is good, but require a large effort we > collectively fail to "pay" until now. > > [ off-topic: BibLibre dedicate a lot of resources to Koha (see > statistics on chris_c blog. A lot being "self-sponsored") and can't > dedicate more. I think everybody should ask himself seriously "What did > I do for Koha last week, what will I do next week ?" ] > I'm not sure we want to get into a who does more for Koha contest, nor do I think that was the point of this email. I do think there are too many patches missing getting 2 independent sign offs, and that is what we need to fix. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand From massoud at kwareict.com Wed May 16 08:03:11 2012 From: massoud at kwareict.com (Massoud Alshareef) Date: Wed, 16 May 2012 09:03:11 +0300 Subject: [Koha-devel] Multi-Lingual SQL & User Defined Parameters In-Reply-To: References: Message-ID: Hello, I have asked a question about two years ago about when we can have Koha support of Multi-Lingual SQL files (used for marc21/Auth fields description in the Staff client) and Multi-Lingual users defined parameters (used for describing items/ libraries & groups/ locations/ patrons categories/ etc), and the answer from Koha development then was that it is under consideration but not in the development pipelines yet, as it will require some re-structuring in Koha system databases and controls. That means, Koha will remain a single language in these areas. With Koha 3.6 release, I noticed the inclusion of "Spanish translation for SQL files" in the INTERNATIONALIZATION enhancement section. Does this mean that Spanish Koha, or any non-English Koha, now has both Spanish and English SQL files, where Koha users can switch between more than one language when, for instance, editing marc records in the staff client ? Koha Preferences description used to be in SQL files, which means a single language prefers, and then moved into PO files format with 3.2 release (I think) and thus Preferences became multi-lingual since then. Thank you Koha development for elaborating on the issue of having a fully bilingual Koha. BTW, Arabic Koha 3.8 is now on the fast-lanes translation speed to be completed within 3-4 weeks. See Arabic Koha 3.8 OPAC demo site on http://176.34.184.60/cgi-bin/koha/opac-search.pl?q=%D8%B9%D9%84%D9%85 Thanks Massoud M. AlShareef, The world of achievement has always belonged to the optimist! KnowledgeWare Technologies (P.O. Box 230-312) Riyadh 11321, Saudi Arabia Cel: +966 505 307 267 massoud at kwareict.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From massoud at kwareict.com Wed May 16 14:55:56 2012 From: massoud at kwareict.com (Massoud Alshareef) Date: Wed, 16 May 2012 15:55:56 +0300 Subject: [Koha-devel] Multi-Lingual SQL & User Defined Parameters In-Reply-To: References: Message-ID: Most academic libraries in the Arabian Gulf region (Saudi, Kuwait, Bahrain, Qatar, UAE, Oman) always have bilingual catalogers, some do Arabic books cataloging (Arabs mostly from Saudi and Egypt with near zero English background) and some do English books cataloging (non-Arabs mostly from India and Pakistan who are generally fluent in English but have little or no Arabic language understanding). Imagine the case when both language catalogers doing cataloging/ authority work using the same Arabic/English Koha installation !! I think it is like a night-mare for one of the two groups at least, and the other group feeling sorry for their colleagues; I did live the experience at a University library using another single language ILS in the late nineties, and if you are wondering it was not a healthy environment experience at all! Thanks Massoud M. AlShareef, The world of achievement has always belonged to the optimist! KnowledgeWare Technologies (P.O. Box 230-312) Riyadh 11321, Saudi Arabia Cel: +966 505 307 267 massoud at kwareict.com On Wed, May 16, 2012 at 3:15 PM, Karam Qubsi wrote: > Hi > Dear Mr Massoud , > Dear all, > > I think this will be very helpful for the people who don't want to use > the English interface in Koha , and as you say when we finish > translating koha 3.8 to Arabic ( very soon inshaallah) , > we will have problems with the people who want to use koha in Arabic > and english in the same time > e.g: > May be some Arab librarian prefer to use koha English interface for > the staff client , and in the case that we've used the translated > sql files (that your company provided it to us) for the marc21 the > Arab librarian who want to use the English interface will have a > problem because all the staff client will be in english except for the > marc records > > and if we use the English version of the marc21 sql files the problem > will be that the Arab librarian who will use the Arabic interface will > see the marc fields in english > > so if we want to use arabic interface we have to use arabic sql files for > marc > > is it possible to make something like armarc as we have normarc in the > SQL structure ?! > > it's not a standard we don't really have 'armarc' and it is not a > solution so the library chose its Marc flavor and all the librarian in > that library will be forced to use this armarc , but will help to make > the installation of the translated Arabic marc more easier > > and for the preferences description is included in the po files but > the preferences still in English (the main term ) > > maybe the best solution is to make all the strings in koha included in > the po files I don't have deep technical background but this will be > more flexible for koha users all over the world for other languages > not only for the Arabic language > > > wish you will be able to do that for all the koha community :) > > > > thanks a lot for you Mr Massoud > > and thanks you all in Koha community for helping us :D > > > Karam Qubsi > Koha Arab Translating Team > http://koha.wikibrary.org/ > Wikibrary for Arab Librarians > http://wikibrary.org > > > > Date: Wed, 16 May 2012 09:00:57 +0300 > > From: Massoud Alshareef > > Subject: [Koha-translate] Multi-Lingual SQL & User Defined Parameters > > To: koha-devel at lists.katipo.co.nz, koha at lists.katipo.co.nz, > > koha-translate at lists.koha-community.org > > Message-ID: > > 5W15pPzmQ at mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > Hello, > > > > I have asked a question about two years ago about when we can have Koha > > support of Multi-Lingual SQL files (used for marc21/Auth fields > description > > in the Staff client) and Multi-Lingual users defined parameters (used for > > describing items/ libraries & groups/ locations/ patrons categories/ > etc), > > and the answer from Koha development then was that it is > > under consideration but not in the development pipelines yet, as it will > > require some re-structuring in Koha system databases and controls. That > > means, Koha will remain a single language in these areas. > > > > With Koha 3.6 release, I noticed the inclusion of "Spanish translation > for > > SQL files" in the INTERNATIONALIZATION enhancement section. Does this > mean > > that Spanish Koha, or any non-English Koha, now has both Spanish and > > English SQL files, where Koha users can switch between more than one > > language when, for instance, editing marc records in the staff client ? > > > > Koha Preferences description used to be in SQL files, which means a > single > > language prefers, and then moved into PO files format with 3.2 release (I > > think) and thus Preferences became multi-lingual since then. > > > > Thank you Koha development for elaborating on the issue of having a fully > > bilingual Koha. > > > > BTW, Arabic Koha 3.8 is now on the fast-lanes translation speed to be > > completed within 3-4 weeks. > > See Arabic Koha 3.8 OPAC demo site on > > http://176.34.184.60/cgi-bin/koha/opac-search.pl?q=%D8%B9%D9%84%D9%85 > > > > Thanks > > Massoud M. AlShareef, > > > > The world of achievement has always belonged to the optimist! > > > > KnowledgeWare Technologies > > (P.O. Box 230-312) > > Riyadh 11321, Saudi Arabia > > Cel: +966 505 307 267 > > massoud at kwareict.com > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > > ------------------------------ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Tue May 22 17:02:31 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Tue, 22 May 2012 15:02:31 +0000 Subject: [Koha-devel] Proposed QA Enhancements In-Reply-To: <20120522085115.GQ31982@rorohiko.wgtn.cat-it.co.nz> References: <4FBB50F6.2060905@biblibre.com>, <20120522085115.GQ31982@rorohiko.wgtn.cat-it.co.nz> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF64BC3@S-MAIL-1B.rijksmuseum.intra> Just a quick response on first glance: The numbers in this discussion are imo far from accurate. As for me, I mostly QA without signing off, just to spare time. In most cases I did apply and test (at least some functionality, in other cases much more). I would not recommend doing QA in Bugzilla only, perhaps with the exception of very small things. Adding the rule that QA must do an additional signoff too will put more work (better testing etc.) on the QA team, and will result in more delay. If a QA member does not trust a patch, why not ask for a second signoff (older idea..)? ________________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Chris Cormack [chrisc at catalyst.net.nz] Verzonden: dinsdag 22 mei 2012 10:51 To: Paul Poulain Cc: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Proposed QA Enhancements * Paul Poulain (paul.poulain at biblibre.com) wrote: > Le 21/05/2012 19:38, Chris Nighswonger a ?crit : > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow#Steps > > > > 1. I propose that we modify step 5 to read: > > > > "The patch is checked and signed-off by the QA team member. Then the bug > > status is set to Passed QA" > Something I made during the 3.8 release was to add many things to the > coding guidelines. My preference goes to QA rules that are clearly > defined and explained. That will help QAing a lot, and "anyone" with a > good Koha experience, and some time to dedicate should/could do it. > > I agree that we *must* have a functional AND a technical review of every > patch, the 2 steps are different. > > > This will ensure that we have clarity that the patch was, indeed, > > touched by a member of the QA team, as well as increasing the accuracy > > of QA stats in git. > Most QA is done in bugzilla only: when a patch is QAed, it's not > signed-off & git bz attach most of the time. > (that's also why your numbers below are meaningless : Ian has not made > only 25 QA or joubu 5 ! OTOH, when I, as RM, push a patch, I always add > my signature, that can be as RM or QA) That's what Chris N was asking for, that a sign off is added when the patch is tested, it must have been applied and tested, so why not sign off and attach it back on the bug at the same time as changing the bug status. > > > 2. I propose that the RM be the QA of last resort. At present the stats > > show that the RM is doing the majority of the QA'ing. > As I just wrote, I don't do the majority of QA, (even if I agree I do a lot) > > As I've said previously, as RM, I dedicate more than half of my time to > this task. > I think that we could have someone dedicated full time to QA and someone > dedicated full time to sign-off. And until we won't... we will face this > kind of trouble. Our workflow is good, but require a large effort we > collectively fail to "pay" until now. > > [ off-topic: BibLibre dedicate a lot of resources to Koha (see > statistics on chris_c blog. A lot being "self-sponsored") and can't > dedicate more. I think everybody should ask himself seriously "What did > I do for Koha last week, what will I do next week ?" ] > I'm not sure we want to get into a who does more for Koha contest, nor do I think that was the point of this email. I do think there are too many patches missing getting 2 independent sign offs, and that is what we need to fix. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand _______________________________________________ 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 koha.sekjal at gmail.com Tue May 22 17:44:23 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Tue, 22 May 2012 11:44:23 -0400 Subject: [Koha-devel] Proposed QA Enhancements In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF64BC3@S-MAIL-1B.rijksmuseum.intra> References: <4FBB50F6.2060905@biblibre.com> <20120522085115.GQ31982@rorohiko.wgtn.cat-it.co.nz> <809BE39CD64BFD4EB9036172EBCCFA310DF64BC3@S-MAIL-1B.rijksmuseum.intra> Message-ID: For my part, I tend to review patches textual to see if they make sense as a changeset. If I cannot tell from reading what this patch does, I'll either apply and test, or ask for clarification. Generally, both of those actions take more effort than reading on Bugzilla, and thus take longer. I agree that it would be preferable to have the actual QA signoff on the patch itself when it gets through QA, so that our git signoff stats are more accurate. That does add the additional overhead of pulling down and applying each patch, then amending the commit and firing back up to BZ... not complicated, but additional steps. Hence why I haven't been doing it reliably. Any QA rules we can put into scripts to automatically check, I'm all for, as that can relieve some of the more tedious work of checking spacing and variable name declarations, and let QA look more in-depth about the patch's implementation. I know we've got a few such tests... anyone who is willing to write more goes in my Nice Person book. My new job is starting to ramp up further, and I'm finding myself doing less QA than I expected. I'll try to rectify that, but if the community feels I'm not doing the job as it needs to be done, I do hope folks will speak up and help us find a remedy to the situation. Cheers, -Ian On Tue, May 22, 2012 at 11:02 AM, Marcel de Rooy wrote: > Just a quick response on first glance: The numbers in this discussion are > imo far from accurate. As for me, I mostly QA without signing off, just to > spare time. In most cases I did apply and test (at least some > functionality, in other cases much more). I would not recommend doing QA in > Bugzilla only, perhaps with the exception of very small things. > Adding the rule that QA must do an additional signoff too will put more > work (better testing etc.) on the QA team, and will result in more delay. > If a QA member does not trust a patch, why not ask for a second signoff > (older idea..)? > > ________________________________________ > Van: koha-devel-bounces at lists.koha-community.org [ > koha-devel-bounces at lists.koha-community.org] namens Chris Cormack [ > chrisc at catalyst.net.nz] > Verzonden: dinsdag 22 mei 2012 10:51 > To: Paul Poulain > Cc: koha-devel at lists.koha-community.org > Onderwerp: Re: [Koha-devel] Proposed QA Enhancements > > * Paul Poulain (paul.poulain at biblibre.com) wrote: > > Le 21/05/2012 19:38, Chris Nighswonger a ?crit : > > > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow#Steps > > > > > > 1. I propose that we modify step 5 to read: > > > > > > "The patch is checked and signed-off by the QA team member. Then the > bug > > > status is set to Passed QA" > > Something I made during the 3.8 release was to add many things to the > > coding guidelines. My preference goes to QA rules that are clearly > > defined and explained. That will help QAing a lot, and "anyone" with a > > good Koha experience, and some time to dedicate should/could do it. > > > > I agree that we *must* have a functional AND a technical review of every > > patch, the 2 steps are different. > > > > > This will ensure that we have clarity that the patch was, indeed, > > > touched by a member of the QA team, as well as increasing the accuracy > > > of QA stats in git. > > Most QA is done in bugzilla only: when a patch is QAed, it's not > > signed-off & git bz attach most of the time. > > (that's also why your numbers below are meaningless : Ian has not made > > only 25 QA or joubu 5 ! OTOH, when I, as RM, push a patch, I always add > > my signature, that can be as RM or QA) > > That's what Chris N was asking for, that a sign off is added when the > patch is tested, it must have been applied and tested, so why not sign > off and attach it back on the bug at the same time as changing the bug > status. > > > > > > 2. I propose that the RM be the QA of last resort. At present the stats > > > show that the RM is doing the majority of the QA'ing. > > As I just wrote, I don't do the majority of QA, (even if I agree I do a > lot) > > > > As I've said previously, as RM, I dedicate more than half of my time to > > this task. > > I think that we could have someone dedicated full time to QA and someone > > dedicated full time to sign-off. And until we won't... we will face this > > kind of trouble. Our workflow is good, but require a large effort we > > collectively fail to "pay" until now. > > > > [ off-topic: BibLibre dedicate a lot of resources to Koha (see > > statistics on chris_c blog. A lot being "self-sponsored") and can't > > dedicate more. I think everybody should ask himself seriously "What did > > I do for Koha last week, what will I do next week ?" ] > > > I'm not sure we want to get into a who does more for Koha contest, nor > do I think that was the point of this email. > > I do think there are too many patches missing getting 2 independent > sign offs, and that is what we need to fix. > > Chris > > -- > Chris Cormack > Catalyst IT Ltd. > +64 4 803 2238 > PO Box 11-053, Manners St, Wellington 6142, New Zealand > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at aandc.org Tue May 22 17:49:56 2012 From: paul.a at aandc.org (Paul) Date: Tue, 22 May 2012 11:49:56 -0400 Subject: [Koha-devel] Print page - Firefox, etc Message-ID: <5.2.1.1.2.20120522085455.025a9590@stormy.ca> Our cataloguers are having a local problem that I was unaware of. This is probably Koha bug 7199 which appears to be a tad inactive; I'd be happy to assist, but have no knowledge whatsoever of how browsers render CSS|templates for printing. Trying to "print page" after a staff screen listing such as (the page itself is perfect) gives an oddball output with the "Results" and "Location" columns squeezed down to very narrow columns on the right hand side of the page. The "check box" column (normally very narrow) expands to well over 50% of page width. This happens (for us at least) in Firefox (v. 12.0), Chrome (build 16.0), Safari (5.1) and MSIE (6.0 - we don't have anything more recent in our Win machine.) A quick review of "equivalent" OPAC search pages (rather than staff-admin) shows no problems. Koha 3.06.01.000, on Linux 2.6.38, Perl 5.010001, Apache 2.2.17, mysql Ver 14.14 Distrib 5.1.54, for debian-linux-gnu Thanks - Paul From oleonard at myacpl.org Tue May 22 20:01:32 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 22 May 2012 14:01:32 -0400 Subject: [Koha-devel] Print page - Firefox, etc In-Reply-To: <5.2.1.1.2.20120522085455.025a9590@stormy.ca> References: <5.2.1.1.2.20120522085455.025a9590@stormy.ca> Message-ID: > This is probably Koha bug 7199 Probably, in that your description matches exactly the PDF attached to the bug ;) However, I can't reproduce the problem in master so this may already have been fixed. Tested in Firefox 12, Chrome 19, Opera 11, and IE 9 on Windows 7. Judging from the description and the timeline of Koha 3.6.1 I'm guessing the bug is caused by my first fix for Bug 6291 which was subsequently reverted in favor of a better fix. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Tue May 22 23:07:21 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 May 2012 23:07:21 +0200 Subject: [Koha-devel] KOCT pushed on contrib repo Message-ID: <4FBC0009.60907@biblibre.com> Hello, I just pushed a few minuts ago a patch with KOCT on the contrib repository (http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary) -- 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 Tue May 22 23:11:58 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 23 May 2012 09:11:58 +1200 Subject: [Koha-devel] KOCT pushed on contrib repo In-Reply-To: <4FBC0009.60907@biblibre.com> References: <4FBC0009.60907@biblibre.com> Message-ID: On 23 May 2012 09:07, Paul Poulain wrote: > Hello, > > I just pushed a few minuts ago a patch with KOCT on the contrib repository > (http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary) > Awesome! Thank you Chris From paul.a at aandc.org Wed May 23 02:15:52 2012 From: paul.a at aandc.org (Paul) Date: Tue, 22 May 2012 20:15:52 -0400 Subject: [Koha-devel] Print page - Firefox, etc In-Reply-To: References: <5.2.1.1.2.20120522085455.025a9590@stormy.ca> <5.2.1.1.2.20120522085455.025a9590@stormy.ca> Message-ID: <5.2.1.1.2.20120522152433.057eed98@localhost> At 02:01 PM 5/22/2012 -0400, Owen Leonard wrote: [snip] >Judging from the description and the timeline of Koha 3.6.1 I'm >guessing the bug is caused by my first fix for Bug 6291 which was >subsequently reverted in favor of a better fix. Thanks - what's the best way on a *production* server to revert the patch and install the better fix? I must admit to not fully understanding how git (or whatever is most appropriate) is setup, and after a look at bug 6291, there appear to be quite a few elements touched. In my sandbox, I once tried (unsuccessfully) to have two parallel but different versions of Koha so do not really want to try that on the production box. Best - Paul > -- 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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. , and From oleonard at myacpl.org Wed May 23 02:32:15 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 22 May 2012 20:32:15 -0400 Subject: [Koha-devel] Print page - Firefox, etc In-Reply-To: <5.2.1.1.2.20120522152433.057eed98@localhost> References: <5.2.1.1.2.20120522085455.025a9590@stormy.ca> <5.2.1.1.2.20120522152433.057eed98@localhost> Message-ID: > Thanks - what's the best way on a *production* server to revert the patch > and install the better fix? I don't know if this is the best way, but the most basic way is probably to grab the updated file from the git web interface: http://git.koha-community.org/gitweb/ I navigated to the 3.6.4 branch and found the most recent version of the file in question, the staff client print stylesheet: http://git.koha-community.org/gitweb/?p=koha-small.git;a=blob_plain;f=koha-tmpl/intranet-tmpl/prog/en/css/print.css;hb=441b98cea41ed7d99354195b79d5b4f44b194913 If you replace your file with that one it should be the functional equivalent of reverting that commit. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From cnighswonger at foundations.edu Thu May 24 15:50:33 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 24 May 2012 09:50:33 -0400 Subject: [Koha-devel] DateTime::Format::MySQL Message-ID: Hi all, The QOTD work recently committed to master adds DateTime::Format::MySQL as a core dependency thereby extending DateTime objects to handle proper formatting of datetime strings for MySQL. While Koha::DateUtils will parse ISO formatted datetime strings, the POD notes that the module is intended to be a temporary aid to demystify DateTime foo while we are transitioning fully to DateTime: "Koha has historically only used dates not datetimes and been content to 40 handle these as strings. It also has confused formatting with actual dates 41 this is a temporary module for wrappers to hide the complexity of switch to DateTime" There are similar DateTime::Format:: plugins for Pg, Oracle, and friends which may be implemented in Koha as support for those db's is added. Basically DateTime::Format::MySQL will parse a correctly MySQL formatted datetime and return a DateTime object for your morphing pleasure. It will also format a DateTime object and return a MySQL datetime string. Read more here: http://tinyurl.com/br49o38 By moving away form a custom DateTime formatting module we reduce long term maintenance costs and issues as well as moving a step closer to dropping the temporary Koha::DateUtils. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielg.koha at gmail.com Fri May 25 00:36:26 2012 From: danielg.koha at gmail.com (Daniel Grobani) Date: Thu, 24 May 2012 15:36:26 -0700 Subject: [Koha-devel] Official Koha Newsletter: Volume 3, Issue 5: May 2012 Message-ID: Official Koha Newsletter: Volume 3, Issue 5: May 2012 [Below is the text of the newsletter. For active links and a more readable format, please visit http://koha-community.org/koha-newsletter-volume-3-issue-5-may-2012] Official Koha Newsletter (ISSN 2153-8328) Volume 3, Issue 5: May 2012 Edited by Daniel Grobani, Koha Community Newsletter Editor. Please submit news items to danielg.koha at gmail.com. Table of Contents Koha Development Koha 3.8.1 Released Koha 3.6.5 Release Imminent Koha Statistics Database Schema Documentation Updated Koha Community New Koha Libraries Community Gossip Past Koha Events May General IRC Meeting New Zealand Koha User Group Day 2012 Upcoming Koha Events June General IRC Meeting KohaCon12 KohaCon13 Koha Development Koha 3.8.1 Released by Chris Cormack The Koha release team is happy to announce the release of Koha 3.8.1. This is a stable release and contains bugfixes as well as updated translations. Koha 3.8.1 can be downloaded here. Release notes are here. Installation instructions can be found here or in the INSTALL files that come in the tarball. Koha 3.6.5 Release Imminent As we go to press on 24 May 2012, Koha 3.6.5 is scheduled to be released today. Koha Statistics Chris Cormack, statistician par excellence, has posted bug statistics for April and statistics for Koha 3.8.1. Database Schema Documentation Updated Koha?s database schema documentation has been updated. Koha Community New Koha Libraries Gerard Cottet Library at Salus University (via ByWater Solutions) Lane Library at Ripon College (via ByWater Solutions) North Central Regional Library (via ByWater Solutions) Community Gossip Lenora Oftedahl reports: ?The StreamNet Library successfully upgraded from 3.0 to 3.6. In addition to our upgrade, we also successfully installed the Koha software on the same server as our WordPress CMS. The two programs are peacefully co-existing through the creative use of subdomains. You can visit our website at our new domain, http://www.streamnetlibrary.org. If other users would like assistance or have suggestions, please feel free to contact Lenora at oftl at critfc.org. Lee Miller of the Butte-Silver Bow Public Library in Montana reports that her library is co-hosting KohaCon12 and that she?ll be presenting at the conference on the use of open source software in Montana libraries and the use of new applications and discovery tools. Equinox Software is looking to hire a support specialist to provide technical support for Koha and Evergreen. Shire of Derby West Kimberley has become the first local government area in Australia to choose Koha to support the delivery of its public library services. More information is here. Past Koha Events May General IRC Meeting The May general IRC meeting was held on 2 May 2012. More info, including the agenda and links to the minutes, is here. New Zealand Koha User Group Day 2012 Current and prospective Koha users got together at the New Zealand Treasury on 15 May 2012 for the second New Zealand Koha users group meeting. Chris Cormack reported on the meeting here. Upcoming Koha Events June General IRC Meeting The June general IRC meeting will be held on Wednesday, 13 June 2012. More info is here. KohaCon12 KohaCon12 is nearly upon us! It will be held in Edinburgh, Scotland, UK, 5-7 June 2012. A hackfest will be held 9-11 June 2012. This is a free conference for everyone interested in the Koha library system. There is no registration fee, but attendees are asked to pre-register. The conference schedule has been posted here. The organizers continue to seek sponsors to help defray the cost of the conference. Sponsors so far include Tamil, PTFS Europe, Catalyst, Libriotech, Projektlink Konsult, The Galecia Group, C & P Bibliography Services, CALYX Information Essentials, and KohaAloha. Information on sponsorship is here. More details on the conference can be found here. KohaCon13 Bidding is now open for hosting of KohaCon13. Proposals can be viewed and added on this page of the Koha community wiki. From jcamins at cpbibliography.com Fri May 25 16:12:26 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Fri, 25 May 2012 10:12:26 -0400 Subject: [Koha-devel] Koha 3.6.5 released Message-ID: The Koha release team is happy to announce the release of Koha 3.6.5 This is a stable release and contains bugfixes as well as updated translations. You can download it at http://download.koha-community.org/ Go forth, download, and enjoy :) RELEASE NOTES FOR KOHA 3.6.5 24 May 2012 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.6.5 can be downloaded from: http://download.koha-community.org/koha-3.06.05.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.6.5 is a bugfix/maintenance release. Highlights of 3.6.5 ====================== 3916 critical Batch Modify tool overwrites dropdown fields - no option for "no change" 6488 critical opachiddenitems not working in master 7485 critical Cannot edit barcode on Fast Add 7513 critical MARC Import Hangs 7597 critical fines not recording the right info in the stats table 7631 critical Self checkout renewal fails because of reference to non-existent subroutine in sco-main.pl 7893 critical Missing build-dependency on libdatetime-format-dateparse-perl and libreadonly-perl 7924 critical Fix handling of command line arguments in koha-remove 7231 major ordering from staged file not using price 7272 major Fix for Bug 6328 causes user accounts to be frozen (SIP2) 7284 major Authority matching algorithm improvements 7454 major Sip renewal all response returns incorrect info 7482 major overdues report downloads without names 7581 major Holds not working in OPAC in singlebranchmode 7636 major error when trying to email cart when opacuserlogin set to don't allow 7838 major Add sort-string-utf.chr for Ukrainian and Russian Bugs fixed in 3.6.5 ====================== 1662 normal Is there a difference between Full and Simplified for Serials History 3216 normal UNIMARC author facets 4976 normal Status of item returned with process_koc.pl is empty in Intranet 5180 normal Autocomplete broken on overdues report 5373 normal fields listed on patron import do not match the csv file 5482 normal Translation problem in guided reports - Item field names 5657 normal biblio records update fails when updating multiple authorities linked with the same biblio 5749 normal The display of borrower adresses composed of streetnumber, streettype and address is broken 5841 normal Routing slip not displaying publication date 6125 normal Plugin for date acquired does not work on ACQ framework 6434 normal Many changes for Ukrainian and Russian sql-tables 6701 normal language on timeout system preference is wrong 7092 normal Complete-subfield searches TraceCompleteSubfields syspref not working correctly 7271 normal Revert getitems default sort to homebranch instead of holding branch 7445 normal Clicking on a tag gives "Language ... does not exist" 7493 normal Deleting a record with comments breaks 7537 normal Implement TraceCompleteSubfields, TraceSubjectSubdivisions and UseICU for NORMARC XSLT 7558 normal Serial issue note doubled up in full history 7579 normal Icons for authorized values/item types not showing in OPAC 7590 normal Cataloging authorities search result page is broken 7609 normal Improving links to find analytics and volumes when using UseControlnumber 7644 normal Invalid markup in staff client language chooser 7645 normal System preferences editor save button obscured by language chooser 7656 normal "undefined" pop-up message when putting hold on reference item 7665 normal Bibs with no ISBN's show broken images for covers when using Syndetics cover images. 7695 normal Boolean operator AND in XSLT gets translated 7699 normal Restricted until datepicker broken 7724 normal Tests requiring Zebra should be skipped if Zebra isn't set up 7727 normal NORMARC XSLT OPAC detail view shows double tabs 7749 normal Not all OKs on the start page are translatable 7766 normal C4/Auth.pm emits debug output to STDOUT 7780 normal fix translator tool verbosity 7824 normal [3.6 only] Typo in opac-userupdate.tt causes the first name to not show in the header 7837 normal nb-NO z3950servers.sql misses column names 7858 normal Missing packages from install_misc/ubuntu.packages 7885 normal Change filename of TransferLog suggested by packages to fit with logrotate 7886 normal C4/ShelfBrowser slow SQL performance 7940 normal Placing a hold on a single item from the staff cart causes errors 8020 normal Prepare debian packages for 3.8 release 4819 enhancement Add ID attribute to certain areas of OPAC so jquery can be used to hide them 7140 enhancement Add item type description on the catalogue search and detail screens 7143 enhancement Bug for tracking changes to the about page 7436 enhancement Set itemtypes.rentalcharge = 0 in sample data for nb-NO and de-DE 7617 enhancement Authority search results should optionally be sorted by system order 7700 enhancement Cart's more details view shows identity numbers 7734 enhancement NO_LIBRARY_SET should be translatable 7738 enhancement "Display more constraints" in subfield configuraton is not properly translatable 7746 enhancement In staff 'No public lists.' is not translatable 7758 enhancement Koha allowing LOST items to check out without alert 7760 enhancement Add ids and classes to every staff page to help with customizaton 7761 enhancement cleaning up empty declarations from staff-global.css 7876 enhancement Add ids to divs and spans with ids in opac-user.tt 7935 enhancement Introduce sys pref to control 'browse results' in OPAC New sysprefs in 3.6.5 ====================== * AutoCreateAuthorities * CatalogModuleRelink * LinkerKeepStale * LinkerModule * LinkerOptions * LinkerRelink * OpacBrowseResults * UseICU * dateformat System requirements ====================== Changes since 3.4: * Perl 5.10 is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.6/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese (Taiwan) * Danish * English (USA) * English (UK) * French (France) * German * Italian * Portuguese (Brazil) * Spanish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.6 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr?d?ric Demians QA Manager: Ian Walls Bug Wranglers: Katrin Fischer, Magnus Enger Past Release Maintainer (3.6.x): Chris Nighswonger < cnighswonger at foundations.edu> Release Maintainer (3.6.x): Jared Camins-Esakov Credits ====================== We thank the following libraries who are known to have sponsored new features in Koha 3.6: * Los Gatos Public Library * NEKLS * East Brunswick Public Library * Athens County Public Libraries * Horowhenua Library Trust * Halton Borough Council * South Taranaki District Council We thank the following individuals who contributed patches to Koha 3.6.5. 1 BibLibre 1 Gaetan Boisson 12 Jared Camins-Esakov 3 Colin Campbell 1 David 2 St?phane Delaune 2 Fr?d?ric Demians 1 Jonathan Druart 9 Magnus Enger 28 Katrin Fischer 1 Chris Hall 12 Kyle M Hall 3 Srdjan Jankovic 1 Janusz Kaczmarek 11 Owen Leonard 1 Sophie Meynieux 1 Chris Nighswonger 3 Dobrica Pavlinusic 1 Maxime Pelletier 6 Paul Poulain 1 MJ Ray 3 Liz Rea 2 Marcel de Rooy 3 Adrien Saurat 5 Robin Sheat 1 Zeno Tajoli 2 Serhij Dubyk {?????? ?????} We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.6.x (i.e., this version of Koha and future bugfix releases) is 3.6.x. Koha 3.8.0 was released on April 23, 2012. The next major feature release of Koha will be Koha 3.10.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 -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Fri May 25 18:00:22 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 25 May 2012 18:00:22 +0200 Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines Message-ID: <4FBFAC96.6050906@biblibre.com> In the wiki page http://wiki.koha-community.org/wiki/DB_schema_bugs, an insconsistency has been noticed: primary keys column name can be: id (in authorised_values table), xxxid (cityid), xxx_id (label_id), xxxId (limitId), xxxcode (branchcode), xxxnumber (borrowernumber) => choose how to name PK and update schema accordingly The bug 7065 add a foreign key to the reserves table, so I think it's time to clearly choose how we name primary keys. The possible options are below, my opinion: 1- id alone => will result in complexity & mistakes, this option must be discarded 2- xxxxid => short option, may result in hard readability. 3- xxxxId => we haven't decided if we want UC in field names. I won't discard this option, but does not favour it. 4- xxx_id => _ still undecided in field names, I'm not sure it's much better than the xxxid one 5- xxxxnumber => number is quite long, and may result in very long field names, which is not good. I does not like this option. Let's start the discussion -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From jcamins at cpbibliography.com Fri May 25 18:04:18 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Fri, 25 May 2012 12:04:18 -0400 Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines In-Reply-To: <4FBFAC96.6050906@biblibre.com> References: <4FBFAC96.6050906@biblibre.com> Message-ID: Paul, et. al., On Fri, May 25, 2012 at 12:00 PM, Paul Poulain wrote: > In the wiki page http://wiki.koha-community.org/wiki/DB_schema_bugs, an > insconsistency has been noticed: > primary keys column name can be: id (in authorised_values table), xxxid > (cityid), xxx_id (label_id), xxxId (limitId), xxxcode (branchcode), > xxxnumber (borrowernumber) => choose how to name PK and update schema > accordingly > > The bug 7065 add a foreign key to the reserves table, so I think it's > time to clearly choose how we name primary keys. > > The possible options are below, my opinion: > > 1- id alone => will result in complexity & mistakes, this option must > be discarded > 2- xxxxid => short option, may result in hard readability. > 3- xxxxId => we haven't decided if we want UC in field names. I won't > discard this option, but does not favour it. > 4- xxx_id => _ still undecided in field names, I'm not sure it's much > better than the xxxid one > I favor this option. I think it's readable, unlike (2), and short, unlike (6). 5- xxxxnumber => number is quite long, and may result in very long > field names, which is not good. I does not like this option. > Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From koha.sekjal at gmail.com Fri May 25 18:15:59 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Fri, 25 May 2012 12:15:59 -0400 Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines In-Reply-To: References: <4FBFAC96.6050906@biblibre.com> Message-ID: I also favour "_id" in general... the underscore separates it out as an identifier, and it's already this way in a large percentage of the database. We need to be very careful, though, if we change any of the existing key names, so that it not only doesn't break the Koha code, but also doesn't break saved Reports. The database update script must do a find/replace in the saved_sql.savedsql field (and should also update saved_sql.last_modified in the process). -Ian On Fri, May 25, 2012 at 12:04 PM, Jared Camins-Esakov < jcamins at cpbibliography.com> wrote: > Paul, et. al., > > On Fri, May 25, 2012 at 12:00 PM, Paul Poulain wrote: > >> In the wiki page http://wiki.koha-community.org/wiki/DB_schema_bugs, an >> insconsistency has been noticed: >> primary keys column name can be: id (in authorised_values table), xxxid >> (cityid), xxx_id (label_id), xxxId (limitId), xxxcode (branchcode), >> xxxnumber (borrowernumber) => choose how to name PK and update schema >> accordingly >> >> The bug 7065 add a foreign key to the reserves table, so I think it's >> time to clearly choose how we name primary keys. >> >> The possible options are below, my opinion: >> >> 1- id alone => will result in complexity & mistakes, this option must >> be discarded >> 2- xxxxid => short option, may result in hard readability. >> 3- xxxxId => we haven't decided if we want UC in field names. I won't >> discard this option, but does not favour it. >> 4- xxx_id => _ still undecided in field names, I'm not sure it's much >> better than the xxxid one >> > > I favor this option. I think it's readable, unlike (2), and short, unlike > (6). > > 5- xxxxnumber => number is quite long, and may result in very long >> field names, which is not good. I does not like this option. >> > > Regards, > Jared > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) jcamins at cpbibliography.com > (web) http://www.cpbibliography.com/ > > > _______________________________________________ > 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 marc at msys.ch Fri May 25 18:23:00 2012 From: marc at msys.ch (Marc Balmer) Date: Fri, 25 May 2012 18:23:00 +0200 Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines In-Reply-To: <4FBFAC96.6050906@biblibre.com> References: <4FBFAC96.6050906@biblibre.com> Message-ID: <4FBFB1E4.3050506@msys.ch> Am 25.05.12 18:00, schrieb Paul Poulain: > In the wiki page http://wiki.koha-community.org/wiki/DB_schema_bugs, an > insconsistency has been noticed: > primary keys column name can be: id (in authorised_values table), xxxid > (cityid), xxx_id (label_id), xxxId (limitId), xxxcode (branchcode), > xxxnumber (borrowernumber) => choose how to name PK and update schema > accordingly Technically, the name of a column does not matter much, since you can always refer to it as . to make it unambigous. In some databases that support schemas, like PostgreSQL, you can refer to columns even as ... > > The bug 7065 add a foreign key to the reserves table, so I think it's > time to clearly choose how we name primary keys. > > The possible options are below, my opinion: > > 1- id alone => will result in complexity & mistakes, this option must > be discarded I contradict. This results neither in complexity nor in mistakes. Imagine two tables, A and B, which both have an id column, then a select would probably look like the following: select A.id as aid, B.id as bid from A, B, where ... So it's not a problem. > 2- xxxxid => short option, may result in hard readability. > 3- xxxxId => we haven't decided if we want UC in field names. I won't > discard this option, but does not favour it. > 4- xxx_id => _ still undecided in field names, I'm not sure it's much > better than the xxxid one These three examples are only a matter of taste whithout any advantages or disadvantages. > 5- xxxxnumber => number is quite long, and may result in very long > field names, which is not good. I does not like this option. > > Let's start the discussion Since the name of a columns is actually not of any importance, from a technical/database view, why impose restrictions on how to use them? Not the column name, but the table schema should indicate whether something is a primary key or not. That said, I can live with any of above naming schemes, but I would prefer to not have a rule on this. I'd prefer [1] or [4], though. From cnighswonger at foundations.edu Fri May 25 18:30:02 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 25 May 2012 12:30:02 -0400 Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines In-Reply-To: <4FBFB1E4.3050506@msys.ch> References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch> Message-ID: On Fri, May 25, 2012 at 12:23 PM, Marc Balmer wrote: > Am 25.05.12 18:00, schrieb Paul Poulain: > > In the wiki page http://wiki.koha-community.org/wiki/DB_schema_bugs, an > > insconsistency has been noticed: > > primary keys column name can be: id (in authorised_values table), xxxid > > (cityid), xxx_id (label_id), xxxId (limitId), xxxcode (branchcode), > > xxxnumber (borrowernumber) => choose how to name PK and update schema > > accordingly > > Technically, the name of a column does not matter much, since you can > always refer to it as . to make it unambigous. > In some databases that support schemas, like PostgreSQL, you can refer > to columns even as ... > > I agree with Marc here. The best way is the correct way which is to cite the "relative path" ie. table.column. Otherwise I'd prefer option 4 for the reasons already stated by several. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Sat May 26 12:15:45 2012 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Sat, 26 May 2012 06:15:45 -0400 Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines In-Reply-To: <4FBFAC96.6050906@biblibre.com> References: <4FBFAC96.6050906@biblibre.com> Message-ID: I am for xxx_id Kyle On Fri, May 25, 2012 at 12:00 PM, Paul Poulain wrote: > xxx_id From chris at bigballofwax.co.nz Sun May 27 11:18:13 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sun, 27 May 2012 21:18:13 +1200 Subject: [Koha-devel] bugs.koha-community.org changes Message-ID: Hi All Tonight, I rejigged the configuration of a few sites I look after namely: bugs.koha-community.org schema.koha-community.org paste.koha-community.org download.koha-community.org piwik.koha-community.org They now live behind nginx, they seem to be working fine, but please let me know if you notice anything untoward. Chris From paul.poulain at biblibre.com Mon May 28 16:48:06 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 May 2012 16:48:06 +0200 Subject: [Koha-devel] Signing-off a patch for a customer Message-ID: <4FC39026.7040205@biblibre.com> Hello koha-devel, I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them) At BibLibre, we have 3 project managers: St?phane Delaye / Gaetan Boisson / Fran?ois Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch. I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works. I propose that we define a standard message, something like Signed-off-by: Delaye Stephane patch validated by , signed-off in their name Can I have your agreement with this idea ? (of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From marc at msys.ch Mon May 28 16:52:33 2012 From: marc at msys.ch (Marc Balmer) Date: Mon, 28 May 2012 16:52:33 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC39026.7040205@biblibre.com> References: <4FC39026.7040205@biblibre.com> Message-ID: <4FC39131.4000306@msys.ch> Am 28.05.12 16:48, schrieb Paul Poulain: > Hello koha-devel, > > I just pushed a follow-up for bug 6858. If you look at the patch, you'll > see that the author is from BibLibre, as well as the sign-offer. But if > you look more carefully on the patch comments, you may understand that > Stephane Delaye has signed-off "in the name of the library". We're > facing here a case where the library don't want/can't sign-off their > patch (they don't know how to do it and don't want to bother with doing > it. They just said this patch worked for them) > > At BibLibre, we have 3 project managers: St?phane Delaye / Gaetan > Boisson / Fran?ois Charbonnier. They are librarians and are doing the > glue between the library our customer and our developers. > they know how to sign-off a patch. > > I want, in this mail, request that those 3 ppl from BibLibre (and only > them) can be sign-offers for patches written by another BibLibre > developer, once the library has confirmed it works. > > I propose that we define a standard message, something like > Signed-off-by: Delaye Stephane > patch validated by , signed-off in their name > > Can I have your agreement with this idea ? I have absolutely no problem with this. To me it sounds like "signed of by stephane delaye of biblibre, on behalf of ", which is a perfectly fine proxy situation. > (of course, in case another support provider has the same kind of > situation, this would also be applicable. It's not something I want for > BibLibre only) - Marc From cnighswonger at foundations.edu Mon May 28 17:03:55 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 28 May 2012 11:03:55 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC39026.7040205@biblibre.com> References: <4FC39026.7040205@biblibre.com> Message-ID: Hi Paul, On Mon, May 28, 2012 at 10:48 AM, Paul Poulain wrote: > Hello koha-devel, > > I just pushed a follow-up for bug 6858. If you look at the patch, you'll > see that the author is from BibLibre, as well as the sign-offer. But if > you look more carefully on the patch comments, you may understand that > Stephane Delaye has signed-off "in the name of the library". We're > facing here a case where the library don't want/can't sign-off their > patch (they don't know how to do it and don't want to bother with doing > it. They just said this patch worked for them) > > At BibLibre, we have 3 project managers: St?phane Delaye / Gaetan > Boisson / Fran?ois Charbonnier. They are librarians and are doing the > glue between the library our customer and our developers. > they know how to sign-off a patch. > > I want, in this mail, request that those 3 ppl from BibLibre (and only > them) can be sign-offers for patches written by another BibLibre > developer, once the library has confirmed it works. > > I propose that we define a standard message, something like > Signed-off-by: Delaye Stephane > patch validated by , signed-off in their name > > Can I have your agreement with this idea ? > (of course, in case another support provider has the same kind of > situation, this would also be applicable. It's not something I want for > BibLibre only) A look over the history of that bug seems to indicate that Biblibre has been responsible for: 1. Creation of the code 2. Sign-off of the code 3. QA of the code I am not comfortable with this situation. It is not particularly a "Biblibre" thing with me, but a matter of principle. And it is occurring with greater frequency. I believe we need to stick with the principles we agreed to. This patch clearly missed the "approval" of a dis-interested party in its initial commit to master. (Perhaps Katrin mentioned this at some point, but I'm not sure.) We need to take up the slack here and get a disinterested QA on this followup prior to pushing it to master. I am of the strong opinion that going forward we need to maintain a more strict compliance with this principle of dis-interested sign-off/QA. Clearly at times one or the other may be impractical, however, one *or* the other is always possible. Perhaps it may not fit the desired schedule of the vendor, but violation of this principle is the first step down a slippery slope. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer at bsz-bw.de Mon May 28 17:19:39 2012 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Mon, 28 May 2012 17:19:39 +0200 Subject: [Koha-devel] Signing-off a patch for a customer References: <4FC39026.7040205@biblibre.com> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD01626725@Bodensee.bsz-bw.de> Hi Paul and all, I agree with Chris N. here. Every exception we make, makes it harder to explain and stick to our rules. I tinkk every patch should at least have 2 parties involved. Katrin -----Urspr?ngliche Nachricht----- Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Mo 28.05.2012 17:03 An: Paul Poulain Cc: koha-devel at lists.koha-community.org Betreff: Re: [Koha-devel] Signing-off a patch for a customer Hi Paul, On Mon, May 28, 2012 at 10:48 AM, Paul Poulain wrote: > Hello koha-devel, > > I just pushed a follow-up for bug 6858. If you look at the patch, you'll > see that the author is from BibLibre, as well as the sign-offer. But if > you look more carefully on the patch comments, you may understand that > Stephane Delaye has signed-off "in the name of the library". We're > facing here a case where the library don't want/can't sign-off their > patch (they don't know how to do it and don't want to bother with doing > it. They just said this patch worked for them) > > At BibLibre, we have 3 project managers: St?phane Delaye / Gaetan > Boisson / Fran?ois Charbonnier. They are librarians and are doing the > glue between the library our customer and our developers. > they know how to sign-off a patch. > > I want, in this mail, request that those 3 ppl from BibLibre (and only > them) can be sign-offers for patches written by another BibLibre > developer, once the library has confirmed it works. > > I propose that we define a standard message, something like > Signed-off-by: Delaye Stephane > patch validated by , signed-off in their name > > Can I have your agreement with this idea ? > (of course, in case another support provider has the same kind of > situation, this would also be applicable. It's not something I want for > BibLibre only) A look over the history of that bug seems to indicate that Biblibre has been responsible for: 1. Creation of the code 2. Sign-off of the code 3. QA of the code I am not comfortable with this situation. It is not particularly a "Biblibre" thing with me, but a matter of principle. And it is occurring with greater frequency. I believe we need to stick with the principles we agreed to. This patch clearly missed the "approval" of a dis-interested party in its initial commit to master. (Perhaps Katrin mentioned this at some point, but I'm not sure.) We need to take up the slack here and get a disinterested QA on this followup prior to pushing it to master. I am of the strong opinion that going forward we need to maintain a more strict compliance with this principle of dis-interested sign-off/QA. Clearly at times one or the other may be impractical, however, one *or* the other is always possible. Perhaps it may not fit the desired schedule of the vendor, but violation of this principle is the first step down a slippery slope. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at msys.ch Mon May 28 17:21:58 2012 From: marc at msys.ch (Marc Balmer) Date: Mon, 28 May 2012 17:21:58 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD01626725@Bodensee.bsz-bw.de> References: <4FC39026.7040205@biblibre.com> <028B1A54D03E7B4482CDCA4EC8F06BFD01626725@Bodensee.bsz-bw.de> Message-ID: <4FC39816.6070707@msys.ch> Am 28.05.12 17:19, schrieb Fischer, Katrin: > Hi Paul and all, > > I agree with Chris N. here. Every exception we make, makes it harder to > explain and stick to our rules. > I tinkk every patch should at least have 2 parties involved. But, if the patch we speak about, has been tested at the library, that makes it already two involved parties, I would say. Or am I missing sth here? - Marc > > Katrin > > > -----Urspr?ngliche Nachricht----- > Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris > Nighswonger > Gesendet: Mo 28.05.2012 17:03 > An: Paul Poulain > Cc: koha-devel at lists.koha-community.org > Betreff: Re: [Koha-devel] Signing-off a patch for a customer > > Hi Paul, > > On Mon, May 28, 2012 at 10:48 AM, Paul Poulain > wrote: > >> Hello koha-devel, >> >> I just pushed a follow-up for bug 6858. If you look at the patch, you'll >> see that the author is from BibLibre, as well as the sign-offer. But if >> you look more carefully on the patch comments, you may understand that >> Stephane Delaye has signed-off "in the name of the library". We're >> facing here a case where the library don't want/can't sign-off their >> patch (they don't know how to do it and don't want to bother with doing >> it. They just said this patch worked for them) >> >> At BibLibre, we have 3 project managers: St?phane Delaye / Gaetan >> Boisson / Fran?ois Charbonnier. They are librarians and are doing the >> glue between the library our customer and our developers. >> they know how to sign-off a patch. >> >> I want, in this mail, request that those 3 ppl from BibLibre (and only >> them) can be sign-offers for patches written by another BibLibre >> developer, once the library has confirmed it works. >> >> I propose that we define a standard message, something like >> Signed-off-by: Delaye Stephane >> patch validated by , signed-off in their name >> >> Can I have your agreement with this idea ? >> (of course, in case another support provider has the same kind of >> situation, this would also be applicable. It's not something I want for >> BibLibre only) > > > A look over the history of that bug seems to indicate that Biblibre has > been responsible for: > > 1. Creation of the code > 2. Sign-off of the code > 3. QA of the code > > I am not comfortable with this situation. It is not particularly a > "Biblibre" thing with me, but a matter of principle. And it is occurring > with greater frequency. > > I believe we need to stick with the principles we agreed to. This patch > clearly missed the "approval" of a dis-interested party in its initial > commit to master. (Perhaps Katrin mentioned this at some point, but I'm not > sure.) We need to take up the slack here and get a disinterested QA on this > followup prior to pushing it to master. > > I am of the strong opinion that going forward we need to maintain a more > strict compliance with this principle of dis-interested sign-off/QA. > Clearly at times one or the other may be impractical, however, one *or* the > other is always possible. Perhaps it may not fit the desired schedule of > the vendor, but violation of this principle is the first step down a > slippery slope. > > Kind Regards, > Chris > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From paul.poulain at biblibre.com Mon May 28 17:34:59 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 May 2012 17:34:59 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> Message-ID: <4FC39B23.2050908@biblibre.com> Le 28/05/2012 17:03, Chris Nighswonger a ?crit : > Hi Paul, > I believe we need to stick with the principles we agreed to. This patch > clearly missed the "approval" of a dis-interested party in its initial > commit to master. (Perhaps Katrin mentioned this at some point, but I'm > not sure.) We need to take up the slack here and get a disinterested QA > on this followup prior to pushing it to master. If you look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6858#c15, you'll see that MathildeF (from Nimes Public Library) tested the patch -during the hackfest-, so the initial patch has been "sign-off-ed" by her. Except she's a librarian and don't nothing about git. That's why I've setup sandboxes (and would like to improve them), but don't expect her to do more than this. (That's the same thing with the follow-up, except it's less clear on the bugzilla thread) > I am of the strong opinion that going forward we need to maintain a more > strict compliance with this principle of dis-interested sign-off/QA. > Clearly at times one or the other may be impractical, however, one *or* > the other is always possible. I mostly agree with you here. About the idea that i'm breaking our rule, i've reviewed all patches I've pushed since 3.8.0. Here is the list of the patches that are "BibLibre only" if you look at git: * 5a29c39c9fe838ba5af8f7c52937bb094b80d67a, trivial follow-up to the initial patch * 2338d02e9eded9dca6fdb6d425e1dc675c7c1a2d, patch signed-off by Nicole, does not appear because the patch had to be rebased (also tested by MathildeF with sandboxes) * b35d34e2ae4713c1f2f524ac565e2623e9f5243a, trivial follow-up to the initial patch * 18f21b32c6bfb4caefa00d8aaf650a67d1531d1c, trivial follow-up to the initial patch (I don't want to count bug 6858 in this list, because, for me, it has been tested by a dis-interested -well, in fact, calling the library "dis-interested" is maybe not the best term, but nevermind ;-) ) My conclusion is that I don't break the rule. When I do QA, I go from oldest to newest. If I see a patch that is from BibLibre only (which is already an uncommon case), I do my QA comments, but don't change the QA status, saying "I'll let someone else from the QA team change the status". I don't want to break the rule. I just request that 3 identified ppl from BibLibre can sign-off in the name of the customer (I like the Proxy term). > Perhaps it may not fit the desired > schedule of the vendor, but violation of this principle is the first > step down a slippery slope. It's not only a "vendor schedule". It's also for users: if the author says it works, the library also say it works, fact that is expressed through "the proxy" of BibLibre project manager, I don't understand where's the problem ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From jcamins at cpbibliography.com Mon May 28 17:40:19 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Mon, 28 May 2012 11:40:19 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC39816.6070707@msys.ch> References: <4FC39026.7040205@biblibre.com> <028B1A54D03E7B4482CDCA4EC8F06BFD01626725@Bodensee.bsz-bw.de> <4FC39816.6070707@msys.ch> Message-ID: Marc, But, if the patch we speak about, has been tested at the library, that > makes it already two involved parties, I would say. > Neither of the parties is disinterested. I think having the sign-off by the library is probably okay for this type of patch where there are only a certain number of parties who can test the feature, but in that case, Chris and Katrin suggested that QA should be done by someone other than party 1. For the patches where the only person who could do QA works for party 1 (not that I can imagine any situation in which case this would be true), a sign-off from someone without a financial interest in the patch should be required. Speaking as a Koha service provider, I am strongly in support of the requirement that at least one step in the approval process should be done by a disinterested party. It would certainly make developments commissioned by customers easier if I could mark the tested patch "signed off" on the basis of their testing, but I (and every other developer) rely on outside feedback for identifying the edge cases and bugs that just don't come up for our particular customers. If there isn't enough interest in a certain patch that's been "sitting around" too long, perhaps the solution is for the sponsor to place a non-monetary "bounty" on the patch. For example, "I will send half a batch of fudge to the first two people who provide useful feedback on the patch." We don't want rubber stamping. Often, I think, the reason a patch sits around too long is that no one else understands what the patch does. This is certainly the case for some of the patches that I've looked at. I can't figure out exactly what the patch does, so I don't want to *fail* it, but at the same time, I can't really sign off on it because I don't know if it's working. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Mon May 28 17:46:11 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Mon, 28 May 2012 11:46:11 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC39B23.2050908@biblibre.com> References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> Message-ID: Paul, et. al., Sorry about the second e-mail ten seconds after the first. (I don't want to count bug 6858 in this list, because, for me, it has > been tested by a dis-interested -well, in fact, calling the library > "dis-interested" is maybe not the best term, but nevermind ;-) ) > I don't see how the library that commissioned the development could be disinterested. I don't want to break the rule. I just request that 3 identified ppl > from BibLibre can sign-off in the name of the customer (I like the Proxy > term). > In case this wasn't clear, I have absolutely no objection to this, provided the customer sticks a note on the bug so the history is clear. Actually, if I have time, I'd like to extend your sandbox code to allow libraries to sign off directly from the sandbox. I'd also like to add features to allow the sandbox system to handle testing indexing. Better to have your project managers test other patches than spend time inserting "Signed-off-by" lines for libraries that are using the sandbox but don't understand git. :) Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 5p4m at gmx.de Mon May 28 17:45:42 2012 From: 5p4m at gmx.de (Mirko) Date: Mon, 28 May 2012 17:45:42 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC39816.6070707@msys.ch> References: <4FC39026.7040205@biblibre.com> <028B1A54D03E7B4482CDCA4EC8F06BFD01626725@Bodensee.bsz-bw.de> <4FC39816.6070707@msys.ch> Message-ID: <4FC39DA6.7030702@gmx.de> Marc Balmer wrote > Am 28.05.12 17:19, schrieb Fischer, Katrin: >> Hi Paul and all, >> >> I agree with Chris N. here. Every exception we make, makes it harder to >> explain and stick to our rules. >> I tinkk every patch should at least have 2 parties involved. > > But, if the patch we speak about, has been tested at the library, that > makes it already two involved parties, I would say. > > Or am I missing sth here? I think the point is what Chris called a "dis-interested" party. Both BibLibre as the vendor and the library itself as the party that requested a patch have a strong interest in getting the patch pushed. There is no party involved that does not have own interest in seeing the patch pushed and will have an "unbiased" look at it. I agree that having this exemption is a problem. Not because I don't trust BibLibre in any way, but as a matter of principle. If we make exeptions for BibLibre, we have to make them for all other vendors too. Who will decide what vendors are allowed to work this way? What about new companies without a long Koha history? - Mirko From Katrin.Fischer at bsz-bw.de Mon May 28 18:05:50 2012 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Mon, 28 May 2012 18:05:50 +0200 Subject: [Koha-devel] Signing-off a patch for a customer References: <4FC39026.7040205@biblibre.com><028B1A54D03E7B4482CDCA4EC8F06BFD01626725@Bodensee.bsz-bw.de><4FC39816.6070707@msys.ch> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD01626726@Bodensee.bsz-bw.de> Hi all, thanks Jared! That's what I meant. To bring this discussion back to Paul's initial question: I think we should encourage libraries to get involved in testing and participating in the community. The sandboxes are a tool to lower the barrier for libraries, which is great. I would like to see the library itself note the sign-off in bugzilla. It would be great if there were some notes about the testing (what, how, which configuration), but a short note would be a good start. It would be great if the credit could go to the library. We have talked about adding the 'sign offers' to the release notes as an additional encouragement for testers. I would love to see the names of lots of libraries showing up there. The other thing that would be a condition for me is "third party" (as Jared explained it) QA for those patches. Hope that makes sense, Katrin -----Urspr?ngliche Nachricht----- Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Jared Camins-Esakov Gesendet: Mo 28.05.2012 17:40 An: Marc Balmer Cc: koha-devel at lists.koha-community.org Betreff: Re: [Koha-devel] Signing-off a patch for a customer Marc, But, if the patch we speak about, has been tested at the library, that > makes it already two involved parties, I would say. > Neither of the parties is disinterested. I think having the sign-off by the library is probably okay for this type of patch where there are only a certain number of parties who can test the feature, but in that case, Chris and Katrin suggested that QA should be done by someone other than party 1. For the patches where the only person who could do QA works for party 1 (not that I can imagine any situation in which case this would be true), a sign-off from someone without a financial interest in the patch should be required. Speaking as a Koha service provider, I am strongly in support of the requirement that at least one step in the approval process should be done by a disinterested party. It would certainly make developments commissioned by customers easier if I could mark the tested patch "signed off" on the basis of their testing, but I (and every other developer) rely on outside feedback for identifying the edge cases and bugs that just don't come up for our particular customers. If there isn't enough interest in a certain patch that's been "sitting around" too long, perhaps the solution is for the sponsor to place a non-monetary "bounty" on the patch. For example, "I will send half a batch of fudge to the first two people who provide useful feedback on the patch." We don't want rubber stamping. Often, I think, the reason a patch sits around too long is that no one else understands what the patch does. This is certainly the case for some of the patches that I've looked at. I can't figure out exactly what the patch does, so I don't want to *fail* it, but at the same time, I can't really sign off on it because I don't know if it's working. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon May 28 18:08:58 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 May 2012 18:08:58 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> Message-ID: <4FC3A31A.1040003@biblibre.com> Le 28/05/2012 17:46, Jared Camins-Esakov a ?crit : > Paul, et. al., > > Sorry about the second e-mail ten seconds after the first. > > (I don't want to count bug 6858 in this list, because, for me, it has > been tested by a dis-interested -well, in fact, calling the library > "dis-interested" is maybe not the best term, but nevermind ;-) ) > > > I don't see how the library that commissioned the development could be > disinterested. me too, but the term "dis-interested" was used by chris_n, so I used it too. But I agree everybody involved in a patch has an interest to see it pushed ;-) > I don't want to break the rule. I just request that 3 identified ppl > from BibLibre can sign-off in the name of the customer (I like the Proxy > term). > In case this wasn't clear, I have absolutely no objection to this, > provided the customer sticks a note on the bug so the history is clear. I think you missed something: don't expect a *french* librarian to create an account on bugzilla that is in this strange language called *english* ! Some of them will do, but that's only a small part. [ Just for information: at the beginning, we asked our first customers to use bugzilla to declare bugs. 4 bugs in 2 years (rough numbers). Then we opened mantis, internal to BibLibre. We've almost reached mantis number 10000 !!! -we also use it internally, for our projects, not only for Koha support- ] > Actually, if I have time, I'd like to extend your sandbox code to allow > libraries to sign off directly from the sandbox. +1. That's also in my roadmap (but not on the top of my pile) I also want to submit again the new updatedatabase system. What is really bad with the current one is that patches with updatedatabase are almost always broken, they are almost impossible to test with sandboxes. Note that St?phane send a mail to all french libraries that came to Marseille hackfest to point some (5-10) bugs that could be signed-off. Without too much success in the feedback, but we will continue ! > I'd also like to add > features to allow the sandbox system to handle testing indexing. what do you mean by testing indexing ? > Better > to have your project managers test other patches than spend time > inserting "Signed-off-by" lines for libraries that are using the sandbox > but don't understand git. :) +1 (and, also, we won't add the librarian as "signed-off-by", because they could recieve mail -from jenkins for example- that will well... look strange to them) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Mon May 28 18:14:05 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 28 May 2012 12:14:05 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC3A31A.1040003@biblibre.com> References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> Message-ID: On Mon, May 28, 2012 at 12:08 PM, Paul Poulain wrote: > Le 28/05/2012 17:46, Jared Camins-Esakov a ?crit : > > Paul, et. al., > > > > Sorry about the second e-mail ten seconds after the first. > > > > (I don't want to count bug 6858 in this list, because, for me, it has > > been tested by a dis-interested -well, in fact, calling the library > > "dis-interested" is maybe not the best term, but nevermind ;-) ) > > > > > > I don't see how the library that commissioned the development could be > > disinterested. > me too, but the term "dis-interested" was used by chris_n, so I used it > too. But I agree everybody involved in a patch has an interest to see it > pushed ;-) > > By "disinterested" I specifically mean one who has no pecunary (cash) interest in seeing the patch pushed. This exlcue both ends of the transaction: the party paying and the party being paid. All others would be truly disinterested parties. > > I don't want to break the rule. I just request that 3 identified ppl > > from BibLibre can sign-off in the name of the customer (I like the > Proxy > > term). > > In case this wasn't clear, I have absolutely no objection to this, > > provided the customer sticks a note on the bug so the history is clear. > I think you missed something: don't expect a *french* librarian to > create an account on bugzilla that is in this strange language called > *english* ! > Some of them will do, but that's only a small part. > > Have them use *french* then... or whatever language they are comfortable in. There are enough resources to handle translation around here I think. Does BZ have a multi-lingual interface? Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Mon May 28 18:16:09 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 28 May 2012 12:16:09 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> Message-ID: On Mon, May 28, 2012 at 11:46 AM, Jared Camins-Esakov < jcamins at cpbibliography.com> wrote: > > I don't want to break the rule. I just request that 3 identified ppl >> from BibLibre can sign-off in the name of the customer (I like the Proxy >> term). >> > > In case this wasn't clear, I have absolutely no objection to this, > provided the customer sticks a note on the bug so the history is clear. > Actually, if I have time, I'd like to extend your sandbox code to allow > libraries to sign off directly from the sandbox. I'd also like to add > features to allow the sandbox system to handle testing indexing. Better to > have your project managers test other patches than spend time inserting > "Signed-off-by" lines for libraries that are using the sandbox but don't > understand git. :) > > > +1,000 Having things scripted so that anyone on a sandbox can sign-off both in BZ and git would be spectacular. Perhaps authentication could be coordinated between BZ and the sandbox to ensure some level of integrity. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon May 28 18:28:58 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 May 2012 18:28:58 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> Message-ID: <4FC3A7CA.9040109@biblibre.com> Le 28/05/2012 18:16, Chris Nighswonger a ?crit : > On Mon, May 28, 2012 at 11:46 AM, Jared Camins-Esakov > > wrote: > Having things scripted so that anyone on a sandbox can sign-off both in > BZ and git would be spectacular. Perhaps authentication could be > coordinated between BZ and the sandbox to ensure some level of integrity. there is already an authentication, but it's a "static" one. on biblibre sandboxes, it's my login that is used. That's different from the author of the signoff, that an easy git config ... can change on the fly. What would be pretty easy to do would be: * have a signoff.pl page (like sandbox.pl) * the user enter his mail, name, bug number * the script does "git config $name / $mail" + git bz attach $bugnumber * the user goes to bugzilla, obsolete manually the bug and change the status to "signed-off" (we even could easily redirect to the bugzilla page). The requirement would be to have the user having a bugzilla account. That would also mean the signed-off patch would look as if uploaded by me (for BibLibre sandboxes), but that's not a problem. We even could create a "fake sandbox" account if we want. HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Mon May 28 18:30:31 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 May 2012 18:30:31 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> Message-ID: <4FC3A827.8070204@biblibre.com> Le 28/05/2012 18:14, Chris Nighswonger a ?crit : > Have them use *french* then... or whatever language they are comfortable > in. There are enough resources to handle translation around here I think. > Does BZ have a multi-lingual interface? Yes it does. although the quality was quite average last time I've checked (many years ago). That would be a good + to have bugzilla in french, for sure ! -- 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 28 21:58:45 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 29 May 2012 07:58:45 +1200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC3A827.8070204@biblibre.com> References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> Message-ID: On May 29, 2012 4:30 AM, "Paul Poulain" wrote: > > Le 28/05/2012 18:14, Chris Nighswonger a ?crit : > > > Have them use *french* then... or whatever language they are comfortable > > in. There are enough resources to handle translation around here I think. > > Does BZ have a multi-lingual interface? > > Yes it does. although the quality was quite average last time I've > checked (many years ago). > That would be a good + to have bugzilla in french, for sure ! > > Lucky bugzilla is also free software, we can fix translation issues. Be nice to give back to a project we use daily. And to add my 2cents, I also support at least one disinterested party preferably 2 in the signoff/qa. I also heavily support making it easier for French speakers to sign off. Im happy if they comment in French too, I know enough French speakers to have it translated when I push to 3.8.x. Maybe a task for hackfest. Chris > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Mon May 28 23:15:40 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 29 May 2012 09:15:40 +1200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> Message-ID: On 29 May 2012 07:58, Chris Cormack wrote: > > On May 29, 2012 4:30 AM, "Paul Poulain" wrote: >> >> Le 28/05/2012 18:14, Chris Nighswonger a ?crit : >> >> > Have them use *french* then... or whatever language they are comfortable >> > in. There are enough resources to handle translation around here I >> > think. >> > Does BZ have a multi-lingual interface? >> >> Yes it does. although the quality was quite average last time I've >> checked (many years ago). >> That would be a good + to have bugzilla in french, for sure ! >> >> > Lucky bugzilla is also free software, we can fix translation issues. Be nice > to give back to a project we use daily. > > And to add my 2cents, I also support at least one disinterested party > preferably 2 in the signoff/qa. > I also heavily support making it easier for French speakers to sign off. Im > happy if they comment in French too, I know enough French speakers to have > it translated when I push to 3.8.x. > > Maybe a task for hackfest. > Well it was was easier than I thought. http://bugs.koha-community.org/bugzilla3/ Top right should have a language chooser, only in 3 languages now, EN, DE, and FR .. but if people want I can install any of the ones here http://www.bugzilla.org/download/#localizations (that are for 4.2/4.2.1) Just let me know Chris From nengard at gmail.com Tue May 29 09:50:48 2012 From: nengard at gmail.com (Nicole Engard) Date: Tue, 29 May 2012 08:50:48 +0100 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> Message-ID: Just to add in my opinion here. As someone who has been in Paul's situation, where a library (that has paid us to write them code) has been testing (and sometimes using the code in production) and has confirmed that things work I agree that putting a sign off in their name should be an okay practice. I also agree though that someone not from my company should QA the patch - that extra set of outside eyes is essential. What I don't think should happen (and I don't think anyone is suggesting this) is that a patch that is written by our company and signed off by our partner should have to wait for another sign off before hitting the QA queue. Thanks (and see many of you soon!), Nicole C. Engard From paul.poulain at biblibre.com Tue May 29 10:00:12 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 May 2012 10:00:12 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39026.7040205@biblibre.com> <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> Message-ID: <4FC4820C.2080307@biblibre.com> Le 29/05/2012 09:50, Nicole Engard a ?crit : > Just to add in my opinion here. > > As someone who has been in Paul's situation, where a library (that has > paid us to write them code) has been testing (and sometimes using the > code in production) and has confirmed that things work I agree that > putting a sign off in their name should be an okay practice. I also > agree though that someone not from my company should QA the patch - > that extra set of outside eyes is essential. Thanks Nicole, I'm "happy" to see BibLibre is not the only one facing this kind of problem. > What I don't think should happen (and I don't think anyone is > suggesting this) is that a patch that is written by our company and > signed off by our partner should have to wait for another sign off > before hitting the QA queue. Agreed. Side comment: in some cases, as RM, I switch back a QAed patch to "need sign-off" for some patches that are large and/or require a very careful testing. That's quite uncommon, and not related to who made/signed-off the patch. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From dpavlin at rot13.org Tue May 29 11:24:26 2012 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Tue, 29 May 2012 11:24:26 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC4820C.2080307@biblibre.com> References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> Message-ID: <20120529092426.GA5373@rot13.org> On Tue, May 29, 2012 at 10:00:12AM +0200, Paul Poulain wrote: > Le 29/05/2012 09:50, Nicole Engard a ?crit : > > Just to add in my opinion here. > > > > As someone who has been in Paul's situation, where a library (that has > > paid us to write them code) has been testing (and sometimes using the > > code in production) and has confirmed that things work I agree that > > putting a sign off in their name should be an okay practice. I also > > agree though that someone not from my company should QA the patch - > > that extra set of outside eyes is essential. > Thanks Nicole, > I'm "happy" to see BibLibre is not the only one facing this kind of problem. I would just like to add that we are in same situation with EAN-13 barcode support[1]. They have running it in production, signing off patches is somewhat of high bar for them. 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From chris at bigballofwax.co.nz Tue May 29 11:35:49 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 29 May 2012 21:35:49 +1200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <20120529092426.GA5373@rot13.org> References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org> Message-ID: On 29 May 2012 21:24, Dobrica Pavlinusic wrote: > On Tue, May 29, 2012 at 10:00:12AM +0200, Paul Poulain wrote: >> Le 29/05/2012 09:50, Nicole Engard a ?crit : >> > Just to add in my opinion here. >> > >> > As someone who has been in Paul's situation, where a library (that has >> > paid us to write them code) has been testing (and sometimes using the >> > code in production) and has confirmed that things work I agree that >> > putting a sign off in their name should be an okay practice. ?I also >> > agree though that someone not from my company should QA the patch - >> > that extra set of outside eyes is essential. >> Thanks Nicole, >> I'm "happy" to see BibLibre is not the only one facing this kind of problem. > > I would just like to add that we are in same situation with EAN-13 > barcode support[1]. They have running it in production, signing off > patches is somewhat of high bar for them. > > 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 > Is logging into bugzilla and commenting on the bug too much of a high bar also? Or, how about using gerrit, to sign off, eg http://gerrit.workbuffer.org:8080/#/c/7/ If they were logged in, they could mark that verified. Or use the Biblibre sandboxes to do something similar? I think making it easier for people to do the first sign off is a good thing, of course I'd still like to see ideally 2 other disinterested parties checking it before it was pushed too. Chris From kyle.m.hall at gmail.com Tue May 29 12:30:34 2012 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Tue, 29 May 2012 06:30:34 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <20120529092426.GA5373@rot13.org> References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org> Message-ID: I am also of the mind the sign-off should be allowed by another employee of the same organization as the developer, provided they signer has no history of signing off on patches without testing. I do strongly also believe that QA must then be done by a disinterested party. Kyle On Tue, May 29, 2012 at 5:24 AM, Dobrica Pavlinusic wrote: > On Tue, May 29, 2012 at 10:00:12AM +0200, Paul Poulain wrote: >> Le 29/05/2012 09:50, Nicole Engard a ?crit : >> > Just to add in my opinion here. >> > >> > As someone who has been in Paul's situation, where a library (that has >> > paid us to write them code) has been testing (and sometimes using the >> > code in production) and has confirmed that things work I agree that >> > putting a sign off in their name should be an okay practice. ?I also >> > agree though that someone not from my company should QA the patch - >> > that extra set of outside eyes is essential. >> Thanks Nicole, >> I'm "happy" to see BibLibre is not the only one facing this kind of problem. > > I would just like to add that we are in same situation with EAN-13 > barcode support[1]. They have running it in production, signing off > patches is somewhat of high bar for them. > > 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 > > -- > 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/ From M.de.Rooy at rijksmuseum.nl Tue May 29 13:50:10 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Tue, 29 May 2012 11:50:10 +0000 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org>, Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> I agree with most responses in this thread: If a company makes a patch, a customer of that company signs off, it should not be QAed by that company, but by a "neutral" party. The QAer should even be allowed to ask for a second outside signoff if he feels the patch needs that additional proof. As Paul mentioned earlier (he does QA but does not set the status): In order to prevent the appearance of pushing the process, you could even ask if it would be wiser to refrain from such QA comments. (Or just mail them to the author.) Marcel ________________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Kyle Hall [kyle.m.hall at gmail.com] Verzonden: dinsdag 29 mei 2012 12:30 To: Dobrica Pavlinusic Cc: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Signing-off a patch for a customer I am also of the mind the sign-off should be allowed by another employee of the same organization as the developer, provided they signer has no history of signing off on patches without testing. I do strongly also believe that QA must then be done by a disinterested party. Kyle From samuel.desseaux at ecp.fr Tue May 29 13:55:00 2012 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Tue, 29 May 2012 13:55:00 +0200 Subject: [Koha-devel] opac not available Message-ID: <4FC4B914.3070707@ecp.fr> Hello, Since i've upgraded for koha 3.8, i can't access on my opac. I think my virtualhost is good (i join it in attached file) but maybe there's something wrong i've not seen. I've the same url with two differents ports. For the intranet, it's ok but for the opac, it's the problem. thank you. samuel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: koha.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 326 bytes Desc: not available URL: From paul.poulain at biblibre.com Tue May 29 14:05:31 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 May 2012 14:05:31 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org>, <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4FC4BB8B.6040204@biblibre.com> Le 29/05/2012 13:50, Marcel de Rooy a ?crit : > I agree with most responses in this thread: If a company makes a patch, a customer of that company signs off, > it should not be QAed by that company, but by a "neutral" party. > The QAer should even be allowed to ask for a second outside signoff if he feels the patch needs that additional proof. What's the QA done for ? it's looking at the quality of the code. So, a QAer can request a 2nd signoff, but only if he feel that the code is missing a case (like "I feel this code will work for UNIMARC, could someone check for MARC21" ? or "work for sysprefX = OFF, must be checked for sysprefX = ON as well". I feel that should be an uncommon case. The RM has a more global responsibility to ensure the global consistency of the soft. > As Paul mentioned earlier (he does QA but does not set the status): > In order to prevent the appearance of pushing the process, > you could even ask if it would be wiser to refrain from such QA comments. (Or just mail them to the author.) I'm not sure I understand ? Do you mean I should not QA if I can't set the status ? Sound a very bad idea : if I see something wrong, like an unconditionnal warn, a missing use Modern::Perl, it must be said publicly, to avoid having another QAer requesting this problem to be fixed Reminder (or information in case you don't know) = I usually QA & push patches ordered by last modification date, ASC (So the oldest 1st). If I see something wrong while I'm reviewing, I don't understand why I should stay silent ! HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From robin at catalyst.net.nz Tue May 29 14:15:09 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 30 May 2012 00:15:09 +1200 Subject: [Koha-devel] opac not available In-Reply-To: <4FC4B914.3070707@ecp.fr> References: <4FC4B914.3070707@ecp.fr> Message-ID: <4FC4BDCD.9020000@catalyst.net.nz> Op 29-05-12 23:55, Samuel Desseaux schreef: > I've the same url with two differents ports. For the intranet, it's ok > but for the opac, it's the problem. You never said what your problem is. Robin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From samuel.desseaux at ecp.fr Tue May 29 14:22:19 2012 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Tue, 29 May 2012 14:22:19 +0200 Subject: [Koha-devel] opac not available In-Reply-To: <4FC4BDCD.9020000@catalyst.net.nz> References: <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> Message-ID: <4FC4BF7B.4000500@ecp.fr> Le 29/05/2012 14:15, Robin Sheat a ?crit : > Op 29-05-12 23:55, Samuel Desseaux schreef: >> I've the same url with two differents ports. For the intranet, it's ok >> but for the opac, it's the problem. > You never said what your problem is. > > Robin. When i want go to the intranet (koha.ecp.fr:8080), everything is ok. When i want to go on the opac (koha.ecp.fr:80), i've this message " It works! This is the default web page for this server. The web server software is running but no content has been added, yet." Maybe it's a dns issue or something else? > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 326 bytes Desc: not available URL: From semarie-koha at latrappe.fr Tue May 29 14:57:49 2012 From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie) Date: Tue, 29 May 2012 14:57:49 +0200 Subject: [Koha-devel] opac not available In-Reply-To: <4FC4BF7B.4000500@ecp.fr> References: <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> <4FC4BF7B.4000500@ecp.fr> Message-ID: <20120529125749.GA5535@latrappe.fr> On Tue, May 29, 2012 at 02:22:19PM +0200, Samuel Desseaux wrote: > Le 29/05/2012 14:15, Robin Sheat a ?crit : > >Op 29-05-12 23:55, Samuel Desseaux schreef: > >>I've the same url with two differents ports. For the intranet, it's ok > >>but for the opac, it's the problem. > >You never said what your problem is. > > > >Robin. > > When i want go to the intranet (koha.ecp.fr:8080), everything is ok. > > When i want to go on the opac (koha.ecp.fr:80), i've this message " > > > It works! > > This is the default web page for this server. > > The web server software is running but no content has been added, yet." > > > Maybe it's a dns issue or something else? Hello Samuel, The address http://koha.ecp.fr/ works (for me): i could access your opac... (using internet: I hope is wanted) So it should be a network problem (dns / port-forwarding / ...) Do you use *exactly* http://koha.ecp.fr/ ? (and not an ip or another network name, for example) The virtual-host works like it: - when a connection arrived to apache (so your browser need to know an IP address [generally resolved by dns]) - the server check the "Host:" header (presented by the browser) to determine which virtual-host the browser request The page "it works" is the default page (so match, when no other virtual-host match) An other point, the intranet is accessible over internet too (when adding :8080 to the URL). You could (should ?) restrict this access to "trusted" IP/address (with "accept/deny from" apache configuration directive at minimum). -- Fr?re S?bastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe Web: http://www.latrappe.fr/ From samuel.desseaux at ecp.fr Tue May 29 15:04:49 2012 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Tue, 29 May 2012 15:04:49 +0200 Subject: [Koha-devel] opac not available In-Reply-To: <20120529125749.GA5535@latrappe.fr> References: <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> <4FC4BF7B.4000500@ecp.fr> <20120529125749.GA5535@latrappe.fr> Message-ID: <4FC4C971.5080003@ecp.fr> Le 29/05/2012 14:57, Fr?re S?bastien Marie a ?crit : > On Tue, May 29, 2012 at 02:22:19PM +0200, Samuel Desseaux wrote: >> Le 29/05/2012 14:15, Robin Sheat a ?crit : >>> Op 29-05-12 23:55, Samuel Desseaux schreef: >>>> I've the same url with two differents ports. For the intranet, it's ok >>>> but for the opac, it's the problem. >>> You never said what your problem is. >>> >>> Robin. >> When i want go to the intranet (koha.ecp.fr:8080), everything is ok. >> >> When i want to go on the opac (koha.ecp.fr:80), i've this message " >> >> >> It works! >> >> This is the default web page for this server. >> >> The web server software is running but no content has been added, yet." >> >> >> Maybe it's a dns issue or something else? > > Hello Samuel, > > The address http://koha.ecp.fr/ works (for me): i could access your opac... (using internet: I hope is wanted) > > So it should be a network problem (dns / port-forwarding / ...) > > Do you use *exactly* http://koha.ecp.fr/ ? (and not an ip or another network name, for example) > > The virtual-host works like it: > - when a connection arrived to apache (so your browser need to know an IP address [generally resolved by dns]) > - the server check the "Host:" header (presented by the browser) to determine which virtual-host the browser request > > The page "it works" is the default page (so match, when no other virtual-host match) > > > > > An other point, the intranet is accessible over internet too (when adding :8080 to the URL). You could (should ?) restrict this access to "trusted" IP/address (with "accept/deny from" apache configuration directive at minimum). > Thank you, it's a problem in my office. For the intranet, i've planned it and do asap. -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 326 bytes Desc: not available URL: From paul.poulain at biblibre.com Tue May 29 15:07:32 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 May 2012 15:07:32 +0200 Subject: [Koha-devel] opac not available In-Reply-To: <20120529125749.GA5535@latrappe.fr> References: <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> <4FC4BF7B.4000500@ecp.fr> <20120529125749.GA5535@latrappe.fr> Message-ID: <4FC4CA14.2000207@biblibre.com> Le 29/05/2012 14:57, Fr?re S?bastien Marie a ?crit : > The address http://koha.ecp.fr/ works (for me): i could access your opac... (using internet: I hope is wanted) > > So it should be a network problem (dns / port-forwarding / ...) could is be a ridiculous caching problem: firefox (or a proxy) thinking he don't need to query Apache again, and you see the old initial page ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From fridolyn.somers at gmail.com Tue May 29 15:07:41 2012 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 29 May 2012 15:07:41 +0200 Subject: [Koha-devel] opac not available In-Reply-To: <20120529125749.GA5535@latrappe.fr> References: <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> <4FC4BF7B.4000500@ecp.fr> <20120529125749.GA5535@latrappe.fr> Message-ID: Hie, You must desactivate the Apache default website on port 80. Look into /etc/apache2/sites-enabled/. If you see file named "default", do : "sudo a2dissite default" and "sudo apache2ctl reload". It will reload apache configuration, do not use it in production. If doesn't work, look at who listens to 80 port with : "netstat". Regards, On Tue, May 29, 2012 at 2:57 PM, Fr?re S?bastien wrote: > On Tue, May 29, 2012 at 02:22:19PM +0200, Samuel Desseaux wrote: > > Le 29/05/2012 14:15, Robin Sheat a ?crit : > > >Op 29-05-12 23:55, Samuel Desseaux schreef: > > >>I've the same url with two differents ports. For the intranet, it's ok > > >>but for the opac, it's the problem. > > >You never said what your problem is. > > > > > >Robin. > > > > When i want go to the intranet (koha.ecp.fr:8080), everything is ok. > > > > When i want to go on the opac (koha.ecp.fr:80), i've this message " > > > > > > It works! > > > > This is the default web page for this server. > > > > The web server software is running but no content has been added, yet." > > > > > > Maybe it's a dns issue or something else? > > > Hello Samuel, > > The address http://koha.ecp.fr/ works (for me): i could access your > opac... (using internet: I hope is wanted) > > So it should be a network problem (dns / port-forwarding / ...) > > Do you use *exactly* http://koha.ecp.fr/ ? (and not an ip or another > network name, for example) > > The virtual-host works like it: > - when a connection arrived to apache (so your browser need to know an IP > address [generally resolved by dns]) > - the server check the "Host:" header (presented by the browser) to > determine which virtual-host the browser request > > The page "it works" is the default page (so match, when no other > virtual-host match) > > > > > An other point, the intranet is accessible over internet too (when adding > :8080 to the URL). You could (should ?) restrict this access to "trusted" > IP/address (with "accept/deny from" apache configuration directive at > minimum). > > -- > Fr?re S?bastien Marie > Abbaye Notre Dame de La Trappe > 61380 Soligny-la-Trappe > Web: http://www.latrappe.fr/ > _______________________________________________ > 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 fridolyn.somers at gmail.com Marsillargues - France -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.a at aandc.org Tue May 29 15:29:29 2012 From: paul.a at aandc.org (Paul) Date: Tue, 29 May 2012 09:29:29 -0400 Subject: [Koha-devel] opac not available In-Reply-To: <4FC4CA14.2000207@biblibre.com> References: <20120529125749.GA5535@latrappe.fr> <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> <4FC4BF7B.4000500@ecp.fr> <20120529125749.GA5535@latrappe.fr> Message-ID: <5.2.1.1.2.20120529092007.056a9c78@localhost> At 03:07 PM 5/29/2012 +0200, Paul Poulain wrote: >Le 29/05/2012 14:57, Fr?re S?bastien Marie a ?crit : > > The address http://koha.ecp.fr/ works (for me): i could access your > opac... (using internet: I hope is wanted) > > > > So it should be a network problem (dns / port-forwarding / ...) >could is be a ridiculous caching problem: firefox (or a proxy) thinking >he don't need to query Apache again, and you see the old initial page ? When we are in testing/maintenance/upgrade mode, we systematically use all browsers (FF, Opera, Chrome, Safari and limited IE) with cache disabled (or set to zero.) Doesn't everyone do this? We occasionally disable memcached also (although the variations and permutations on Apache 2.4 can be challenging.) A slightly more complex matter is if any intermediate proxy uses Squid, which can cache DNS as well as content. Best - P. From fridolyn.somers at gmail.com Tue May 29 15:35:48 2012 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 29 May 2012 15:35:48 +0200 Subject: [Koha-devel] opac not available In-Reply-To: <5.2.1.1.2.20120529092007.056a9c78@localhost> References: <4FC4B914.3070707@ecp.fr> <4FC4BDCD.9020000@catalyst.net.nz> <4FC4BF7B.4000500@ecp.fr> <20120529125749.GA5535@latrappe.fr> <4FC4CA14.2000207@biblibre.com> <5.2.1.1.2.20120529092007.056a9c78@localhost> Message-ID: Yes, we use Firefox with cache disabled. (One may use WebDeveloper extension to do so). DNS cache may still exist but a simple close/reopen resolves the problem I think. On Tue, May 29, 2012 at 3:29 PM, Paul wrote: > At 03:07 PM 5/29/2012 +0200, Paul Poulain wrote: > >> Le 29/05/2012 14:57, Fr?re S?bastien Marie a ?crit : >> > The address http://koha.ecp.fr/ works (for me): i could access your >> opac... (using internet: I hope is wanted) >> > >> > So it should be a network problem (dns / port-forwarding / ...) >> could is be a ridiculous caching problem: firefox (or a proxy) thinking >> he don't need to query Apache again, and you see the old initial page ? >> > > When we are in testing/maintenance/upgrade mode, we systematically use all > browsers (FF, Opera, Chrome, Safari and limited IE) with cache disabled (or > set to zero.) Doesn't everyone do this? We occasionally disable memcached > also (although the variations and permutations on Apache 2.4 can be > challenging.) A slightly more complex matter is if any intermediate proxy > uses Squid, which can cache DNS as well as content. > > Best - P. > ______________________________**_________________ > 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 fridolyn.somers at gmail.com Marsillargues - France -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.poulain at biblibre.com Tue May 29 16:18:58 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 May 2012 16:18:58 +0200 Subject: [Koha-devel] Sandbox improved Message-ID: <4FC4DAD2.6000603@biblibre.com> Hello, I worked last night and today to an improvement of sandboxes. If you go to : http://pro.test1.biblibre.com/cgi-bin/koha/sandbox.pl you'll see you have now the option to ask for putting a signoff to a given bug. This will (every minute) add a signoff (with "Your name" and "Your email") on the patch, attach it to bugzilla, set the status to "signed off", try obsolete the existing patch, and send a mail. the "try obsolete the existing patch" will be done only if there is only one patch attached to bugzilla. If there is more than 1, only the HEAD one is signed off and attached, so I can't obsolete all of them. To avoid a problem, in this case, the mail clearly states that you must go to the bug (the URL is provided) and obsolete manually. If someone want to test test1, I'll thank him. If someone want to take time to update the wiki page, i'll thank him. If someone want to provide a nicer look to sandbox.pl page, i'll thank him. If someone want to install sandbox on his own server, head to http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary and read http://git.koha-community.org/gitweb/?p=contrib/global.git;a=blob;f=sandbox/README.install;h=1895246402e944472a9754a22713d27126c084bb;hb=HEAD (Note that mails on test1 are not sent yet, for an unknown reason, they are blocked, our sysop is investigating) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From samuel.desseaux at ecp.fr Tue May 29 17:07:52 2012 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Tue, 29 May 2012 17:07:52 +0200 Subject: [Koha-devel] branchcode/ldap Message-ID: <4FC4E648.7050000@ecp.fr> Hi, For the connection with an ldap, koha need a "branchcode". All the others fields are ok for me except "branchcode". I don't find "branchcode" or equivalent in my ldap. Could someone explain to me what does it means branchcode? best regards samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 326 bytes Desc: not available URL: From koha.sekjal at gmail.com Tue May 29 17:12:10 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Tue, 29 May 2012 11:12:10 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: <4FC4BB8B.6040204@biblibre.com> References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org> <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> <4FC4BB8B.6040204@biblibre.com> Message-ID: To me, the role of QA is to be highly conservative. The QA team needs to look at a piece of incoming code, and not only judge it on how well it does it's intended purpose, but how it affects all the other code and workflows that surround it. The folks creating and signing off on code are often looking to answer the question "does it work?". I approach the QA process asking the question "what does it break?". Often times, the answer is "nothing", and we get a great new feature in our codebase. But sometimes the patch changes a core function or variable declaration in a way that isn't spotted, and only applicable on certain use cases. Or a new dependency is added that conflicts with something existing. Or a security hole is introduced under some conditions. A person asking "does this work?" isn't necessarily going to spot these things in their testing; our code is very complex. I'm sure we can all recall cases where piece of code was committed to do one thing, and then required a followup because it broke something else under specific circumstances. I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task. That said, if ANYONE sees a problem with a patch, I would encourage them to note it on the bug report. If s/he is confident this is a serious problem, or a violation of well-documented coding practices, then please feel free to set "Failed QA". That status is open to everyone to set, because, as stated earlier, QA is a highly conservative process, and I'd prefer a patch have to wait a little longer to be re-evaluated than to have a new bug introduced that could have been prevented with a word. That's my perspective on the matter. I'd also very much like to see it made easier for libraries to provide their sign-off on code, as they're often some of the best to evaluate "does it work?". -Ian On Tue, May 29, 2012 at 8:05 AM, Paul Poulain wrote: > Le 29/05/2012 13:50, Marcel de Rooy a ?crit : > > I agree with most responses in this thread: If a company makes a patch, > a customer of that company signs off, > > it should not be QAed by that company, but by a "neutral" party. > > The QAer should even be allowed to ask for a second outside signoff if > he feels the patch needs that additional proof. > > What's the QA done for ? it's looking at the quality of the code. So, a > QAer can request a 2nd signoff, but only if he feel that the code is > missing a case (like "I feel this code will work for UNIMARC, could > someone check for MARC21" ? or "work for sysprefX = OFF, must be checked > for sysprefX = ON as well". I feel that should be an uncommon case. > The RM has a more global responsibility to ensure the global consistency > of the soft. > > > As Paul mentioned earlier (he does QA but does not set the status): > > In order to prevent the appearance of pushing the process, > > you could even ask if it would be wiser to refrain from such QA > comments. (Or just mail them to the author.) > I'm not sure I understand ? > Do you mean I should not QA if I can't set the status ? Sound a very bad > idea : if I see something wrong, like an unconditionnal warn, a missing > use Modern::Perl, it must be said publicly, to avoid having another QAer > requesting this problem to be fixed > > Reminder (or information in case you don't know) = I usually QA & push > patches ordered by last modification date, ASC (So the oldest 1st). If I > see something wrong while I'm reviewing, I don't understand why I should > stay silent ! > > HTH > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdavis at uttyler.edu Tue May 29 17:12:43 2012 From: tdavis at uttyler.edu (Elliott Davis) Date: Tue, 29 May 2012 15:12:43 +0000 Subject: [Koha-devel] branchcode/ldap In-Reply-To: <4FC4E648.7050000@ecp.fr> References: <4FC4E648.7050000@ecp.fr> Message-ID: <7E2623294CB09249AA51272D2782A4F0A4A14C@CATBERT.info.uttyler.edu> Samuel, The branchcode allows you to assign patrons coming in from your ldap config to a certain branch. For example if you have multiple libraries and multiple ldap configurations you could assign people from one ldap tree to a certain branch and people from a different ldap tree to a different branch. This usually isn't the case and you can generally just hard code the branch value for your library in the branchcode field. Ex: TYLER Hope that helps! Elliott Davis -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Samuel Desseaux Sent: Tuesday, May 29, 2012 10:08 AM To: koha-devel at lists.koha-community.org; Koha Subject: [Koha-devel] branchcode/ldap Hi, For the connection with an ldap, koha need a "branchcode". All the others fields are ok for me except "branchcode". I don't find "branchcode" or equivalent in my ldap. Could someone explain to me what does it means branchcode? best regards samuel From cnighswonger at foundations.edu Wed May 30 02:21:53 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 29 May 2012 20:21:53 -0400 Subject: [Koha-devel] Gerrit as a workflow aid [Was: Re: Signing-off a patch for a customer] Message-ID: This is important enough to deserve its own thread imho. So I'm changing the subject. On Tue, May 29, 2012 at 5:35 AM, Chris Cormack wrote: > > Or, how about using gerrit, to sign off, eg > http://gerrit.workbuffer.org:8080/#/c/7/ > > If they were logged in, they could mark that verified. I am very much in favor of us implementing gerrit to help tighten up our workflow. I would like to see us begin a discussion on this and put it up for a vote among developers during the June or July meeting. So let's talk! Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Wed May 30 02:30:24 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 29 May 2012 20:30:24 -0400 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org> <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> <4FC4BB8B.6040204@biblibre.com> Message-ID: On Tue, May 29, 2012 at 11:12 AM, Ian Walls wrote: > To me, the role of QA is to be highly conservative. The QA team needs to > look at a piece of incoming code, and not only judge it on how well it does > it's intended purpose, but how it affects all the other code and workflows > that surround it. The folks creating and signing off on code are often > looking to answer the question "does it work?". I approach the QA process > asking the question "what does it break?". > > Often times, the answer is "nothing", and we get a great new feature in > our codebase. But sometimes the patch changes a core function or variable > declaration in a way that isn't spotted, and only applicable on certain use > cases. Or a new dependency is added that conflicts with something > existing. Or a security hole is introduced under some conditions. A > person asking "does this work?" isn't necessarily going to spot these > things in their testing; our code is very complex. I'm sure we can all > recall cases where piece of code was committed to do one thing, and then > required a followup because it broke something else under specific > circumstances. > > I strongly believe that having a 'neutral party' to do the QA work is > essential to keeping our codebase strong and healthy. We need the fresh > set of eyes, the different perspective, the alternate use case. We need > someone asking "what does it break?", and I don't think the folks who've > been asking the question "does it work?" are the best suited to that task. > +1 Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Wed May 30 02:38:29 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 30 May 2012 12:38:29 +1200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org> <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> <4FC4BB8B.6040204@biblibre.com> Message-ID: On 30 May 2012 12:30, Chris Nighswonger wrote: > On Tue, May 29, 2012 at 11:12 AM, Ian Walls wrote: >> >> To me, the role of QA is to be highly conservative.? The QA team needs to >> look at a piece of incoming code, and not only judge it on how well it does >> it's intended purpose, but how it affects all the other code and workflows >> that surround it.? The folks creating and signing off on code are often >> looking to answer the question "does it work?".? I approach the QA process >> asking the question "what does it break?". >> >> Often times, the answer is "nothing", and we get a great new feature in >> our codebase. But sometimes the patch changes a core function or variable >> declaration in a way that isn't spotted, and only applicable on certain use >> cases.? Or a new dependency is added that conflicts with something >> existing.? Or a security hole is introduced under some conditions.? A person >> asking "does this work?" isn't necessarily going to spot these things in >> their testing; our code is very complex.? I'm sure we can all recall cases >> where piece of code was committed to do one thing, and then required a >> followup because it broke something else under specific circumstances. >> >> I strongly believe that having a 'neutral party' to do the QA work is >> essential to keeping our codebase strong and healthy.? We need the fresh set >> of eyes, the different perspective, the alternate use case.? We need someone >> asking "what does it break?", and I don't think the folks who've been asking >> the question "does it work?" are the best suited to that task. > > > +1 > +1 from me also Chris From magnus at enger.priv.no Wed May 30 10:48:15 2012 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 30 May 2012 10:48:15 +0200 Subject: [Koha-devel] Signing-off a patch for a customer In-Reply-To: References: <4FC39B23.2050908@biblibre.com> <4FC3A31A.1040003@biblibre.com> <4FC3A827.8070204@biblibre.com> <4FC4820C.2080307@biblibre.com> <20120529092426.GA5373@rot13.org> <809BE39CD64BFD4EB9036172EBCCFA310DF6A91D@S-MAIL-1B.rijksmuseum.intra> <4FC4BB8B.6040204@biblibre.com> Message-ID: On 30 May 2012 02:38, Chris Cormack wrote: > On 30 May 2012 12:30, Chris Nighswonger wrote: >> On Tue, May 29, 2012 at 11:12 AM, Ian Walls wrote: >>> >>> To me, the role of QA is to be highly conservative.? The QA team needs to >>> look at a piece of incoming code, and not only judge it on how well it does >>> it's intended purpose, but how it affects all the other code and workflows >>> that surround it.? The folks creating and signing off on code are often >>> looking to answer the question "does it work?".? I approach the QA process >>> asking the question "what does it break?". >>> >>> Often times, the answer is "nothing", and we get a great new feature in >>> our codebase. But sometimes the patch changes a core function or variable >>> declaration in a way that isn't spotted, and only applicable on certain use >>> cases.? Or a new dependency is added that conflicts with something >>> existing.? Or a security hole is introduced under some conditions.? A person >>> asking "does this work?" isn't necessarily going to spot these things in >>> their testing; our code is very complex.? I'm sure we can all recall cases >>> where piece of code was committed to do one thing, and then required a >>> followup because it broke something else under specific circumstances. >>> >>> I strongly believe that having a 'neutral party' to do the QA work is >>> essential to keeping our codebase strong and healthy.? We need the fresh set >>> of eyes, the different perspective, the alternate use case.? We need someone >>> asking "what does it break?", and I don't think the folks who've been asking >>> the question "does it work?" are the best suited to that task. >> >> >> +1 >> > +1 from me also +1 Magnus Enger libriotech.no From magnus at enger.priv.no Wed May 30 10:56:09 2012 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 30 May 2012 10:56:09 +0200 Subject: [Koha-devel] Gerrit as a workflow aid [Was: Re: Signing-off a patch for a customer] In-Reply-To: References: Message-ID: On 30 May 2012 02:21, Chris Nighswonger wrote: > I am very much in favor of us implementing gerrit to help tighten up our > workflow. > > I would like to see us begin a discussion on this and put it up for a vote > among developers during the June or July meeting. > > So let's talk! And for those of us who don't already know it, maybe someone could point out some recommended reading ( http://gerrit-documentation.googlecode.com/svn/Documentation/2.4/intro-quick.html perhaps? ) and/or outline how they see it affecting our workflow? Best regards, Magnus Enger libriotech.no From chris at bigballofwax.co.nz Wed May 30 11:09:56 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 30 May 2012 21:09:56 +1200 Subject: [Koha-devel] Gerrit as a workflow aid [Was: Re: Signing-off a patch for a customer] In-Reply-To: References: Message-ID: On 30 May 2012 20:56, Magnus Enger wrote: > > And for those of us who don't already know it, maybe someone could > point out some recommended reading ( > http://gerrit-documentation.googlecode.com/svn/Documentation/2.4/intro-quick.html > perhaps? ) and/or outline how they see it affecting our workflow? > Here's how Mahara use it, http://www.slideshare.net/rkabalin/how-mahara-code-revision-works Chris From paul.poulain at biblibre.com Wed May 30 12:31:51 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 May 2012 12:31:51 +0200 Subject: [Koha-devel] Gerrit as a workflow aid [Was: Re: Signing-off a patch for a customer] In-Reply-To: References: Message-ID: <4FC5F717.8030208@biblibre.com> Le 30/05/2012 02:21, Chris Nighswonger a ?crit : > This is important enough to deserve its own thread imho. So I'm changing > the subject. wow... yes, this is important enough to deserve its own thread ! thanks for starting this, I completely missed chris_c link to Gerrit ! At first glance, the http://www.slideshare.net/rkabalin/how-mahara-code-revision-works is really appealing. > I am very much in favor of us implementing gerrit to help tighten up our workflow. +1 > I would like to see us begin a discussion on this and put it up for a vote among developers during the June or July meeting. I know that not everybody will be at the KohaCon12, but that's a topic we must talk about during the hackfest !!! Thanks a lot to both chris-es -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From christianjcj at gmail.com Wed May 30 23:01:04 2012 From: christianjcj at gmail.com (Christian Calle Jahuira) Date: Wed, 30 May 2012 17:01:04 -0400 Subject: [Koha-devel] Autolocation independent venues are enabled Message-ID: Dear It is a pleasure to greet you. I have the following doubt or error, I am trying to access the koha and I get the following message when I create a user as an administrator. I write from La Paz - Bolivia. "Error: User not authorized to exit click Error: Autolocation independent venues are enabled, and you are entering with an IP address that is not their home. " My question is whether something in the code movement auth.pl. Thanks for your help. -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: christianjcj at gmail.com Cel: 73017301 - 65151595 From chrisc at catalyst.net.nz Wed May 30 23:17:49 2012 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 31 May 2012 09:17:49 +1200 Subject: [Koha-devel] Autolocation independent venues are enabled In-Reply-To: References: Message-ID: <20120530211749.GK31982@rorohiko.wgtn.cat-it.co.nz> * Christian Calle Jahuira (christianjcj at gmail.com) wrote: > Dear > > It is a pleasure to greet you. > > I have the following doubt or error, I am trying to access the koha > and I get the following message when I create a user as an > administrator. > > I write from La Paz - Bolivia. > > "Error: User not authorized to exit click > Error: Autolocation independent venues are enabled, and you are > entering with an IP address that is not their home. " > > My question is whether something in the code movement auth.pl. > I suspect that you have the Autolocation systempreference turned on. And the user you are adding is trying to login as is not coming from the ip range you have defined for the library it belongs to. You could try switching the autolocation preference off. BTW what version of Koha are you running? Chris > > Thanks for your help. > > -- > Christian Jhonny Calle Jahuira > TUTOR ELEARNING - UMSA > Consultor Sistemas de Informacion de Bibliotecas de la UMSA > Email: christianjcj at gmail.com > Cel: 73017301 - 65151595 > _______________________________________________ > 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/ -- 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 lrea at nekls.org Thu May 31 21:47:35 2012 From: lrea at nekls.org (Liz Rea) Date: Thu, 31 May 2012 14:47:35 -0500 Subject: [Koha-devel] Reminder: please check on your stuff in Failed QA Message-ID: <50B1B576-C923-44C9-93BF-2A79F6926808@nekls.org> I was perusing through bugzilla today and I was surprised at how much stuff there was in Failed QA that is just apparently abandoned. There's a lot of good stuff in there, some of it with really trivial stuff to fix to allow inclusion. Please check on your patches and get them fixed up so we can get all of your wonderful code into Koha. Thanks! Liz Rea lrea at nekls.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: email_signature.jpeg Type: image/jpeg Size: 4862 bytes Desc: not available URL: From robert at naygames.com Thu May 31 22:02:11 2012 From: robert at naygames.com (Robert Nay) Date: Thu, 31 May 2012 14:02:11 -0600 Subject: [Koha-devel] Koha API for use in mobile app Message-ID: <92EE683C33FE4F7EBF895DDA9D0EB3F3@naygames.com> I am looking to create an iPhone/Android app for my local library, and am wondering about the best way to go about this. Does Koha have some API that can be accessed from a third-party client (in this case, a mobile application)? Koha pages seem to have an "unapi" link in them, is this something that could be used? I am relatively new to Koha, so any help or advice would be greatly appreciated. Thanks! Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Thu May 31 23:09:32 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 31 May 2012 17:09:32 -0400 Subject: [Koha-devel] Reminder: please check on your stuff in Failed QA In-Reply-To: <50B1B576-C923-44C9-93BF-2A79F6926808@nekls.org> References: <50B1B576-C923-44C9-93BF-2A79F6926808@nekls.org> Message-ID: > I was perusing through bugzilla today and I was surprised at how much > stuff there was in Failed QA that is just apparently abandoned. There's a saved search for it: http://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Failed%20QA&sharer_id=21&list_id=31391 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From koha4arab at gmail.com Tue May 22 23:49:12 2012 From: koha4arab at gmail.com (kouider bounama) Date: Tue, 22 May 2012 21:49:12 -0000 Subject: [Koha-devel] arabic Language for koha3.8 In-Reply-To: References: Message-ID: <1337723808811-5713443.post@n5.nabble.com> arabic (68%, OPAC 100%) -- View this message in context: http://koha.1045719.n5.nabble.com/Koha-3-8-1-released-tp5713183p5713443.html Sent from the Koha-devel mailing list archive at Nabble.com. From manjunayak1977 at gmail.com Mon May 28 10:55:16 2012 From: manjunayak1977 at gmail.com (Manju N) Date: Mon, 28 May 2012 08:55:16 -0000 Subject: [Koha-devel] Claim is not sending a serial claim notification Message-ID: Hi All, I am using koha 3.6 and postfix mail in which claim email notice is not generating for serial claim but other notification for patrons are working fine. I can view claim log activity Under Tools-Additional tools-Log viewer information but not sending claim notices to respective vendor email id. Can anyone suggest me how to fix this ? Thanks Manju Naika Asst.Librarian Central Library -------------- next part -------------- An HTML attachment was scrubbed... URL: