IRC log for #koha, 2008-09-13

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
12:03 Amit hi danny
12:05 danny morning #koha, hey Amit
13:59 acmoore Amit: it's OK. I'm not waiting on your document or anything. Send it in whenver you get to it.
13:59 Amit ok sir
15:33 eric hi everyone.  Is there a place where we can see the status of Koha 3 for Windows?
15:36 I found this link http://wiki.koha.org/doku.php?[…]installer_project, last update: 2008/01/30
15:38 paul eric: afaik, it doesn't work & won't work, unless you use the VMWARE provided by dont-remember-who
15:38 gmcharlt Kyle
15:38 paul hi gmcharlt
15:38 gmcharlt hi paul
15:38 paul very quiet chanel those days...
15:38 (and very very busy for us...)
15:39 gmcharlt hopefully less quiet in a few hours :)
15:39 paul yep.
15:40 eric Is there someone looking to make the Win32 version works?
15:40 Anybody knows what are the remaining problems of the Windows version?
15:41 paul a library that can't be installed on windows
15:41 (expat ?)
15:41 (libxml ?)
15:42 eric ok, it still this problem.  Is that the only one? (I don't tell that it is simple to fix, though)
15:43 I'll give it a try and let you know.
15:44 wish me luck! :)
16:45 Amit hi
16:45 #koha
16:53 mc hello workd
16:53 world
16:54 someone knows how to list available databases with yaz?
17:38 Amit hi
18:04 frederic gmcharlt: I'm replying to your email on koha-devel
18:05 I'm going out this evening and won't participate to the IRC meeeting
18:05 QA manager role is obviously not clearly defined or can by really huge!
18:06 gmcharlt frederic: ok, thanks
18:06 frederic So I will clarify in my email that I'm available BUT to a limited extend...
18:18 slef hi all
18:18 Amit hi slef
18:20 gmcharlt hello slef
18:51 Amit Hi
18:52 there is one question
18:52 delhi public library uses 12 GB RAM server
18:52 but koha software response slow
18:53 hdl hi
18:53 Amit koha installation Centos-5.2
18:53 with zebra
18:53 hi hdl
18:53 hdl Amit : redhat has problems with PERL
18:53 Amit this not right sir
18:53 i think
18:54 ?/
18:54 use debian
18:54 only for koha
18:54 acmoore hdl: are you referring to the recent bug found in redhat's perl that caused slowness when using code that used overloading?
18:54 hdl yes
18:54 Amit no this is not right
18:55 i tell one thing more
18:55 in my laptop
18:55 it works fine
18:55 hdl what is not right ?
18:55 Amit redhat has problems with perl
18:56 but in server
18:56 its response slow
18:56 hdl
18:56 acmoore hdl: I'm not sure if that applies to centos or not. Here's a reference in case amit wants to investigate it:  http://perlbuzz.com/2008/08/re[…]ding-in-perl.html
18:57 Amit i think it is due
18:57 hdl Amit : you can try and make some benchmarking on your installlation.
18:57 Amit yes
18:57 acmoore vipul seems to say that centos 5.2 is affected.
18:57 Amit sir tell me one this
18:57 one thing
18:57 this is due becuase i have some editing in zebra
18:58 for indian languages searching
18:58 hdl hi acmoore
18:58 acmoore hi hdl.
18:58 Amit try to reformating the server this is right
18:59 acmoore I think there are some perl modules out there (catalyst?) that check for this RHEL bug and complain if it's found. Perhaps we need to start doing something similar. Unless it will be fixed soon.
19:00 gmcharlt acmoore: easy enough to add to Makefile.PL as a check
19:00 Amit this is right there is lot of perl module needed in rpm based linux compare to debian
19:00 gmcharlt OK, greetings all
19:00 it's time for the Koha community meeting
19:00 on the agenda
19:00 Amit ok
19:00 gmcharlt 1. Confirm 3.2 RM, TM, and DocM
19:01 2. Decide 3.0 RMaint
19:01 mc q/na
19:01 oops
19:01 gmcharlt 3. Discuss the Kaitiaki position
19:01 mc hello all
19:01 Amit hi mc
19:01 gmcharlt 4. Discuss the QA manager for 3.2
19:01 5. Discuss features for 3.2
19:01 before we get started with #1, any other agenda items
19:01 ?
19:01 Amit one
19:01 more for my side
19:02 give u give me permission then i say
19:02 gmcharlt Amit: go ahead, what's your agenda item?
19:02 Amit proper software testing before releasing stable version
19:03 gmcharlt ok, we can discuss after #4 (QA manager)
19:03 Amit ok
19:03 slef going mobile - excuse me if I PTO
19:03 kados can we do a quick roll call?
19:03 Amit hi jmf
19:03 gmcharlt let's start with candidates
19:04 nengard nengard for documentation manager - here
19:04 gmcharlt hdl: you're still here, right?
19:04 and chris?
19:04 hdl yes
19:04 kados kados for QA Manager and/or RMaint 3.0 - here
19:04 gmcharlt frederic said he would not be able to attend
19:05 atz hello all
19:06 gmcharlt ok, everybody who is actively on channel, please announce yourself for the record
19:06 acmoore Andrew Moore, with liblime. here.
19:06 ryan Ryan Higgins, LibLlime
19:06 danielsweeney Dan Sweeney from LibLime, here.
19:06 nicomo nicomo here (biblibre)
19:06 slef MJ Ray of www.ttllp.co.uk and others
19:06 ccatalfo_ Chris Catalfo, LibLime, here
19:06 atz Joe Atzberger, LibLime
19:06 kados Josh Ferraro, LibLime here
19:06 hdl Henri-Damien LAURENT, BibLibre
19:06 brendan Brendan of bibliomation INC here
19:06 danny Danny Bouman from Howard County Library here
19:06 gmcharlt Galen Charlton, LibLime
19:06 Sharon Sharon Moreland, Northeast Kansas Library System
19:06 nengard Nicole Engard of Liblime
19:07 Ruth_ Ruth Vargas -- Howard County Library, Maryland, USA
19:07 melissa Melissa of Bibliomation, Inc. here
19:07 kados I'd say that's quorum ;-)
19:07 gmcharlt ok, on to agenda item #1
19:07 let's start with translation manager
19:08 chris (Chris Cormack) has volunteer to be TM for 3.2
19:08 mc Marc Chantreux, Biblibre
19:08 gmcharlt and announced plans for putting up a new interface
19:08 chris: are you awake yet?
19:08 ;)
19:09 anybody else planning to announce candidacy for TM?
19:09 atz i was wondering if he'd make a 7AM (Saturday?) NZ start time...
19:09 gmcharlt .
19:09 kados I'll motion that Chris be appointed to that position
19:09 nengard I second
19:09 hdl ++
19:09 nicomo +
19:09 gmcharlt ++
19:09 slef I ask to defer to end of meeting in case Chris wakes up after nightmares ;-)
19:09 Amit +
19:10 atz as long as our European colleagues who depend most on the translations agree, i'm for it.
19:10 hdl slef : is there any other volunteer anyway ?
19:10 gmcharlt and everywhere else in world, of course :)
19:11 I move that Chris be named TM for Koha 3.2 by acclamation, pending his acceptance
19:11 hdl + Chris proposal seems to get our votes.
19:11 gmcharlt ok, hearing no dissent, let's move on to Documentation Manager
19:11 slef hdl: NAFAIK but I think it's nice to give him a chance to attend like he said before we discuss him
19:12 atz we can revisit it if/when he comes in
19:12 gmcharlt slef: he did imply he was attending today, and there's no opposition - if he doesn't want it after all, he can decline
19:12 ryan i'll copy + slowpaste the backlog :)
19:12 gmcharlt ok, so nengard (Nicole Engard) is candidate for doc manager
19:12 slef ryan: newlogbot has posted it to the web
19:13 hdl nengard++
19:13 ryan nengard++
19:13 hdl for Doc Manager.
19:13 kados nengard++
19:13 atz ++
19:13 acmoore any other candidates or nominees?
19:13 nicomo nengard ++
19:13 mc ++
19:13 Amit ++
19:13 gmcharlt ++
19:13 slef ++
19:13 hcl-Luis ++
19:13 acmoore nengard++
19:13 kados acmoore: not that I know of, don't think anyone on the list stepped forward
19:13 ccatalfo_ ++
19:14 slef I'd like it if we could use a more portable doc format than Google in future please (what does Plone use?)
19:14 hdl (But this is a plebiscit ;) )
19:14 brendan ++
19:14 nengard Plone will allow us to export as PDF ... and maybe more ...
19:14 atz i don't think google docs was ever meant to be the "end state" of the documentation
19:15 nengard atz - absolutely not!
19:15 kados though one nice thing I'd hate to lose is the 'notify of site changes'
19:15 maybe we can have that in plone too
19:15 nengard and it's not handling the load very well - I keep getting 404 errors for pages that exist
19:15 ryan yeah, i like the notifications
19:15 gmcharlt RSS feeds in plone?
19:15 nengard kados and ryan the notifications are not accurate
19:15 you're not getting notified everything i update a doc
19:15 kados ahh, interesting
19:15 nengard just when i add one
19:15 or update the toc :)
19:15 kados google-- then
19:15 nengard just fyi
19:15 google--
19:16 kados heh
19:16 nicomo as far as translation of the docs are concerned, the many images make things more difficult I think...
19:16 for translation
19:16 even though I agree it's more telling
19:16 slef I can convert all sorts of things to RSS as long as the basic data (Last Modified dates or whatever) are there.
19:16 acmoore is nengard now appointed to that position, or is there anything else to do first?
19:16 nengard nicomo i agree -but they are appreciated by many english speakers ... they make it easier to follow the instructions
19:16 nicomo understandably
19:17 slef acmoore: give nengard any doc suggestions we have - but I've shot mine
19:17 gmcharlt OK, we've confirmed Nicole as DocM
19:17 atz yeah, that's tough tradeoff... valuable screenshots, but not language-portable
19:17 gmcharlt ok, on to RM for 3.2
19:17 I am a candidate
19:17 kados I'd like to nominate Galen Charlton for 3.2 RM
19:17 nengard gmcharlt++
19:17 kados as the outgoing RM
19:17 nicomo ++
19:17 hdl gmcharlt++
19:17 acmoore nengard: sounds like there's some demand for discussing documentatino at a later date.
19:18 nengard acmoore - i'm all for it!
19:18 gmcharlt any other candidates?
19:18 ryan gmcharlt ++
19:18 brendan ++
19:18 ccatalfo_ ++
19:18 Amit ++
19:18 melissa ++
19:18 Ruth_ ++
19:18 acmoore gmcharlt++
19:19 atz that looks like everybody
19:19 acmoore any objections?
19:19 kados guess that settles it then :-)
19:19 hdl should there be a wiki page for Documnetation improvement or on new koha.org site ?
19:19 gmcharlt thank you all
19:19 hdl applause
19:20 gmcharlt hdl: wiki for now, I would think
19:20 nengard hdl - wiki page for now works for me, we can move it when we get a site
19:20 gmcharlt ok, before we move on to #2, any other discussion about the positions named thus far?
19:20 .
19:20 ..
19:20 ...
19:20 ok, #2 - release maintainer for 3.0
19:21 candidates are hdl and kados
19:21 either way, it is my intention
19:21 to set up gitosis so that RMaint can push to 3.0.x branch
19:22 atz there have been major bugs discovered w/ the 3.0 release code, so the position will have some work to do cherry-picking patching
19:22 hdl yes.
19:22 I have seen many patches sent that should be backported to branch 3.0
19:23 kados I'm flexible w/respect to hdl taking 3.0 RMaint
19:23 atz hdl: it is my understanding that BibLibre supports you for this position
19:23 hdl I think there could be bug fixes releases on a quarter or bimonthly base.
19:23 atz (obviously josh can speak for liblime)
19:23 nicomo yes we do
19:23 mc yep
19:23 hdl for president^wRM
19:24 hdl RMaint.
19:24 not RM :D
19:24 mc sorry mr presi^wRMaint.
19:24 ;)
19:24 slef I'm divided on this.  There are merits in both.
19:24 acmoore what are the opinions on cherry-picking *features* into 3.0? are they about the same between hdl and kados? is that a differentiator?
19:25 atz so, in general, do we want the RM to transition into being Maintainer with future releases?
19:25 that seems like a normal progression
19:25 mc hmm ... is it a question of merits ? so we're all candidate :)
19:25 hdl I am not going in for cherry picking features.
19:26 nengard since kados is also up for QA I say it makes sense for hdl to handle the Rmaint
19:26 mc acmoore, according to me: 3.0 must be frozen
19:26 only debug
19:26 Amit yes
19:26 i think ur right
19:26 mc
19:26 hdl new features could add bugs when there is need for debugging.
19:26 slef I like that in general.  In particular, I'm not sure about one co holding both RM and RMaint and I'd like to see hdl try a lead role now.
19:26 ryan while rm-> rmaint seems natural, i would assume kados would not hold both qa and rmaint.  Is it the case that kados's candidacy is dependent on the qa position ?
19:26 atz but I like the idea of hdl on this job.  honestly, i think i talk more to him that josh, most weeks!
19:27 slef damn I'm typing slowly today
19:27 kados ryan: yea ... and I'm kinda holding out for the QA position pending another candidate who has time
19:27 I think it woudl be good to give hdl a shot at RMaint
19:28 nengard hdl++
19:28 atz it sounds like we are generally agreed then
19:28 ryan hdl++
19:28 gmcharlt hdl++
19:28 nicomo hdl ++
19:28 atz hdl++ indeed
19:28 acmoore looks like hdl has drawn the short straw. ;)
19:28 brendan hdl++
19:29 atz unless hdl has comment, we can table #2 and move to #3
19:29 hdl thank you.
19:29 gmcharlt ok #3
19:29 the question of the position of Kaitiaki
19:29 kados right
19:29 gmcharlt is Rachel on channel?
19:29 nengard gmcharlt can you define that position?
19:30 atz the translation is something like "Guardian"
19:30 kados nengard: one of the problems is that no-one has ever agreed to my knowledge on what the Kaitiaki's actual role is ;-)
19:30 and ...
19:30 nengard ah
19:30 kados we haven't had an active one in many many years
19:30 so my claim is that we don't need one ;-)
19:30 acmoore I move that this position be eliminated.
19:30 gmcharlt formal definition, such as it is, is at http://www.koha.org/about-koha/faq.html#faq19
19:30 atz de facto, the position is empty.  last held by Rachel
19:30 kados so ... discuss
19:31 atz it seems like what frederic was describing in his recent email to list
19:31 hdl I think we need kind of person who could be put before.
19:31 kados i think a community organizer role would be useful
19:31 someone who is actively involved in scheduling meetings, doing promotion, etc.
19:31 would be especially useful
19:32 hdl Maybe someone who has community organizer and kind of recognition in library world.
19:32 atz particularly a mutlilingual candidate
19:32 kados hdl: *nod*
19:32 atz: yep, good point, that would be nice
19:32 paul_ hello world !!!
19:32 hdl hi paul
19:32 atz greets paul
19:32 hdl #3 kaitiaki role
19:32 gmcharlt hi paul
19:33 kados (boarding a plane in 10 minutes)
19:33 gmcharlt I think Kaitiaki position should be left unfilled for now
19:33 atz i think the question of Kiatiaki can effectively be deferred .
19:33 ryan it seems more a users' group position, or liason between developers and community.  I think it's too vague to fill now.
19:33 gmcharlt unless somebody is planning to volunteer immediately?
19:33 atz #4 then.
19:34 slef I would but would suggest asking kohala and kudos for a better candidate first
19:34 I'll do that if you like
19:34 ryan slef: sounds good
19:34 gmcharlt ok, so position is left open for now
19:34 tabled as far as this meeting is concerned
19:35 slef paul_: http://koha.org/cgi-bin/logs.p[…]ed_query=%231+day
19:35 gmcharlt and slef will query users groups
19:35 slef gmcharlt: ITYM shelved
19:35 paul_ slef : thx
19:35 slef gmcharlt: or parked - (tabled has a different meaning US v UK/NZ)
19:35 paul_ ITYM ???
19:35 gmcharlt tabled, shelved - tomayto, tomahto ;)
19:36 paul_ gmcharlt ???
19:36 gmcharlt paul_: I think you meant
19:36 anyway, I think we've dealt with #3
19:36 atz "tabled" is parliamentary speak... by nature strange.
19:36 nicomo laisse paul ils font des jeux de mots entre US et UK
19:36 allowed myself a little french here to explain to paul
19:36 paul_ paul can't reach koha.org
19:36 seems 6667 is OK, but 80 isn't
19:36 could we switch back to QA ?
19:37 gmcharlt paul_: koha.org works for me
19:37 paul_ (sorry for that)
19:37 gmcharlt anyway, on to #4
19:37 acmoore paul_ we haven't gotten there yet.
19:37 paul_ gmcharlt: no sits work for me
19:37 slef small Q - can someone remind me whether we have a kudos mailing list?  (there are linkedin and facebook groups I know)
19:37 kados slef: nope, not as of yet
19:37 nengard slef no list
19:37 atz #4: QA Manager role for 3.2
19:38 cm there is one, slef.  go to http://ccfls.org/kudos for info.
19:38 gmcharlt candidates are frederic and kados
19:38 cm it exists, but nobody uses it!  :P
19:38 gmcharlt frederic is absent, and kados is soon to be
19:38 kados cm: hehe, maybe we need to list that on koha.org
19:38 slef cm: thanks.
19:38 cm yeah, good idea, kados.
19:38 kados I've layed out my opinions about QA Manager in the list
19:38 paul_ gmcharlt & me spoke of a distributed QA
19:39 atz paul: to some degree, i think that has been happening w/ the patches list
19:39 hdl frederic proposed thg.
19:39 paul_ atz: I agree.
19:39 kados atz: I don't agree, I think sign-off on specific patches is essential
19:39 paul_ I think we could/should have a more formal workflow for patches.
19:39 atz git signatures and community review helped endorse and improve patches sent
19:39 kados atz: ie, not being passive, but active review
19:39 gmcharlt from my point of view
19:40 kados where every patch gets 2-3 sign-offs
19:40 paul_ gmcharlt: suggested to have at least 2 ppl signing a patch
19:40 hdl But I think that neither candidates could have the time to achiev all the tasks listed by kados.
19:40 gmcharlt I need a separate set of eyes on each patch
19:40 atz hdl: that is true
19:40 gmcharlt as far as LibLime is concerned, we can move ourselves to a mode
19:40 kados i have time, or can make it
19:40 gmcharlt where all of our patches have at least two signoffs (dev + one other LL person)
19:41 but I also want review of all patches
19:41 and external review of LL patches, where possible
19:41 hdl I agree with you.
19:41 slef paul_: depending how you do it, that might cause problems for TTLLP (davi and me work on different bits) and Calyx (who have one publicly-active coder AFAIK)
19:41 hdl patches who comes the day before release should get hold.
19:42 gmcharlt slef: the recommendation (or ideal, anyway) for a organization to do internal review would be applicable to those large enough to do it
19:42 would not be expecting individual contributors to seek out others to sign off on patches
19:43 but would like a pool of volunteers (including kados) to participate in patch review, testing, and signoff
19:43 kados I think that someone should corrdinate that effort, and that perhaps that person is the QA manager, or perhaps it's the RM
19:43 hdl the fact is that having a list for patches helped anyone see what was sent.
19:43 slef hdl: yes
19:43 kados there's also the matter of organizing automated testing
19:44 hdl acmoore did some good job on that.
19:44 kados and manual testing of each patch has to be a priority as well IMO ... someone needs to be personally responsible for that (even in a distributed environment IMO)
19:44 slef and automated linking to bugs?
19:44 kados and ensuring that patch submission communication is open ... ie, to make sure nothing slips through the cracks without any comment
19:44 gmcharlt slef: pianohacker has some stuff he's been playing for linking patches to bugs
19:44 slef I like the idea that QAM is about developing tools/practices to watch this, more than the read-every-line idea.
19:44 paul_ during 1st stage of dev, patches may introduce some known unstability. How should we deal with that ?
19:45 I'm wondering if we don't need 2 kinds of QA :
19:45 acmoore hdl: thanks. There's a lot more that ought to be done with that sutff, though.
19:45 paul_ - at start : coding rules, correct Perl, ...
19:45 kados paul_: I think we should avoid that in 3.2 at least in the RM repo
19:45 slef paul_: put it up a public branch until ready to submit?
19:45 hdl (acmoore: I reckon)
19:45 kados paul_: we should assume that 3.2 is always 'stable' if not complete
19:45 paul_ - at beta/RC : individual testing of each patch
19:45 gmcharlt paul_: dev should warn; RM and QA reviewers should open bugs if an instability is to be permitted to exist until the feature is complete
19:46 paul_ maybe (and that's what we started with new acq module)
19:46 gmcharlt but agree with kados, that shouldn't be allowed (knowingly) to happen too often
19:46 paul_: but as much as practical, patches should be tested as they come in
19:47 and not wait for initial testing until beta
19:47 nicomo gmcharlt ++
19:47 paul_ ok, I put my idea back in my bag
19:47 kados that way we'll avoid the problem with 3.0 where we discovered 6 months of bugfixing before we could release
19:47 even when 'feature complete'
19:47 gmcharlt for this to work, implies that patches (and patch series) should be reasonably self-contained
19:48 kados *nod*
19:48 acmoore since there is no immediate candidate, perhaps one way to help distribute this load would be to have the RM not accept any patches that haven't been signed off by someone else. Then, those of us who read patches@ would have to test and signoff things before they get added.
19:48 gmcharlt acmoore: I'm willing to go with that as a general rule
19:49 but reserve right to exercise discretion in order to fix breakage
19:49 paul_ acmoore: what would be the workflow then ?
19:49 when a patch is submitted to patches@, someone test it & resend it to patches@ ?
19:49 bye kados
19:49 have a good flight
19:49 kados but I agree with acmoore's proposal, and generally with whatever y'all come up with ;-)
19:49 cheers
19:49 mc cya kados
19:49 acmoore paul_: I'm not sure, but something like: mail your patches to the patches list as always. And, if there are unsigned ones there that you know somethinga bout, apply them to try them out and signoff on them.
19:50 bye, kados.
19:50 paul_ unless i'm missing something "sign off" is only local, so one will have to resend it to notify he has tested the patch, right ?
19:50 hdl bye kados
19:50 acmoore paul_:  you make a good point that this will cause patches to get sent multiple times.
19:51 paul_: you're right. git allows you to "sign off" on a patch, but you have to send it again.
19:51 hdl acmoore: should there be a flag on non signedoff messages ?
19:51 ryan so we will need some kind of patch management application ?  to track patch statuses ?
19:51 slef ryan: is that what topgit does?
19:52 acmoore hdl: It's starting to look like there are holes in my idea. ;)
19:52 gmcharlt ryan: possibly - I can mock something up
19:52 and look at topgit per slef's suggestion
19:52 ryan it would be nice to be able to see all submitted patches and their statuses, why they were rejected, etc.
19:52 acmoore ryan and slef: I'd hate to introduce so much slowness in the workflow. Perhaps I've recommended a bad idea.
19:52 ryan without searching mail archives.
19:52 paul_ ryan: you're reintroducing a bit of centralization ;-)
19:53 hdl maybe :
19:53 ryan true
19:53 hdl on the wiki.
19:53 or on bugs.koha.org
19:53 gmcharlt hdl: that will easily break down if patch statuses are not tracked as automatically as possible
19:53 hdl since any patch has to be referenced to a bug.
19:53 slef bugs would seem better suited than the wiki for this, but I'm not sure quite how it would be done
19:53 gmcharlt I think this is something we have to work towards
19:54 paul_ hdl: any patch fixing a bug. patches for new features don't. am I right ?
19:54 ryan implementing something like this would be a task for the QAM :)
19:54 hdl we can have enhacement bugs.
19:55 acmoore paul_: I'd like to see every accepted patch reference a bug #, but I don't know if we're recommending policies right now or just looking for a person.
19:55 atz i know we often reference enhancement bugs when clients ask for a feature that is already being worked on.
19:55 hdl ryan: not the task of but under the responsibility of ;)
19:56 atz so what is the question before us?
19:56 ryan i don't find bugzilla to be very smooth to work with for this purpose, but would accept using it that way.  Doesn't get us any closer to deciding on a QA though
19:57 davi acmoore, That is good for a maintenance branch, but not need for a development branch
19:57 There is not 'bugs' under development but only features under development
19:57 acmoore Perhaps the situation we're in here is that neither candidates for QA role are present
19:58 gmcharlt I think we'll need to decide this one on the mailing list
19:58 acmoore davi: it is unfortunate that bugzilla calls them "bugs" instead of "issues" or "work orders" or something similar that encompasses both bugs and features.
19:58 gmcharlt so I move to postpone this decision for now and move on
19:58 acmoore second.
19:59 ryan gmcharlt: agreed
19:59 nicomo gmcharlt ++
19:59 gmcharlt ok, so moving on to Amit's agenda item regarding the 3.0 release
20:00 Amit ok
20:00 gmcharlt Amit: go ahead
20:00 Amit there is problem in koha-3 stable
20:00 with availibity issuse
20:00 i mean to say
20:00 i m telling u this is something mistake in code
20:01 i think
20:01 suppose
20:01 we have multiple branches in library
20:01 gmcharlt ok, have you reported a bug at bugs.koha.org?
20:01 Amit yes
20:01 but no solutions
20:01 davi acmoore, IMHO it is convenient or even needed to use a bug management tool for release under maintenance, but not for branch under heavy development. For branch under heavy development it is more convenient mailing list and chat channels
20:02 paul_ davi: ++
20:02 + we write RFCs on wiki.koha.org
20:02 Amit should i continue
20:02 hdl Amit : seeing your data, there is a problem on NULL homebranch and holding branch
20:02 Amit no
20:02 hdl yes.
20:02 Amit hi have check
20:02 home branch and holding branch
20:02 are not null
20:02 hdl have you checked your items table ?
20:02 Amit i have check my sql query
20:02 slef ( http://code.istique.net/?p=git-porcelains.git is git-send-bugzilla if anyone wants it)
20:03 atz i think we identified that originally, and problems persisted even after correcting it.
20:03 hdl what you showed me had obvious problems.
20:03 paul_ Amit: hdl has 4 years experience & something like 20 or 30 migrations. So you should consider he is probably right ;-)
20:03 Amit holding and home branch both show
20:03 i have already tired in debian
20:03 gmcharlt apologies, but I think this is getting off-topic for the meeting - can we defer this for now and get back to Amit's bug after we finish #5?
20:03 Amit but problem is same
20:04 default installation
20:04 and testing only two or three records
20:04 but problem remain same
20:05 u have already checked hdl this one?
20:05 gmcharlt sorry, but let's move on to #5 - discussing features planned for 3.2
20:06 atz gmcharlt: yes, i think we can address #5
20:06 Amit ok
20:06 gmcharlt RFCs are at http://wiki.koha.org/doku.php?[…]velopment:rfcs3.2
20:06 acmoore Amit: thanks.
20:06 Amit as u wish
20:06 gmcharlt there are several large projects going on
20:07 BibLibre's new acquisitions module
20:07 paul_ gmcharlt: I don't have any access to 80 port, so no wiki.koha.org for me
20:07 only 6667 works !
20:07 (my provider is probably bugguy...)
20:07 gmcharlt system groups, holdings records, and authority control work from LibLime
20:08 extending granular permissions
20:08 a number of circulation changes
20:08 and I want to thank danny for the Koha work he's planning for the Howard County library
20:09 atz yes, interesting stuff
20:09 nicomo "extending granular permissions" and "management of librarian permissions on acquisition module" are really close
20:09 acmoore It looks like quite a bit to get written before another release.
20:09 gmcharlt there are a number of possible architecture and coding practice changes that have been discussed as well
20:09 including the 'use warnings' pragma
20:09 atz I would like to see all C4/* also use Carp
20:10 if the C4 modules are reliable, then they should be pointing to errors in the callers script
20:10 acmoore atz: Carp++
20:10 gmcharlt and reviving Tumer's idea of moving the copies of item and holdings data out of bibliositems.marcxml
20:10 mc carp++
20:11 gmcharlt and emitting them only for indexing
20:11 and related to that would be switching to the DOM filter for Zebra indexing
20:12 acmoore is right, there is a lot of stuff to do
20:12 in my schedule proposal of August 11
20:12 atz it's best to have it out there anyway, even if it doesn't get completed for 3.2
20:13 gmcharlt I proposed three coding phases, each followed by a stabiliziation phase
20:13 the stabilization phases would be for bugfixing, and during them
20:13 atz the RM's job will be to prune back features that aren't ready for prime time yeet
20:13 *yet
20:13 gmcharlt acceptance of patches for new features will be slowed
20:13 that way, we can avoid pushing back the bugfixing to the end of the release cycle
20:14 my overall goal for 3.2
20:14 besides adding a bunch of cool stuff
20:14 is to make Koha more stable
20:15 atz ++
20:15 gmcharlt and imporve its modularity
20:15 so, that all being said
20:15 I request that interested parties review the RFCs on the wikis
20:15 acmoore gmcharlt: that sounds like a good way to make sure that the codebase doesn't stray too far from being stable.
20:16 gmcharlt and if there's anything particular controversial
20:16 paul_ could we say that coding guidelines MUST be used for new code, and SHOULD be used for old code modified ?
20:16 gmcharlt to start discussing them on the mailing lists
20:16 paul_: that's reasonable
20:16 paul_ gmcharlt: /me agree
20:16 atz paul_: i think so
20:16 acmoore paul_: I thnk that's reasonable if we think that the guidelindes on the wiki are current.
20:16 hdl Problem of RFcs will resied much more in implementations than on specifications imho.
20:17 gmcharlt we should start a discussion of the coding guidelines
20:17 slef gmcharlt: we're finding that 3.0.0 and portability things are enough work just now... can we revisit RFCs after 3.0.1?
20:17 paul_ I think that RFCs should have (SQL) data structure specified
20:18 ricardo slef:  Agreed  :)   (Hi everyone, BTW!)
20:18 paul_ like "I will add feature XX. This will need new table RR, new column CCC and constraint II"
20:18 acmoore paul_ I think that's reasonable and I'll try to do it with my features.
20:18 gmcharlt paul_:  in some cases, that's too soon - but I woudl agree that DB schema changes, particularly major ones, should be discussed before being officially submitted
20:19 I also encourage people to put up git trees or previews of patches of features under development
20:19 that may not be ready for formal submission yet
20:19 hdl maybe could be a good practis to propose the patches on a website.
20:19 atz in some cases, if this had been done previously, some confusion about vestigial data structures might be avoided
20:19 paul_ gmcharlt: agreed that sometimes it's too soon to give details. But the global idea should be possible, isn't it ?
20:19 hdl So that ppl can test.
20:19 gmcharlt slef: regarding review of RFCs - I think that really should be ongoing from this point on
20:19 atz gitweb is the right tool for that
20:20 hdl atz: yes.
20:20 ricardo slef: I also think your suggestion fits in the gmcharlt proposal. Koha 3.0 (like Koha 3.2) should also have a "stabilization" phase. And we now are in that stabilization phase...  Galen: aren't we?
20:20 atz 3.0 actually needs to be less stable... hasn't changed for weeks while major bugs are being patched
20:20 gmcharlt ricardo: well, in practice, most of the 3.2 patches have been stuff that can be applied to fix 3.0 problems
20:21 hdl 3.0 is beyond stable point.
20:21 gmcharlt so now that we have a RMaint, I assume 3.0.1 can be done soonish
20:21 but that's up to hdl to announce
20:21 hdl it is feature freezed.
20:21 ricardo atz: Right... But that's what I mean by "stabilization": fixing Bugs in Koha 3.0
20:21 hdl I will try to release minor versions on bimonthly base.
20:22 atz 6/year ?
20:22 gmcharlt but LL, at least, does have to get started coding 3.2 features
20:22 ricardo gmcharlt: "LL"?
20:22 hdl Is that too few ?
20:22 LibLime
20:22 gmcharlt ricardo: sorry, LibLime
20:22 ricardo hdl / gmcharlt : OK, Thanks  :)
20:22 atz hdl: just clarifying that you don't mean 2 per month
20:23 paul_ right. Bi monthly means 2 per months.
20:23 acmoore atz: I had the same question. "semimonthly"?
20:23 paul_ which is a little bit too much :D
20:23 hdl Sorry.
20:23 ricardo paul_: *nod*
20:23 nicomo_ every other month is a nice work around
20:23 ;-)
20:23 hdl 2 per month would be a nightmare with all translations and stuff.
20:23 atz the term gets used both ways... confusingly
20:24 that sounds like a good schedule
20:24 ricardo atz: Yes, that's true ("term gets used both ways")
20:24 acmoore hdl: I'm excited that you're looking to do calendar based releases, as opposed to "whenever we need one" or "whenver we're ready".
20:24 paul_ acmoore: that's what I did with 2.2
20:24 one RMaint every quarter
20:24 gmcharlt given that some 3.2 feature work will necessarily be starting now
20:24 paul_ 2.2.0 => 2.2.9
20:24 atz it should be manageable with the flow of patches towards maintenance
20:24 hdl acmoore: the fact is that features are freezed.
20:25 gmcharlt shall we name 10 October as a date for finishing internal review of the RFCs
20:25 hdl So bug fixing is more predictable.
20:25 gmcharlt we should not, however, delay this too long
20:25 acmoore gmcharlt: that sounds like a good deadline, and bring up questions on the mailing list?
20:25 hdl gmcharlt: ++
20:25 ricardo acmoore: Agreed. The problem will be to decide on what features to CUT / MOVE to the next version, when the shedules start slipping ... That's a decision for the Release Manager or for the Release Maintainer, BTW?
20:26 gmcharlt release manager
20:26 ricardo s/shedules/schedules
20:26 gmcharlt: OK. Thanks for the info
20:26 atz this has been a pretty good meeting.
20:26 gmcharlt I will propose a schedule on koha-devel
20:27 atz too bad chris cormack didn't show up...
20:27 gmcharlt targeting release of 3.2 around April/May 2009 (i.e., roughly 33 weeks after RFC review is compete)
20:27 paul_ why 33 ?
20:27 atz thanks to biblibre and slef for staying up late
20:27 paul_ yw
20:28 slef atz: it's only 2130 here.
20:28 gmcharlt paul_: roughly six months - exact number of weeks is arbitrary, of course
20:28 atz late for a workday, anyway
20:28 slef yeah, late to be working I guess
20:28 nicomo_ 10:30pm
20:28 atz slef: on a weekend no less
20:29 gmcharlt but my main goal is to not let 3.2 go much longer than 7 to 8 months at most, even if features slip
20:29 paul_ 6 months = 33 weeks ? I must go back school...
20:29 lol
20:29 ricardo paul_: Eheheh
20:29 gmcharlt I said *roughly* :)
20:29 paul_ I agree with the idea anyway
20:30 gmcharlt ok, since we've run nearly an hour and a half, I'm declaring this meeting closed
20:30 Amit ok good night
20:30 ricardo paul_: Don't you know that when a computer guy says something takes "5 minutes" he really means "half a hour"?  ;-)
20:30 Amit but i say one thing
20:30 paul_ that's what my wife always says...
20:30 atz Amit: do you have a link you want us to look at?
20:30 Amit i m not happy
20:31 right now link is not present
20:31 i will be shown on monday
20:31 links is www.openlx.in:8080
20:31 for staff page
20:31 danny thanks for the meeting everyone
20:31 nicomo_ ok have a good week-end everyone
20:31 hdl gmcharlt: thx.
20:32 brendan have a good weekend everyone - thanks
20:32 paul_ bye everybody.
20:32 i'll be unavailable most of next week.
20:33 slef dang - switched off wireless and had forgot to reconnect network cable
20:33 ricardo Amit: Just curious: up there, you said you reported a bug. What is the Bug Number?
20:34 paul_ bye slef
20:34 Amit ok
20:34 i will give u
20:34 ricardo slef: Have a nice dinner  :)
20:34 slef gmcharlt: topic
20:34 ricardo Bye paul_  :)
20:35 gmcharlt slef: thanks for reminder
20:35 Amit bug 2581
20:35 gmcharlt have a good dinner
20:36 Ruth_ thanks, all.  first experience with this and found it very informative.
20:36 ricardo http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2581
20:36 Amit yes
20:37 and 2579
20:37 with screen shots
20:37 http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2579
20:38 mc cya all
20:38 ricardo Amit: OK. Let me ask Galen a question here
20:38 Amit ok
20:38 ricardo gmcharlt: In the first Bug page that Amit told about (2581), you wrote this:
20:39 ------- Comment  #6 From Galen Charlton  2008-09-11 07:10:42  [reply] -------
20:39 I've pushed Henri's patch for this bug to 3.1 master.  However, I find it
20:39 worrisome that your database has some items where homebranch is null.
20:39 Amit no
20:39 i have already checked
20:39 ricardo gmcharlt: Is "3.1 Master" the same as HEAD now?
20:40 hdl ricardo: yes.
20:40 gmcharlt ricardo: it is
20:40 Amit home and holding branch are not null
20:40 ricardo hdl / gmcharlt: OK. Thanks. So we are still working only in one branch, right?
20:40 Amit ok give me one min
20:40 gmcharlt for most stuff
20:40 Amit i wil u show online
20:40 ricardo gmcharlt: OK. Thanks
20:40 gmcharlt hdl would be cherry-picking from head to feed patches into the 3.0.x branch
20:41 Amit if u give me permission
20:41 ricardo Amit: Sure!  :)
20:41 Amit wait
20:41 i m setting up
20:41 ricardo gmcharlt: Right. But that will only happen AFTER creating a (code) branch that has NOT yet been created. Right?
20:42 gmcharlt ricardo: no, the 3.0.x branch exists now
20:43 ricardo gmcharlt: Ah, OK... We have two heads now. I see it now at the bottom of the git web page:
20:43 "master" and "3.0.x"
20:43 paul_ ricardo: you've got it
20:43 Amit wait
20:43 i m setting with ip
20:43 paul_ except that 3.0.x has no new patch
20:43 ricardo paul_: Yeah... Although, I have to admit that I am a bit slow, eheh
20:43 paul_ (as all are pushed in master, and hdl will cherry pick to 3.0.x)
20:44 ricardo paul_: Understood. Thanks
20:45 gmcharlt: I had "followed" the regular "HEAD" in git. So, I'm guessing that I do NOT have to change anything in my git configuration to follow "master". Right?
20:46 gmcharlt richardo: correct
20:46 ricardo gmcharlt: Thanks "Galeno"  ;-)
20:47 Amit http://openlx.in/cgi-bin/koha/[…]levance&do=Search
20:47 gmcharlt heh - I deserved that ;)
20:47 Amit check this
20:47 ricardo gmcharlt: Eheh... Glad that you spotted it  ("richardo")  :)
20:47 Amit:  OK
20:48 chris sorry im so totally late, had a sick kid, who is finally happy(ish) now
20:49 ricardo Amit: OK. I have two results (BTW: I didn't know you could do a search just by "a". I thought that would be a "stop word".)
20:49 atz chris: we gave all the jobs to you.
20:49 ricardo atz: LOL!
20:49 Amit click on
20:49 book item
20:49 check bok
20:49 ricardo gmcharlt: Eheheh
20:49 Amit:  OK
20:50 Amit have u search 2 books
20:50 atz Amit: i assume your actual holdings are 2 items
20:50 ricardo Amit: I have a really slow access to that web page. Please be patient
20:50 gmcharlt chris: seriously, you've been named translation manager by acclamation
20:50 Amit ok
20:50 gmcharlt chris: if you've changed your mind, let us know
20:51 ricardo Amit: OK. "Building applications with the Linux standard base" has two copies. One in "East Library" and the other one in "West Library". Right?
20:51 Amit yes
20:51 but show
20:51 atz yeah, but the front "hits" page shows only 1
20:52 Amit only one
20:52 rhcl I only see one copy of "Building applications" at East Library.
20:53 atz rhcl: right, click to details page, see 2
20:53 ricardo atz: Got it. In the search results page the availability line for that book only reads"Availability:  Copies available:  East Library (1),"  (missing West Library)
20:53 Amit yes
20:53 this is the problem
20:53 atz that's rather odd
20:54 chris gmcharlt: cool :) nope havent changed my mind
20:54 ricardo Amit: Mason James asked you a question in that same Bug web page :
20:54 Amit yes
20:54 hdl Amit : I only see one Location column.
20:55 Amit he has
20:55 sory
20:56 atz gmcharlt: does the hits page draw from zebra index?
20:56 ricardo Amit: Where?
20:56 atz (for availability info)
20:56 Amit yes
20:56 ricardo Sorry
20:56 Amit mason james say
20:56 his koha is work fine
20:56 there is no bug
20:56 but in my koha
20:57 not shown branches
20:57 chris looks like a very good meeting
20:57 Amit only one
20:57 others are not shown
20:57 ricardo Amit: No. That's not what I meant. He asked you to (1) rebuild zebra-indexes  and (2) see the output of a SQL command
20:57 select holdingbranch , homebranch from items where biblionumber = 1;
20:57 Amit i have already done
20:57 ok
20:58 gmcharlt atz: yes
20:58 Amit +---------------+------------+
20:58 | holdingbranch | homebranch |
20:58 +---------------+------------+
20:58 | EL            | EL         |
20:58 | WL            | WL         |
20:58 +---------------+------------+
20:58 2 rows in set (0.00 sec)
20:58 output is this
20:58 ---------------+------------+
20:58 | holdingbranch | homebranch |
20:58 +---------------+------------+
20:58 | EL            | EL         |
20:58 | WL            | WL         |
20:58 +---------------+------------+
20:58 2 rows in set (0.00 sec)
20:58 this is after rebuilding the zebra
20:58 ricardo Amit: OK. Thanks. And you have also rebuilt zebra indexes, right? What command did you use?
20:59 Amit for rebulding
20:59 ricardo Amit: Yes, for rebuilding.
20:59 Amit [root@localhost migration_tools]# ./rebuild_zebra.pl -b -r -a    
21:00 ricardo Amit: OK. Thanks (I'm afraid I can't check the usage for that right now. I have to start a Virtual Machine for that)
21:01 Amit ok
21:01 what do u think
21:01 problem in  Search.pm
21:01 module
21:01 this is my thinking
21:01 atz Amit: i think this is only a problem with the index
21:02 Amit u mean tosay
21:02 zebra
21:05 atz what output did you get from rebuild_zebra.pl ?
21:10 Amit 02:29:13-13/09 zebraidx(4129) [log] add grs.marcxml.record /tmp/ZPFvk3XrS6/biblio/exported_records 0
21:14 02:29:13-13/09 zebraidx(4129) [log] key_block_create t=1
21:14 02:29:13-13/09 zebraidx(4129) [log] add grs.marcxml.record /tmp/ZPFvk3XrS6/biblio/exported_records 1299
21:14 02:29:13-13/09 zebraidx(4129) [log] sorting section 1
21:14 02:29:13-13/09 zebraidx(4129) [log] writing section 1
21:14 02:29:13-13/09 zebraidx(4129) [log] finished section 1
21:14 02:29:14-13/09 zebraidx(4129) [log] Iterations          3538
21:14 02:29:14-13/09 zebraidx(4129) [log] Distinct words       800
21:14 02:29:14-13/09 zebraidx(4129) [log] Updates                0
21:14 02:29:14-13/09 zebraidx(4129) [log] Deletions              0
21:14 02:29:14-13/09 zebraidx(4129) [log] Insertions           800
21:14 02:29:14-13/09 zebraidx(4129) [log] key_block_create t=1
21:14 02:29:14-13/09 zebraidx(4129) [log] Records: 2 i/u/d 2/0/0
21:14 02:29:14-13/09 zebraidx(4129) [log] zebra_stop: 0.52 0.07 0.01
21:14 02:29:14-13/09 zebraidx(4132) [log] zebra_start 2.0.8 /etc/koha/zebradb/zebra-biblios.cfg
21:14 02:29:14-13/09 zebraidx(4132) [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-regx.so
21:14 02:29:14-13/09 zebraidx(4132) [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-alvis.so
21:14 02:29:14-13/09 zebraidx(4132) [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-safari.so
21:14 02:29:14-13/09 zebraidx(4132) [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-text.so
21:14 02:29:14-13/09 zebraidx(4132) [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-marc.so
21:14 02:29:14-13/09 zebraidx(4132) [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-xml.so
21:14 02:29:14-13/09 zebraidx(4132) [log] enabling shadow spec=/var/lib/koha/zebradb/biblios/shadow:4G
21:14 02:29:14-13/09 zebraidx(4132) [log] cache_fname = /var/lib/koha/zebradb/biblios/shadow/cache
21:14 02:29:14-13/09 zebraidx(4132) [log] zebra_stop: 0.32 0.00 0.00
21:15 ====================
21:15 CLEANING
21:15 ====================
21:15 this is the output
21:27 ricardo Amit: I have to admit that I can't help you much. That output looks correct, but I don't use Zebra myself. I tried to use Zebra in an early Beta version of Koha, but had some problems and disabled Zebra. That also ended up having some problems, but I was able to work around them, with some useful info from Paul Poulain and Galen Charlton. Next step would probably be to debug the code. Maybe...
21:27 ...a grep for "Copies available" is a good start?  :-/
21:28 Amit ok
21:28 i m right
21:28 ok thanx
21:29 one thing more
21:29 in beta version
21:29 ricardo Amit: You're welcome.
21:29 Amit it would work fine
21:29 this is problem in case of stable version of koha
21:33 ricardo Amit: Are you now using the latest DEVELOPMENT version (available from "git")?
21:34 Amit yes
21:34 last one form hdl
21:34 ricardo Amit: Right. OK
21:34 Amit in my debian
21:34 box
21:34 and in another machine
21:34 but problem remain same
21:36 ricardo Amit: Right  :(
21:36 Amit ok
21:36 but i seen howard library catalog
21:36 it work fine
21:36 show all branches
21:36 in availibility
21:37 atz gmcharlt:  Amit's version of zebra is 2.0.8.  Any idea if anything significant has changed between that and 2.0.22 ?
21:37 gmcharlt atz: there've been a number of bugfixes between those versions
21:38 hdl availability is taken out of record.
21:38 but the record whos fine in yaz-client.
21:38 shows.
21:39 It is really odd noone else has this problem.
21:43 atz error from log is:
21:43 [Sat Sep 13 03:01:42 2008] [error] [client 210.211.166.62] [Sat Sep 13 03:01:42 2008] opac-search.pl: PARAM:LOOP:next_loop:hash pointer was expected but not fou
21:43 nd at /usr/lib/perl5/site_perl/5.8​.8/i386-linux-thread-multi/HTML/Template/Pro.pm line 191., referer: http://openlx.in/cgi-bin/koha/opac-search.pl
22:13 ricardo atz / hdl / gmcharlt: What would be a good way for Amit to try to debug code in opac-search.pl / Search.pm ?
22:15 gmcharlt ricardo: good old fashioned warn statements and examine apache log
22:15 or reproduce call to the C4::Search APIs in a little command-line script and step through with Perl debugger
22:15 Amit yes
22:16 i m comfortable on perl debugging
22:16 ricardo gmcharlt: OK, thanks
22:16 Amit thanx
22:19 ricardo gmcharlt: Changing a bit subject, I have noticed a Bug Report from Beverly Church from LibLime:
22:19 Bug 2599 - Search limits not working
22:20 http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2599
22:20 Is this a follow-up to a Beda's post (searching URL...)
22:20 atz ricardo: yeah, for a while they didn't display.  display is now fixed.  but they don't work.
22:20 item type adv. search
22:20 ricardo atz: Are they buggy in 3.0 Final or just in some development version after 3.0 Final?
22:21 atz ricardo: not sure.  
22:21 ricardo atz: OK, thanks
22:23 There's the post from Beda Skuzics:
22:23 Limits are killing the search
22:23 http://www.nabble.com/Limits-a[…]h-tc19336170.html
22:24 atz same idea
22:24 ricardo atz: OK. Independently discovered by both of them, I assume
22:24 atz yes, in the past week or so
22:25 ricardo atz: Do you know if the problem and solution is applicable to both MARC21 / UNIMARC and Zebra / NoZebra ("gotta" love all those possible combinations for testing / debugging  ;-)
22:26 atz: Ah... Sorry. There's NO solution yet, right?
22:26 atz would only affect zebra
22:26 afaict
22:27 ricardo atz: OK, thanks for the info. I think I have the same problem with a NoZebra installation, but I still have to test it in other machine, to be more sure
01:10 Bye people!  :)
03:10 greg Hello all, I am running into an issue installing koha
03:11 I did the Makefile.PL && make && sudo make install
03:11 and everything came out great, yet I did not get the databases created.  

← Previous day | Today | Next day → | Search | Index

koha1