From kohadevel at agogme.com Wed Jan 5 20:11:49 2011 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 5 Jan 2011 19:11:49 -0000 (UCT) Subject: [Koha-devel] Record indexing and retrieval options Message-ID: <3165a8c5ecdb19967e18f8315de7a962.squirrel@wmail.agogme.com> In the middle of last month, I started adding a very detailed report of my investigations into various options for record indexing and retrieval in Koha to the end of the Switch to Solr RFC in the wiki, http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC . I moved the report to its own page at http://wiki.koha-community.org/wiki/Record_Indexing_and_Retrieval_Options_for_Koha and added links from the RFC to content related most directly to the work being done by BibLibre. The report aims at an objective record of facts about the particular options, except where some comparisons containing a point of view are necessary and appropriate in the advantages and disadvantages section. No overall recommendation is contained in the report. The purpose of the report is to provide information to help each of us better inform our judgements for each of our own conclusions. No overall conclusions are included in the report. There are other places for arguing for particular preferences overall including this mailing list. I will offer particular recommendations based on my investigation in some other messages. Yet, aside from the great exception of not abstracting to preserve existing record indexing and retrieval options, I find the choice of software options which BibLibre are taking in their implementation of Solr/Lucene to be reasonable. There will be time in future to address some Koha design deficiencies for record indexing which are unnecessarily preserved in BibLibre's work. I do not criticise BibLibre for where they have not corrected some pre-existing Koha deficiencies. 1. INVESTIGATIONS. The report is the product of much investigation of source code; testing; correspondence with Index Data and Knowledge Integration; and communication with several people including those working on Solr/Lucene record indexing at BibLibre. BibLibre provided a test server for which I was able to verify some Zebra bugs which had been reported by BibLibre before finding some of the bugs in the Zebra bugs database. Despite my efforts, the report may be especially prone to error or omission in the large scope of the problem. A few omissions where I simply did not have sufficient time to describe some aspect of some options are noted in the report or should otherwise be obvious. Corrections of errors and omissions would be greatly appreciated. Very little in the report is the result of direct answers from Index Data and Knowledge Integration. However, both Sebastian Hammer from Index Data and Ian Ibbotson from Knowledge Integration were very helpful in giving guidance about options to investigate. I have special thanks to give to Ian Ibbotson who was especially helpful when I followed some clues which both he and Sebastian had left in messages referring to some challenges of implementing Solr/Lucene. Some of my follow up questions have gone unanswered but few people are able to sustain giving sufficient answers to questions even when paid to do so. 2. SECTIONS. 2.1. OPTIONS. Sections of the report identify options for basic functional uses of record indexing and retrieval. Options are described for the possibility of mixing and matching options together instead of an exhaustive list of all possible combinations. 2.2. ADVANTAGES AND DISADVANTAGES. Each option has an advantages and disadvantages section. In trying to have a balanced presentation, some aspect of particular options listed in the advantages subsection are also listed in the disadvantages subsection with summary explanation about the disadvantageous part of that particular aspect. 2.3. CONFIGURATION. A configuration section identifies the files and scripts used to configure the various options which are most helpful in comparing options. Links to source code have been provided where possible. Summary comparison has been the goal not completeness but I welcome more complete improvements. BibLibre work on configuration supporting Solr/Lucene is summarised with links to source code. Some links to BibLibre demonstrations of their proof of concept and work in progress have not yet been included. Please help keep BibLibre configuration work in progress for supporting Solr/Lucene updated. 2.4. CODE FUNCTIONALITY. A summary of code functionality is given for each option. Links to source code have been provided where possible. This section is the one most likely to have mistakes which need correcting especially for how various Index Data programs relate to YAZ in the sequence of calls back and forth. I used logic rather than reading the source code in some cases. BibLibre work on code functionality supporting Solr/Lucene is summarised with links to source code. Some links to BibLibre demonstrations of their proof of concept and work in progress have not yet been included. Please help keep BibLibre code functionality work in progress for supporting Solr/Lucene updated. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From kohadevel at agogme.com Wed Jan 5 22:01:06 2011 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 5 Jan 2011 21:01:06 -0000 (UCT) Subject: [Koha-devel] Solr Search use cases In-Reply-To: <6a37a07ae9fe0042c51ad181e660eb40.squirrel@wmail.agogme.com> References: <4D13500B.2040100@biblibre.com> <4D135189.90605@alinto.com> <6a37a07ae9fe0042c51ad181e660eb40.squirrel@wmail.agogme.com> Message-ID: <76c0afd0d88daed9147caa9df359bc93.squirrel@wmail.agogme.com> Working in consultation with Claire Hernandez and Henri-Damien Laurent from BibLibre, I have replaced the test queries use cases Google Docs spreadsheet with tables in the wiki. Claire said that she would provide redirection links from the Google Docs spreadsheet for those missing this announcement. 1. EASE OF EDITING TABLES IN WIKI SYNTAX. There can be difficulties using wiki syntax to edit tables. The problem is mostly related to losing track of the column while editing content in a row. That problem is corrected by editing each cell of the table on its own line in wiki syntax as recommended on the MediaWiki and Wikipedia help pages for editing tables. The simplest MediaWiki table illustrates. {| border="1" | Column 1 Heading | Column 2 Heading | Column 3 Heading |- |row 1 column 1 content |row 1 column 2 content |row 1 column 3 content |- |row 2 column 1 content |row 2 column 2 content |row 2 column 3 content |} Empty cells are fine. Line breaks are generally ignored in wiki syntax, therefore, the separate lines for individual cells in a row are transformed into the correct HTML for a table row. If editing a table in wiki syntax is easy enough, then the main reason for using a Google Docs spreadsheet for adding test queries is gone. Use of non-free Google Docs software with is thus avoided. 2. LINKS. The main page for test queries is at http://wiki.koha-community.org/wiki/Solr/Lucene_Test_Queries_for_Koha . Pages which actually contain the tests are merely linked from that page and from the Switch to Solr RFC for Solr/Lucene queries. Solr/Lucene query syntax documentation and BibLibre work in progress demonstrations available for testing are linked from http://wiki.koha-community.org/wiki/Solr/Lucene_Documentation . Test query pages which have been created include the following. The main page for Solr/Lucene test queries is at http://wiki.koha-community.org/wiki/Solr/Lucene_Test_Queries_for_Koha . Simple user test queries are at http://wiki.koha-community.org/wiki/Simple_User_Test_Queries_for_Koha_with_Solr/Lucene . Simple user test queries are not expressed in Solr/Lucene query syntax/ See the wiki page with a couple of test cases which I created for explanation. SimpleServer Z39.50/SRU test queries are at http://wiki.koha-community.org/wiki/SimpleServer_as_a_Z39.50/SRU_Server_Test_Queries_for_Koha_with_Solr/Lucene . I created links from the main test queries page for test query pages for other options including OPAC metasearch with Solr/Lucene, nozebra, Zebra, etc. I do not have a near term intention to populate such pages myself, however, anyone interested may start them. 3. ORGANISING TEST QUERIES. After much work examining the existing the existing table of test queries and thinking about what would be needed for the most demanding use cases I found that the main table needed subdivision to help ensure that we have some tests which properly isolate particular functionality. Tests also need to combine functionality and almost every test inevitably combines some functionality. The test have been somewhat organised in one table but I found it difficult to determine at a glance what had and had not been tested. Even with such a small number of test cases, the organising principle which may have been used when starting seemed to be drifting as is inevitable for all organisational efforts. Good organisation merely provides functionally useful organising principles and constrains the rate of organisational drift. 3.1. TEST CASE COMPLETENESS. The easiest remedy to ensuring that we do not miss testing important functionality is to define the functionality in advance in a taxonomy of possible functionality. I used the most complete existing taxonomy of query functionality as defined in Z39.50/SRU as a model. I did not include all the details but enough basic categories to organise what we have and guide us to avoid missing tests for important functionality. No matter that no record indexing system system will support every type of query possible. Knowing what can be implemented and testing for that is important. Having conducted the exercise of categorising the tests, I note that we have no tests for some basic features. The categories which I defined are not detailed enough to list everything within particular tests. 3.2. REDUCING ORGANISATIONAL DRIFT. Separating the organisational parts into separate tables should help reduce the rate of drift into disorganisation. I have included an unclassified table as place to put queries where there is uncertainty about an appropriate place to include a new test query. Most importantly I expect the number of tests to grow greatly over time for particular functionality which may be difficult to implement without bugs or for which it is difficult to construct a single comprehensive test. The bugs or incompleteness may be in underlying dependencies and not in any aspect of the Koha implementation. I certainly do not expect any stemming automation to work perfectly, for example, and I imagine accumulating examples from several different languages where we need to know the limits of functionality. We may best identify such issues upstream and pass our findings upstream but we should be able to organise the problem ourselves. Growth in what needs organising poses challenges maintaining a functionally useful order. If we come to have hundreds of tests for stemming in different languages, for example, we could more them to a different page and link to upstream treatment. 3.3. ORGANISATIONAL COMPLETENESS. Only the main Solr/Lucene test queries page has a high degree of organisational completeness in the taxonomy of possible queries at mostly consistent level of detail. Much remains to be added in a similar manner to the page for SimpleServer Z39.50/SRU test queries. However, supporting many query options for a Z39.50/SRU server for the world to use is much less important than supporting every possible query option for the OPAC which has far greater use. 3.4. UNCLASSIFIED TABLE. We do not want to loose any test queries which people might have to hesitancy in relation to the organisation modeled on Z39.50/SRU organisation. An unclassified test queries table is provided at the end of each page for those who have trouble classifying their test queries and no time to improve the clarity of the organisation. 4. ADDITIONAL TABLE FORMATTING. The formatting of the tables in the wiki could be improved but I may not have time for a while with my other commitments. Tables could have actual titles instead of relying upon wiki section headings. Columns might be more uniform in width from one table to another instead of varying by the content of a particular table. Colour coding could distinguish work. Rows for which the feature test has been developed could appear in green for example. [There might also be a disadvantage to colour coding that people adding new rows to the table and not observing how the colour coding is functioning might inadvertently copy colour coding which does not apply to a newly added row. An inline comment of do not copy this bit comment if you are adding a new row might help.] Additional columns could be added if we need them in future such as priority and links to particular bug reports. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Mon, December 27, 2010 19:05, Thomas Dukleth wrote: > Reply inline: > > > On Thu, December 23, 2010 13:41, LAURENT Henri-Damien wrote: >> Le 23/12/2010 14:35, LAURENT Henri-Damien a ?crit : >>> Hi, >>> we proposed in our solr meeting to gather the use cases that you would >>> like to add and proove with the solr search. >>> We wondered why nobody had added any yet.... >>> And we realized that the document, though public, would not be >>> editable. >>> This has been fixed now. >>> So all the persons who were longing to add usecases are now able to do >>> so. The link is the same as previously publicised. >>> https://spreadsheets.google.com/pub?key=0AuZF5Y_c4pIxdEVzTjUtUGFoQnFpSkpfbTU5Ykc3b2c&hl=en&output=html >>> >>> Please, enter whatever query you have success or problem with on zebra. >>> We will try and do it with solr and then build the user interface for >>> it. >>> Hope that helps. >> Still failing to edit. >> This latest one should do : >> http://tinyurl.com/3ydnuhw >> If anyone wants to test and tell me if it is ok now. > > Yesterday, I had only an error pop-up dialog box at one minute or several > second intervals in multiple web browsers. > > Today, I had no edit options for the spreadsheet. > > I added an alternative use cases table to the BibLibre Solr RFC, > http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC#How_To_Help , for > those having difficulty editing the Google Docs spreadsheet. > [...] From cnighswonger at foundations.edu Thu Jan 6 14:02:31 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 6 Jan 2011 08:02:31 -0500 Subject: [Koha-devel] Update on 3.2 Roadmap Message-ID: My apologies to all for missing the meeting yesterday. Koha 3.2.x continues to roll along on its monthly release schedule thanks to the hard work of various developers and the 3.4 Release Manager. January's release of 3.2.3 is scheduled for the 22nd, just a little over two weeks from today. So far there are 40 some commits since the release of 3.2.2. The new work flow implemented upon the release of 3.2.0 has made scheduled, time-based maintenance releases a reality. I would encourage all interested parties to get behind this 100% as it will be the surest way to move Koha's entire release cycle to a time basis. A reminder to developers submitting patches which need to be back-ported to the 3.2.x branch: Please ensure that your patch will apply cleanly to both HEAD *and* 3.2.x. If not, please supply a separate patch marked for the 3.2.x branch. Patches causing merge conflicts will be rejected until fixed. Kia mau ki te mahi pai! Kind Regards, Chris NIghswonger Koha 3.2.x Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Jan 6 16:04:07 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 06 Jan 2011 16:04:07 +0100 Subject: [Koha-devel] News of BibLibre patches Message-ID: <4D25D9E7.40606@biblibre.com> After the KohaCon, we have submitted 9 branches with a lot of patches to be integrated to 3.4 A page has been opened to summarize that: http://wiki.koha-community.org/wiki/BibLibre_patches_to_be_integrated_for_3.4 Here is the status as of today : * 3 branches have been merged: admin / reports / serials * 2 branches are awaiting qa: the big one (related to circulation & members changes, see our RFCs on the wiki and #5575 on bugzilla. I have reset/recommited all the patches to have only 50+ patches instead of 200+) and the cataloguing one (that is quite large too, #5574) * I've sent a pull request for 3 branches : OPAC (#5584), authorities (#5581), acquisition (#5580) I won't sent a pull request on the various branch : looking carefully at it, it contains a lot of usefull things, but they are related to a lot of various things and can/will be splitted in smaller patches. we will split them and send the patches "one by one". Important notice: chris said yesterday at the irc meeting that the move to template::toolkit should be merged into master on feb. It means it becomes urgent to do QA on those branches & integrate them into master. It must be done before we move to T::T, or it will request too much work to be integrated. That's why I propose 2 IRC to work on the 2 main branches (circ / cataloguing). * proposed circ IRC qa-meeting: jan, 11th, from 12GMT to 14GMT, AND from 20GMT to 22GMT * proposed cataloguing qa-meeting: jan, 17th, from 12GMT to 14GMT, AND from 20GMT to 22GMT For those meetings, i'll setup a fresh install for ppl to test & give feedback. If someone want to test & give feedback before or after the meetings, feel free to add comments to the bugs. I know those branches are quite large, and it will be hard to signoff them, so I suggest ppl doing some tests add a comment on the BZ entry, to let chris know they have tested (thx to owen that already added an entry to #5574, that i'll fix asap) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From colin.campbell at ptfs-europe.com Thu Jan 6 17:48:33 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 06 Jan 2011 16:48:33 +0000 Subject: [Koha-devel] News of BibLibre patches In-Reply-To: <4D25D9E7.40606@biblibre.com> References: <4D25D9E7.40606@biblibre.com> Message-ID: <4D25F261.5000901@ptfs-europe.com> On 06/01/11 15:04, Paul Poulain wrote: > After the KohaCon, we have submitted 9 branches with a lot of patches to > be integrated to 3.4 > * I've sent a pull request for 3 branches : OPAC (#5584), authorities > (#5581), acquisition (#5580) On the acquisitions, I think this patch is a bit suspect without as syspref as it deletes items and biblios and I think that may conflict with how many people want their workflow > commit a0854683dbfcd44de390dd87afccffca786c57a3 > Author: Jean-Andr? Santoni > Date: Thu Aug 19 15:04:46 2010 +0200 > > (bug #4110) Delete items from aq order The are some regressions from some things addressed in master in that branch. That needs further testing. In the authorities branch there are the addition of some install files for UNIMARC in French. I'm assuming they could be signed off and pushed as is, can you confirm? They should not be dependent on the rest of the branch. (i.e. the search authorities change appears to fix some cases but break some currently working behaviour -- needs further testing to determine) Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From paul.poulain at biblibre.com Thu Jan 6 17:59:06 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 06 Jan 2011 17:59:06 +0100 Subject: [Koha-devel] News of BibLibre patches In-Reply-To: <4D25F261.5000901@ptfs-europe.com> References: <4D25D9E7.40606@biblibre.com> <4D25F261.5000901@ptfs-europe.com> Message-ID: <4D25F4DA.8090709@biblibre.com> Le 06/01/2011 17:48, Colin Campbell a ?crit : > On 06/01/11 15:04, Paul Poulain wrote: >> After the KohaCon, we have submitted 9 branches with a lot of patches to >> be integrated to 3.4 Hi Colin, (thx for the quick feedback) >> * I've sent a pull request for 3 branches : OPAC (#5584), authorities >> (#5581), acquisition (#5580) > On the acquisitions, I think this patch is a bit suspect without as > syspref as it deletes items and biblios and I think that may conflict > with how many people want their workflow >> commit a0854683dbfcd44de390dd87afccffca786c57a3 >> Author: Jean-Andr? Santoni >> Date: Thu Aug 19 15:04:46 2010 +0200 >> >> (bug #4110) Delete items from aq order For the item, I don't think so : you can't delete an order once the basket has been closed. So, it's usually related to an order placed by mistake. So you don't have the item, and if you delete the order line (because no more budget, or you choose a wrong supplier), then it's good to delete the item as well. I can't see a case where it functionnally relevant to delete the order line and not the item For the biblio, this can be discussed. But most of our libraries think that it's better to delete the biblio if there are no more items. Usually, the case is : * I added an order, that created item & biblio * oups, made a mistake (no more budget available, or wrong supplier) * delete the order * forget it => useless biblio remaining in the catalogue => library & users unhappy. If you hadn't the "forget it" line, I would agree. But when saying libraries : "hey, don't forget to delete the biblio when you delete the order, it's still here, it's usefull if you plan to order the book to someone else", they answer: 'i'll forget that the biblio is here, and create it again, resulting in 2 biblios in the catalogue' So we decided to delete the biblio as well. > The are some regressions from some things addressed in master in that > branch. That needs further testing. > > In the authorities branch there are the addition of some install files > for UNIMARC in French. I'm assuming they could be signed off and pushed > as is, can you confirm? They should not be dependent on the rest of the > branch. (i.e. the search authorities change appears to fix some cases > but break some currently working behaviour -- needs further testing to > determine) Some yes, but as it's written in one commit, there is a "default" authority now, that can be used for searching on all authority types. and we did not the MARC21 version of the default authority. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From colin.campbell at ptfs-europe.com Thu Jan 6 18:55:48 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 06 Jan 2011 17:55:48 +0000 Subject: [Koha-devel] News of BibLibre patches In-Reply-To: <4D25F4DA.8090709@biblibre.com> References: <4D25D9E7.40606@biblibre.com> <4D25F261.5000901@ptfs-europe.com> <4D25F4DA.8090709@biblibre.com> Message-ID: <4D260224.6010000@ptfs-europe.com> On 06/01/11 16:59, Paul Poulain wrote: > For the biblio, this can be discussed. But most of our libraries think > that it's better to delete the biblio if there are no more items. > Usually, the case is : > * I added an order, that created item & biblio > * oups, made a mistake (no more budget available, or wrong supplier) > * delete the order > * forget it > => useless biblio remaining in the catalogue => library & users unhappy. > > If you hadn't the "forget it" line, I would agree. I'm thinking of biblios which may relate to subscriptions, electronic_resources, or be related to edifact info. These may well have zero copies but you don't want them removed because one of their orderlines was removed. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From paul.poulain at biblibre.com Fri Jan 7 08:44:48 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 07 Jan 2011 08:44:48 +0100 Subject: [Koha-devel] News of BibLibre patches In-Reply-To: <4D260224.6010000@ptfs-europe.com> References: <4D25D9E7.40606@biblibre.com> <4D25F261.5000901@ptfs-europe.com> <4D25F4DA.8090709@biblibre.com> <4D260224.6010000@ptfs-europe.com> Message-ID: <4D26C470.7000702@biblibre.com> Le 06/01/2011 18:55, Colin Campbell a ?crit : > I'm thinking of biblios which may relate to subscriptions, > electronic_resources, or be related to edifact info. These may well have > zero copies but you don't want them removed because one of their > orderlines was removed maybe a confirmation request when removing the order would be the best in this case. Something like: "you're about to delete the last item of this biblio do you want to delete the biblio as well Y/N ?" I think it would be better than a syspref, it gives the control back to the librarian. cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From colin.campbell at ptfs-europe.com Fri Jan 7 11:29:30 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Fri, 07 Jan 2011 10:29:30 +0000 Subject: [Koha-devel] News of BibLibre patches In-Reply-To: <4D26C470.7000702@biblibre.com> References: <4D25D9E7.40606@biblibre.com> <4D25F261.5000901@ptfs-europe.com> <4D25F4DA.8090709@biblibre.com> <4D260224.6010000@ptfs-europe.com> <4D26C470.7000702@biblibre.com> Message-ID: <4D26EB0A.8060501@ptfs-europe.com> On 07/01/11 07:44, Paul Poulain wrote: > Le 06/01/2011 18:55, Colin Campbell a ?crit : >> I'm thinking of biblios which may relate to subscriptions, >> electronic_resources, or be related to edifact info. These may well have >> zero copies but you don't want them removed because one of their >> orderlines was removed > maybe a confirmation request when removing the order would be the best > in this case. > > Something like: > "you're about to delete the last item of this biblio do you want to > delete the biblio as well Y/N ?" > I think it would be better than a syspref, it gives the control back to > the librarian. That would be a good solution. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From fridolyn.somers at gmail.com Fri Jan 7 15:07:55 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 7 Jan 2011 15:07:55 +0100 Subject: [Koha-devel] home or holding branch behavior Message-ID: Hie, I open a mail about home or holding branch behavior. In* 3.2.0* : If xslt if ON for OPAC display : - Search results page displays the *home branch* of items - Details page (Normal view) displays the *holding branch* of items If xslt if OFF for OPAC display : - Search results page displays the *home or holding branch* of items depending on *HomeOrHoldingBranch* syspref - Details page (Normal view) displays the *holding branch* of items This is a odd behaviour. In my opinion : First, branch display in OPAC should be independent of *HomeOrHoldingBranch*syspref, which manages circulation. Second, branch type should be the same in : - both results and details pages - query search limit on branch => defined in Zebra configuration : ccl.properties ("branch homebranch" by default). - branch facet => defined in Koha.pm (hard-coded 995$b) The default branch type seems then to be the *home* one. In this case, details page should display *home* branch (or at least both). But the branch displayed in OPAC should help the user where to find the book non ? In this case, the default branch type should be the *holding* on. Best regards, *PS :* This is related to bug 3262 : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3262 -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From jcamins at cpbibliography.com Fri Jan 7 15:57:34 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Fri, 7 Jan 2011 09:57:34 -0500 Subject: [Koha-devel] [Koha-patches] Pull request: Bug 5528 analytical records In-Reply-To: References: Message-ID: [Moving to koha-devel for discussion] Good morning. Katrin Fischer and I spent the morning poking at the code for bug 5528, and we have a few comments. 1) The "Analyze" link is a bit confusing. I think we both expected that link to run a script that would find pre-existing links. Perhaps that could be changed to something like "Create analytic"? 2) We both had some trouble figuring out how to use the new features. Is there any documentation? 3) The DB update needs to add subfields '0' and '9' to the 773 field. Otherwise, nothing works, and there's no indication why. 4) Links to the host record should appear on the XSLT display, too, not just the Normal display. Analytic records created using the "Analyze" link also seem to break the existing 773 display when XSLT is enabled, and it's not clear why. 5) Using barcodes for linking is a little troubling, since some libraries with analytics may not have barcodes. It seems to me a good compromise would be to have the option to create links based on either the barcode or the 773$w. Regards, Jared On Wed, Jan 5, 2011 at 1:09 PM, savitra sirohi wrote: > Hi, analytical records patches are available at: > > git://kohadev.osslabs.biz/bug_5528_analytical_records.git > > The patches are rebased to master and include Unimarc support. > > Thanks, > Savitra Sirohi > Nucsoft OSS labs > http://www.osslabs.biz > _______________________________________________ > Koha-patches mailing list > Koha-patches at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-patches > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Jared Camins-Esakov Freelance bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrea at moablibrary.org Sat Jan 8 12:00:44 2011 From: adrea at moablibrary.org (adrea at moablibrary.org) Date: Sat, 8 Jan 2011 04:00:44 -0700 Subject: [Koha-devel] Out of the Office Message-ID: <44beededbdd645ec82f30860a1c741da@4849fcf163ac4afa99a368f193ff3b94> I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org From nengard at gmail.com Sun Jan 9 01:34:47 2011 From: nengard at gmail.com (Nicole Engard) Date: Sat, 8 Jan 2011 19:34:47 -0500 Subject: [Koha-devel] January Newsletter: Call for Articles Message-ID: Hi all, After our IRC meeting this month I am going to try and keep doing this monthly. The new publication date for 2011 will be the 25th of the month. I need all your articles (preferably short - with links to longer articles if there is more to share) sent to me by the 23rd your local time. Thanks in advance for all contributions, Nicole C. Engard Documentation Manager From ian.walls at bywatersolutions.com Sun Jan 9 15:56:02 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Sun, 9 Jan 2011 09:56:02 -0500 Subject: [Koha-devel] Unicode and PDF... a work-around? Message-ID: Fellow developers, I've got a client who needs to print some pocket labels for their books. Sadly, since some of these titles have some funky Unicode characters in the 245$abc, the PDF they generate comes out corrupted and unusable. This is a serious problem for their move forward with Koha. My research on in the list archives shows that this is well-known problem, and is in many ways out of our hands. PDFs don't handle Unicode as natively as we need, and the compromises to make it work are much less encouraging. It seems like this just isn't going to work unless Adobe decides to help. (see http://koha.1045719.n5.nabble.com/Diacriticals-Unicode-and-PDF-s-td3068755.html#nonefor more details) This got me thinking about a potential alternative. Perhaps we could offer a 4th Label Creator output option (in addition to PDF, CSV and XML), of HTML. Using similar markup that we use for print holds and overdues, it may be possible to recreate the page on the browser window in a format that anyone can read (and if they can't, their local machine can install the necessary fonts or language packs). There are numerous Print To PDF options for all kinds of browsers and platforms, so the end result could be the same, only without our code having to do the heavy PDF lifting. Does this sound like a feasible plan? Am I missing any subtleties that would make this untenable? Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Sun Jan 9 19:36:03 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 9 Jan 2011 13:36:03 -0500 Subject: [Koha-devel] Unicode and PDF... a work-around? In-Reply-To: References: Message-ID: 2011/1/9 Ian Walls > This got me thinking about a potential alternative. Perhaps we could offer > a 4th Label Creator output option (in addition to PDF, CSV and XML), of > HTML. Using similar markup that we use for print holds and overdues, it may > be possible to recreate the page on the browser window in a format that > anyone can read (and if they can't, their local machine can install the > necessary fonts or language packs). There are numerous Print To PDF options > for all kinds of browsers and platforms, so the end result could be the > same, only without our code having to do the heavy PDF lifting. > > Does this sound like a feasible plan? Am I missing any subtleties that > would make this untenable? > I have already done work on an "html" print option the formatting of which would be controlled by css. You can see my progress here: http://git.koha-community.org/gitweb/?p=wip/koha-chris_n.git;a=shortlog;h=refs/heads/label-create-html The work was begun some months ago and is cold a the moment, so you will have to read through it to figure how it works. It is actually pretty far along. Be warned that in its current state it breaks the pdf printing capability. It is probably within less than 40 hours of completion. My premise for starting this work was exactly that you have mentioned: Browsers display unicode very well. From that point one can do whatever one likes with the output. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From henridamien.laurent at gmail.com Mon Jan 10 09:13:50 2011 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Mon, 10 Jan 2011 09:13:50 +0100 Subject: [Koha-devel] Unicode and PDF... a work-around? In-Reply-To: References: Message-ID: <4D2ABFBE.9040908@gmail.com> Le 09/01/2011 15:56, Ian Walls a ?crit : > Fellow developers, > > > I've got a client who needs to print some pocket labels for their books. > Sadly, since some of these titles have some funky Unicode characters in > the 245$abc, the PDF they generate comes out corrupted and unusable. > This is a serious problem for their move forward with Koha. > > My research on in the list archives shows that this is well-known > problem, and is in many ways out of our hands. PDFs don't handle > Unicode as natively as we need, and the compromises to make it work are > much less encouraging. It seems like this just isn't going to work > unless Adobe decides to help. (see > http://koha.1045719.n5.nabble.com/Diacriticals-Unicode-and-PDF-s-td3068755.html#none > for more details) > > This got me thinking about a potential alternative. Perhaps we could > offer a 4th Label Creator output option (in addition to PDF, CSV and > XML), of HTML. Using similar markup that we use for print holds and > overdues, it may be possible to recreate the page on the browser window > in a format that anyone can read (and if they can't, their local machine > can install the necessary fonts or language packs). There are numerous > Print To PDF options for all kinds of browsers and platforms, so the end > result could be the same, only without our code having to do the heavy > PDF lifting. > > Does this sound like a feasible plan? Am I missing any subtleties that > would make this untenable? Hi Ian For what it is worth, we made some HTML to PDF work. you can see a result here http://test.koha.nimes.fr/relances_html/ It is based on pisa http://www.xhtml2pdf.com/doc/pisa-en.html and works pretty out of the box. It consists in a post process after gather_print_notices.pl. here is the script : http://git.biblibre.com/?p=koha;a=blob;f=misc/cronjobs/printoverdues.sh;h=f7b677ee82bb2475d5e7879a44d24abb9196b836;hb=refs/heads/master Hope that helps. -- Henri-Damien LAURENT BibLibre From colin.campbell at ptfs-europe.com Mon Jan 10 11:59:19 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Mon, 10 Jan 2011 10:59:19 +0000 Subject: [Koha-devel] Unicode and PDF... a work-around? In-Reply-To: References: Message-ID: <4D2AE687.6070203@ptfs-europe.com> On 09/01/11 14:56, Ian Walls wrote: > Fellow developers, > > > This got me thinking about a potential alternative. Perhaps we could offer > a 4th Label Creator output option (in addition to PDF, CSV and XML), of > HTML. Using similar markup that we use for print holds and overdues, it may > be possible to recreate the page on the browser window in a format that > anyone can read (and if they can't, their local machine can install the > necessary fonts or language packs). There are numerous Print To PDF options > for all kinds of browsers and platforms, so the end result could be the > same, only without our code having to do the heavy PDF lifting. I did this for a site to print orders, using Template::Toolkit to generate the document and firefox plugins to generate pdfs and print. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From tajoli at cilea.it Mon Jan 10 15:40:09 2011 From: tajoli at cilea.it (Zeno Tajoli) Date: Mon, 10 Jan 2011 15:40:09 +0100 Subject: [Koha-devel] [Koha-patches] Pull request: Bug 5528 analytical records In-Reply-To: References: Message-ID: <4D2B1A49.9020605@cilea.it> Hi to all, I write a particial answer to those questions: > 2) We both had some trouble figuring out how to use the new features. Is > there any documentation? I'm the volonteer to write documentation on the feature. In fact the answer is no. So a little documentation: The feature is visible only if the preference 'EasyAnalyticalRecords' is on yes. The feature is for linking analitycal to their fathers. So in fact it only insert a 773 (Marc21) / 461 (Unimarc) in the analytical record. The idea is that the anaytical record is not indipendent part of a host record. For example an illustration inside a book. So the analytical record not has items but you can use the item data of the host. This is why it used the barcode, it is the identifier of the item. The only others identifier of the item is the itemnumber but is not a clearly visible data for the librarian. So the workflow that I image: 1)Librarian catalogues the host record at bibliographic level and add 1 o more items to it 2)Librarian insert the analytical record at bibliographic level, he doesn't add an item 3)Librarian connects analytical with host reading the barcode with the barcode reader. > 3) The DB update needs to add subfields '0' and '9' to the 773 field. > Otherwise, nothing works, and there's no indication why. Right, those definitions are mandatory. > 5) Using barcodes for linking is a little troubling, since some libraries > with analytics may not have barcodes. It seems to me a good compromise would > be to have the option to create links based on either the barcode or the > 773$w. In fact this feature si primary done to link a record with items (the host) to records without items. So if the library want to do link without barcodes, is better that setup the preference 'EasyAnalyticalRecords' on 'NO'. I think that links with bibliographic data are better done with Katrin Fischer patch. Bye Zeno Tajoli -- Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @) From savitra.sirohi at osslabs.biz Mon Jan 10 17:06:26 2011 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Mon, 10 Jan 2011 21:36:26 +0530 Subject: [Koha-devel] [Koha-patches] Pull request: Bug 5528 analytical records In-Reply-To: <4D2B1A49.9020605@cilea.it> References: <4D2B1A49.9020605@cilea.it> Message-ID: Jared, Thanks for the feedback. Work on including '0' and '9' to the database scripts is already in progress. I will change the link to "Create analytic" and take a look at XSLT (completely missed this!) as well. Adding to Zeno's explanation: relationships can be created by: 1. From the analytical record, using the "Link to host item", under Edit menu. This creates a new 773/461 field in the analytical record. 2. From the host record, using the "Create analytic" link. This creates an empty MARC record, with just the 773 populated. 3. Running the CLI script, create_analytical_rel.pl, this looks at analytical records with 773 fields populated, finds the host items bibilionumber and itemnumber using the barcode stored in 773$o (Marc21) and populates subfields 0 and 9. The host's items are displayed under the analytical record as well as under the host record. Holds can be placed on the host items from the analytical records. Only specific holds are allowed for analytical records. Thanks, Savitra On Mon, Jan 10, 2011 at 8:10 PM, Zeno Tajoli wrote: > Hi to all, > > I write a particial answer to those questions: > >> 2) We both had some trouble figuring out how to use the new features. Is >> there any documentation? > > I'm the volonteer to write documentation on the feature. > In fact the answer is no. > So a little documentation: > > The feature is visible only if the preference 'EasyAnalyticalRecords' is > on yes. > The feature is for linking analitycal to their fathers. > So in fact it only insert a 773 (Marc21) / 461 (Unimarc) in the > analytical record. > The idea is that the anaytical record is not indipendent part of a host > record. For example an illustration inside a book. > So the analytical record not has items but you can use the item data of > the host. > > This is why it used the barcode, it is the identifier of the item. > The only others identifier of the item is the itemnumber but is not a > clearly visible data for the librarian. > > So the workflow that I image: > 1)Librarian catalogues the host record at bibliographic level and add 1 > o more items to it > 2)Librarian insert the analytical record at bibliographic level, he > doesn't add an item > 3)Librarian connects analytical with host reading the barcode with the > barcode reader. > >> 3) The DB update needs to add subfields '0' and '9' to the 773 field. >> Otherwise, nothing works, and there's no indication why. > Right, those definitions are mandatory. > >> 5) Using barcodes for linking is a little troubling, since some libraries >> with analytics may not have barcodes. It seems to me a good compromise would >> be to have the option to create links based on either the barcode or the >> 773$w. > > In fact this feature si primary done to link a record with items (the > host) to records without items. > So if the library want to do link without barcodes, is better that setup > the preference 'EasyAnalyticalRecords' on 'NO'. > > I think that links with bibliographic data are better done with Katrin > Fischer patch. > > Bye > Zeno Tajoli > -- > Zeno Tajoli > CILEA - Segrate (MI) > tajoliAT_SPAM_no_prendiATcilea.it > (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @) > From paul.poulain at biblibre.com Tue Jan 11 10:07:08 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 11 Jan 2011 10:07:08 +0100 Subject: [Koha-devel] patch to add to BibLibre-opac branch (#5584) Message-ID: <4D2C1DBC.9040805@biblibre.com> Hi Chris, owen noticed a problem in BibLibre-opac branch, I fixed it you can cherry pick the patch on our repo: a5b653ae9682c1e5e19da0bcff1021dc1a0ed972 thx -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Jan 11 10:40:31 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 11 Jan 2011 10:40:31 +0100 Subject: [Koha-devel] (reminder) IRC QA-meeting for BibLibre circulation & borrower patches Message-ID: <4D2C258F.4040108@biblibre.com> Hello, As announced last week, i'm available today on IRC and anyone who want to jump in a QA session of circulation & borrowers improvements coming from BibLibre for 3.4 can jump in. * http://borrowers34.git.biblibre.com/cgi-bin/koha/mainpage.pl login test/test is available and is a fresh install from this branch * what it contains is on wiki.biblibre.com http://wiki.koha-community.org/wiki/BibLibre_patches_to_be_integrated_for_3.4 * the bugzilla entry for any comment is #5575 HTH -- 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 Jan 11 10:43:57 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 11 Jan 2011 22:43:57 +1300 Subject: [Koha-devel] patch to add to BibLibre-opac branch (#5584) In-Reply-To: <4D2C1DBC.9040805@biblibre.com> References: <4D2C1DBC.9040805@biblibre.com> Message-ID: On 11 January 2011 22:07, Paul Poulain wrote: > Hi Chris, > > owen noticed a problem in BibLibre-opac branch, I fixed it you can > cherry pick the patch on our repo: > > a5b653ae9682c1e5e19da0bcff1021dc1a0ed972 > Done Chris From paul.poulain at biblibre.com Tue Jan 11 10:48:18 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 11 Jan 2011 10:48:18 +0100 Subject: [Koha-devel] (reminder) IRC QA-meeting for BibLibre circulation & borrower patches In-Reply-To: <4D2C258F.4040108@biblibre.com> References: <4D2C258F.4040108@biblibre.com> Message-ID: <4D2C2762.3040501@biblibre.com> Le 11/01/2011 10:40, Paul Poulain a ?crit : > Hello, > > As announced last week, i'm available today on IRC and anyone who want > to jump in a QA session of circulation & borrowers improvements coming > from BibLibre for 3.4 can jump in. > > * http://borrowers34.git.biblibre.com/cgi-bin/koha/mainpage.pl login > test/test is available and is a fresh install from this branch > * what it contains is on wiki.biblibre.com > http://wiki.koha-community.org/wiki/BibLibre_patches_to_be_integrated_for_3.4 > * the bugzilla entry for any comment is #557 Another usefull url : http://git.koha-community.org/gitweb/?p=koha.git;a=log;h=refs/heads/new/awaiting_qa/enh/bug_5575 look at all the patches that are 5 days old and from me: it's what is in this branch ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From adrea at moablibrary.org Tue Jan 11 12:00:46 2011 From: adrea at moablibrary.org (adrea at moablibrary.org) Date: Tue, 11 Jan 2011 04:00:46 -0700 Subject: [Koha-devel] Out of the Office Message-ID: <54bca02eff474d339b8be2d65cd76a42@f4dd737c42be49a3a179a1718a4e936e> I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org From paul.poulain at biblibre.com Tue Jan 11 18:24:08 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 11 Jan 2011 18:24:08 +0100 Subject: [Koha-devel] QA session for BibLibre for Circ & members improvements Message-ID: <4D2C9238.6010706@biblibre.com> Hello, Today, I've been available on IRC for some QA on our Circ & Members branch. Thanks to Katrin that said she could not join and to owen that did some tests but could not go far because of an updatedatabase with XXX numbers. I had planned to be available from 20GMT to 22GMT, but it will be from 21GMT to 23GMT, sorry for the delay. Anyway, I did a lot of testings and have fixed some glitches in fines partial payements (patchs to be picked up by chris). I did a lot of tests on check-in/checkouts/hold/renewals without noticing any problem (reminder : with this branch, all issuing rules are now at a granular level branch/patron category/itemtype : Current checkouts allowed Loan period (day) Fine amount Fine charging interval Grace period (day) Suspension duration (day) Renewals allowed (count) Renewals period (days) Holds allowed (count) Holds pickup delay (day) Allow on shelf holds Holds restricted to library Rental Discount (%) HTH, and see you again in 3 hours ;-) -- 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 Tue Jan 11 23:11:11 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 11 Jan 2011 17:11:11 -0500 Subject: [Koha-devel] 3.2.3 Release Schedule Message-ID: Hi all, 3.2.3 is on track to be released on January 22, 2010, however, there is another important date between now and then which I wanted to point out. On January 15, 2011, 3.2.3 will enter a string freeze to facilitate finalization of translation updates. After this date the only patches introducing string changes which will be pushed for 3.2.3 will be those addressing blocker bugs or security issues. All others will be pushed to 3.2.4. Patches not introducing string changes will be pushed up to the time of the release. Keep up the good work! Kind Regards, Chris Nighswonger 3.2 Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Tue Jan 11 23:12:05 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 11 Jan 2011 17:12:05 -0500 Subject: [Koha-devel] 3.2.3 Release Schedule In-Reply-To: References: Message-ID: Hmm.... cut-n-paste strikes again... ;-) 3.2.3 is on track to be released on January 22, 2011 rather than a year ago. On Tue, Jan 11, 2011 at 5:11 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > Hi all, > > 3.2.3 is on track to be released on January 22, 2010, however, there is > another important date between now and then which I wanted to point out. > > On January 15, 2011, 3.2.3 will enter a string freeze to facilitate > finalization of translation updates. After this date the only patches > introducing string changes which will be pushed for 3.2.3 will be those > addressing blocker bugs or security issues. All others will be pushed to > 3.2.4. > > Patches not introducing string changes will be pushed up to the time of the > release. > > Keep up the good work! > > Kind Regards, > Chris Nighswonger > 3.2 Release Maintainer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Wed Jan 12 00:12:43 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 11 Jan 2011 18:12:43 -0500 Subject: [Koha-devel] 3.2.x Maintenance Request Message-ID: Hi all, Kudos to all of those who have been turning out bugfixes like grist mills of late! I have a request for both devs and those doing qa/sign-offs. Please verify that patches apply cleanly both to master and to 3.2.x prior to submitting. This is becoming more important as these two branches diverge. It will become imperative for all patches after the move to TT in a few weeks. I will do my best to send notices back to the patches list for those that do not apply to 3.2.x. Kind Regards, Chris Koha 3.2. Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Fri Jan 14 13:31:45 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Fri, 14 Jan 2011 12:31:45 +0000 Subject: [Koha-devel] FW: What should an empty authority subfield do? In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311C5A69@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA311C5A69@S-MAIL-1B.rijksmuseum.intra> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311C5C8A@S-MAIL-1B.rijksmuseum.intra> Copying to dev list for additional comments. ________________________________ Referring a question in bug 5572 to the Koha list for further comments from the list. Bug 5572 introduces a refinement on authority merging. (Copying the change of an authority to the related biblio records.) Janusz (author of the patch) wrote: The original behavior in 3.0 was: when authority has been changed, then in the corresponding fields in the bibliographic records all the subfields of such fields controlled by authority will be dropped and created anew with only subfields which have a value in the authority. The new behavior is much better: in the bibliographic record only subfields which have a value in the authority_to (the new authority) will be changed. BUT what if there was a subfield present (with value) in authority (and in bibliographic) and the value is now deleted form authority? It will still stay in all bibliographic, whereas it should not. Hence my proposal: subfields not active in authority framework will be preserved; subfields active in the authority framework (i.e. controlled by this authority type) should be set as in the authority record - either have the value of corresponding subfield in authority or be empty. Marcel (tester of patch) commented: Tested your patch: it works as described. I see your point when you should clear a subfield at the authority side and you want to see the same at the biblio side. [How often would that happen?] However, if the subfield was already empty at the authority side and you update the auth record, do you also want to clear at that moment any possible info in that subfield at the biblio side? Does an empty authority subfield that is "not in the ignore tab" in the framework, really mean that that subfield should always be empty too at the biblio side? I am not sure about that; I will copy this comment to the Koha list for possible further discussion. What do you think? Thanks for further clarification. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lculber at mdah.state.ms.us Fri Jan 14 15:52:49 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Fri, 14 Jan 2011 08:52:49 -0600 Subject: [Koha-devel] Koha - Advanced cataloging search RFC on 001 Message-ID: <4D306341.8090103@mdah.state.ms.us> In the wiki, it has that Howard County Library was proposing an RFC to allow searching on the 001. http://wiki.koha-community.org/wiki/Advanced_cataloging_search_RFC In the old documentation that is on LibLime's site, it says "field 001 is a special field that you cannot map data to in Koha" We need to be able to link to that number. Does anyone have any ideas about how to do so, since we cannot seem to keep our current id's when migrating to Koha 3.2? Thanks. -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From Katrin.Fischer at bsz-bw.de Fri Jan 14 16:09:42 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Fri, 14 Jan 2011 16:09:42 +0100 Subject: [Koha-devel] Koha - Advanced cataloging search RFC on 001 In-Reply-To: <4D306341.8090103@mdah.state.ms.us> References: <4D306341.8090103@mdah.state.ms.us> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFDF66441@Bodensee.bsz-bw.de> Hi Linda, not sure I understand your questions correctly, but I hope this is helpful for you: There is a search option for 001 field in z39.50 search in cataloging called 'Control number'. This will be available in acquisitions in 3.4 too. You can also search for the 001 fields in simple search in staff and opac, using following syntax: 'Control-number:'. Please note it has to be a big C. I think you could also add a search option in the pull down using some jQuery. You can also construct links to your OPAC using 001: http://hfjs.bsz-bw.de/cgi-bin/koha/opac-search.pl?q=Control-number: 005288320 Not being able to map means probably that you can't map it to biblio or biblioitems table. But you don't need that to make it searchable :) Katrin > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Linda Culberson > Sent: Friday, January 14, 2011 3:53 PM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] Koha - Advanced cataloging search RFC on 001 > > In the wiki, it has that Howard County Library was proposing an RFC > to allow searching on the 001. > http://wiki.koha-community.org/wiki/Advanced_cataloging_search_RFC > In the old documentation that is on LibLime's site, it says "field 001 > is a special field that you cannot map data to in Koha" > We need to be able to link to that number. Does anyone have any ideas > about how to do so, since we cannot seem to keep our current id's when > migrating to Koha 3.2? > Thanks. > > -- > Linda Culberson lculber at mdah.state.ms.us > Archives and Records Services Division > Ms. Dept. of Archives& History > P. O. Box 571 > Jackson, MS 39205-0571 > Telephone: 601/576-6873 > Facsimile: 601/576-6824 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > From lculber at mdah.state.ms.us Fri Jan 14 16:19:55 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Fri, 14 Jan 2011 09:19:55 -0600 Subject: [Koha-devel] Koha - Advanced cataloging search RFC on 001 In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFDF66441@Bodensee.bsz-bw.de> References: <4D306341.8090103@mdah.state.ms.us> <028B1A54D03E7B4482CDCA4EC8F06BFDF66441@Bodensee.bsz-bw.de> Message-ID: <4D30699B.9070006@mdah.state.ms.us> Katrin, That was a huge help. I had read about the "control-number" but note that I was reading it with a lowercase "C" Thanks! On 1/14/2011 9:09 AM, Fischer, Katrin wrote: > Hi Linda, > > not sure I understand your questions correctly, but I hope this is > helpful for you: > > There is a search option for 001 field in z39.50 search in cataloging > called 'Control number'. This will be available in acquisitions in 3.4 > too. > > You can also search for the 001 fields in simple search in staff and > opac, using following syntax: 'Control-number:'. Please note it has to > be a big C. > > I think you could also add a search option in the pull down using some > jQuery. > > You can also construct links to your OPAC using 001: > http://hfjs.bsz-bw.de/cgi-bin/koha/opac-search.pl?q=Control-number: > 005288320 > > Not being able to map means probably that you can't map it to biblio or > biblioitems table. But you don't need that to make it searchable :) > > Katrin > >> -----Original Message----- >> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- >> bounces at lists.koha-community.org] On Behalf Of Linda Culberson >> Sent: Friday, January 14, 2011 3:53 PM >> To: koha-devel at lists.koha-community.org >> Subject: [Koha-devel] Koha - Advanced cataloging search RFC on 001 >> >> In the wiki, it has that Howard County Library was proposing an RFC >> to allow searching on the 001. >> http://wiki.koha-community.org/wiki/Advanced_cataloging_search_RFC >> In the old documentation that is on LibLime's site, it says "field 001 >> is a special field that you cannot map data to in Koha" >> We need to be able to link to that number. Does anyone have any ideas >> about how to do so, since we cannot seem to keep our current id's when >> migrating to Koha 3.2? >> Thanks. >> >> -- >> Linda Culberson lculber at mdah.state.ms.us >> Archives and Records Services Division >> Ms. Dept. of Archives& History >> P. O. Box 571 >> Jackson, MS 39205-0571 >> Telephone: 601/576-6873 >> Facsimile: 601/576-6824 >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From lculber at mdah.state.ms.us Fri Jan 14 18:05:12 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Fri, 14 Jan 2011 11:05:12 -0600 Subject: [Koha-devel] Koha - More on Advanced cataloging search RFC on 001 In-Reply-To: <4D30699B.9070006@mdah.state.ms.us> References: <4D306341.8090103@mdah.state.ms.us> <028B1A54D03E7B4482CDCA4EC8F06BFDF66441@Bodensee.bsz-bw.de> <4D30699B.9070006@mdah.state.ms.us> Message-ID: <4D308248.4090904@mdah.state.ms.us> Katrin and others, I'm not sure I understand this, but the search Katrin gave worked the first time I tried it, but I am not able to get it to work consistently. Most often I got a 404:Page not found error, Looking at the log file I see: opac-search.pl: Use of uninitialized value in hash element at /usr/share/koha/lib/C4/XSLT.pm line 213., referer: http://koha.mdah.state.ms.us/koha/opac-search.pl?q=Control-number:000000073 So I looked up line 213 in XSLT.pm and it deals with items: my $homebranch = xml_escape($branches->{$item->{homebranch}}->{'branchname'}); my $itemcallnumber = xml_escape($item->{itemcallnumber}); $xml.= "$homebranch". "$status". "".$itemcallnumber."" . ""; I discovered that this error seems to happen with records will lots of items. http://koha.mdah.state.ms.us/koha/opac-search.pl?q=Control-number:000036801 which has only one item worked once and then generated an error: opac-MARCdetail.pl: Use of uninitialized value in string ne at /usr/share/koha/opac/cgi-bin/opac/opac-MARCdetail.pl line 144., referer: http://koha.mdah.state.ms.us/cgi-bin/koha/opac-detail.pl?biblionumber=36083 Just typing in http://koha.mdah.state.ms.us/cgi-bin/koha/opac-detail.pl?biblionumber=36083 does give the right record though, so the index is working, it just doesn't consistently pull up the record Has anyone else noticed this behavior? We are on Koha version 3.02.02 On 1/14/2011 9:19 AM, Linda Culberson wrote: > Katrin, > That was a huge help. I had read about the "control-number" but note > that I was reading it with a lowercase "C" > Thanks! > > On 1/14/2011 9:09 AM, Fischer, Katrin wrote: >> Hi Linda, >> >> not sure I understand your questions correctly, but I hope this is >> helpful for you: >> >> There is a search option for 001 field in z39.50 search in cataloging >> called 'Control number'. This will be available in acquisitions in 3.4 >> too. >> >> You can also search for the 001 fields in simple search in staff and >> opac, using following syntax: 'Control-number:'. Please note it has to >> be a big C. >> >> I think you could also add a search option in the pull down using some >> jQuery. >> >> You can also construct links to your OPAC using 001: >> http://hfjs.bsz-bw.de/cgi-bin/koha/opac-search.pl?q=Control-number: >> 005288320 >> >> Not being able to map means probably that you can't map it to biblio or >> biblioitems table. But you don't need that to make it searchable :) >> >> Katrin >> >>> -----Original Message----- >>> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- >>> bounces at lists.koha-community.org] On Behalf Of Linda Culberson >>> Sent: Friday, January 14, 2011 3:53 PM >>> To: koha-devel at lists.koha-community.org >>> Subject: [Koha-devel] Koha - Advanced cataloging search RFC on 001 >>> >>> In the wiki, it has that Howard County Library was proposing an RFC >>> to allow searching on the 001. >>> http://wiki.koha-community.org/wiki/Advanced_cataloging_search_RFC >>> In the old documentation that is on LibLime's site, it says "field 001 >>> is a special field that you cannot map data to in Koha" >>> We need to be able to link to that number. Does anyone have any ideas >>> about how to do so, since we cannot seem to keep our current id's when >>> migrating to Koha 3.2? >>> Thanks. >>> >>> -- >>> Linda Culberson lculber at mdah.state.ms.us >>> Archives and Records Services Division >>> Ms. Dept. of Archives& History >>> P. O. Box 571 >>> Jackson, MS 39205-0571 >>> Telephone: 601/576-6873 >>> Facsimile: 601/576-6824 >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> >> >> > -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From cnighswonger at foundations.edu Fri Jan 14 18:30:19 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 14 Jan 2011 12:30:19 -0500 Subject: [Koha-devel] Koha - More on Advanced cataloging search RFC on 001 In-Reply-To: <4D308248.4090904@mdah.state.ms.us> References: <4D306341.8090103@mdah.state.ms.us> <028B1A54D03E7B4482CDCA4EC8F06BFDF66441@Bodensee.bsz-bw.de> <4D30699B.9070006@mdah.state.ms.us> <4D308248.4090904@mdah.state.ms.us> Message-ID: On Fri, Jan 14, 2011 at 12:05 PM, Linda Culberson wrote: > ?Katrin and others, > I'm not sure I understand this, but the search Katrin gave worked the first > time I tried it, but I am not able to get it to work consistently. Most > often I got a ?404:Page not found error, > Looking at the log file I see: > ?opac-search.pl: Use of uninitialized value in hash element at > /usr/share/koha/lib/C4/XSLT.pm line 213., referer: > http://koha.mdah.state.ms.us/koha/opac-search.pl?q=Control-number:000000073 > > So I looked up line 213 in XSLT.pm and it deals with items: > my $homebranch = > xml_escape($branches->{$item->{homebranch}}->{'branchname'}); Is it possible that some of your items are missing a homebranch assignment? Kind Regards, Chris From adrea at moablibrary.org Fri Jan 14 18:31:23 2011 From: adrea at moablibrary.org (adrea at moablibrary.org) Date: Fri, 14 Jan 2011 10:31:23 -0700 Subject: [Koha-devel] Out of the Office Message-ID: <46a2737cb9124c25beed65210aca07b1@45cbe97b84c647efb4f7f67870286945> I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org From lculber at mdah.state.ms.us Fri Jan 14 19:38:55 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Fri, 14 Jan 2011 12:38:55 -0600 Subject: [Koha-devel] Koha - More on Advanced cataloging search RFC on 001 In-Reply-To: References: <4D306341.8090103@mdah.state.ms.us> <028B1A54D03E7B4482CDCA4EC8F06BFDF66441@Bodensee.bsz-bw.de> <4D30699B.9070006@mdah.state.ms.us> <4D308248.4090904@mdah.state.ms.us> Message-ID: <4D30983F.4040903@mdah.state.ms.us> This is interesting, I did find some that had the homebranch missing although they were not the ones I was testing. I fixed them anyway. Now my error message is: script not found or unable to stat: /usr/share/koha/opac/cgi-bin/opac/opac-query However, I've been experimenting and at least sometimes (it hasn't broken yet) the following works: http://koha.mdah.state.ms.us/cgi-bin/koha/opac-search.pl?idx=Control-number&q=000000073 On 1/14/2011 11:30 AM, Chris Nighswonger wrote: > On Fri, Jan 14, 2011 at 12:05 PM, Linda Culberson > wrote: >> ? Katrin and others, >> I'm not sure I understand this, but the search Katrin gave worked the first >> time I tried it, but I am not able to get it to work consistently. Most >> often I got a ? 404:Page not found error, >> Looking at the log file I see: >> ? opac-search.pl: Use of uninitialized value in hash element at >> /usr/share/koha/lib/C4/XSLT.pm line 213., referer: >> http://koha.mdah.state.ms.us/koha/opac-search.pl?q=Control-number:000000073 >> >> So I looked up line 213 in XSLT.pm and it deals with items: >> my $homebranch = >> xml_escape($branches->{$item->{homebranch}}->{'branchname'}); > Is it possible that some of your items are missing a homebranch assignment? > > Kind Regards, > Chris > > -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From cnighswonger at foundations.edu Sat Jan 15 02:56:47 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 14 Jan 2011 20:56:47 -0500 Subject: [Koha-devel] 3.2.3 Release Schedule In-Reply-To: References: Message-ID: As of Sat, 15 Jan 2011 00:00 +0000, 3.2.x is in a string freeze until the 3.2.3 release currently scheduled for January 22, 2011. From nengard at gmail.com Sat Jan 15 03:03:20 2011 From: nengard at gmail.com (Nicole Engard) Date: Fri, 14 Jan 2011 21:03:20 -0500 Subject: [Koha-devel] January Newsletter: Call for Articles In-Reply-To: References: Message-ID: Just a friendly reminder that I have yet to receive any articles for this month's newsletter. Please start sending them along and get them to me no later than the 23rd (your local time). Thanks Nicole On Sat, Jan 8, 2011 at 7:34 PM, Nicole Engard wrote: > Hi all, > > After our IRC meeting this month I am going to try and keep doing this > monthly. ?The new publication date for 2011 will be the 25th of the > month. ?I need all your articles (preferably short - with links to > longer articles if there is more to share) sent to me by the 23rd your > local time. > > Thanks in advance for all contributions, > Nicole C. Engard > Documentation Manager > From adrea at moablibrary.org Sat Jan 15 12:00:45 2011 From: adrea at moablibrary.org (adrea at moablibrary.org) Date: Sat, 15 Jan 2011 04:00:45 -0700 Subject: [Koha-devel] Out of the Office Message-ID: I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org From rick at praxis.com.au Sat Jan 15 22:02:55 2011 From: rick at praxis.com.au (Rick Welykochy) Date: Sun, 16 Jan 2011 08:02:55 +1100 Subject: [Koha-devel] Out of the Office In-Reply-To: References: Message-ID: <4D320B7F.3030200@praxis.com.au> adrea at moablibrary.org wrote: > I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. Sigh. -- _________________________________ Rick Welykochy || Praxis Services The truth is rarely pure and never simple. -- Oscar Wilde From M.de.Rooy at rijksmuseum.nl Mon Jan 17 10:00:05 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 17 Jan 2011 09:00:05 +0000 Subject: [Koha-devel] Perl // operator Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> Hi, I came across the new Perl 5.10 // defined-or operator in Koha code. (See below) The INSTALL doc says that we still run under Perl 5.8.8. Should we still refrain from using it? Regards, Marcel For instance in commit 8e5ee007db451f62fe17c456215013e422f25bec Author: Robin Sheat robin at catalyst.net.nz Bug 5186 - allow tax rates to be set to zero (master) Two examples: --- a/acqui/addorderiso2709.pl +++ b/acqui/addorderiso2709.pl - my $gst = $bookseller->{gstrate} || C4::Context->preference(" + # '//' is like '||' but tests for defined, rather than true + my $gst = $bookseller->{gstrate} // C4::Context->preference(" --- a/acqui/basketgroup.pl +++ b/acqui/basketgroup.pl @@ -137,8 +137,8 @@ sub BasketTotal { my @orders = GetOrders($basketno); for my $order (@orders){ $total = $total + ( $order->{ecost} * $order->{quantity} ); - if ($bookseller->{invoiceincgst} && ! $bookseller->{listincgst} && ( $b - my $gst = $bookseller->{gstrate} || C4::Context->preference("gist") + if ($bookseller->{invoiceincgst} && ! $bookseller->{listincgst} && ( $b + my $gst = $bookseller->{gstrate} // C4::Context->preference("gist") -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon Jan 17 10:50:43 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 17 Jan 2011 10:50:43 +0100 Subject: [Koha-devel] Perl // operator In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D3410F3.4010004@biblibre.com> Le 17/01/2011 10:00, Marcel de Rooy a ?crit : > > Hi, > > I came across the new Perl 5.10 // defined-or operator in Koha code. > (See below) > > The INSTALL doc says that we still run under Perl 5.8.8. > > Should we still refrain from using it? > > > I vote no (to refrain, so yes to use // ;-) )=> I think we should use 5.10 pragmas, as 5.10 is everywhere except on very old distros. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From marc.chantreux at biblibre.com Mon Jan 17 10:58:10 2011 From: marc.chantreux at biblibre.com (Marc Chantreux) Date: Mon, 17 Jan 2011 10:58:10 +0100 Subject: [Koha-devel] koha default perl interpreter policy ? In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> Message-ID: <20110117095810.GA18796@auckland.lan> hello, On Mon, Jan 17, 2011 at 09:00:05AM +0000, Marcel de Rooy wrote: > Hi, > > I came across the new Perl 5.10 // defined-or operator in Koha code. (See > below) > > The INSTALL doc says that we still run under Perl 5.8.8. I guess there is more and more koha code that isn't 5.8 compliant anymore. Plus: - most of recent distributions are still 5.1[02] by default - there was so many additions in 5.10, i just see it as a MAJOR release! More and more modules from CPAN use them! - performance improvements and bugfixes are numerous since 5.8 > Should we still refrain from using it? //, given, named captures, re verbs ... and so on ... Koha has to step forward with some KISS and predictable policy. My proposal have a simple rule: "The default koha perl interpreter version is the one of current debian stable". Benefits - timeline trolls outsourced to a wise group (no one can blame debian for hasty rushes) - predictable easily (just check the version of testing distribution) - fits the usecase of most of us regards -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com From marc.chantreux at biblibre.com Mon Jan 17 11:09:15 2011 From: marc.chantreux at biblibre.com (Marc Chantreux) Date: Mon, 17 Jan 2011 11:09:15 +0100 Subject: [Koha-devel] Perl // operator In-Reply-To: <4D3410F3.4010004@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> <4D3410F3.4010004@biblibre.com> Message-ID: <20110117100915.GB18796@auckland.lan> On Mon, Jan 17, 2011 at 10:50:43AM +0100, Paul Poulain wrote: > I vote no (to refrain, so yes to use // ;-) )=> I think we should use > 5.10 pragmas, as 5.10 is everywhere except on very old distros. well, actually every koha perl files should begin with something like: use 5.10.0; use strict; use warnings; # ... moar ... which can be replaced by: use Modern::Perl; read the code of this module (only few lines) and see how easy to set a default discipline. Koha could have his own one! marc -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com From nengard at gmail.com Mon Jan 17 13:56:39 2011 From: nengard at gmail.com (Nicole Engard) Date: Mon, 17 Jan 2011 07:56:39 -0500 Subject: [Koha-devel] Running Koha 3.2 and 3.4 Message-ID: Hi all, I have seen a bunch of messages from chris_n saying that we need to test our patched on Koh 3.2.x as well as the current HEAD. So my question is how do you all do that? I have one local virtual machine with HEAD on it - I have no clue how to have both 3.2.x and HEAD. I tried copying my VM and while it looks like that went okay, I have no idea how to access that VM via the browser to actually test Koha. So I guess I'm looking for a tutorial and/or guidance on how to keep two installs up to date. Nicole From mjr at phonecoop.coop Mon Jan 17 17:51:23 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 17 Jan 2011 16:51:23 +0000 (GMT) Subject: [Koha-devel] Perl // operator In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> Message-ID: <20110117165123.BBEF94F733@nail.towers.org.uk> Marcel de Rooy wrote: > I came across the new Perl 5.10 // defined-or operator in Koha code. (See below) > The INSTALL doc says that we still run under Perl 5.8.8. > Should we still refrain from using it? It's not very clear, but http://www.cpan.org/src/README.html seems to say that 5.8 is still supported. So I'd say we remain compatible with that for 3.4, but I feel this is the Release Manager's decision. Current stable releases (3.0 and 3.2) should definitely keep working on 5.8.8. It would be very nasty for a library to do a small version upgrade and discover they need to upgrade perl! Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work http://www.software.coop/products/ From marc.chantreux at biblibre.com Mon Jan 17 18:48:36 2011 From: marc.chantreux at biblibre.com (Marc Chantreux) Date: Mon, 17 Jan 2011 18:48:36 +0100 Subject: [Koha-devel] Perl // operator In-Reply-To: <20110117165123.BBEF94F733@nail.towers.org.uk> References: <809BE39CD64BFD4EB9036172EBCCFA311D249F@S-MAIL-1B.rijksmuseum.intra> <20110117165123.BBEF94F733@nail.towers.org.uk> Message-ID: <20110117174836.GA2327@auckland.lan> On Mon, Jan 17, 2011 at 04:51:23PM +0000, MJ Ray wrote: > It's not very clear, but http://www.cpan.org/src/README.html seems to > say that 5.8 is still supported. perl stable version is 5.12, not even 5.10 (released on December 18, 2007). 5.8 (last maintenance release: December 14, 2008) is "maintained". it doesn't mean "you should use it" but "if you have perl legacy scripts to run on a old system, we carre about it". plus! most of us still use a 5.10 interpreter so we can't provide a any serious waranty to be 5.8 compliant as long as we haven't a test suite with large coverage running on a perlbrewed 5.8. is there a *real* reason to take us away from all new perl features ? regards -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com From gmcharlt at gmail.com Mon Jan 17 20:35:33 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Mon, 17 Jan 2011 14:35:33 -0500 Subject: [Koha-devel] Running Koha 3.2 and 3.4 In-Reply-To: References: Message-ID: Hi, On Mon, Jan 17, 2011 at 7:56 AM, Nicole Engard wrote: > I have seen a bunch of messages from chris_n saying that we need to > test our patched on Koh 3.2.x as well as the current HEAD. So my > question is how do you all do that? I have one local virtual machine > with HEAD on it - I have no clue how to have both 3.2.x and HEAD. I > tried copying my VM and while it looks like that went okay, I have no > idea how to access that VM via the browser to actually test Koha. ?So > I guess I'm looking for a tutorial and/or guidance on how to keep two > installs up to date. Using two VMs would be one way of doing it, but we'd need to know more about your VM setup to work out any problems with accessing their web interfaces simultaneously. The two VMs should be assigned different internal IP addresses by the VM host software; running sudo ifconfig in each one might tell you what they are. As far as having a 3.4 and a 3.2 database in a single VM, it would basically be a matter of * creating two MySQL databases * creating to dev-mode Koha installations, one tracking master and the other 3.2.x, with different run-time directories * creating two Apache site definitions For work that you do on the command line, you'd have to make sure that the PERL5LIB and KOHA_CONF environment variables were set to refer to whichever database you are working with at the time. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From mjr at phonecoop.coop Mon Jan 17 21:02:37 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 17 Jan 2011 20:02:37 +0000 (GMT) Subject: [Koha-devel] Perl // operator In-Reply-To: <20110117174836.GA2327@auckland.lan> Message-ID: <20110117200237.CD1264F733@nail.towers.org.uk> Marc Chantreux wrote: > On Mon, Jan 17, 2011 at 04:51:23PM +0000, MJ Ray wrote: > > It's not very clear, but http://www.cpan.org/src/README.html seems to > > say that 5.8 is still supported. > > perl stable version is 5.12, not even 5.10 (released on December 18, 2007). > > 5.8 (last maintenance release: December 14, 2008) is "maintained". it > doesn't mean "you should use it" but "if you have perl legacy scripts to > run on a old system, we carre about it". Yes, I know all that, but 5.8 has not been end-of-lifed like 5.6 yet, has it? It's in the same "maintained" status as 5.10, it appears. > plus! most of us still use a 5.10 interpreter so we can't provide a > any serious waranty to be 5.8 compliant as long as we haven't a test > suite with large coverage running on a perlbrewed 5.8. So "use 5.008_006;" wouldn't warn you when you exceed it? Ouch. > is there a *real* reason to take us away from all new perl features ? World domination! 5.8 is still a bigger potential user base. The most conspicuous laggard is MacOS X 10.6 which I think has perl 5.10.0 but built in a way that MARC::Charset doesn't like. Happily, it also has some version of 5.8. I wouldn't recommend running Koha on MacOS X, but some people do and I don't understand why we should drop them for the sake of replacing a few defined-s and things like that with less readable alternatives. As I wrote before, I'm fine with whatever Chris decides on 3.4, but 5.8 support should remain in 3.2 and 3.0. Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From chrisc at catalyst.net.nz Tue Jan 18 02:35:56 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 18 Jan 2011 14:35:56 +1300 Subject: [Koha-devel] Perl // operator In-Reply-To: <20110117200237.CD1264F733@nail.towers.org.uk> References: <20110117174836.GA2327@auckland.lan> <20110117200237.CD1264F733@nail.towers.org.uk> Message-ID: <20110118013556.GS27877@rorohiko> * MJ Ray (mjr at phonecoop.coop) wrote: > > As I wrote before, I'm fine with whatever Chris decides on 3.4, but > 5.8 support should remain in 3.2 and 3.0. > Hi All I think making 3.4 use 5.10 is fine, I do agree that we should leave it for 3.2 and 3.0. I will update the dependencies for perl and also MARC::Record dependency to catch the bug fixes galen pushed. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From adrea at moablibrary.org Tue Jan 18 12:00:44 2011 From: adrea at moablibrary.org (adrea at moablibrary.org) Date: Tue, 18 Jan 2011 04:00:44 -0700 Subject: [Koha-devel] Out of the Office Message-ID: <4424e49ddd4f4594a7e21dfd536e4b8e@06ce479b553041e290ed2ff97b97314d> I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org From cnighswonger at foundations.edu Tue Jan 18 14:35:24 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 18 Jan 2011 08:35:24 -0500 Subject: [Koha-devel] Perl // operator In-Reply-To: <20110118013556.GS27877@rorohiko> References: <20110117174836.GA2327@auckland.lan> <20110117200237.CD1264F733@nail.towers.org.uk> <20110118013556.GS27877@rorohiko> Message-ID: 2011/1/17 Chris Cormack : > * MJ Ray (mjr at phonecoop.coop) wrote: >> >> As I wrote before, I'm fine with whatever Chris decides on 3.4, but >> 5.8 support should remain in 3.2 and 3.0. >> > Hi All > > I think making 3.4 use 5.10 is fine, I do agree that we should leave it > for 3.2 and 3.0. Incidentally, the patch in question has not been pushed to 3.2.x. Kind Regards, Chris From mao at lins.fju.edu.tw Tue Jan 18 20:56:20 2011 From: mao at lins.fju.edu.tw (=?UTF-8?B?5q+b5oW256aO?=) Date: Wed, 19 Jan 2011 03:56:20 +0800 Subject: [Koha-devel] Out of the Office In-Reply-To: <4424e49ddd4f4594a7e21dfd536e4b8e@06ce479b553041e290ed2ff97b97314d> References: <4424e49ddd4f4594a7e21dfd536e4b8e@06ce479b553041e290ed2ff97b97314d> Message-ID: Could any stop this mail keeping sending? or, We have to accept it till Adrea come back 2/2/11. 2011/1/18 : > I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. ?I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. ?I will respond to your email as soon as possible when I return to work. > > Thank you, > Adrea > > Adrea Lund > Head of Adult Services > Grand County Public Library > 257 E. Center St. > Moab, UT 84532 > 435-259-1111 ext11 > www.moablibrary.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/ > -- Wishing you all the best. . . . Anthony Mao ??? http://bit.ly/maolins Department of Library and Information Science Fu Jen Catholic University ?http://bit.ly/lins 510 Jhongjheng Rd., Sinjhuang City, Taipei County 24205, Taiwan From chrisc at catalyst.net.nz Tue Jan 18 21:40:29 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 19 Jan 2011 09:40:29 +1300 Subject: [Koha-devel] Out of the Office In-Reply-To: References: <4424e49ddd4f4594a7e21dfd536e4b8e@06ce479b553041e290ed2ff97b97314d> Message-ID: <20110118204029.GV27877@rorohiko> * ??? (mao at lins.fju.edu.tw) wrote: > Could any stop this mail keeping sending? > or, > We have to accept it till Adrea come back 2/2/11. I have stopped it on the main list. Biblibre could you stop it on the devel one? Chris > > 2011/1/18 : > > I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. ?I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. ?I will respond to your email as soon as possible when I return to work. > > > > Thank you, > > Adrea > > > > Adrea Lund > > Head of Adult Services > > Grand County Public Library > > 257 E. Center St. > > Moab, UT 84532 > > 435-259-1111 ext11 > > www.moablibrary.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/ > > > > > > -- > Wishing you all the best. . . . > > > Anthony Mao ??? http://bit.ly/maolins > Department of Library and Information Science > Fu Jen Catholic University ?http://bit.ly/lins > 510 Jhongjheng Rd., Sinjhuang City, > Taipei County 24205, > Taiwan > _______________________________________________ > 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 savitra.sirohi at osslabs.biz Wed Jan 19 07:15:08 2011 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Wed, 19 Jan 2011 11:45:08 +0530 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: Message-ID: Folks, I am looking for suggestions on the best long term, architectural solution to add charting for Koha reports. Do we use: - Google visualization API - Perl module Chart - Perl module GD - something else? Also any input on adding Business Intelligence capabilities? - Perl module Business::Intelligenece::Microstrategy - Integrate with other open source BI tool like Pentaho, Jaspersoft - something else? Thanks! Savitra From jransom at library.org.nz Wed Jan 19 08:33:29 2011 From: jransom at library.org.nz (Joann Ransom) Date: Wed, 19 Jan 2011 20:33:29 +1300 Subject: [Koha-devel] [Koha] Flood recovery in Brisbane - pulling data from Koha In-Reply-To: References: Message-ID: Hi Amanda, I can't even begin to imagine what turmoil your brain is coping with kudos to you for asking for help. I see Bob Birchall has contacted you - that is great and I love that they are offering to help for free :D You may not even need the backend; if the catalogue is up then you can haul out what you need from a web browser. If you want to chat through / bounce off ideas working through this please feel to sing out. Chin up - you will get through this. Cheers Jo. On Wed, Jan 19, 2011 at 5:45 PM, Amanda and Hugh Gardner < hagardner at bigpond.com> wrote: > Thanks Jo, > > I did wonder about pulling out the info on cost and I hadn't thought about > last seen, on loan and purchase date. Thanks! I was too busy trying to > work out how to do it. I'll update my process to include. At the moment I > can't access the backend but am hoping to be able to do that tomorrow. IT > is having huge difficulties providing me with remote access. > > Cheers, > > Amanda > ------------------------------ > *From:* hfields19 at gmail.com [mailto:hfields19 at gmail.com] *On Behalf Of *Joann > Ransom > *Sent:* Wednesday, 19 January 2011 2:36 PM > *To:* Amanda and Hugh Gardner > *Cc:* koha at lists.katipo.co.nz > *Subject:* Re: [Koha] Flood recovery in Brisbane - pulling data from Koha > > Hi Amanda, > > I should think you will be able to run any number of reports over the Koha > data to haul out whatever 'results' you need so long as the backend data is > available. It is easy to manipulate reports data in excel but the 64,000 > line limit is a trap for young players (Access is better). > > You will probably also want to know the stock which was not currently on > issue or loan. A last seen date might be useful too if you need to justify > that the stock list is current ie not 'lost'. > > You may also want to extract the data about cost and list prices and date > of purchase in order to get a sense of the value of the lost stock. You may > need to sort by purchase date and claim 90% of the value of stock less than > 1 year old but only 10% of stock 9 years old etc. > > Good luck > > Cheers Jo. > > 2011/1/19 Amanda and Hugh Gardner > >> Hi All, >> >> I'm hoping I can get some advice with regard to pulling data from Koha. >> >> My library has recently been completely inundated during the Brisbane >> floods and nothing was saved except the library catalogue on Koha! I am the >> current librarian, however, I have only been in the position for four weeks >> and have not had a chance to learn the ins and outs of Koha. I am also not >> a techie so am relying on IT staff to assist with my queries which has not >> proved successful as they are off recovering other parts of the >> organisation's network. >> >> In order to create an inventory of the library collection for insurance >> purposes I would like to export data from the following fields and dump them >> into an Excel create an spreadsheet. >> >> The data I need are from the following fields: >> >> Item type >> Title >> Publisher >> Date >> ISBN >> ISSN >> Item count >> Location >> Barcode >> >> Can this be done from the back end of Koha and if so, how do I do it? >> >> Any advice would be greatly appreciated, keeping in mind I am not familiar >> with this database at all and will have no IT support. >> >> Many thanks, >> >> Amanda >> >> >> _______________________________________________ >> Koha mailing list http://koha-community.org >> Koha at lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> >> > > > -- > Joann Ransom RLIANZA > Head of Libraries, > Horowhenua Library Trust. > > *Q: Why is this email three sentences or less? > A: http://three.sentenc.es* > > -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. *Q: Why is this email three sentences or less? A: http://three.sentenc.es* -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrea at moablibrary.org Wed Jan 19 08:34:13 2011 From: adrea at moablibrary.org (adrea at moablibrary.org) Date: Wed, 19 Jan 2011 00:34:13 -0700 Subject: [Koha-devel] Out of the Office Message-ID: <64e3281028654b41a4b529c53e175604@367e38d0d93c49af96fbe1dc617049b2> I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org From mjr at software.coop Wed Jan 19 11:09:35 2011 From: mjr at software.coop (MJ Ray) Date: Wed, 19 Jan 2011 10:09:35 +0000 (GMT) Subject: [Koha-devel] Out of the Office In-Reply-To: <20110118204029.GV27877@rorohiko> Message-ID: <20110119100935.2085C4F733@nail.towers.org.uk> Chris Cormack wrote: > I have stopped it on the main list. > > Biblibre could you stop it on the devel one? Could you please add filters to hold "Subject: Out of Office" and "Subject: autoreply" for moderation? They should be rare. Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From mjr at phonecoop.coop Wed Jan 19 11:17:37 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 19 Jan 2011 10:17:37 +0000 (GMT) Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: Message-ID: <20110119101737.387F24F733@nail.towers.org.uk> savitra sirohi wrote: > Folks, I am looking for suggestions on the best long term, > architectural solution to add charting for Koha reports. > > Do we use: > - Google visualization API > - Perl module Chart > - Perl module GD > - something else? I'd prefer a Perl module to a closed-source cloud service (for both ethical/privacy and practical debugging reasons), but it's been years since I really reviewed the field. > Also any input on adding Business Intelligence capabilities? Not from me, sorry. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From tomascohen at gmail.com Wed Jan 19 13:49:01 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Jan 2011 09:49:01 -0300 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: Message-ID: On Wed, Jan 19, 2011 at 3:15 AM, savitra sirohi wrote: > Folks, I am looking for suggestions on the best long term, > architectural solution to add charting for Koha reports. > > Do we use: > - Google visualization API > - Perl module Chart > - Perl module GD > - something else? We used JQplot for several charts. To+ From cnighswonger at foundations.edu Wed Jan 19 13:50:31 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 19 Jan 2011 07:50:31 -0500 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: Message-ID: On Wed, Jan 19, 2011 at 1:15 AM, savitra sirohi wrote: > Folks, I am looking for suggestions on the best long term, > architectural solution to add charting for Koha reports. > > Do we use: > - Google visualization API > - Perl module Chart > - Perl module GD GD is already a Koha dependency, so going with that would avoid adding another dependency. Kind Regards, Chris From colin.campbell at ptfs-europe.com Wed Jan 19 15:34:45 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Wed, 19 Jan 2011 14:34:45 +0000 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: Message-ID: <4D36F685.40407@ptfs-europe.com> On 19/01/11 12:50, Chris Nighswonger wrote: > On Wed, Jan 19, 2011 at 1:15 AM, savitra sirohi > wrote: >> Folks, I am looking for suggestions on the best long term, >> architectural solution to add charting for Koha reports. >> >> Do we use: >> - Google visualization API >> - Perl module Chart >> - Perl module GD > > GD is already a Koha dependency, so going with that would avoid adding > another dependency. > And I've seen it used to produce some nice looking reports. Definitely worth looking at. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From tomascohen at gmail.com Wed Jan 19 16:04:28 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Jan 2011 12:04:28 -0300 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: <4D36F685.40407@ptfs-europe.com> References: <4D36F685.40407@ptfs-europe.com> Message-ID: On Wed, Jan 19, 2011 at 11:34 AM, Colin Campbell wrote: > On 19/01/11 12:50, Chris Nighswonger wrote: >> On Wed, Jan 19, 2011 at 1:15 AM, savitra sirohi >> wrote: >>> Folks, I am looking for suggestions on the best long term, >>> architectural solution to add charting for Koha reports. >>> >>> Do we use: >>> - Google visualization API >>> - Perl module Chart >>> - Perl module GD >> >> GD is already a Koha dependency, so going with that would avoid adding >> another dependency. >> > And I've seen it used to produce some nice looking reports. Definitely > worth looking at. I'ts server-side. I'd prefer sending the client all the data inside a json and a javacsript library to render everything ono the client side. My 2 cents To+ From paul.poulain at biblibre.com Wed Jan 19 16:34:49 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 19 Jan 2011 16:34:49 +0100 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: <4D36F685.40407@ptfs-europe.com> Message-ID: <4D370499.6080702@biblibre.com> Le 19/01/2011 16:04, Tomas Cohen Arazi a ?crit : > I'ts server-side. I'd prefer sending the client all the data inside a > json and a javacsript library to render everything ono the client > side. shouldn't we just wait for html5 support then (isn't this in html5. Not sure at all, if someone want to confirm...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From salvazm at masmedios.com Wed Jan 19 17:10:16 2011 From: salvazm at masmedios.com (Salvador Zaragoza Rubio) Date: Wed, 19 Jan 2011 17:10:16 +0100 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: <4D370499.6080702@biblibre.com> References: <4D36F685.40407@ptfs-europe.com> <4D370499.6080702@biblibre.com> Message-ID: <4D370CE8.1040105@masmedios.com> El 19/01/2011 16:34, Paul Poulain escribi?: > Le 19/01/2011 16:04, Tomas Cohen Arazi a ?crit : >> I'ts server-side. I'd prefer sending the client all the data inside a >> json and a javacsript library to render everything ono the client >> side. > shouldn't we just wait for html5 support then (isn't this in html5. Not > sure at all, if someone want to confirm...) > The canvas element is part of HTML5 and allows for dynamic, scriptable rendering of 2D shapes and bitmap images. [SIC] http://en.wikipedia.org/wiki/Canvas_element The element is supported by the current versions of Mozilla Firefox, Google Chrome, Safari, and Opera. Current versions of Internet Explorer including IE 8 cannot natively display canvas content.[7] Google and Mozilla plugins are available[8] and support is under development for Internet Explorer 9. [SIC] http://en.wikipedia.org/wiki/Canvas_element http://en.wikipedia.org/wiki/Canvas_element http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5_Canvas) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5527 bytes Desc: S/MIME Cryptographic Signature URL: From tomascohen at gmail.com Wed Jan 19 17:25:09 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Jan 2011 13:25:09 -0300 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: <4D370CE8.1040105@masmedios.com> References: <4D36F685.40407@ptfs-europe.com> <4D370499.6080702@biblibre.com> <4D370CE8.1040105@masmedios.com> Message-ID: 2011/1/19 Salvador Zaragoza Rubio : > El 19/01/2011 16:34, Paul Poulain escribi?: >> Le 19/01/2011 16:04, Tomas Cohen Arazi a ?crit : >>> I'ts server-side. I'd prefer sending the client all the data inside a >>> json and a javacsript library to render everything ono the client >>> side. >> shouldn't we just wait for html5 support then (isn't this in html5. Not >> sure at all, if someone want to confirm...) >> > The canvas element is part of HTML5 and allows for dynamic, scriptable > rendering of 2D shapes and bitmap images. [SIC] > http://en.wikipedia.org/wiki/Canvas_element If we agree this should be done client-side, we could see several js libraries roadmaps to see if they will be porting to canvas element soon. To+ From cnighswonger at foundations.edu Wed Jan 19 17:39:11 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 19 Jan 2011 11:39:11 -0500 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: <4D36F685.40407@ptfs-europe.com> Message-ID: On Wed, Jan 19, 2011 at 10:04 AM, Tomas Cohen Arazi wrote: > On Wed, Jan 19, 2011 at 11:34 AM, Colin Campbell > wrote: >> On 19/01/11 12:50, Chris Nighswonger wrote: >>> On Wed, Jan 19, 2011 at 1:15 AM, savitra sirohi >>> wrote: >>>> Folks, I am looking for suggestions on the best long term, >>>> architectural solution to add charting for Koha reports. >>>> >>>> Do we use: >>>> - Google visualization API >>>> - Perl module Chart >>>> - Perl module GD >>> >>> GD is already a Koha dependency, so going with that would avoid adding >>> another dependency. >>> >> And I've seen it used to produce some nice looking reports. Definitely >> worth looking at. > > I'ts server-side. I'd prefer sending the client all the data inside a > json and a javacsript library to render everything ono the client > side. So what are the pros/cons for server-side/client-side processing of charts? Kind Regards, Chris From tomascohen at gmail.com Wed Jan 19 17:45:23 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Jan 2011 13:45:23 -0300 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: <4D36F685.40407@ptfs-europe.com> Message-ID: On Wed, Jan 19, 2011 at 1:39 PM, Chris Nighswonger wrote: > > So what are the pros/cons for server-side/client-side processing of charts? If you used google chart API you will see you can enjoy several features like zooming, region selection, etc that are nice. The same for pie charts where you can choose several pieces and work with their values. I not very creative today but some interactivity might be useful. Modifying the graphs without reloading. The server-load part perhaps is not very important as this feature would be used primarly on the staff interface. To+ From chris at bigballofwax.co.nz Wed Jan 19 17:58:37 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 20 Jan 2011 05:58:37 +1300 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: <4D36F685.40407@ptfs-europe.com> Message-ID: On 20 January 2011 05:45, Tomas Cohen Arazi wrote: > On Wed, Jan 19, 2011 at 1:39 PM, Chris Nighswonger > wrote: >> >> So what are the pros/cons for server-side/client-side processing of charts? > > If you used google chart API you will see you can enjoy several > features like zooming, region selection, etc that are nice. The same > for pie charts where you can choose several pieces and work with their > values. > I personally think we should take that out of the mix. If we were to do client side, I agree with MJ that it should be done using free software. Not a closed source cloud API. Again both for ethical (friends don't let friends use proprietary software :)) and practical reasons (depending on an Opaque API that might change makes maintenance hard). So if we were to do it clientside, what Free Software library could we use, and what benefits would that give us over a server side library and are their any downsides. Chris From tomascohen at gmail.com Wed Jan 19 18:14:55 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Jan 2011 14:14:55 -0300 Subject: [Koha-devel] Charting/Analysis for Koha In-Reply-To: References: <4D36F685.40407@ptfs-europe.com> Message-ID: On Wed, Jan 19, 2011 at 1:58 PM, Chris Cormack wrote: > On 20 January 2011 05:45, Tomas Cohen Arazi wrote: >> On Wed, Jan 19, 2011 at 1:39 PM, Chris Nighswonger >> wrote: >>> >>> So what are the pros/cons for server-side/client-side processing of charts? >> >> If you used google chart API you will see you can enjoy several >> features like zooming, region selection, etc that are nice. The same >> for pie charts where you can choose several pieces and work with their >> values. >> > I personally think we should take that out of the mix. If we were to > do client side, I agree with MJ that it should be done using free > software. Not a closed source cloud API. Again both for ethical > (friends don't let friends use proprietary software :)) and practical > reasons (depending on an Opaque API that might change makes > maintenance hard). > > So if we were to do it clientside, what Free Software library could we > use, and what benefits would that give us over a server side library > and are their any downsides. I fully agree that we should use a free and open source library, I proposed trying JQplot (http://www.jqplot.com/). In my email, I used the example of google's library for pointing the kind of usability that a library on the client could allow. To+ From nengard at gmail.com Sat Jan 22 19:59:39 2011 From: nengard at gmail.com (Nicole Engard) Date: Sat, 22 Jan 2011 13:59:39 -0500 Subject: [Koha-devel] January Newsletter: Call for Articles In-Reply-To: References: Message-ID: I have only two articles for the January newsletter ... please get me your content soon so I can get this out on time. Nicole On Fri, Jan 14, 2011 at 9:03 PM, Nicole Engard wrote: > Just a friendly reminder that I have yet to receive any articles for > this month's newsletter. Please start sending them along and get them > to me no later than the 23rd (your local time). > > Thanks > Nicole > > On Sat, Jan 8, 2011 at 7:34 PM, Nicole Engard wrote: >> Hi all, >> >> After our IRC meeting this month I am going to try and keep doing this >> monthly. ?The new publication date for 2011 will be the 25th of the >> month. ?I need all your articles (preferably short - with links to >> longer articles if there is more to share) sent to me by the 23rd your >> local time. >> >> Thanks in advance for all contributions, >> Nicole C. Engard >> Documentation Manager >> > From cnighswonger at foundations.edu Sun Jan 23 00:10:03 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sat, 22 Jan 2011 18:10:03 -0500 Subject: [Koha-devel] Koha 3.2.3 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.2.3. The package can be retrieved from: http://download.koha-community.org/koha-3.02.03.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.03.tar.gz.MD5 http://download.koha-community.org/koha-3.02.03.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.03.tar.gz.sig Release notes for 3.2.3 are below the fold. Come and get it! [More...] RELEASE NOTES FOR KOHA 3.2.3 - 22 January 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.2.3 can be downloaded from: http://download.koha-community.org/koha-3.02.03.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation Koha 3.2.3 is a bugfix/maintenance release. Highlights of 3.2.3 ====================== Some of the higher profile bugs addressed in this release are: 4286 Subscription expired at its creation 4438 incorrect "Budget total exceeds period allocation" error when editing fund 4945 Patron search is limited by default to the currently logged-in library 5480 Some usual UNIMARC cataloguing plugins doesn't work anymore 5542 Limit to availability not working 5611 can't add comments and tags in the OPAC when mod_perl is activated This release also contains a variety of minor enhancements improving Koha's interface and underlying scripts. Bugs fixed in 3.2.3 ====================== 3153 'maxoutstanding' syspref does not disallow placing holds on staff side 3199 batchRebuildBiblioTables.pl failed due to missing argument 3262 OPAC needs syspref to show homebranch instead of current location on detail page 3347 Inconsistencies with tables in opac-shelves.tmpl 3459 topissues doesn't take care of ccode. 3550 Use GetRecordValue to get the subtitle 3737 search order title should me more fuzzy 3743 Acquisition stats ordering by month 3859 Attach Item Clarification 3918 Add to order lists inconsistent 3987 New Sys Prefs Branch - Alphabetize prefs in sections 4131 link on subscripton page says 'create routing' even when one exists 4473 Recent comments view for the OPAC 4826 Choose either 'new basket' or 'add basket' 4885 Only 1 ISBN shows in non-XSL detail view 4891 Order facets in left sidebar of search results 4908 OPAC patron details page doesn't show patron's home library 4942 When a new patron is created and the expiry date is left blank, it comes up with an invalid date 4946 hold warning needs rewording 4950 checkbox should be removed when can't place a hold 4984 Invalid XHTML in staff client search results 4997 More searches menu not on OPAC MARC and ISBD detail pages 5006 Invalid XHTML in record matching rules template 5040 "Distance" misspelled in default framework 5045 The help doesn't work if something strips the referrers 5055 crontab.example should use standard file paths 5143 Subtitles not showing on view_holdsqueue.pl 5294 Vendor name shows with '%20' 5327 Unit tests required for all C4 modules 5374 Update date/time last transaction (MARC 005) when saving biblio record 5375 Update date/time last transaction (MARC 005) when saving authority record 5398 several pages in the staff interface do not obey noItemTypeImages 5399 remove useless eval 'use C4::Foo' 5403 C4::Koha::DisplayISBN should be wrapper for Business::ISBN->as_string 5419 account fees not showing as reason to not check out 5446 Item creation in Acquisition module doesn't control mandatory fields 5451 can add tags with userlogin turned off 5470 improvements to results display in the staff client 5486 HomeOrHoldingBranch description inaccurate 5489 Send hold email to branch email address if it exists instead of koha email address 5492 import patrons page title reads 'cataloging' 5497 add option to supply library phone #, address, and other fields to circ receipts 5510 Hard to tell what instance a cron error comes from 5518 Add to shelf icon doesn't appear in OPAC results page 5526 List of lists should be in alphabetical order by list name 5531 Missing sysprefs in language specific files 5550 Wrong file name in package-installed docs 5556 OPAC does not display the type of authority 5557 Logs cannot be viewed by user with granular permission view_system_logs 5562 circ history says 'issues' instead of 'checkouts' 5563 note on enhanced content about cover images inaccurate 5570 item types not showing on other editions 5571 tags as bulleted list too long 5582 MARC Field Documentation links incorrect on tags < 080 5583 Rename variable to reflect what it is 5585 today's date does not display on receipts and slips 5589 Duplicate Code in Suggestions 5601 SIP Due dates miscalculated via DateTime 5603 advance_notices.pl generating "uninitialized value in hash element" 5604 additional icons for the Seshat set Commits in 3.2.3 without a referenced bug report: * Added more unit tests to check when JSONStream should fail. * Added unit tests to test all of get_amazon_tld in Amazon.pm. * Added unit tests for Biblio and moved it to db_dependent as it requires the database. * Added unit tests using a test database for XISBN. * Created unit testing using the testdatabase for XISBN. * Added extra unit tests to Debug.t * Adding new developers to the history * Removing OPACNoResultsFound Enhancement Syspref * Deleted old sample budget sql-data for Ukrainian and Russian System requirements ====================== Changes since 3.0: * The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.x. Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://www.kohadocs.org/usersguide/apb.html for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.2 is Release Manager: Galen Charlton Documentation Manager: Nicole Engard Translation Manager: Chris Cormack Release Maintainer (3.0.x): Henri-Damien Laurent Release Maintainer (3.2.x): Chris Nighswonger Credits ====================== We thank the following individuals who contributed patches to Koha 3.2.3: Nahuel Angelinetti Claudia Colin Campbell Galen Charlton Chris Cormack Fr?d?ric Demians Johnboy Marcel de Rooy Serhij Dubyk {?????? ?????} Nicole Engard Magnus Enger Amit Gupta Srdjan Jankovic Henri-Damien Laurent Owen Leonard Chris Nighswonger Liz Rea Bryce Sanchez Robin Sheat Spartaness Zach Sim Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes to koha-patches at lists.koha-community.org. The 3.2.x Release Maintainer especially thanks the 3.4 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 287 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.3 on its announced schedule. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. From fridolyn.somers at gmail.com Mon Jan 24 14:28:24 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 24 Jan 2011 14:28:24 +0100 Subject: [Koha-devel] GIT repository Lyon 2 University Message-ID: Hie, Progilone has finished the Koha project for Lyon 2 University (France). You can find all features developed on our GIT repository http://git.progilone.com/. Each feature is in a branch started from 3.2.0 master revision from koha-community. Feel free to ask for details. Best regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From ian.walls at bywatersolutions.com Mon Jan 24 14:54:44 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Mon, 24 Jan 2011 08:54:44 -0500 Subject: [Koha-devel] GIT repository Lyon 2 University In-Reply-To: References: Message-ID: Oooh, some good looking stuff in there! -Ian 2011/1/24 Fridolyn SOMERS > Hie, > > Progilone has finished the Koha project for Lyon 2 University (France). > > You can find all features developed on our GIT repository > http://git.progilone.com/. > Each feature is in a branch started from 3.2.0 master revision from > koha-community. > > Feel free to ask for details. > > Best regards, > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Mon Jan 24 15:04:57 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Mon, 24 Jan 2011 09:04:57 -0500 Subject: [Koha-devel] GIT repository Lyon 2 University In-Reply-To: References: Message-ID: > Each feature is in a branch started from 3.2.0 master revision from > koha-community. > > Feel free to ask for details. Okay, asking for details :) Can you create entries in Bugzilla for each of these features? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From fridolyn.somers at gmail.com Mon Jan 24 15:19:45 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 24 Jan 2011 15:19:45 +0100 Subject: [Koha-devel] GIT repository Lyon 2 University In-Reply-To: References: Message-ID: Ok. For all features ? Some are very specific and must be adapted to current revision. I'll begin with features that may be included easily. Regards, On Mon, Jan 24, 2011 at 3:04 PM, Owen Leonard wrote: > > Each feature is in a branch started from 3.2.0 master revision from > > koha-community. > > > > Feel free to ask for details. > > Okay, asking for details :) Can you create entries in Bugzilla for > each of these features? > > -- Owen > > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From charl at prograbiz.com Mon Jan 24 20:38:09 2011 From: charl at prograbiz.com (Charl) Date: Mon, 24 Jan 2011 21:38:09 +0200 Subject: [Koha-devel] Koha 2 to Koha 3 Message-ID: <75E30349CF6045928796B02C7C634FD6@CharlPC> ?I am upgrading one of our sites from 2.9 to 3. I cannot find the procedure anywhere. Can anyone please help with the procedure? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Mon Jan 24 22:33:49 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 25 Jan 2011 10:33:49 +1300 Subject: [Koha-devel] Koha 2 to Koha 3 In-Reply-To: <75E30349CF6045928796B02C7C634FD6@CharlPC> References: <75E30349CF6045928796B02C7C634FD6@CharlPC> Message-ID: 2011/1/25 Charl : > I am upgrading one of our sites from 2.9 to 3. I cannot find the procedure > anywhere. > Can anyone please help with the procedure? > Thank you. > _______________________________________________ > Hi Charl You will want to get to 3.2.3 eventually (being the latest stable version of Koha) but to do so, you first have to upgrade to 3.0.0 A good guide to doing that is here http://wiki.koha-community.org/wiki/Upgrading_2.2 Hope that helps Chris From cybermon at gmail.com Wed Jan 26 08:15:34 2011 From: cybermon at gmail.com (Cybermon) Date: Wed, 26 Jan 2011 15:15:34 +0800 Subject: [Koha-devel] Softlink Alice import to koha Message-ID: Dear koha developer, I would like to ask 2 questions from you. 1. I would like to import catalog information from the Softlink Alice/library software/ to koha ILS. Could you help me that how can i import our book catalog with items and barcodes to Koha. 2. How can i install other additional languages/Mongolian/ after installed Koha on server? When I following the wiki guide than i have following error. Install templates 'opac From: /usr/share/koha/opac/htdocs/opac-tmpl/prog/en/ To : /usr/share/koha/opac/htdocs/opac-tmpl/prog/mon With: /usr/share/koha/intranet/cgi-bin/misc/translator/po/mon-i-opac-t-prog-v-3002000.po Can't exec "/usr/share/koha/intranet/cgi-bin/misc/translator/ tmpl_process3.pl": No such file or directory at LangInstaller.pm line 286. Install templates 'intranet From: /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/ To : /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/mon With: /usr/share/koha/intranet/cgi-bin/misc/translator/po/mon-i-staff-t-prog-v-3002000.po Can't exec "/usr/share/koha/intranet/cgi-bin/misc/translator/ tmpl_process3.pl": No such file or directory at LangInstaller.pm line 286. Koha directories hierarchy for mon must be created first root at UBPLServer:/usr/share/koha/misc/translator# perl translate install mon readdir() attempted on invalid dirhandle $fh at LangInstaller.pm line 62. closedir() attempted on invalid dirhandle $fh at LangInstaller.pm line 63. Install templates Best regards, Gana -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Jan 27 17:03:54 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 27 Jan 2011 17:03:54 +0100 Subject: [Koha-devel] Development workflow Message-ID: <4D41976A.1090109@biblibre.com> Hello koha-devel, The more time passes, the more I think we have a workflow for Koha development that does not work correctly/efficiently/fluently. The rule we have is: * create a branch for the feature * file a bug for it * submit your branch to koha-patches ML * the RM checks that everything apply smoothly on master & ask for QA * someone signs-off the branch/patch * the RM merge the branch. For the maintenance branch, this workflow is perfect and must be secured more and more to avoid any regression. As I see it, there is always someone that can find time to sign-off a patch or 2. As ppl have system live with it i'm sure it's cricital for many ppl to check & double check ! But for the next release/unstable branch this workflow does not work well. Here is a single line of something owen said on the chat today: paul_p: I would much prefer to be testing your stuff today, but other stuff is taking precedence. God knows i'll be forever thankfull to owen for the work he does. But this sentence reveals something: for most of us, there is always "other stuff taking precedence" :\ BibLibre has submitted many new features 3 months ago. I tried to motivate ppl to get feedback & sign-off. I even have organised an IRC meeting ... where no one came. Those patches includes new features, and requires a lot of work to be tested. 2 weeks ago, I did the same for a bunch of small improvements (and I have many many more pending). Once again, no feedback, except for one very easy-to-test (new images) : signed-off by Nicole & pushed by chris in less than 24H! Those 2 minor events (with owen & nicole) made me realize that it's technically and functionnaly hard & long to test: rebase, drop database, install, file test cases, check the new features,... At KohaCon, liz tested some of those features and said "wow, great, I want this feature for my library !" (I don't remember what it was exactly). The problem is that liz is not a techie woman, and can't test patches by her own. For our images, it was easy for Nicole to test, no need to updatedatabase or anything complex, just reach the itemtypes.pl page check the images are here. Easy for a librarian ! Other point: dependancies between new features. Let me take an example: Templates on those devs relies on html::template. Chris is working on moving everything to Template::Toolkit. Once he consider it's ready, he should submit for QA, as for every new features. Suppose no-one sign-off. And suppose someone sign-off, there are 2 options: * move master to T::T when it's signed-off. What happends with other branches not merged ? they can't be merged anymore, they have to be rewritten. wow, I can't imagine that something we've submitted for QA 3 months ago has to be rewritten because no-one took care of it ! * wait until those branches are merged. Two major problems here: the release date won't be respected, and we have switched again to feature based release. Or 3.4 will be released on time, but won't contain many things all those great features that are live in all our libraries since months. The second problem is that other devs are on the way. They still rely on H::T as master is based on that. Switching to T::T will cause problems for those branches later. well, I think that none of those solutions is a correct one. I can take an other example: the analytics record feature may/will probably overlap functionnaly with the new features we have submitted for cataloguing (not sure, but i think so). Suppose our cataloguing branch is integrated in 2 weeks. it has been submitted 3 months ago. It means our indian colleagues will have to rebase & face problems to get their analytical record branch working. If our branch had been merged quickly, they would have had 3 more months to deal with it. Our actual workflow, causes a lot of overhead ! And -worst- I don't think it improves the stability & security: there are merge problems that are difficults to detect. It means that any test done on analytical records would have to be done again if our cataloguing branch is merged : more work, more pain. And the later a branch is merged, the smaller the time to find a problem. My main conclusion is that we are not a large enough community to deal with testing/validating/merging new features in a short timeline. So I think we must change the way we integrate new features. The general idea being: remove the sign-off lock on the workflow. Here is a proposal: Let's go back to the timeline: we plan to release a version every 6 months. We could have a window of, say 4 months. During those 4 months a feature can be included if : 1- the submitter provides something that applies on master (ie: it's technically valid) 2- no-one object in 2 weeks (or 3, or 4, or defined by the RM when the branch is submitted) It put more pressure on others to test quickly, and don't put pain on parallels/parallelizing developments. Once a branch is merged if there is a problem, then everybody should see it, and it will be fixed ! Then, for 1 month, any new feature can be applied only if a newly submitted branch is approved/signed-off (less than 2 months to detect a problem in a new feature is a must-have) Then, feature freeze, 1 month debugging and translating. I know it is a big change in the workflow, but the actual one is not working well, so, we have to find another one. I humbly request to have this question being put on the next irc agenda (which does not mean you should not also start a thread here, of course) PS: pls don't say i'm wrong and the workflow works well. Having branches submitted 3 months ago, getting no feedback, and planning to have a release in less than 3 months, can't be considered as something working well. Friendly. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From oleonard at myacpl.org Thu Jan 27 17:23:29 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 27 Jan 2011 11:23:29 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: <4D41976A.1090109@biblibre.com> References: <4D41976A.1090109@biblibre.com> Message-ID: One of the reasons it's taking so long to test bug 5575, and one of the reasons why it's hard to get others to test branches like it is that the branch includes so many changes at once. It would be so much simpler to be testing a branch that introduced a single feature or bugfix. I could look at that one thing, confirm it works, and sign off. As it is I have to poke around looking in different places, trying different things, looking for things which might have changed. It is so important that qa branches/patches are feature- or bug-specific. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Thu Jan 27 17:43:11 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 27 Jan 2011 17:43:11 +0100 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> Message-ID: <4D41A09F.4080107@biblibre.com> Le 27/01/2011 17:23, Owen Leonard a ?crit : > One of the reasons it's taking so long to test bug 5575, and one of > the reasons why it's hard to get others to test branches like it is > that the branch includes so many changes at once. It would be so much > simpler to be testing a branch that introduced a single feature or > bugfix. I could look at that one thing, confirm it works, and sign > off. As it is I have to poke around looking in different places, > trying different things, looking for things which might have changed. > > It is so important that qa branches/patches are feature- or bug-specific. Yes, I agree, (and this point about too large branches has already been rised) But: * when you add a major new feature, there are always many dependancies, making the branch not easy to test * it's not only a problem for this specific branch. I'm not comfortable with the fact that smaller patches/branches stays pending without feedback. No-one has given feedback on other branches as well. Including new ones that are very small and should/could be validated easily The problem is not that it takes so long to test, it's that no-one test ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ian.walls at bywatersolutions.com Thu Jan 27 17:49:53 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 27 Jan 2011 11:49:53 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: <4D41976A.1090109@biblibre.com> References: <4D41976A.1090109@biblibre.com> Message-ID: Paul, I hear you. There are lots of really great features that are in limbo, waiting to be tested. The unfortunate situation of life is that we're all incredibly busy, and it's hard to find time to test things. This is compounded when testing certain features requires coding or systems experience, since that limits the pool of potential testers. As a result, lots of good stuff sits, waits, and diverges. So what can be done? I don't think that changing the signoff procedure will have the desired effect. That'll just let more unreviewed code slip in, potentially introducing bugs we won't find for weeks/months/years. I think a better solution is make it easier to test and signoff on work. There are several components to this: - Testing plans for larger developments/bugfixes - A robust testing data set made readily available - Teaching people how to test and signoff on code By including testing plans with developments or complex bugfixes, the developer is communicating to everyone how they can prove their code works. It lays out the intention of the development (it should do x, y and z), and a series of tests to show how to get x, y and z without losing a, b and c. Combine this testing plan (written in language librarians can understand, not coder jargon) with the necessary data set to do the testing (an SQL dump you just load into a DB), and you've lowered the barrier for testing so that anyone who can afford a little time to run through a series of listed procedures can answer the question "does this work?". The third step to this is to lay out the procedure for running through the test plan in a clear, simple manner, and distribute that information far and wide. Make it something that librarians can do by following a list of steps. Lowering the threshold of experience required to test things will allow us to harness the Long Tail. To this end, I'm throwing my hat in the ring for Quality Assurance Manager for Koha 3.6. My proposal can be found on the wiki ( http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and much of it is explained above. In addition to this, I would also serve as a coordinator for testing work submitted, and provide regular reports to the community on the status of these developments. Branches that are not receiving active testing feedback would receive attention towards creating a simpler, easier to follow testing plan. I would very much like to discuss this at the next IRC meeting. It'll be pretty early for me (5am, I believe), but I'll caffeinate heavily beforehand :) Cheers, -Ian On Thu, Jan 27, 2011 at 11:03 AM, Paul Poulain wrote: > Hello koha-devel, > > The more time passes, the more I think we have a workflow for Koha > development that does not work correctly/efficiently/fluently. > The rule we have is: > * create a branch for the feature > * file a bug for it > * submit your branch to koha-patches ML > * the RM checks that everything apply smoothly on master & ask for QA > * someone signs-off the branch/patch > * the RM merge the branch. > > For the maintenance branch, this workflow is perfect and must be secured > more and more to avoid any regression. As I see it, there is always > someone that can find time to sign-off a patch or 2. As ppl have > system live with it i'm sure it's cricital for many ppl to check & > double check ! > > But for the next release/unstable branch this workflow does not work well. > > Here is a single line of something owen said on the chat today: > paul_p: I would much prefer to be testing your stuff today, but > other stuff is taking precedence. > > God knows i'll be forever thankfull to owen for the work he does. But this > sentence reveals something: for most of us, there is always "other stuff > taking precedence" :\ > > BibLibre has submitted many new features 3 months ago. I tried to > motivate ppl to get feedback & sign-off. I even have organised an IRC > meeting ... where no one came. Those patches includes > new features, and requires a lot of work to be tested. > 2 weeks ago, I did the same for a bunch of small improvements (and I > have many many more pending). Once again, no feedback, except for one > very easy-to-test (new images) : signed-off by Nicole & pushed by chris > in less than 24H! > Those 2 minor events (with owen & nicole) made me realize that it's > technically and > functionnaly hard & long to test: rebase, drop database, install, file > test cases, check the new features,... At KohaCon, liz tested some of > those features and said "wow, great, I want this feature for my library > !" (I don't remember what it was exactly). The problem is that liz is > not a techie woman, and can't test patches by her own. For our images, > it was easy for Nicole to test, no need to updatedatabase or anything > complex, just reach the itemtypes.pl page check the images are here. > Easy for a librarian ! > > Other point: dependancies between new features. Let me take an example: > Templates on those devs relies on html::template. Chris is working on > moving everything to Template::Toolkit. > Once he consider it's ready, he should submit for QA, as for every new > features. > Suppose no-one sign-off. > And suppose someone sign-off, there are 2 options: > * move master to T::T when it's signed-off. What happends with other > branches > not merged ? they can't be merged anymore, they have to be rewritten. > wow, I can't imagine that something we've submitted for QA 3 months ago > has to be rewritten because no-one took care of it ! > * wait until those branches are merged. Two major problems here: the > release date won't be respected, and we have switched again to feature > based release. Or 3.4 will be released on time, but won't contain many > things all those great features that are live in all our libraries since > months. The second problem is that other devs are on the way. They still > rely on H::T as master is based on that. Switching to T::T will cause > problems for those branches later. > well, I think that none of those solutions is a correct one. > > I can take an other example: the analytics record feature may/will > probably overlap functionnaly with the new features we have submitted > for cataloguing (not sure, but i think so). Suppose our cataloguing > branch is integrated in 2 weeks. it has been submitted 3 months ago. It > means our indian colleagues will have to rebase & face problems to get > their analytical record branch working. If our branch had been merged > quickly, they would have had 3 more months to deal with it. > Our actual workflow, causes a lot of overhead ! And -worst- I don't > think it improves the stability & security: there are merge problems > that are difficults to detect. It means that any test done on analytical > records would have to be done again if our cataloguing branch is merged > : more work, more pain. And the later a branch is merged, the smaller > the time to find a problem. > > My main conclusion is that we are not a large enough community to deal > with testing/validating/merging new features in a short timeline. So I > think we must change the way we integrate new features. The general idea > being: remove the sign-off lock on the workflow. > > Here is a proposal: > Let's go back to the timeline: we plan to release a version every 6 months. > We could have a window of, say 4 months. During those 4 months a feature > can be included if : > 1- the submitter provides something that applies on master (ie: it's > technically valid) > 2- no-one object in 2 weeks (or 3, or 4, or defined by the RM when the > branch is submitted) > > It put more pressure on others to test quickly, and don't put pain on > parallels/parallelizing developments. Once a branch is merged if there > is a problem, then everybody should see it, and it will be fixed ! > > Then, for 1 month, any new feature can be applied only if a newly > submitted branch is approved/signed-off (less than 2 months to detect a > problem in a new feature is a must-have) > Then, feature freeze, 1 month debugging and translating. > > I know it is a big change in the workflow, but the actual one is not > working well, so, we have to find another one. > I humbly request to have this question being put on the next irc agenda > (which does not mean you should not also start a thread here, of course) > > PS: pls don't say i'm wrong and the workflow works well. Having branches > submitted 3 months ago, getting no feedback, and planning to have a release > in less than 3 months, can't be considered as something working well. > > Friendly. > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Thu Jan 27 18:03:14 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 28 Jan 2011 06:03:14 +1300 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> Message-ID: 2011/1/28 Ian Walls : > Paul, > > > I hear you.? There are lots of really great features that are in limbo, > waiting to be tested.? The unfortunate situation of life is that we're all > incredibly busy, and it's hard to find time to test things.? This is > compounded when testing certain features requires coding or systems > experience, since that limits the pool of potential testers.? As a result, > lots of good stuff sits, waits, and diverges. > > So what can be done?? I don't think that changing the signoff procedure will > have the desired effect.? That'll just let more unreviewed code slip in, > potentially introducing bugs we won't find for weeks/months/years. > > I think a better solution is make it easier to test and signoff on work. I agree whole heartedly > There are several components to this: l> > Testing plans for larger developments/bugfixes > A robust testing data set made readily available > Teaching people how to test and signoff on code > > By including testing plans with developments or complex bugfixes, the > developer is communicating to everyone how they can prove their code works. > It lays out the intention of the development (it should do x, y and z), and > a series of tests to show how to get x, y and z without losing a, b and c. > > Combine this testing plan (written in language librarians can understand, > not coder jargon) with the necessary data set to do the testing (an SQL dump > you just load into a DB), and you've lowered the barrier for testing so that > anyone who can afford a little time to run through a series of listed > procedures can answer the question "does this work?". > > The third step to this is to lay out the procedure for running through the > test plan in a clear, simple manner, and distribute that information far and > wide.? Make it something that librarians can do by following a list of > steps.? Lowering the threshold of experience required to test things will > allow us to harness the Long Tail. > > To this end, I'm throwing my hat in the ring for Quality Assurance Manager > for Koha 3.6.? My proposal can be found on the wiki > (http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and much > of it is explained above.? In addition to this, I would also serve as a > coordinator for testing work submitted, and provide regular reports to the > community on the status of these developments.? Branches that are not > receiving active testing feedback would receive attention towards creating a > simpler, easier to follow testing plan. > That sounds like a great idea to me. I think that this is indeed missing, a champion of testing if you will, someone to pester people :) > I would very much like to discuss this at the next IRC meeting.? It'll be > pretty early for me (5am, I believe), but I'll caffeinate heavily beforehand > :) > I think Ian has covered the sentiment of what I wanted to say, the problem isn't that stuff needs to be tested, I think we all agree things should be tested and signed off before going in master. But that testing is hard. Testing is made much harder by not following the one feature per branch rule. I just wanted to touch on one point Paul mentioned about the T::T work. We have been working to create a script to automatically convert H::T::P templates to T::T. Just so that we don't get into the scenario Paul mentions of having people having to rewrite their changes. Hundreds of hours of work have gone into making it so that the burden won't fall on the people submitting the code. Eventually we will stop accepting patches in H::T::P but it wont be write away, and certainly anything already submitted we wont be trying to make the authors rewrite. Chris From cnighswonger at foundations.edu Thu Jan 27 18:06:37 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 27 Jan 2011 12:06:37 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> Message-ID: +1 to Ian's thoughts. Kind Regards, Chris 2011/1/27 Ian Walls > Paul, > > > I hear you. There are lots of really great features that are in limbo, > waiting to be tested. The unfortunate situation of life is that we're all > incredibly busy, and it's hard to find time to test things. This is > compounded when testing certain features requires coding or systems > experience, since that limits the pool of potential testers. As a result, > lots of good stuff sits, waits, and diverges. > > So what can be done? I don't think that changing the signoff procedure > will have the desired effect. That'll just let more unreviewed code slip > in, potentially introducing bugs we won't find for weeks/months/years. > > I think a better solution is make it easier to test and signoff on work. > There are several components to this: > > - Testing plans for larger developments/bugfixes > - A robust testing data set made readily available > - Teaching people how to test and signoff on code > > By including testing plans with developments or complex bugfixes, the > developer is communicating to everyone how they can prove their code works. > It lays out the intention of the development (it should do x, y and z), and > a series of tests to show how to get x, y and z without losing a, b and c. > > Combine this testing plan (written in language librarians can understand, > not coder jargon) with the necessary data set to do the testing (an SQL dump > you just load into a DB), and you've lowered the barrier for testing so that > anyone who can afford a little time to run through a series of listed > procedures can answer the question "does this work?". > > The third step to this is to lay out the procedure for running through the > test plan in a clear, simple manner, and distribute that information far and > wide. Make it something that librarians can do by following a list of > steps. Lowering the threshold of experience required to test things will > allow us to harness the Long Tail. > > To this end, I'm throwing my hat in the ring for Quality Assurance Manager > for Koha 3.6. My proposal can be found on the wiki ( > http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and much > of it is explained above. In addition to this, I would also serve as a > coordinator for testing work submitted, and provide regular reports to the > community on the status of these developments. Branches that are not > receiving active testing feedback would receive attention towards creating a > simpler, easier to follow testing plan. > > I would very much like to discuss this at the next IRC meeting. It'll be > pretty early for me (5am, I believe), but I'll caffeinate heavily beforehand > :) > > Cheers, > > > -Ian > > > > > On Thu, Jan 27, 2011 at 11:03 AM, Paul Poulain wrote: > >> Hello koha-devel, >> >> The more time passes, the more I think we have a workflow for Koha >> development that does not work correctly/efficiently/fluently. >> The rule we have is: >> * create a branch for the feature >> * file a bug for it >> * submit your branch to koha-patches ML >> * the RM checks that everything apply smoothly on master & ask for QA >> * someone signs-off the branch/patch >> * the RM merge the branch. >> >> For the maintenance branch, this workflow is perfect and must be secured >> more and more to avoid any regression. As I see it, there is always >> someone that can find time to sign-off a patch or 2. As ppl have >> system live with it i'm sure it's cricital for many ppl to check & >> double check ! >> >> But for the next release/unstable branch this workflow does not work well. >> >> Here is a single line of something owen said on the chat today: >> paul_p: I would much prefer to be testing your stuff today, but >> other stuff is taking precedence. >> >> God knows i'll be forever thankfull to owen for the work he does. But this >> sentence reveals something: for most of us, there is always "other stuff >> taking precedence" :\ >> >> BibLibre has submitted many new features 3 months ago. I tried to >> motivate ppl to get feedback & sign-off. I even have organised an IRC >> meeting ... where no one came. Those patches includes >> new features, and requires a lot of work to be tested. >> 2 weeks ago, I did the same for a bunch of small improvements (and I >> have many many more pending). Once again, no feedback, except for one >> very easy-to-test (new images) : signed-off by Nicole & pushed by chris >> in less than 24H! >> Those 2 minor events (with owen & nicole) made me realize that it's >> technically and >> functionnaly hard & long to test: rebase, drop database, install, file >> test cases, check the new features,... At KohaCon, liz tested some of >> those features and said "wow, great, I want this feature for my library >> !" (I don't remember what it was exactly). The problem is that liz is >> not a techie woman, and can't test patches by her own. For our images, >> it was easy for Nicole to test, no need to updatedatabase or anything >> complex, just reach the itemtypes.pl page check the images are here. >> Easy for a librarian ! >> >> Other point: dependancies between new features. Let me take an example: >> Templates on those devs relies on html::template. Chris is working on >> moving everything to Template::Toolkit. >> Once he consider it's ready, he should submit for QA, as for every new >> features. >> Suppose no-one sign-off. >> And suppose someone sign-off, there are 2 options: >> * move master to T::T when it's signed-off. What happends with other >> branches >> not merged ? they can't be merged anymore, they have to be rewritten. >> wow, I can't imagine that something we've submitted for QA 3 months ago >> has to be rewritten because no-one took care of it ! >> * wait until those branches are merged. Two major problems here: the >> release date won't be respected, and we have switched again to feature >> based release. Or 3.4 will be released on time, but won't contain many >> things all those great features that are live in all our libraries since >> months. The second problem is that other devs are on the way. They still >> rely on H::T as master is based on that. Switching to T::T will cause >> problems for those branches later. >> well, I think that none of those solutions is a correct one. >> >> I can take an other example: the analytics record feature may/will >> probably overlap functionnaly with the new features we have submitted >> for cataloguing (not sure, but i think so). Suppose our cataloguing >> branch is integrated in 2 weeks. it has been submitted 3 months ago. It >> means our indian colleagues will have to rebase & face problems to get >> their analytical record branch working. If our branch had been merged >> quickly, they would have had 3 more months to deal with it. >> Our actual workflow, causes a lot of overhead ! And -worst- I don't >> think it improves the stability & security: there are merge problems >> that are difficults to detect. It means that any test done on analytical >> records would have to be done again if our cataloguing branch is merged >> : more work, more pain. And the later a branch is merged, the smaller >> the time to find a problem. >> >> My main conclusion is that we are not a large enough community to deal >> with testing/validating/merging new features in a short timeline. So I >> think we must change the way we integrate new features. The general idea >> being: remove the sign-off lock on the workflow. >> >> Here is a proposal: >> Let's go back to the timeline: we plan to release a version every 6 >> months. >> We could have a window of, say 4 months. During those 4 months a feature >> can be included if : >> 1- the submitter provides something that applies on master (ie: it's >> technically valid) >> 2- no-one object in 2 weeks (or 3, or 4, or defined by the RM when the >> branch is submitted) >> >> It put more pressure on others to test quickly, and don't put pain on >> parallels/parallelizing developments. Once a branch is merged if there >> is a problem, then everybody should see it, and it will be fixed ! >> >> Then, for 1 month, any new feature can be applied only if a newly >> submitted branch is approved/signed-off (less than 2 months to detect a >> problem in a new feature is a must-have) >> Then, feature freeze, 1 month debugging and translating. >> >> I know it is a big change in the workflow, but the actual one is not >> working well, so, we have to find another one. >> I humbly request to have this question being put on the next irc agenda >> (which does not mean you should not also start a thread here, of course) >> >> PS: pls don't say i'm wrong and the workflow works well. Having branches >> submitted 3 months ago, getting no feedback, and planning to have a release >> in less than 3 months, can't be considered as something working well. >> >> Friendly. >> >> -- >> Paul POULAIN >> http://www.biblibre.com >> Expert en Logiciels Libres pour l'info-doc >> Tel : (33) 4 91 81 35 08 >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal > > _______________________________________________ > 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 Jan 27 18:19:34 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 27 Jan 2011 18:19:34 +0100 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> Message-ID: <4D41A926.80101@biblibre.com> Le 27/01/2011 17:49, Ian Walls a ?crit : > I hear you. There are lots of really great features that are in > limbo, waiting to be tested. The unfortunate situation of life is > that we're all incredibly busy, and it's hard to find time to test > things. This is compounded when testing certain features requires > coding or systems experience, since that limits the pool of potential > testers. As a result, lots of good stuff sits, waits, and diverges. i'm very happy to read that we agree on the problem (congrats you've summarized in 3 lines what I needed 50+ to express ;-) ) > So what can be done? I don't think that changing the signoff > procedure will have the desired effect. That'll just let more > unreviewed code slip in, potentially introducing bugs we won't find > for weeks/months/years. That's where we disagree, but if we agree on the problem, if we all put our hands in it, we will find a solution that appears to all to be the good one ! > I think a better solution is make it easier to test and signoff on > work. There are several components to this: > > * Testing plans for larger developments/bugfixes > * A robust testing data set made readily available > * Teaching people how to test and signoff on code > > By including testing plans with developments or complex bugfixes, the > developer is communicating to everyone how they can prove their code > works. It lays out the intention of the development (it should do x, > y and z), and a series of tests to show how to get x, y and z without > losing a, b and c. > > Combine this testing plan (written in language librarians can > understand, not coder jargon) with the necessary data set to do the > testing (an SQL dump you just load into a DB), and you've lowered the > barrier for testing so that anyone who can afford a little time to run > through a series of listed procedures can answer the question "does > this work?". well, in my opinion, the one that does this testing plan must not be the one who wrote the feature. Because, of course, the feature has been tested, and the one who tested will have missed a use-case, or forgotten something,... ("given enough eyes, all bugs will be found"). So we're back to the question: who can dedicate time? Maybe we're back to the question of someone being (collectively) paid just for this role? As of today, I see that no-one find time to do it ! > The third step to this is to lay out the procedure for running through > the test plan in a clear, simple manner, and distribute that > information far and wide. Make it something that librarians can do by > following a list of steps. Lowering the threshold of experience > required to test things will allow us to harness the Long Tail. > > To this end, I'm throwing my hat in the ring for Quality Assurance > Manager for Koha 3.6. My proposal can be found on the wiki > (http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and > much of it is explained above. In addition to this, I would also > serve as a coordinator for testing work submitted, and provide regular > reports to the community on the status of these developments. > Branches that are not receiving active testing feedback would receive > attention towards creating a simpler, easier to follow testing plan. Do you really think? I don't think so: If that were the case, then someone should/would have said "well seems interesting, but I need more information/help/..." We had setup sandbox for all our branches, organized a meeting where I were alone (only kf jumped-in to say "sorry, I can't be here"). I was so disappointed that ... I forgot I had planned a 2nd meeting, a few days later, was not here as expected, and no-one complained, so I concluded no-one has been attending as well. I ask and will continue to ask on #irc when someone passes around, but I feel like someone crying in the desert (frenchism suspected here) So, I fully agree that the workflow is theorically a good one. But we lack the ressource to make it happen. I'm very scared about that, but i'd like to see things going on anyway. > I would very much like to discuss this at the next IRC meeting. It'll > be pretty early for me (5am, I believe), but I'll caffeinate heavily > beforehand :) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From oleonard at myacpl.org Thu Jan 27 18:29:59 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 27 Jan 2011 12:29:59 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: <4D41A926.80101@biblibre.com> References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: On Thu, Jan 27, 2011 at 12:19 PM, Paul Poulain wrote: > Le 27/01/2011 17:49, Ian Walls a ?crit : >> Branches that are not receiving active testing feedback would receive >> attention towards creating a simpler, easier to follow testing plan. > > Do you really think? I don't think so: If that were the case, then > someone should/would have said "well seems interesting, but I need more > information/help/..." This is problematic for the same reason it's problematic to organize a QA session on IRC: It's hard to find the right people at the right time. It's daunting to approach a QA branch which has an unknown scope, and hard to ask questions if you don't know what you're looking for. If there is a branch to test, I want to know as much as possible about what is to be tested We have the right infrastructure with the workflow we have if these conditions are met: 1. The branch covers one feature/fix. 2. The feature/fix is described in a bug report. If these things are true I've got everything I need in order to test. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chris at bigballofwax.co.nz Thu Jan 27 18:37:41 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 28 Jan 2011 06:37:41 +1300 Subject: [Koha-devel] Development workflow In-Reply-To: <4D41A926.80101@biblibre.com> References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: On 28 January 2011 06:19, Paul Poulain wrote: > Le 27/01/2011 17:49, Ian Walls a ?crit : >> I hear you. ?There are lots of really great features that are in >> limbo, waiting to be tested. ?The unfortunate situation of life is >> that we're all incredibly busy, and it's hard to find time to test >> things. ?This is compounded when testing certain features requires >> coding or systems experience, since that limits the pool of potential >> testers. ?As a result, lots of good stuff sits, waits, and diverges. > i'm very happy to read that we agree on the problem (congrats you've > summarized in 3 lines what I needed 50+ to express ;-) ) >> So what can be done? ?I don't think that changing the signoff >> procedure will have the desired effect. ?That'll just let more >> unreviewed code slip in, potentially introducing bugs we won't find >> for weeks/months/years. > That's where we disagree, but if we agree on the problem, if we all put > our hands in it, we will find a solution that appears to all to be the > good one ! >> I think a better solution is make it easier to test and signoff on >> work. ?There are several components to this: >> >> ? ? * Testing plans for larger developments/bugfixes >> ? ? * A robust testing data set made readily available >> ? ? * Teaching people how to test and signoff on code >> >> By including testing plans with developments or complex bugfixes, the >> developer is communicating to everyone how they can prove their code >> works. ?It lays out the intention of the development (it should do x, >> y and z), and a series of tests to show how to get x, y and z without >> losing a, b and c. >> >> Combine this testing plan (written in language librarians can >> understand, not coder jargon) with the necessary data set to do the >> testing (an SQL dump you just load into a DB), and you've lowered the >> barrier for testing so that anyone who can afford a little time to run >> through a series of listed procedures can answer the question "does >> this work?". > well, in my opinion, the one that does this testing plan must not be the > one who wrote the feature. Because, of course, the feature has been > tested, and the one who tested will have missed a use-case, or forgotten > something,... ("given enough eyes, all bugs will be found"). > So we're back to the question: who can dedicate time? > Maybe we're back to the question of someone being (collectively) paid > just for this role? As of today, I see that no-one find time to do it ! >> The third step to this is to lay out the procedure for running through >> the test plan in a clear, simple manner, and distribute that >> information far and wide. ?Make it something that librarians can do by >> following a list of steps. ?Lowering the threshold of experience >> required to test things will allow us to harness the Long Tail. >> >> To this end, I'm throwing my hat in the ring for Quality Assurance >> Manager for Koha 3.6. ?My proposal can be found on the wiki >> (http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and >> much of it is explained above. ?In addition to this, I would also >> serve as a coordinator for testing work submitted, and provide regular >> reports to the community on the status of these developments. >> Branches that are not receiving active testing feedback would receive >> attention towards creating a simpler, easier to follow testing plan. > Do you really think? I don't think so: If that were the case, then > someone should/would have said "well seems interesting, but I need more > information/help/..." > We had setup sandbox for all our branches, organized a meeting where I > were alone (only kf jumped-in to say "sorry, I can't be here"). I was so > disappointed that ... I forgot I had planned a 2nd meeting, a few days > later, was not here as expected, and no-one complained, so I concluded > no-one has been attending as well. I ask and will continue to ask on > #irc when someone passes around, but I feel like someone crying in the > desert (frenchism suspected here) > > So, I fully agree that the workflow is theorically a good one. But we > lack the ressource to make it happen. I'm very scared about that, but > i'd like to see things going on anyway. I think the workflow is good in practice too. For nearly every change the workflow is * create a branch per feature * file a bug for it * submit your patches to the ML * bug is marked needs signed off * someone takes the patch signs off it applies and works, and submits signed off patch * bug is marked signed off * RM applies signed off patch to a branch based on master * RM tests, if it is ok * RM Merges * bug is marked patch pushed * Feature/bug is tested and bug updated * bug is marked resolved The problem is, and I don't mean to harp on about this but it is important, is that the work that is waiting to be merged has not followed the workflow. The branches are not one per feature. This causes workflow to deal with then to become: * massive bunch of changes submitted in one branch * RM merge into qa ready branches testing they merge cleanly to master * try to find people to test a huge pile of changes * changes signed off * RM tests * Merged Now this a legacy problem, but one we need to make sure doesn't happen again, this is the only reason I keep repeating, One feature per branch. What I see is we have 2 things that need to happen, the Biblibre patches need to get tested, and in general the testing step of the workflow could be improved. I don't think either of these issues will be solved by removing the sign off step. Biblibre have acknowledged that they made a mistake in having one massive branch with all the changes on it and I congratulate them on that. To butcher an old saying 'To make a mistake is Human, to admit it in public is divine'. To their credit they have also tried to cut the work into smaller branches. But they are still big branches with more than one feature in them, and this I think is the major in fact could be the only reason they have not all been fully tested and merged yet. This is a separate problem, lets call it, how do we deal with work that has been submitted that doesn't follow the workflow, and work on a solution for that. Paul himself said that for patches that do follow the workflow (the image patch Nicole tested and signed off) the workflow works. So lets not change that, lets work out how to deal with patches that have been submitted that dont follow the workflow, ie, step 1, one branch per feature. It's not an easy problem but it is one we are all motivated to solve. No one. least of all me, wants to see anyones work go to waster. I want Biblibre's code in master before 3.4, lets try to work out how we can do it. All the while keeping vigilant and making sure all work follows the one branch per feature/bug rule for the future. Combine that with a better way of testing, and someone championing that, I think we are looking good for the future. Chris PS please forgive typos, I was woken at 5am by my son, and haven't had enough caffeine yet. From nengard at gmail.com Thu Jan 27 18:43:08 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 27 Jan 2011 12:43:08 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: Nicole would like to chip in here on lots of points. Paul brings me up as an example of someone who signs off on the easy to test features and Ian brings up training/teaching people how to test/sign off. I think these two things are very important to note. I would sign off on more complex patches if I wasn't terrified of screwing up my one and only Koha installation/database. I know I can backup and restore and all that jazz, but I've never done it and to that end it's scary. I've screwed up my git repo a few times just trying to test the 'easy' patches! :) I would love to be properly trained in doing this so I can test further. I am on the road a lot and do most of my sign offs while alone in hotel rooms - that's the perfect quiet time to test!!! So if someone wants to do a tutorial video or write up detailed instructions I could do more (and I'm sure others like me could too). Thanks Nicole From cnighswonger at foundations.edu Thu Jan 27 19:21:13 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 27 Jan 2011 13:21:13 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: On Thu, Jan 27, 2011 at 12:37 PM, Chris Cormack wrote: > This is a separate problem, lets call it, how do we deal with work > that has been submitted that doesn't follow the workflow, and work on > a solution for that. > Paul himself said that for patches that do follow the workflow (the > image patch Nicole tested and signed off) the workflow works. So lets > not change that, lets work out how to deal with patches that have been > submitted that dont follow the workflow, ie, step 1, one branch per > feature. > > It's not an easy problem but it is one we are all motivated to solve. > No one. least of all me, wants to see anyones work go to waster. I > want Biblibre's code in master before 3.4, lets try to work out how we > can do it. All the while keeping vigilant and making sure all work > follows the one branch per feature/bug rule for the future. Combine > that with a better way of testing, and someone championing that, I > think we are looking good for the future. > > This is the heart of the problem as I see it. The current workflow is fine (and could be embellished with Ian's suggestions/proposal.) The issue of the outstanding Biblibre code is a "left-over" problem which we need to setup up to, fix, and get behind us as soon as possible. Perhaps we should schedule a "Test Fest" similar to a "Hack Fest" and get a group of people together to pound on the Biblibre test servers one day? Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanbargw at gmail.com Thu Jan 27 19:26:27 2011 From: vanbargw at gmail.com (Jerry Van Baren) Date: Thu, 27 Jan 2011 13:26:27 -0500 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: <4D41B8D3.400@gmail.com> On 1/27/2011 12:43 PM, Nicole Engard wrote: > Nicole would like to chip in here on lots of points. Paul brings me > up as an example of someone who signs off on the easy to test features > and Ian brings up training/teaching people how to test/sign off. I > think these two things are very important to note. I would sign off > on more complex patches if I wasn't terrified of screwing up my one > and only Koha installation/database. I know I can backup and restore > and all that jazz, but I've never done it and to that end it's scary. > I've screwed up my git repo a few times just trying to test the 'easy' > patches! :) > > I would love to be properly trained in doing this so I can test > further. I am on the road a lot and do most of my sign offs while > alone in hotel rooms - that's the perfect quiet time to test!!! So if > someone wants to do a tutorial video or write up detailed instructions > I could do more (and I'm sure others like me could too). > > Thanks > Nicole What would be Really Useful would be a virtual machine (e.g. Amazon EC2 or VMware) with a test environment to "lower the bar" for technical skills and computer resource availability. That could enable a larger pool of people who could test branches. As others pointed out, the worst case is some legacy large patch branches... having a EC2 test instance might break the logjam on them but should not be necessary for smaller patches. Amazon has very good starter terms: --------------------------------------------------------------------- Free Tier* As part of AWS?s Free Usage Tier, new AWS customers can get started with Amazon EC2 for free. Upon sign-up, new AWS customers receive the following EC2 services each month for one year: * 750 hours of EC2 running Linux/Unix Micro instance usage * 750 hours of Elastic Load Balancing plus 15 GB data processing * 10 GB of Amazon Elastic Block Storage (EBS) plus 1 million IOs, 1 GB snapshot storage, 10,000 snapshot Get Requests and 1,000 snapshot Put Requests * 15 GB of bandwidth in and 15 GB of bandwidth out aggregated across all AWS services --------------------------------------------------------------------- Best regards, gvb From nengard at gmail.com Thu Jan 27 19:40:09 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 27 Jan 2011 13:40:09 -0500 Subject: [Koha-devel] Official Koha Newsletter: Volume 2, Issue 1: January 2011 Message-ID: Please read the newsletter online for live links: http://koha-community.org/koha-newsletter-volume-2issue-1-january-2011/ Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 1: January 2011 Table of Contents * Koha Developments o RFC Roundup: Members/Patrons o Koha 3.2.3 is now available * Koha Libraries o 7 Public Libraries in Pampanga Receive Koha Computers o National Folk Archive in the UK Launches Online Catalog * Koha Events o OS Academy a big success for Koha o KUDOS Conference in May Koha Developments RFC Roundup: Members/Patrons by MJ Ray The following Patrons management improvement ideas have Requests For Comments listed on the Koha Community Wiki. If you have suggestions you could make about these topics, please add comments to the relevant page by logging in and clicking the ?Edit? tab at the top of the page. Alternatively, you could start a discussion on the email list or web forum. * Calculate fines in days debarred RFC o Koha 3.0 lets the library define fines in money only. Some libraries needs to be able to set ?debarred? fines. When a patron returns books lately, he is debarred for some days. * Enhancements to debarred patron o Gonenoaddress, lost or debarred are currently just toggle choices. Enhancements proposed include adding a comment field to each choice and adding an expiry date for debarring. * Duplicate card button o This feature would add a new button to duplicate a patron card. A new form with the duplicated values will open up and when the librarian puts the cursor on a field, the value will be erased ready to write the new value. Then the librarian can save the new card. * Enhancements to the display of extended patron attributes in circ o This RFC proposes having some extended attributes display in circ/circulation.pl and jumping straight to the patron details page if there is only one match for a patron search. * Fines Tab o Redesign the fines tab to allow partial payment and record/show more information about fines, such as the librarian taking the fine, the transaction time and payment method. * Patron Reading record management RFC and Patron self-managing privacy RFC o The laws in some countries requires that the library cleans the reading record after some time. These new features would let the user himself decide what to do with the reading record. The current behaviour will be the initial default and changed through a system preference. ** Please Contribute! ** Please, if you have any feedback or encouragement for any of the above, follow the link and add comments, or start a discussion. Koha 3.2.3 is now available by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.2.3. The package can be retrieved from: http://download.koha-community.org/koha-3.02.03.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.03.tar.gz.MD5 http://download.koha-community.org/koha-3.02.03.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.03.tar.gz.sig Release notes for 3.2.3 are below the fold. Come and get it! Read more. Koha Libraries 7 Public Libraries in Pampanga Receive Koha Computers by Pampanga PIO City of San Fernando ? The National Library of the Philippines (NLP) turned over seven Koha computer units to seven public libraries in the province in ceremonies held recently at the Pampanga Provincial Library. Read More. National Folk Archive in the UK Launches Online Catalog by Elaine Bradtke The first collection of the Vaughan Williams Memorial Library catalogue has been launched into cyberspace: http://catalogue.efdss.org. More on this story can be found on WorldCentralMusic.org. Koha Events OS Academy a big success for Koha by Chris Cormack Over the last 2 weeks Catalyst has been running a pilot of an ?Academy? for high school age students. I was very happy to be a part of what, in my opinion, turned out to be a very well run and most worthwhile exercise. During the first week the students were treated to tutorial sessions, including installing ubuntu on their laptops, using git, perl, php, postgresql, configuring a server, copyright, licenses, freedom, community, graphics (inkscape & the gimp), html css and javascript. Quite a list now I see it all written down. Read More. KUDOS Conference in May by David Schuster Put May 2 and 3, 2011 on your calendars for the KUDOS conference to be held in Madison, Wisconsin we are finalizing the venue. More information on transportation and housing to come. This will be a conference for and by users of Koha in collaboration with vendors that support or interact with Koha. We are hopeful that this conference will be a low cost/no cost option with the help of sponsorships from vendors and libraries. We are looking for volunteers to serve on the planning and program committees. If you are interested in helping out, please let me know. We need to get to work on this right away! This is NOT going to be a KohaCon and at this time no Hackfest is being organized. Newsletter edited by Nicole C. Engard, Koha Documentation Manager. Please send future story ideas to me. From chris at bigballofwax.co.nz Thu Jan 27 19:24:56 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 28 Jan 2011 07:24:56 +1300 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: On 28 January 2011 07:21, Chris Nighswonger wrote: > On Thu, Jan 27, 2011 at 12:37 PM, Chris Cormack > wrote: > > > >> >> This is a separate problem, lets call it, how do we deal with work >> that has been submitted that doesn't follow the workflow, and work on >> a solution for that. >> Paul himself said that for patches that do follow the workflow (the >> image patch Nicole tested and signed off) the workflow works. So lets >> not change that, lets work out how to deal with patches that have been >> submitted that dont follow the workflow, ie, step 1, one branch per >> feature. >> >> It's not an easy problem but it is one we are all motivated to solve. >> No one. least of all me, wants to see anyones work go to waster. I >> want Biblibre's code in master before 3.4, lets try to work out how we >> can do it. All the while keeping vigilant and making sure all work >> follows the one branch per feature/bug rule for the future. Combine >> that with a better way of testing, and someone championing that, I >> think we are looking good for the future. >> > > This is the heart of the problem as I see it. The current workflow is fine > (and could be embellished with Ian's suggestions/proposal.) The issue of the > outstanding Biblibre code is a "left-over" problem which we need to setup up > to, fix, and get behind us as soon as possible. > > Perhaps we should schedule a "Test Fest" similar to a "Hack Fest" and get a > group of people together to pound on the Biblibre test servers one day? > I could commit to a couple of hours for that, and I think I could get a few other catalyst employees too. Chris From kmkale at anantcorp.com Fri Jan 28 10:41:42 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Fri, 28 Jan 2011 15:11:42 +0530 Subject: [Koha-devel] make test fails on BackgroundJob.t Message-ID: Hi All, I am doing a dev install with a fresh git clone on a new machine. make test fails with following.. Test Summary Report ------------------- t/BackgroundJob.t (Wstat: 65280 Tests: 1 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 8 tests but ran 1. Files=99, Tests=6821, 53 wallclock secs ( 1.57 usr 0.24 sys + 26.95 cusr 2.46 csys = 31.22 CPU) Result: FAIL Failed 1/99 test programs. 0/6821 subtests failed. make: *** [test_dynamic] Error 255 Looking back on the make test output I see t/BackgroundJob.t ................... DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. t/BackgroundJob.t ................... 1/8 DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. Use of uninitialized value $timeout in pattern match (m//) at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Auth.pm line 606. DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. OPAC Install required, redirecting to maintenance at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Auth.pm line 560. # Looks like you planned 8 tests but ran 1. t/BackgroundJob.t ................... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 7/8 subtests Can someone please tell me whats going on here? PS : And I also see a bunch of " DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480." lines in the make test output. I can login to the kohadev database with the credentials I am supplying perl Makefile.PL Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From cnighswonger at foundations.edu Fri Jan 28 14:20:36 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 28 Jan 2011 08:20:36 -0500 Subject: [Koha-devel] make test fails on BackgroundJob.t In-Reply-To: References: Message-ID: Hi Koustubha, On Fri, Jan 28, 2011 at 4:41 AM, Koustubha Kale wrote: > Hi All, > I am doing a dev install with a fresh git clone on a new machine. > make test fails with following.. > > > Looking back on the make test output I see > > t/BackgroundJob.t ................... DBD::mysql::db selectrow_array > failed: Table 'kohadev.systempreferences' doesn't exist at > /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. > This is because the db is not yet populated and so does not have a systempreferences table. This test should be moved to the db_dependent subdir so that it is not executed by default. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Fri Jan 28 15:01:37 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Fri, 28 Jan 2011 19:31:37 +0530 Subject: [Koha-devel] make test fails on BackgroundJob.t In-Reply-To: References: Message-ID: On Fri, Jan 28, 2011 at 6:50 PM, Chris Nighswonger wrote: > Hi Koustubha, > > On Fri, Jan 28, 2011 at 4:41 AM, Koustubha Kale > wrote: >> >> Hi All, >> I am doing a dev install with a fresh git clone on a new machine. >> make test fails with following.. >> > > > >> >> Looking back on the make test output I see >> >> t/BackgroundJob.t ................... DBD::mysql::db selectrow_array >> failed: Table 'kohadev.systempreferences' doesn't exist at >> /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. > > This is because the db is not yet populated and so does not have a > systempreferences table. > > This test should be moved to the db_dependent subdir so that it is not > executed by default. > > Kind Regards, > Chris > I get a bunch of these. But make test fails only on t/BackgroundJob.t Please see a paste at http://paste.koha-community.org/129 Also I get a bunch of "Use of uninitialized value..." & "Illegal date specified..." too Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From paul.poulain at biblibre.com Fri Jan 28 18:30:32 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 28 Jan 2011 18:30:32 +0100 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <4D41A926.80101@biblibre.com> Message-ID: <4D42FD38.5030101@biblibre.com> Le 27/01/2011 19:21, Chris Nighswonger a ?crit : > This is the heart of the problem as I see it. The current workflow is > fine (and could be embellished with Ian's suggestions/proposal.) The > issue of the outstanding Biblibre code is a "left-over" problem which > we need to setup up to, fix, and get behind us as soon as possible. ++ > Perhaps we should schedule a "Test Fest" similar to a "Hack Fest" and > get a group of people together to pound on the Biblibre test servers > one day? ++ How should we organise this test fest ? Should I start a doodle to get a time ? Or say "it open dayX and dayY, i'll be on the channel" ? i'm listening to your suggestions ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From reedwade at gmail.com Sat Jan 29 11:40:28 2011 From: reedwade at gmail.com (Reed Wade) Date: Sat, 29 Jan 2011 23:40:28 +1300 Subject: [Koha-devel] utf8 in labels pdf -- kernel of a solution Message-ID: I was poking around at bug 2246 for some reason and thought it might be more fun to step back a bit. The result is a perl fragment that does the basic work of creating a pdf which has a barcode and text in Greek, Cyrillic, all the latins, Japanese, Thai, Hindi and Gujarati (I'm not conversant in most of those languages so I might have some silly mistakes there) all on one page. It uses PDF::API2 instead of PDF::Reuse. If you're curious, have a look at http://reedwade.net/koha/labels/ for the perl script and the pdf output. The enabling feature of interest is the ability in PDF::API2 to build a font from a set of ttf fonts and assigning different unicode code pages (or ranges) for each. It might be possible to rejigger C4/Creators/PDF.pm to use PDF::API2 instead of PDF::Reuse. This is something I predict I will not have time to pursue further anytime soon -- I'm hoping someone else might enjoy that? -reed From prawesh.shrestha at yipl.com.np Thu Jan 20 06:36:36 2011 From: prawesh.shrestha at yipl.com.np (Prawesh Shrestha) Date: Thu, 20 Jan 2011 11:21:36 +0545 Subject: [Koha-devel] Using Unicode in Koha Message-ID: Hi, I am from Nepal and using Koha Library Management System and very new to it. I want to use Nepali unicode to enter records in the system. Till now I know that its possible while researching on the net. However, eluded with details to make it work. How can I get the details to make it happen? With Regards, -- Prawesh Shrestha Project Engineer --------------------------------------------- Young Innovations Pvt. Ltd. GPO 8976 EPC 241 Pulchowk, Lalitpur, Nepal Tel: +977-01 2291892 http://yipl.com.np info[at]yipl[dot]com[dot]np ---------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From semarie-koha at latrappe.fr Sat Jan 29 12:13:28 2011 From: semarie-koha at latrappe.fr (=?ISO-8859-15?Q?Fr=E8re_S=E9bastien_Marie?=) Date: Sat, 29 Jan 2011 12:13:28 +0100 (CET) Subject: [Koha-devel] Imported MARC notice and Authorities: : inconsistent database Message-ID: Hello, Recently, we have imported a set of notices, from another abbey, in the reservoir. When we create a new examplar using the previous imported notices, the field 700.9 (authority - internal koha number) refering the auth_id isn't updated or removed (still reference the old authority number, in the other catalog). As result, we have an examplar with 700.a (authority name) correct, but with an internal reference wrong (not valid in us catalog). If we search all notices linked with an authority, there is wrong attribution. Next an example. Starting with: - Notices in reservoir: - Title_A / Author_A (auth_id = 1) [from import] - Authority in catalog: - Author_B (auth_id = 1) [created locally] - Notice in catalog: - Title_B / Author_B (auth_id = 1) Next, we create a new examplar based on notice in reservoir, result: - Authority in catalog: - Author_B (auth_id = 1) [created locally] - Notice in catalog: - Title_A / Author_A (auth_id = 1) - Title_B / Author_B (auth_id = 1) (doubt if Author_A added in authorities or not) Now, if search notice attached with Author_B (auth_id = 1): results: - Title_A / Author_A (auth_id = 1) - Title_B / Author_B (auth_id = 1) The database is inconsistent. Where is the problem: - a misused of imported MARC: an option somewhere should be set... - a bug in importing MARC: 700.9 should be cleaned before import... - another possibility ? Currently, no bug report filled, as I don't no if it is a misusing or a bug. Thanks. -- Fr?re S?bastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe T?l: 02.33.84.17.00 Fax: 02.33.34.98.57 Web: http://www.latrappe.fr/ From mjr at phonecoop.coop Sun Jan 30 02:47:09 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Sun, 30 Jan 2011 01:47:09 +0000 (GMT) Subject: [Koha-devel] Using Unicode in Koha In-Reply-To: Message-ID: <20110130014709.7AF725028C@nail.towers.org.uk> Prawesh Shrestha wrote: > Hi, I am from Nepal and using Koha Library Management System and very new to > it. I want to use Nepali unicode to enter records in the system. Till now I > know that its possible while researching on the net. However, eluded with > details to make it work. How can I get the details to make it happen? Hi. Thanks for the question, but to help with that, I think people will need a bit more information. You probably need to tell us:- * A precise problem description, including the name of the program being used (such as the name of the web browser) and what symptoms you're seeing instead of seeing the characters appear. * How to obtain the error, step-by-step if possible. * If that process has worked for you before, the date when it worked. (This is copy-pasta which you could avoid by reading the list archives before posting. I see many bug reports that are missing vital info like the above and this seems better than you getting no reply.) Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From kmkale at anantcorp.com Sun Jan 30 09:09:14 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sun, 30 Jan 2011 13:39:14 +0530 Subject: [Koha-devel] utf8 in labels pdf -- kernel of a solution In-Reply-To: References: Message-ID: On Sat, Jan 29, 2011 at 4:10 PM, Reed Wade wrote: > I was poking around at bug 2246 for some reason and thought it might > be more fun to step back a bit. > > The result is a perl fragment that does the basic work of creating a > pdf which has a barcode and text in Greek, Cyrillic, all the latins, > Japanese, Thai, Hindi and Gujarati (I'm not conversant in most of > those languages so I might have some silly mistakes there) all on one > page. > > It uses PDF::API2 instead of PDF::Reuse. > > If you're curious, have a look at http://reedwade.net/koha/labels/ > for the perl script and the pdf output. > > The enabling feature of interest is the ability in PDF::API2 to build > a font from a set of ttf fonts and assigning different unicode code > pages (or ranges) for each. > > It might be possible to rejigger C4/Creators/PDF.pm to use PDF::API2 > instead of PDF::Reuse. > > This is something I predict I will not have time to pursue further > anytime soon -- I'm hoping someone else might enjoy that? > > -reed > > Hi Reed, This is very interesting. Been a problem for long for Indic barcodes. I would love to dabble in this. Thanks. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trmurakami at gmail.com Sun Jan 30 19:11:55 2011 From: trmurakami at gmail.com (Tiago Murakami) Date: Sun, 30 Jan 2011 16:11:55 -0200 Subject: [Koha-devel] Zebra issues Message-ID: Hi, I Installed Koha 3.2.2 by koha-common debian package and it works very well. But, when I restart the server, the zebra stop works. I try koha-start-zebra (instance) but don?t work Anybody can help me? -- Tiago Murakami Librarian Brazil From chris at bigballofwax.co.nz Sun Jan 30 19:24:31 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 31 Jan 2011 07:24:31 +1300 Subject: [Koha-devel] Zebra issues In-Reply-To: References: Message-ID: On 31 January 2011 07:11, Tiago Murakami wrote: > Hi, > > I Installed Koha 3.2.2 by koha-common debian package and it works very > well. But, when I restart the server, the zebra stop works. > > I try koha-start-zebra (instance) but don?t work > > Anybody can help me? Ol? Tiago First I'm glad you are finding the packages useful. Secondly, you will want to have a look in /var/log/koha/instancename/ There should be some logs in there to do with zebra, that might shed some light on why it's not starting. We use packages for all our clients, and I haven't run into the not starting one, my first guess is permissions (that's my first guess for everything) You are running the command with sudo eh? Anyway I hope the logs show something useful. Chris From trmurakami at gmail.com Sun Jan 30 22:54:46 2011 From: trmurakami at gmail.com (Tiago Murakami) Date: Sun, 30 Jan 2011 19:54:46 -0200 Subject: [Koha-devel] Zebra issues In-Reply-To: References: Message-ID: Hi Chris, Thanks a lot!!! I installed koha-common as a root and its cause a deleting of /var/lock and /var/run directory when i reboot a system. I put on koha-common mkdir and chwon commands to recriate this directorys and its works. cheers Tiago Murakami http://minhabiblioteca.com On Sun, Jan 30, 2011 at 4:24 PM, Chris Cormack wrote: > On 31 January 2011 07:11, Tiago Murakami wrote: >> Hi, >> >> I Installed Koha 3.2.2 by koha-common debian package and it works very >> well. But, when I restart the server, the zebra stop works. >> >> I try koha-start-zebra (instance) but don?t work >> >> Anybody can help me? > > Ol? Tiago > > First I'm glad you are finding the packages useful. Secondly, you will > want to have a look in /var/log/koha/instancename/ > > There should be some logs in there to do with zebra, that might shed > some light on why it's not starting. We use packages for all our > clients, and I haven't run into the not starting one, my first guess > is permissions (that's my first guess for everything) > > You are running the command with sudo eh? Anyway I hope the logs show > something useful. > > Chris > -- Tiago Murakami From M.de.Rooy at rijksmuseum.nl Mon Jan 31 09:11:16 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 31 Jan 2011 08:11:16 +0000 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> Just my late response on this thread: 1) If I include a test plan but should forget steps/test areas etc., and a non-developer tests the patch: aren?t we decreasing the value of signoff? In that case we could still end up with not signing patches in the long run.. Still, something is perhaps better than nothing at all. 2) A patch should not be too big. 3) Much depends on how the QA role is filled in [Ian?s plans sounds good]. If the QA could give more guidance on which patches should be tested next, testers are not just cherry picking patches.. Why should QA not mail once a week or so the first 10 or 20 patches that he wants to be signed? Could prevent older/larger/less interesting sounding patches waiting and newer (smaller/..) patches getting signed and pushed. Would make the process even more ?fair? to everyone. Marcel Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Ian Walls Verzonden: donderdag 27 januari 2011 17:50 Aan: Paul Poulain CC: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Development workflow Paul, I hear you. There are lots of really great features that are in limbo, waiting to be tested. The unfortunate situation of life is that we're all incredibly busy, and it's hard to find time to test things. This is compounded when testing certain features requires coding or systems experience, since that limits the pool of potential testers. As a result, lots of good stuff sits, waits, and diverges. So what can be done? I don't think that changing the signoff procedure will have the desired effect. That'll just let more unreviewed code slip in, potentially introducing bugs we won't find for weeks/months/years. I think a better solution is make it easier to test and signoff on work. There are several components to this: * Testing plans for larger developments/bugfixes * A robust testing data set made readily available * Teaching people how to test and signoff on code By including testing plans with developments or complex bugfixes, the developer is communicating to everyone how they can prove their code works. It lays out the intention of the development (it should do x, y and z), and a series of tests to show how to get x, y and z without losing a, b and c. Combine this testing plan (written in language librarians can understand, not coder jargon) with the necessary data set to do the testing (an SQL dump you just load into a DB), and you've lowered the barrier for testing so that anyone who can afford a little time to run through a series of listed procedures can answer the question "does this work?". The third step to this is to lay out the procedure for running through the test plan in a clear, simple manner, and distribute that information far and wide. Make it something that librarians can do by following a list of steps. Lowering the threshold of experience required to test things will allow us to harness the Long Tail. To this end, I'm throwing my hat in the ring for Quality Assurance Manager for Koha 3.6. My proposal can be found on the wiki (http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and much of it is explained above. In addition to this, I would also serve as a coordinator for testing work submitted, and provide regular reports to the community on the status of these developments. Branches that are not receiving active testing feedback would receive attention towards creating a simpler, easier to follow testing plan. I would very much like to discuss this at the next IRC meeting. It'll be pretty early for me (5am, I believe), but I'll caffeinate heavily beforehand :) Cheers, -Ian On Thu, Jan 27, 2011 at 11:03 AM, Paul Poulain > wrote: Hello koha-devel, The more time passes, the more I think we have a workflow for Koha development that does not work correctly/efficiently/fluently. The rule we have is: * create a branch for the feature * file a bug for it * submit your branch to koha-patches ML * the RM checks that everything apply smoothly on master & ask for QA * someone signs-off the branch/patch * the RM merge the branch. For the maintenance branch, this workflow is perfect and must be secured more and more to avoid any regression. As I see it, there is always someone that can find time to sign-off a patch or 2. As ppl have system live with it i'm sure it's cricital for many ppl to check & double check ! But for the next release/unstable branch this workflow does not work well. Here is a single line of something owen said on the chat today: paul_p: I would much prefer to be testing your stuff today, but other stuff is taking precedence. God knows i'll be forever thankfull to owen for the work he does. But this sentence reveals something: for most of us, there is always "other stuff taking precedence" :\ BibLibre has submitted many new features 3 months ago. I tried to motivate ppl to get feedback & sign-off. I even have organised an IRC meeting ... where no one came. Those patches includes new features, and requires a lot of work to be tested. 2 weeks ago, I did the same for a bunch of small improvements (and I have many many more pending). Once again, no feedback, except for one very easy-to-test (new images) : signed-off by Nicole & pushed by chris in less than 24H! Those 2 minor events (with owen & nicole) made me realize that it's technically and functionnaly hard & long to test: rebase, drop database, install, file test cases, check the new features,... At KohaCon, liz tested some of those features and said "wow, great, I want this feature for my library !" (I don't remember what it was exactly). The problem is that liz is not a techie woman, and can't test patches by her own. For our images, it was easy for Nicole to test, no need to updatedatabase or anything complex, just reach the itemtypes.pl page check the images are here. Easy for a librarian ! Other point: dependancies between new features. Let me take an example: Templates on those devs relies on html::template. Chris is working on moving everything to Template::Toolkit. Once he consider it's ready, he should submit for QA, as for every new features. Suppose no-one sign-off. And suppose someone sign-off, there are 2 options: * move master to T::T when it's signed-off. What happends with other branches not merged ? they can't be merged anymore, they have to be rewritten. wow, I can't imagine that something we've submitted for QA 3 months ago has to be rewritten because no-one took care of it ! * wait until those branches are merged. Two major problems here: the release date won't be respected, and we have switched again to feature based release. Or 3.4 will be released on time, but won't contain many things all those great features that are live in all our libraries since months. The second problem is that other devs are on the way. They still rely on H::T as master is based on that. Switching to T::T will cause problems for those branches later. well, I think that none of those solutions is a correct one. I can take an other example: the analytics record feature may/will probably overlap functionnaly with the new features we have submitted for cataloguing (not sure, but i think so). Suppose our cataloguing branch is integrated in 2 weeks. it has been submitted 3 months ago. It means our indian colleagues will have to rebase & face problems to get their analytical record branch working. If our branch had been merged quickly, they would have had 3 more months to deal with it. Our actual workflow, causes a lot of overhead ! And -worst- I don't think it improves the stability & security: there are merge problems that are difficults to detect. It means that any test done on analytical records would have to be done again if our cataloguing branch is merged : more work, more pain. And the later a branch is merged, the smaller the time to find a problem. My main conclusion is that we are not a large enough community to deal with testing/validating/merging new features in a short timeline. So I think we must change the way we integrate new features. The general idea being: remove the sign-off lock on the workflow. Here is a proposal: Let's go back to the timeline: we plan to release a version every 6 months. We could have a window of, say 4 months. During those 4 months a feature can be included if : 1- the submitter provides something that applies on master (ie: it's technically valid) 2- no-one object in 2 weeks (or 3, or 4, or defined by the RM when the branch is submitted) It put more pressure on others to test quickly, and don't put pain on parallels/parallelizing developments. Once a branch is merged if there is a problem, then everybody should see it, and it will be fixed ! Then, for 1 month, any new feature can be applied only if a newly submitted branch is approved/signed-off (less than 2 months to detect a problem in a new feature is a must-have) Then, feature freeze, 1 month debugging and translating. I know it is a big change in the workflow, but the actual one is not working well, so, we have to find another one. I humbly request to have this question being put on the next irc agenda (which does not mean you should not also start a thread here, of course) PS: pls don't say i'm wrong and the workflow works well. Having branches submitted 3 months ago, getting no feedback, and planning to have a release in less than 3 months, can't be considered as something working well. Friendly. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon Jan 31 09:43:56 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 31 Jan 2011 09:43:56 +0100 Subject: [Koha-devel] Development workflow In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> References: <4D41976A.1090109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D46764C.3080407@biblibre.com> Le 31/01/2011 09:11, Marcel de Rooy a ?crit : > > Just my late response on this thread: > > 3) Much depends on how the QA role is filled in [Ian?s plans sounds > good]. If the QA could give more guidance on which patches should be > tested next, testers are not just cherry picking patches.. Why should > QA not mail once a week or so the first 10 or 20 patches that he wants > to be signed? Could prevent older/larger/less interesting sounding > patches waiting and newer (smaller/..) patches getting signed and > pushed. Would make the process even more ?fair? to everyone. > Sounds like a very good idea. I've investigated a little big bugzilla to see if we could have a query showing what is to sign-off. It seems that we have ... 164 bugs waiting for sign-off : http://bugs.koha-community.org/bugzilla3/buglist.cgi?field0-0-0=cf_patch_status&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=equals&value0-0-0=Needs%20Signoff I'm highly surprised by this number. Did I make a wrong query ? Is bugzilla uptodate ? I can't imagine there are so many patches awaiting QA, but maybe i'm wrong ;\ -- 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 Jan 31 09:50:43 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 31 Jan 2011 21:50:43 +1300 Subject: [Koha-devel] Development workflow In-Reply-To: <4D46764C.3080407@biblibre.com> References: <4D41976A.1090109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> <4D46764C.3080407@biblibre.com> Message-ID: On 31 January 2011 21:43, Paul Poulain wrote: > Le 31/01/2011 09:11, Marcel de Rooy a ?crit : >> >> Just my late response on this thread: >> >> 3) ? ?Much depends on how the QA role is filled in [Ian?s plans sounds >> good]. If the QA could give more guidance on which patches should be >> tested next, testers are not just cherry picking patches.. Why should >> QA not mail once a week or so the first 10 or 20 patches that he wants >> to be signed? Could prevent older/larger/less interesting sounding >> patches waiting and newer (smaller/..) patches getting signed and >> pushed. Would make the process even more ?fair? to everyone. >> > Sounds like a very good idea. > I've investigated a little big bugzilla to see if we could have a query > showing what is to sign-off. > > It seems that we have ... 164 bugs waiting for sign-off : > http://bugs.koha-community.org/bugzilla3/buglist.cgi?field0-0-0=cf_patch_status&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=equals&value0-0-0=Needs%20Signoff > > I'm highly surprised by this number. Did I make a wrong query ? Is > bugzilla uptodate ? I can't imagine there are so many patches awaiting > QA, but maybe i'm wrong ;\ > > No that's right, I think I've pointed this out before, but I have links to the searches on my release wiki http://koha-releasemanagement.branchable.com/ (links up the top) Of course anyone can sign off on these, if we look at the statistics for the 3.2.3 release http://blog.bigballofwax.co.nz/2011/01/23/koha-3-2-3-statistics/ We can see who did signoffs for that release, http://blog.bigballofwax.co.nz/2010/12/22/koha-3-2-2-statistics/ for 3.2.2. Id love to see more names in there, Ive managed to get my list of patches awaiting testing from me down to 2, so time to start filling that list back up again. Get signing off people :) Chris From M.de.Rooy at rijksmuseum.nl Mon Jan 31 10:01:28 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 31 Jan 2011 09:01:28 +0000 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> <4D46764C.3080407@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311DB3E2@S-MAIL-1B.rijksmuseum.intra> Already for some weeks this number is around 160. They include bug reports pertaining to specific rel 3.0. If the patch no longer applies and assuming that nothing happens any more in 3.0, I would set these reports to Not apply. Or even close them? Note that I closed a 3.0 bug in the past, but got negative response on doing so.. Just a tip: Save your query in Bugzilla for reports to be signed. -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Chris Cormack Verzonden: maandag 31 januari 2011 09:51 Aan: Paul Poulain CC: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Development workflow On 31 January 2011 21:43, Paul Poulain wrote: > Le 31/01/2011 09:11, Marcel de Rooy a ?crit : >> >> Just my late response on this thread: >> >> 3) ? ?Much depends on how the QA role is filled in [Ian?s plans sounds >> good]. If the QA could give more guidance on which patches should be >> tested next, testers are not just cherry picking patches.. Why should >> QA not mail once a week or so the first 10 or 20 patches that he wants >> to be signed? Could prevent older/larger/less interesting sounding >> patches waiting and newer (smaller/..) patches getting signed and >> pushed. Would make the process even more ?fair? to everyone. >> > Sounds like a very good idea. > I've investigated a little big bugzilla to see if we could have a query > showing what is to sign-off. > > It seems that we have ... 164 bugs waiting for sign-off : > http://bugs.koha-community.org/bugzilla3/buglist.cgi?field0-0-0=cf_patch_status&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=equals&value0-0-0=Needs%20Signoff > > I'm highly surprised by this number. Did I make a wrong query ? Is > bugzilla uptodate ? I can't imagine there are so many patches awaiting > QA, but maybe i'm wrong ;\ > > No that's right, I think I've pointed this out before, but I have links to the searches on my release wiki http://koha-releasemanagement.branchable.com/ (links up the top) Of course anyone can sign off on these, if we look at the statistics for the 3.2.3 release http://blog.bigballofwax.co.nz/2011/01/23/koha-3-2-3-statistics/ We can see who did signoffs for that release, http://blog.bigballofwax.co.nz/2010/12/22/koha-3-2-2-statistics/ for 3.2.2. Id love to see more names in there, Ive managed to get my list of patches awaiting testing from me down to 2, so time to start filling that list back up again. Get signing off people :) 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 chris at bigballofwax.co.nz Mon Jan 31 10:07:25 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 31 Jan 2011 22:07:25 +1300 Subject: [Koha-devel] Development workflow In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311DB3E2@S-MAIL-1B.rijksmuseum.intra> References: <4D41976A.1090109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> <4D46764C.3080407@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB3E2@S-MAIL-1B.rijksmuseum.intra> Message-ID: On 31 January 2011 22:01, Marcel de Rooy wrote: > Already for some weeks this number is around 160. > They include bug reports pertaining to specific rel 3.0. If the patch no longer applies and assuming that nothing happens any more in 3.0, I would set these reports to Not apply. Or even close them? Note that I closed a 3.0 bug in the past, but got negative response on doing so.. > The thing to do, is test if the bug still exists in master/3.2.x, if it does update the bug accordingly (change the version). If the patch doesn't apply you can change it from needs signoff to 'Does not apply'. I wouldn't close the bug unless I was sure it isn't present in either master or 3.2.x Chris From paul.poulain at biblibre.com Mon Jan 31 10:20:57 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 31 Jan 2011 10:20:57 +0100 Subject: [Koha-devel] Development workflow In-Reply-To: References: <4D41976A.1090109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> <4D46764C.3080407@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB3E2@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D467EF9.9010303@biblibre.com> Le 31/01/2011 10:07, Chris Cormack a ?crit : > The thing to do, is test if the bug still exists in master/3.2.x, if > it does update the bug accordingly (change the version). If the patch > doesn't apply you can change it from needs signoff to 'Does not > apply'. > > I wouldn't close the bug unless I was sure it isn't present in either > master or 3.2.x it isn't present in either or both master/3.2 ? -- 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 Jan 31 10:22:04 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 31 Jan 2011 10:22:04 +0100 Subject: [Koha-devel] irc down ? Message-ID: <4D467F3C.7000507@biblibre.com> Hi, It's probably already known, but IRC seems down. Side question: shouldn't we move to a wider irc server (like freenode) ? Wouldn't require katipo help to deal with problems. -- 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 Jan 31 10:40:04 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 31 Jan 2011 22:40:04 +1300 Subject: [Koha-devel] Development workflow In-Reply-To: <4D467EF9.9010303@biblibre.com> References: <4D41976A.1090109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB2EC@S-MAIL-1B.rijksmuseum.intra> <4D46764C.3080407@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA311DB3E2@S-MAIL-1B.rijksmuseum.intra> <4D467EF9.9010303@biblibre.com> Message-ID: On 31 January 2011 22:20, Paul Poulain wrote: > Le 31/01/2011 10:07, Chris Cormack a ?crit : >> The thing to do, is test if the bug still exists in master/3.2.x, if >> it does update the bug accordingly (change the version). If the patch >> doesn't apply you can change it from needs signoff to 'Does not >> apply'. >> >> I wouldn't close the bug unless I was sure it isn't present in either >> master or 3.2.x > it isn't present in either or both master/3.2 ? > One of the foibles of English, is that they both mean the same thing. To be more clear, make sure the bug doesn't exist in 3.2.x and doesn't exist in master Chris From psm_vu at india.com Mon Jan 31 11:15:58 2011 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Mon, 31 Jan 2011 10:15:58 +0000 (UTC) Subject: [Koha-devel] Using Unicode in Koha In-Reply-To: References: Message-ID: <20110131101552.E2C0340000180@smtp02.zmail.com> An HTML attachment was scrubbed... URL: From mjr at phonecoop.coop Mon Jan 31 18:57:16 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 31 Jan 2011 17:57:16 +0000 (GMT) Subject: [Koha-devel] irc down ? In-Reply-To: <4D467F3C.7000507@biblibre.com> Message-ID: <20110131175716.30B5E5028C@nail.towers.org.uk> Paul Poulain asked: > It's probably already known, but IRC seems down. > > Side question: shouldn't we move to a wider irc server (like freenode) ? > Wouldn't require katipo help to deal with problems. Looked down to me this morning too, but I didn't have time to investigate. If we move, please to OFTC or anywhere nicer than freenode. Or maybe it's time to move to a jabber/xmpp multi-user conference so all those Google Talk users can interact with us more easily? koha at conference.jabber.ttllp.co.uk should be open if we want to use it. Regards, -- MJ Ray, member of www.software.coop Experts in web and GNU/Linux (# number in subject emails = copy to all workers unless asked.) Turo Technology LLP, reg'd in England+Wales, number OC303457 Reg. Office: 36 Orchard Cl., Kewstoke, Somerset, GB-BS22 9XY From chris at bigballofwax.co.nz Mon Jan 31 19:04:42 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 1 Feb 2011 07:04:42 +1300 Subject: [Koha-devel] irc down ? In-Reply-To: <20110131175716.30B5E5028C@nail.towers.org.uk> References: <4D467F3C.7000507@biblibre.com> <20110131175716.30B5E5028C@nail.towers.org.uk> Message-ID: On 1 February 2011 06:57, MJ Ray wrote: > Paul Poulain asked: >> It's probably already known, but IRC seems down. >> >> Side question: shouldn't we move to a wider irc server (like freenode) ? >> Wouldn't require katipo help to deal with problems. > > Looked down to me this morning too, but I didn't have time to investigate. Feels a lot like hardware fail, its been down a while and the power was flicking in Wellington last night, will know more when people awake. > > If we move, please to OFTC or anywhere nicer than freenode. OFTC works for me. It corresponds to the goals and ideals of the Koha project. > Or maybe > it's time to move to a jabber/xmpp multi-user conference so all those > Google Talk users can interact with us more easily? > > koha at conference.jabber.ttllp.co.uk should be open if we want to use it. > Id be open to giving it a try, but can we run things like the meetingbot, logbot, pastebot etc there? Chris > Regards, > -- > MJ Ray, member of www.software.coop Experts in web and GNU/Linux > (# number in subject emails = copy to all workers unless asked.) > Turo Technology LLP, reg'd in England+Wales, number OC303457 > Reg. Office: 36 Orchard Cl., Kewstoke, Somerset, GB-BS22 9XY > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > From gmcharlt at gmail.com Mon Jan 31 19:36:21 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Mon, 31 Jan 2011 13:36:21 -0500 Subject: [Koha-devel] irc down ? In-Reply-To: References: <4D467F3C.7000507@biblibre.com> <20110131175716.30B5E5028C@nail.towers.org.uk> Message-ID: Hi, On Mon, Jan 31, 2011 at 1:04 PM, Chris Cormack wrote: > On 1 February 2011 06:57, MJ Ray wrote: >> If we move, please to OFTC or anywhere nicer than freenode. > > OFTC works for me. It corresponds to the goals and ideals of the Koha project. OFTC is fine with me. If the Katipo server stays down for much longer, I suggest we just plan on migrating over soon. >> Or maybe >> it's time to move to a jabber/xmpp multi-user conference so all those >> Google Talk users can interact with us more easily? >> >> koha at conference.jabber.ttllp.co.uk should be open if we want to use it. >> > Id be open to giving it a try, but can we run things like the > meetingbot, logbot, pastebot etc there? I'm not opposed to the experiment (though not particularly in favor of it either because of the additional time I suspect it would take to port the bots over), but would prefer that we set up things so that the service is named koha at conference.koha-community.org or the like. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From mjr at phonecoop.coop Mon Jan 31 19:43:16 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 31 Jan 2011 18:43:16 +0000 (GMT) Subject: [Koha-devel] irc down ? In-Reply-To: Message-ID: <20110131184316.2981C5028C@nail.towers.org.uk> Chris Cormack asked: > On 1 February 2011 06:57, MJ Ray wrote: > > If we move, please to OFTC or anywhere nicer than freenode. > > OFTC works for me. It corresponds to the goals and ideals of the Koha project. OK, some of us are on irc.oftc.net #koha now. > > Or maybe > > it's time to move to a jabber/xmpp multi-user conference so all those > > Google Talk users can interact with us more easily? > > > > koha at conference.jabber.ttllp.co.uk should be open if we want to use it. > > > Id be open to giving it a try, but can we run things like the > meetingbot, logbot, pastebot etc there? It's a different protocol, so we'd probably need different bots. That alone might be reason enough to keep on with IRC. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From mjr at phonecoop.coop Mon Jan 31 19:47:39 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 31 Jan 2011 18:47:39 +0000 (GMT) Subject: [Koha-devel] irc down ? In-Reply-To: Message-ID: <20110131184739.802205028C@nail.towers.org.uk> Galen Charlton wrote: > On Mon, Jan 31, 2011 at 1:04 PM, Chris Cormack wrote: > > On 1 February 2011 06:57, MJ Ray wrote: [...] > >> koha at conference.jabber.ttllp.co.uk should be open if we want to use it. > >> > > Id be open to giving it a try, but can we run things like the > > meetingbot, logbot, pastebot etc there? > > I'm not opposed to the experiment (though not particularly in favor of > it either because of the additional time I suspect it would take to > port the bots over), but would prefer that we set up things so that > the service is named koha at conference.koha-community.org or the like. If someone can set conference.koha-community.org DNS appropriately and help me find how to configure jabber-muc to answer it, then I'm quite happy to set that up. Otherwise, someone else can set it up and I'll move+redirect. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha