June 2003 - Koha-devel - lists.koha-community.org

Bugfix for #496
by Jerome Vizcaino 19 Jun '03

19 Jun '03

Hi all Included is the modified opac-search.pl that fixes the bug #496. As I encounter several problems commiting to CVS, can someone commit it for me ? I'm sorry I have to do it this way but I really have tried everything to get it to work without success. Thank you Jerome

1 0

RE:koha on pache 2
by Jones, Steven 19 Jun '03

19 Jun '03

2 1

Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd)
by COURYHOUSE＠aol.com 19 Jun '03

19 Jun '03

Now you are assuming that I want to learn new programming languages.... I don't even have time to practice the ancient art of ALGOL, SPL, FORTRAN etc... retooling my brain for a new language is not an option... Besides.. pulling 16 hour days leaves little time.... > The code is freely > available and the changes you're looking for aren't too big, you could > write them yourself or hire someone to write them

2 1

Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd)
by Pat Eyler 19 Jun '03

19 Jun '03

On Thu, 19 Jun 2003 COURYHOUSE(a)aol.com wrote: Well, I've already apologized to Ed offline, but since this little flamefest was carried out in public, I should apologize here too. Sorry Ed, both for being abrasive in my response and in letting your request slide off of our collective plates. I've submitted a bug report, http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=498 for those that are following along, in hopes that we can keep it from getting buried again. thanks, -pate > Now you are assuming that I want to learn new programming languages.... I > don't even have time to practice the ancient art of ALGOL, SPL, FORTRAN etc... > retooling my brain for a new language is not an option... Besides.. pulling 16 > hour days leaves little time.... > > > > The code is freely > > available and the changes you're looking for aren't too big, you could > > write them yourself or hire someone to write them > > > Thanks Ed Sharpe, Archivist for SMECC > > See the Museum's Web Site at > > www.smecc.org > > We are always looking for items to add to the museum's display and ref. > library > please advise if you have anything we can use. > > mail: > > Coury House / SMECC > 5802 W. Palmaire Ave. > Glendale Az 85301 USA > > 623-435-1522 > > >

2 1

Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd)
by COURYHOUSE＠aol.com 19 Jun '03

19 Jun '03

I will be back in 6 months then. > Subj:Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd) > Date:6/18/2003 9:36:41 PM US Mountain Standard Time > From:<A HREF="mailto:pate@eylerfamily.org">pate(a)eylerfamily.org</A> > To:<A HREF="mailto:COURYHOUSE@aol.com">COURYHOUSE(a)aol.com</A> > CC:<A HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A>, <A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel(a)lists.sourceforge.net</A> > Sent from the Internet > > > > On Thu, 19 Jun 2003 COURYHOUSE(a)aol.com wrote: > > > To put things in perspective, even before Pate joined this endeavor I > had > > mentioned both LC and MARC with the folks at Katipo Communications. > > As well as Steve T. When Pate came on board I discussed LC as well as > MARC > > with him as well. I was told this evening by someone from the project I > should > > have submitted it as a bug report. It is just a little weird I feel I am > being > > put in a position of defending myself? > > Sorry for making you feel as though you're on the defensive. I'm feeling > a bit that way myself as we're getting closer to 2.0 ... I know that LC > numbers have been kicked around for a while and not much has happened so > far. > > Right now, it's not going to make it into 2.0.0 ... I think it will > probably be in 2.0.1. I'll go submit a bug report/feature request right > now to ensure it doesn't slide of our collective plate again. > > -pate > > > > > The request for LC was not a new one. it may seem so to some of the > folk > > now as many of you were not even here when it was being made! > > > > Thanks Ed Sharpe, Archivist for SMECC > > > > See the Museum's Web Site at > > > > www.smecc.org > > > > We are always looking for items to add to the museum's display and ref. > > library > > please advise if you have anything we can use. > > > > mail: > > > > Coury House / SMECC > > 5802 W. Palmaire Ave. > > Glendale Az 85301 USA > > > > 623-435-1522 > > > > > > > Subj:Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd) > > > Date:6/18/2003 6:04:34 PM US Mountain Standard Time > > > From:<A HREF="mailto:pate@eylerfamily.org">pate(a)eylerfamily.org</A> > > > To:<A HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A>, <A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel(a)lists.sourceforge.net</A> > > > Sent from the Internet > > > > > > > > > > > > hmm, this was really meant for the list at large, not just Ed. > > > > > > sorry, > > > -pate > > > > > > ---------- Forwarded message ---------- > > > Date: Wed, 18 Jun 2003 20:21:56 -0400 (EDT) > > > > > > Thanks Ed Sharpe, Archivist for SMECC See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library please advise if you have anything we can use. mail: Coury House / SMECC 5802 W. Palmaire Ave. Glendale Az 85301 USA 623-435-1522 CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono confidenziali e riservati. Se vi è stato recapitato per errore e non siete fra i destinatari elencati, siete pregati di darne immediatamente avviso al mittente. Le informazioni contenute non devono essere mostrate ad altri, né utilizzate, memorizzate o copiate in qualsiasi forma. CONFIDENTIAL: This e-mail and any attachments are confidential and may contain reserved information. If you are not one of the named recipients, please notify the sender immediately. Moreover, you should not disclose the contents to any other persons, nor should the information contained be used for any purpose or stored or copied in any form.

1 0

Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd)
by COURYHOUSE＠aol.com 18 Jun '03

18 Jun '03

Yea gads these folks are not recreational programmers. They just need a tool to automate their libraries... And... If they wish to use LC why start them playing with Dewey which they are NOT going to use? I know I would not desire to do this and I would not expect them to either. Thanks Ed Sharpe, Archivist for SMECC See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library please advise if you have anything we can use. mail: Coury House / SMECC 5802 W. Palmaire Ave. Glendale Az 85301 USA 623-435-1522 CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono confidenziali e riservati. Se vi è stato recapitato per errore e non siete fra i destinatari elencati, siete pregati di darne immediatamente avviso al mittente. Le informazioni contenute non devono essere mostrate ad altri, né utilizzate, memorizzate o copiate in qualsiasi forma. CONFIDENTIAL: This e-mail and any attachments are confidential and may contain reserved information. If you are not one of the named recipients, please notify the sender immediately. Moreover, you should not disclose the contents to any other persons, nor should the information contained be used for any purpose or stored or copied in any form.

1 0

Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd)
by COURYHOUSE＠aol.com 18 Jun '03

18 Jun '03

To put things in perspective, even before Pate joined this endeavor I had mentioned both LC and MARC with the folks at Katipo Communications. As well as Steve T. When Pate came on board I discussed LC as well as MARC with him as well. I was told this evening by someone from the project I should have submitted it as a bug report. It is just a little weird I feel I am being put in a position of defending myself? The request for LC was not a new one. it may seem so to some of the folk now as many of you were not even here when it was being made! Thanks Ed Sharpe, Archivist for SMECC See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library please advise if you have anything we can use. mail: Coury House / SMECC 5802 W. Palmaire Ave. Glendale Az 85301 USA 623-435-1522 > Subj:Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd) > Date:6/18/2003 6:04:34 PM US Mountain Standard Time > From:<A HREF="mailto:pate@eylerfamily.org">pate(a)eylerfamily.org</A> > To:<A HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A>, <A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel(a)lists.sourceforge.net</A> > Sent from the Internet > > > > hmm, this was really meant for the list at large, not just Ed. > > sorry, > -pate > > ---------- Forwarded message ---------- > Date: Wed, 18 Jun 2003 20:21:56 -0400 (EDT)

2 1

RE: [Koha-devel] Re: [Koha] Re: DDC and LC classification - 2 cents more
by Bernadette Cassidy 18 Jun '03

18 Jun '03

No, that's not correct. The problem isn't putting in the LC number, it's getting Koha to accept it and display it in the catalogue record!! ___________________________________________ Bernadette Cassidy Library & Learning Coordinator Allan Bean Centre Burwood Hospital Christchurch New Zealand Tel: (03) 383 9492 Fax: (03) 383 7500 -----Original Message----- From: Stephen Hedges [mailto:shedges@athenscounty.lib.oh.us] Sent: Wednesday, 18 June 2003 7:54 p.m. To: COURYHOUSE(a)aol.com; albert.p.calame(a)sympatico.ca; koha(a)lists.katipo.co.nz; koha-devel(a)lists.sourceforge.net Subject: Re: [Koha-devel] Re: [Koha] Re: DDC and LC classification - 2 cents more I thought it would show whatever you put in. If you put in an LC number, that's what you get out. The problem is being able to put an LC number in, right? Stephen Hedges > Yes, any real marc or later record should have > it, but what I was trying to > stress (and yes I am starting to get stressed)! > You have to have koha have the > ability to use that information for those of us > in the upper educational and > scientific community AND NOT HAVE IT SHOWING > DEWEY! > > This must be an easy to change option for the > library involved that should > be selectable at startup/install time. > > The library that is to use the software should > not have to write any scripts, > recode something, or go to any other effort than > to indicate during install > if they wish Dewey or lc. > > Ed! > > > > Subj:[Koha-devel] Re: [Koha] Re: DDC and LC > classification - 2 cents more > > Date:6/17/2003 5:56:21 PM US Mountain Standard > Time > > From:<A > HREF="mailto:albert.p.calame@sympatico.ca">albert. > p.calame(a)sympatico.ca</a> > > To:<A > HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.k > atipo.co.nz</a>, <A HREF="mailto:koha- > devel(a)lists.sourceforge.net">koha- > devel(a)lists.sourceforge.net</a> > > Sent from the Internet > > > > > > > > Hi All! > > We may be missing the point with this > discussion. Firstly, while DDC > > uses mostly a single Classification Number that > could fit on a single line > > (There are a few cases, as with Shakespeare, > where an additional line with a > > special additional code is used to bring out a > specific play), a Call Number > > is not equal to a Classification Number. The > Call Number on a book or other > > item is intended to assist in the location of > items where they have been > > stored (typically books on shelves), however > the Classification Number is > > just a part of the whole Call Number. As > Steven mentions below, most > > libraries add prefixes to indicate shelving > locations and add an additional > > line to indicate the Author or Biographee. The > Dewey Number can vary in > > length from 2 to probably 20 characters, and in > such cases, often the number > > will be split between more than one line > (average spine labels are only > > about 10 characters wide). > > > > In the case of LC Classification, Call > numbers usually have 4 lines - > > two for Classification, one for Date (the three > Steven has below) and most > > often a line for Cutter Number (a code for > Author similar in function to the > > Dewey Author line). Here, too, there may be a > prefix to make up the entire > > Call Number. > > > > In both cases, the classification number > tries to group materials on > > like subjects together so that they are easier > to locate. > > > > I _don't_ see, however, the need within > koha to give the older non-MARC > > data structure the additional structures needed > to store LC Call Numbers, > > when any of the MARC structures can do so very > well - indeed the required > > subfields are already in place. I would be > surprised if a library that is > > using LC Classification would want to establish > their database in other than > > MARC structure, especially when we realize that > the source of records that > > the typical academic and scientific libraries > that use LC would use to build > > their catalogues are most likely to be in MARC > structure to start with. Why > > convert the data to a new structure when koha > will store it in the original > > structure to start with? > > > > I understand that some librarians may not > particularly care to use MARC, > > I used to be one of them! But it is the de > facto standard for the exchange > > of bibliographic data. It does have all the > fields and subfields already > > defined to do the job for us. It has built-in > flexibility to meet any > > special needs we may have. It doesn't take too > long to come to appreciate > > that the MARC21 structure does let you do > whatever you need to. It only > > requires that you study a bit to get used to it > at first. Non cataloguers > > likely would think I'm a bit batty for even > wanting to!;-) More > > importantly, however, why re-invent the wheel? > > > > The MARC21 structure provides for this by > having several subfields > > devoted to that specific information. As > > long as the fields can contain enough data (I > suggest 16 characters (maybe > > 20) to account for even the longest Dewey > likely to be used with 12 places > > after the decimal , or possibly for a complete > surname which is sometimes > > entered in the case of a biography [some names > could well exceed the 16 > > chars]). {MARC structure gives a maximum field > length for any field of 9999 > > characters, so each subfield could be greater > than the minimums I mention > > above .}Those subfields are: > > > > Tag 852 with subfields - > > > > $h - Classification part (NR) (Dewey or LC > Classification numbers, such > > Alpha Classification as E for Easy, B for > Biography,etc.) > > $i - Item part (R) (Used for author letters, > cutter numbers, or sometimes > > biographees last names) > > $k - Call number prefix (R) (Like REF for > reference collections, etc) > > $m - Call number suffix (R) > > $t - Copy number (NR) > > > > [This information comes from the MARC > Standards page at the Library of > > Congress Web page with my comments in > parentheses after the designation of > > repeatable or non repeatable] > > > > The MARC structure, with subfields k, i, > and m as repeatable does take > > care of places to store the Call Numbers > appropriately. The only problem I > > can see is that the biblioitems table needs to > be able to store the > > information > > in the same way, and koha needs to be able to > display the repeatable > > subfields appropriately also. Display order > would normally be: > > k, h, i, m, t. > > > > Display has always been a problem with > fields that may be longer that > > would fit on a single line of a label, hence > the addition of break > > characters that you may see sometimes as > apostrophes in the middle of long > > Dewey Class numbers. > > > > > > Let's make sure, however, that when it > comes time to display or print > > the Call Numbers, whether with LC or DDC, that > we have stored in koha, that > > we can do so properly, and would be able to > actually print new spine labels > > for books or other items. > > This would be a better use of programming time, > imho, than to add additional > > structures to the non-MARC structured database > in koha for LC users. > > > > That's my 2 cents worth! > > > > Regards, > > Al Calame > > > > Library Automation Consultant, > > Librarian-at-Large, > > Albert P. Calame Consulting > > Montreal, Québec, Canada > > > > 514-745-3424 > > albert.p.calame(a)sympatico.ca > > > > > > Original Message ----- > > From: "Stephen Hedges" > <shedges(a)athenscounty.lib.oh.us> > > To: <ABanks(a)buscominc.com> > > Cc: <koha(a)lists.katipo.co.nz>; <koha- > devel(a)lists.sourceforge.net> > > Sent: Tuesday, June 17, 2003 6:22 PM > > Subject: [Koha] Re: DDC and LC classification > > > > > > > For starters, here's a good place to learn > how Dewey Decimal > > Classification > > > (DDC) works: > > > > > > > http://www.oclc.org/oclc/fp/about/about_the_ddc.ht > m > > > > > > If you look at this URL and the ones Rob > sent, it looks like DDC always > > fits on > > > one line, while LC can run to as many as five > lines. That's true in a > > > theoretical world. In the real world, > libraries muck around and add other > > > stuff, to help the people who have to stick > the books back on the shelves. > > > > > > Here's an example. The copy of The Chicago > Manual of Style I have beside > > me > > > has the Library of Congress Cataloguing-in- > Publication (CIP) data printed > > > inside the fly leaf. It says that the > "official" classifications are as > > > follows: > > > > > > LC would be - > > > Z253 > > > U69 > > > 1993 > > > > > > DDC would be - > > > 808 or 808.027 or 808.0270973 if I'm > really picky. > > > > > > Looks like 3 lines for LC and 1 line for > DDC. > > > > > > But in practice, it's hard for humans to keep > a long string of numbers > > straight > > > and in order when re-shelving books, so most > libraries that use DDC do > > what my > > > library does -- add an extra line with the > first two letters of the title > > or > > > the author's name under a _short_ Dewey > number. So the spine label on > > this > > > particular book reads: > > > 808 > > > Ch > > > instead of > > > 808.0270973 > > > > > > Now it gets really fun! Many libraries also > add stuff _before_ the Dewey > > > number, like AB for audiobooks or YA for > young adult or J for juvenile or > > > junior. (LC libraries sometimes do this, > too.) Yeah, they're really > > > categories and shouldn't be part of the call > number. But again, they help > > > humans find, retrieve, and replace stuff on > library shelves. Practice > > > supercedes theory once again! > > > > > > But to get to the point, five lines should be > quite enough for most > > purposes, > > > for either LC or DDC. I'm sure someone will > disagree, but any library > > that > > > thinks it has to have six lines probably > needs some discipline! > > > > > > Stephen Hedges > > > (Nelsonville Public Library) > > > > > > > I've been working on SQL phrasebooks to > enable > > > > multiple backend DB support. I would be > happy to > > > > help with changing these fields around. > > > > > > > > Since my knowledge of library science is > pretty > > > > much limited to what I've learned off of > this > > > > list, could someone step up to the plate to > do > > > > some research on the type and number of > fields > > > > needed? > > > > > > > > ----- Original Message ----- > > > > From: Chris Cormack <chris(a)katipo.co.nz> > > > > Date: Tuesday, June 17, 2003 1:29 pm > > > > Subject: Re: [Koha] More questions - > another 2 > > > > cents worth > > > > > > > > > I think there may be some confusion > between a > > > > lccn number (library of > > > > > congress control number) and library of > > > > congress call numbers. If I > > > > > understand correctly, a lccn number is > single > > > > unique number used > > > > > to identify > > > > > a specific title, kind of like a serial > number. > > > > However, > > > > > (librarians, please > > > > > correct me if I'm wrong) lccn numbers are > not > > > > used for cataloging and > > > > > shelving books in a library that used the > LC > > > > system. Instead there > > > > > are a > > > > > series of four or five lines of call > numbers > > > > that are used instead. > > > > > > > > > > Rather than try to explain it, let me > refer you > > > > to > > > > > > > > > > http://www.lib.ksu.edu/instructional/understanding > > > > > lccn/webcall2.html or > > > > > > > > > > http://www.hcc.hawaii.edu/education/hcc/library/ca > > > > > llno.html for some > > > > > explanation and samples of LC call > numbers. > > > > > > > > > > The problem is that koha doesn't > currently have > > > > adequate fields of the > > > > > proper type for storing these four or > five > > > > lines of information in the > > > > > database (I think there are such fields > in the > > > > MARC tables, but > > > > > not in the > > > > > basic koha tables). I agree that > accommodating > > > > the different > > > > > catalogingsystems is a template issue, > but feel > > > > that the necessary > > > > > fields need to be > > > > > in place in the database tables first. I > had > > > > actually emailed the > > > > > development list on this same issue a > couple > > > > weeks ago (subject: > > > > > inflexiblefield types for call numbers). > > > > > > > > > > My recommendation would be that we survey > as > > > > many knowledgeable > > > > > librariansas possible to find out how > many > > > > fields are necessary > > > > > for storing call > > > > > numbers under the various systems, what > the > > > > maximum length of each > > > > > needs to > > > > > be, and then add those fields to the > database > > > > tables (unless the > > > > > programmerscould suggest existing fields > that > > > > can be used). I > > > > > think if there were four > > > > > or five flexible fields for storing call > number > > > > information, then > > > > > indeedkoha could be adapted to almost > any > > > > cataloging system by > > > > > reworking the > > > > > templates. > > > > > > > > > > Rob > > > > > > > > > > ----- Original Message ----- > > > > > From: "Chris Cormack" > <chris(a)katipo.co.nz> > > > > > Sent: Tuesday, June 17, 2003 1:20 AM > > > > > Subject: Re: [Koha] More questions - > another 2 > > > > cents worth > > > > > > > > > > > > > > > > We do have an lccn field in the koha > > > > database. And you can load > > > > > data into > > > > > > it, its currently not displaying or > > > > searchable yet though. This > > > > > is a > > > > > > templating issue, im sure we could > change it > > > > quite fast. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Koha mailing list > > > > > Koha(a)lists.katipo.co.nz > > > > > > > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > > > > > > > _______________________________________________ > > > > Koha mailing list > > > > Koha(a)lists.katipo.co.nz > > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > _______________________________________________ > > > Koha mailing list > > > Koha(a)lists.katipo.co.nz > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > ------------------------------------------------ > ------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become > An INetU Hosting Partner. > > Refer Dedicated Servers. We Manage Them. You > Get 10% Monthly Commission! > > INetU Dedicated Managed Hosting > http://www.inetu.net/partner/index.php > > > _______________________________________________ > > Koha-devel mailing list > > > Thanks Ed Sharpe, Archivist for SMECC > > See the Museum's Web Site at > > www.smecc.org > > We are always looking for items to add to the > museum's display and ref. > library > please advise if you have anything we can use. > > mail: > > Coury House / SMECC > 5802 W. Palmaire Ave. > Glendale Az 85301 USA > > 623-435-1522 > > CONFIDENZIALE: Questo messaggio e gli eventuali > allegati sono confidenziali > e riservati. Se vi è stato recapitato per errore > e non siete fra i > destinatari elencati, siete pregati di darne > immediatamente avviso al > mittente. Le informazioni contenute non devono > essere mostrate ad altri, né > utilizzate, memorizzate o copiate in qualsiasi > forma. > > CONFIDENTIAL: This e-mail and any attachments > are confidential and may > contain reserved information. If you are not one > of the named recipients, > please notify the sender immediately. Moreover, > you should not disclose the > contents to any other persons, nor should the > information contained be used > for any purpose or stored or copied in any form. > > > _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting (fwd)
by Pat Eyler 18 Jun '03

18 Jun '03

hmm, this was really meant for the list at large, not just Ed. sorry, -pate ---------- Forwarded message ---------- Date: Wed, 18 Jun 2003 20:21:56 -0400 (EDT) From: Pat Eyler <pate(a)eylerfamily.org> To: COURYHOUSE(a)aol.com Subject: Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting On Wed, 18 Jun 2003 COURYHOUSE(a)aol.com wrote: > Unfortunately my compatriots do not� invest time in futures. We need to make > sure they do not wander off to another system\ having them onboard will add > even more Fame to KOHA. I'm sorry that they're not willing to work toward the solution that they want. Making a bit of an elbow grease investment in 2.0.0 would likely pay back in terms of a better 2.0.1 (with the things they want in it) sooner rather than later. > > they are looking� for something that is complete,� in the following areas.. > > marc import > > marc export > > LC call numbers. > > I assume the other items are all done, but the third one is a necessity too. Yes, the first to are done (subject at this point only to finding and eliminating bugs). > > No one even wants to play with Dewey screens� and start loading the catalog > when what they need is LC. > > It is my belief that the LC item needs to be expedited� so those in the > university and scientific community can start to work. > Ed, we're probably less than 2 months from 2.0.0, the more people who can find and report bugs (and fix them) the faster we can get 2.0.0 out the door. Once 2.0.0 has been put to bed, we can start on 2.0.1. I'm guessing that 2.0.1 will be a much shorter cycle than 2.0.0 (on the order 3 months or less -- no promises though). If you absolutely, positively can't wait until then, you have a couple of choices. The code is freely available and the changes you're looking for aren't too big, you could write them yourself or hire someone to write them. I'm sure that Paul will be happy to accept a big block of changes for 2.0.1 once development starts. I hate to sound negative about this, but it's an important point. Koha exists because people who have wanted specific things have stepped up and done them (sometimes by hiring developers). We're working very hard to get a rock-solid 2.0.0 done in a timely fashion so that we can get back to work on new development. That's the sandbox we all want to be playing in. thanks, -pate > thanks Ed Sharpe archivist for SMECC > ed sharpe archivist for smecc > > Subj: Re: [Koha-devel] Re: [Koha] 3rd pre 2.0 meeting� > > Date: 6/18/2003 3:28:54 PM US Mountain Standard Time > > From: <A HREF="mailto:chicks@chicks.net">chicks(a)chicks.net</A> > > To: <A HREF="mailto:COURYHOUSE@aol.com">COURYHOUSE(a)aol.com</A> > > CC: <A HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A>, <A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel(a)lists.sourceforge.net</A> > > Sent from the Internet > > > > > > > > On Wed, 18 Jun 2003 COURYHOUSE(a)aol.com wrote: > > >OK so it is still not going to be useable� by our community for a while > > then. > > >Ultra bummer. now I have 30 sad news emails to send out. > > > > It doesn't have to be sad news emails!� It's just a matter of timing.� > > You can play with 2.0 koha while waiting for 2.0.1 to get familiar with > > Koha and discover any other issues you may need fixed.� By the time 2.0.1 > > comes out you'll be ready to consider a beta schedule and projected > > production date.� Plus actively testing 2.0 until the next minor release > > comes will almost certainly help 2.0.1 arrive sooner.� What sadness? > > >

1 0

3rd pre 2.0 meeting
by Pat Eyler 18 Jun '03

18 Jun '03

Well, we had another pre 2.0 bug meeting. Many people showed up and most lurked, but several participated. Some interesting threads came up: NPL is closing in on their migration from Spydus to Koha. Concurrently, there seems to be some interest in Koha building in Australia (currently about 80% of Spydus new business is in Australia). It looks as though interesting things may start happening there once 2.0.0 comes out. Interest in a Z39.50 server cropped up again. It won't happen in 2.0.0, but 2.0.1 is a very real possibility. I (Pat Eyler) will be talking to the developers of Zebra (a free z39.50 server engine) to see about integrating their work into Koha. NPL talked a bit about their work with the bulkimporter. Paul agreed to take on a bug that NPL found. The Spanish language translators from Argentina asked about how to work on translations for 2.0.0. You can look at www.koha.org/irc/ for a full log. If you are interested in getting involved, please feel free to get involved in the next irc meeting -- next Wednesday, same time, same place. -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

2 1