18:00:21 #startmeeting 18:00:21 Meeting started Wed Sep 7 18:00:21 2011 UTC. The chair is Brooke. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:29 Hi, just testing...first time...Washoe County Library, Reno 18:00:32 Howdy, Welcome 18:00:41 feel free to introduce yerselves with #info 18:00:42 Hi Brooke 18:00:49 #info Liz Rea, NEKLS 18:00:52 #info MJ Ray, software.coop 18:00:55 #info Marcel de Rooy, Rijksmuseum, Netherlands 18:01:09 #info Daniel Grobani, Samuel Merritt University 18:01:10 #info Chris Nighswonger, FBC, 3.4 Release Maintainer 18:01:12 #info Elliott Davis, University of Texas at Tyler 18:01:15 #info Jane Wagner, PTFS/LibLime 18:01:19 #info Thatcher Rea, ByWater Solutions 18:01:24 #info Nicole C. Engard, ByWater Solutions 18:01:28 #info Ian Walls, ByWater Solutions, 3.6 Quality Assurance Manager 18:01:32 #info Colin Campbell, PTFS-Europe 18:01:40 #info Greg Lawson (May have to step out shortly) 18:01:52 #info Mahangu Weerasinghe, Sri Lanka 18:02:11 #info David Schuster, Plano ISD, Texas 18:02:11 #info Mason James, KohaAloha NZ 18:02:18 rhcl: happens to us all 18:02:19 #info Katrin Fischer, BSZ 18:03:12 Haere Mai, let's get started :D 18:03:13 #info Owen Leonard, Nelsonville Public Library 18:03:27 Roadmap to 3.4 Chris :) 18:03:33 ok 18:03:38 * slef hands Brooke a #topic 18:03:39 hi nancyk! 18:03:47 everything is on track for the release of 3.4.5 on the 22nd of this month 18:03:58 #topic 3.4 Roadmap 18:04:25 plans are to continue releases on a monthly basis as long as work is being done which applies to the 3.4.x branch 18:04:33 outstanding 18:04:35 once things slow down 18:04:43 we'll announce EOL 18:04:50 and take a vote at the nearest meeting 18:05:13 a bunch of work has been pushed for 3.4.5 18:05:32 and thats it for me 18:05:41 chris_n++ 18:05:44 okie dokie, any questions for Chris? 18:06:03 #info a bunch of work pushed for 3.4.5, on track to release 22nd, plans to continue monthly until things slow down 18:06:36 #info Frédéric Demians, Tamil 18:06:37 any blockers or critical bugs chris_n? 18:07:09 slef: one moment 18:08:36 hello, sorry to be a little bit late. 18:08:39 according to BZ there are 12 18:08:44 you may see them here: http://tinyurl.com/3m9qbpb 18:08:55 seven are marked patch-submitted 18:09:07 #link http://tinyurl.com/3m9qbpb 18:09:15 (changing my internet provider at home... just today...) 18:09:18 patch-sent rather 18:09:45 it looks like some have failed QA 18:10:04 #info Paul Poulain, BibLibre, sorry to be a little bit late 18:10:10 just recreated my table 18:10:12 #link http://s.coop/koha34status 18:10:52 some look like they should be closed, but have not been 18:10:57 bug 6292 is critical, needs signoff - anyone want to do it? 18:10:57 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6292 critical, PATCH-Sent, ---, chris, ASSIGNED , Overdue notices have a bug when multiple overdues exist 18:11:16 1 blocker, 1 critical, 4 major are Failed QA 18:11:18 #help bug 6292 18:11:21 movin' on 18:11:22 54 bugs awaiting QA (no blockers, no critical, 5 major). 81 bugs needing signoff (no blockers, 3 critical, 8 major) 18:11:28 we can get this stuff asynchronously 18:11:46 slef: ther eis an open question for the follow up 18:11:50 yeah, OK. Eyeballs are good but we're being too slow 18:12:01 slef: i signed off the first patch, but not sure how to reproduce the problem for the secon dpatch 18:12:25 cait: ok, later 18:12:34 #topic Roadmap to 3.6 18:12:45 * slef gets out of the way before Brooke runs him over 18:12:57 bug 5995 has been back ported to both 3.2.x and 3.4.x btw 18:12:57 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5995 blocker, PATCH-Sent, ---, matthias.meusburger, ASSIGNED , Glitch with checkauth 18:13:00 anyone not named Paul wanna do the update on 3.6 so Paul can ask questions. 18:13:01 it probably can be closed 18:13:16 Brooke: I think I can speak a bit to 3.6 18:13:36 * slef holds 3.6 down for sekjal to give it a damn good talking to 18:13:36 hooray 18:13:41 Ian's got the floor 18:14:10 as mentioned a few lines early, we're at approximately 50 patches needing QA, and around 80 needing signoff 18:14:28 patches have been progressing through the process slowly but continuously 18:14:52 and many "don't apply" or "failed QA" anymore (and that's a pity if it fixed a bug) 18:14:54 major developments that are nearing fruition include Hourly Loans and the Holds Rewrite 18:14:55 #info 50 patches need QA, and around 80 needing signoff, get to gettin'. 18:15:23 hourly loans were one of Paul's questions, wanna go into gorey blow by blow detail? 18:15:31 so far, we have only had to revert one commit 18:15:35 bug 5549 18:15:35 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5549 enhancement, PATCH-Sent, ---, ian.walls, ASSIGNED , Hourly Loans 18:15:58 This development has been signed off by libsysguy, who I believe is using the branch in production 18:16:04 yes we are 18:16:04 #info 55 patches are "failed QA" and 44 are "does not apply" 18:16:25 so hourly loans are now onto the QA stage 18:16:35 What is the main reason for failed or does not apply? 18:16:50 it totally depends on the patch 18:16:52 There's no main reason 18:16:58 if the patch doesn't fix the problem it fails 18:16:59 schuster: I think the main reason for does not apply is "does not apply anymore" 18:17:07 given that this is a MAJOR change to many core modules, testing needs to be thorough and painstaking, lest we break library circulation 18:17:09 and what paul_p said about the other :) 18:17:31 (dna anymore because other patches have been pushed and a rebase is needed) 18:17:46 I will fail a patch in QA if it does not do what it proports to do, if it introduces other bugs or issues, or if it violates style guidelines 18:18:06 from my experience, sometimes (maybe 60% of the time), it's easy to rebase. Sometimes (30%) it's tricky, and 10% it's hard (patch must be rewritten) 18:18:17 ^^ 18:18:37 patches from before the Template::Toolkit conversion in 3.4 are especially lengthy to rebase, as any interface changes must be redone in the new language 18:18:50 (I mean "does not apply". Rough number given by "my feeling @", a trademark from me ;) ) 18:18:56 Thanks paul_p for the descriptive reasoning.. I have been busy with other things for a couple of months and didn't know if it was mainly Template Toolkit type stuff or just bad rebase. 18:19:16 theu number of T::T issues is decreasing. 18:19:42 there are still some (i made one today. patch not sent yet) 18:19:47 #info Thomas Dukleth, Agogme, New York City [with a disembodied connection] 18:20:36 I wanted to ask : should we do something with "Failed QA" or "Does Not Apply" patches that seems "abandonned" by their original author ? 18:20:50 I feel the answer should be different for bugfixes and for enhancements 18:21:07 if the bug still remains someone else can work on it I would think 18:21:12 bugfixes = keep them open, if the bug is still here, it's usefull 18:21:23 mebbe use superceded 18:21:27 enhancements = close them after a toBeDefined time maybe 18:21:33 A small reminder: signer-offers please read the patch and make sure it doesn't introduce new bugs or include unrelated junk. 18:21:35 for things that no longer apply 18:21:36 superceded ? 18:21:39 I agree with that proposal paul_p 18:22:00 paul_p: in debian, the QA team would ask for people to take them over I think 18:22:17 we could assign these enhancements a different Closed status for easy retrieval 18:22:39 unfortunately, if no one is willing to take up a bug fix, we won't get very far by assigning it 18:22:50 sekjal: I like that idea 18:22:52 yep if it's divided into superceded for bugs that don't apply and abandoned for enhancements with no owner, might be clearer. Mebbe no. 18:23:00 then again, if no one is willing to take up a bug fix, it must not be very bad 18:23:23 you're probably right sekjal 18:23:36 or a feature not a lot of people use 18:24:04 or a bug that happens only in a rare situation 18:24:30 (like : you're a french library, using unimarc, printing your itemcallnumber labels, on a A3 printer) 18:24:32 #idea handle mouldy enhancements differently than mouldy bugs 18:25:02 perhps we should add the pending deadlines to the log? 18:25:24 can we programme Huginn to nag about dusty bugs? 18:25:36 like on GBSD? 18:25:49 he already nags abou tneeds sign-off 18:25:50 who contacts the original author in order to get possible reply? 18:26:03 I think don#t make it too much bot messages 18:26:18 we can set up Bugzilla to use Bug Whining to send emails out on a regular basis, with a list of bug reports meeting whatever saved search we like 18:26:19 Right, it's the author of the submitted patch who needs the reminder 18:27:22 Brooke, from Hugin side, probably. The question is also = what can bugzilla provide ? 18:27:35 ultimately, it's not hard to find dusty bugs if any dev has time, is it? 18:27:38 if anyone has a link about bz webservices,... 18:28:21 slef: Yeah, people can find stuff to do if they want to look for it. Most already have plenty to work on. 18:28:24 http://www.bugzilla.org/docs/3.2/en/html/api/Bugzilla/WebService.html maybe 18:29:10 I get the sinking feeling this is a big procedure question and is like to be revisited. Anyone else think so? 18:29:39 I feel we have been here before too... 18:29:44 i think so too 18:30:31 well, we will keep working on our slow hunches, and if anyone has any bril ideas, start a wiki page, write em down, and flag stuff on the next agenda 18:30:33 that said 18:30:42 bug 6537 18:30:42 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6537 enhancement, PATCH-Sent, ---, magnus, ASSIGNED , Simplified sysprefs for the web installer 18:30:52 go Paul :) 18:31:26 would anyone care to provide a bit of amplification on the holds rewrite if this is an appropriate time 18:31:44 i thnk there is a detailed rfc on the wiki ... 18:31:55 the patch for 6537 has been pushed. It means the syspref system will be simplified a lot for translators. 18:32:20 magnuse++ 18:32:37 rhcl: the Holds Rewrite is currently in the testing phase. ByWater Solutions is bringing up a test server to allow the sponsors to test the coded features against their own, familiar data 18:32:48 Since 3.4, the description is now stored in the template scope, no more in the SQL database. It means we don't need anymore to have a syspref.sql file defined for each language 18:33:00 will be simplified for developers 18:33:14 I'd like to open that to the community in general, once we can figure out the privacy issues to the libraries' satisfaction 18:33:20 not having to edit a lot of sql files any longer, but only add new sysprefs to the en file 18:33:32 thanks to magnus, we now have only one syspref.sql file, shared by all languages. located at (searching) 18:33:39 sekjal: privacy issues? 18:33:40 privacy issues are taken very seriously around here - some libraries even refuse to use google books - because it asks google every time 18:33:55 oleonard: patron data 18:34:11 slef: blo/cri 3.4.x bugs now number 4... http://tinyurl.com/3m9qbpb 18:34:23 chris_n: ta 18:34:30 the current test data will be taken from the sponsoring libraries systems, and would need to be anonymized before letting other folks have access for testing 18:34:36 ^^ 18:34:49 well, anonymized, or just wiped completely and reloaded with demo data 18:35:21 * chris_n has whined for large, clean sets of demo data for years :-) 18:35:37 the syspref file is now in misc/data/mysql/syspref.sql. If a specific syspref setup must be defined for a given language (like unimarc for frenchies), you still can have a fr/syspref.sql, that contains only UPDATE 18:36:06 what is nice with this is that it will help translators, but also help having the same syspref loaded for everybody 18:36:24 (previously, there was sometimes bugs because a syspref was not in the fr/syspref.sql file) 18:36:33 I hope i've been clear... 18:36:58 sekjal: just remember that real anonymisation is a myth because behaviour can be identifying.. 18:37:01 lessbugs++ 18:37:26 paul_p: only one small thing 18:37:33 it doesn#t change anything for translators 18:37:43 only for developers - but this is a very good change 18:37:52 cait, you're right 18:38:14 it is a simplification; less rebasing needed 18:38:42 yep, and less conflicts, and more fun ;-) 18:38:48 thd: there are ways to scramble behavior, too, but we'll get all that solved in the near future. 18:38:50 morefun++ 18:38:57 magnuse++ :) 18:39:04 magnuse++ 18:39:07 definetly ! 18:39:11 magnus++++! 18:39:11 magnuse++ 18:39:23 just remember, beer > ++ 18:39:37 #topic Roles for 3.8 18:39:50 well, i promize to pay a beer during next hackfest in Marseille ;-) 18:40:14 about my other question (Koha namespace), i saw someone added a link on the wiki, i haven't read it yet 18:40:28 #info beer > ++ 18:40:45 only if you like bear 18:40:49 um beer 18:41:12 * nengard is scared to admit that she does not like beer at all 18:41:15 ick 18:41:20 cait, but you're german, so you like beer ! 18:41:25 paul_p: that link is to a message I sent out to the koha-devel list just after KohaCon '10 18:41:30 nengard: wine? 18:41:31 wine is probably not usually the best for programming :) 18:41:33 (find beer replace chocolate) 18:41:35 (well, at least, that's what the world think ;-) ) 18:41:39 wahanui: beer? 18:41:40 beer is proof that god loves us and wants us to be happy. 18:41:51 slef if i have to choose between the two ... but usually just fruity girly mixed drinks for me 18:41:56 arright 18:42:00 paul_p: I don't! 18:42:01 back to work you 18:42:09 Roles for 3.8 folks 18:42:19 for Top Sucker I've Paul Poulain 18:42:19 it's like for me : all frenchies like escargots. I don't ;-) 18:42:22 aka RM 18:42:43 Top Sucker... not sure I'll like this name ;-) 18:42:48 hehe 18:42:58 #link http://wiki.koha-community.org/wiki/Roles_for_3.8 18:43:46 no one else for that 18:43:49 I want to be clear that this is only for 3.8, not 4.0 too. 18:43:50 any discussion? 18:44:05 thanks nengard & sekjal for adding you as doc & qa 18:44:06 i like his proposal; will be hard to realize probably, but we probably need more concensus on changing procedures? 18:44:07 I agree with slef. 18:44:08 Is paul_p willing to stand for reappointment next time? 18:44:14 I have some discussion about paul_p's proposal I'd like to bring up 18:44:25 discuss away 18:44:44 slef, my proposal is for both 3.8 and 4.0, as I think both must be started at the same time, as 4.0 is a "long term" change in my mind 18:44:51 I agree that we need to start thinking past the next timed release cycle 18:45:14 but I disagree that Koha 4.0 should be time-released for 12 months after 3.6 18:45:26 sekjal, why ? 18:45:29 I would counterpropose this: 18:45:53 continue the 3.X release cycle on a timed basis 18:45:59 3.8 to 3.10 to 3.12, etc 18:46:03 every 6 months 18:46:19 meanwhile, starting early in the 3.8 release cycle 18:46:20 what would be in 3.10, 3.12,... ? 18:46:36 do you mean we would have 2 versions at the same time ? 18:46:50 (I think he's still talking) 18:46:56 ^ 18:46:58 the community would get together and enumerate the features that would define Koha 4.0 18:47:08 let's answer one question after the other or this will all get very confusing in here 18:47:38 these would be features that would be things we could reasonably expect to complete in the next year or two 18:48:14 every 6 months, the features that are well tested and ready for inclusion could be released as part of the 3.X release cycle 18:48:17 as we do with master currently 18:48:19 #idea long term development goals coupled with short term release cycles 18:48:52 we would continue on 3.X until all the features are developed for 4.0 18:48:58 (Don't quite like the way that's phrased, so feel free to edit it. Just want to highlight the meat of this.) 18:49:33 and rebase those on current master for 4.0? 18:50:08 cait: features would all be on topic branches, based on master 18:50:18 cait, I think you rise a good & major point 18:50:20 and would need to be rebased frequently 18:50:27 sekjal: I suspect the actual development process depends more on what actually happens than any real overarching plan. 18:50:31 sekjal: ok, thx 18:50:41 sekjal, except that if 4.0 include major structural changes, it will quickly be a pain 18:51:06 for example : the solR work changes everything in searching. 18:51:09 New commit(s) needsignoff: [Bug 6854] import_borrowers.pl : Double password encryption on member update if there is no password in the csv and no default password value. 18:51:13 paul_p: my hope is that in the stages where we identify the features for 4.0, we also identify the underlying structural changes common to all those features 18:51:34 so the 'plumbing' changes can be done first, thus laying the groundwork for all the porcelain 18:51:55 IMHO label 4.0 is stritly connect with Solr. That is a big change. it is enough to change number 18:52:06 tajoli++ 18:52:09 sekjal: this sounds happy for interface design. Am I off? 18:52:14 but I plan to do more ! 18:52:31 well, I don't say "impossible", but I think it must be evaluated very carefully. 18:52:38 And Solr is for international support bugsù 18:52:40 Brooke: ? 18:52:42 I believe that Solr support is just one of the features that should be part of Koha 4.0 18:52:49 the move to Koha name space, solR, ... 18:52:55 I like sekjal's proposal 18:53:07 I am woried about having 2 branches, they will diverge pretty fast and be hard to bring together 18:53:20 afraid so too 18:53:20 I would also like to see: arbitrary metadata formats, revist patron data structure, mobile templates 18:53:23 sekjal, suppose library A sponsor a feature, he will want it "asap". So on 3.x . you'll have to "rewrite" it for 4.0. 18:53:29 and that will be a pain. 18:53:33 tying a bunch of features to a magic number like 4.0 doesent necessarily work 18:53:35 oleonard: if you're planning things out, usage consideration is part of that and might declutter some menus and such 18:53:35 better bring it all together at one point in time 18:53:45 In fact Zebra is well for english data, not for a user of mine with greeck + arabic+armenian+ slavic 18:53:46 we (biblibre) face this problem already for H:T:P and T:T 18:53:46 and from the same base 18:54:09 paul_p: library A needs to understand that just because they sponsor a change doesn't mean it will get into Koha on their schedule 18:54:21 it must meet the community's guidelines and procedures 18:54:23 which could take longer 18:54:24 sekjal++ 18:54:26 ^^ a very good point 18:54:31 sekjal, maybe in US you can explain, but in france, you can't ! 18:54:53 in France, the RFP always says "i want this and that, and at this date" 18:54:59 sekjal: I think you mean the community's quality control. 18:55:02 tajoli: we have pretty good experience with hebrew and german 18:55:13 that's why we develop on stable, then port on master 18:55:43 The problem is the mix of many alphabeths 18:55:58 (once a library has adopted Koha it's usually different , fortunatly) 18:56:22 In fact Zebra support every alphabeth, but all in the same time !! 18:56:23 I don't feel that I have enough data on the wiki to vote for paul_p for 4.0 and I will not vote for manifesto-free candidates on principle. I'm concerned that Solr's larger server requirements don't compromise our happy Zebra users. 18:56:50 tajoli: I can only tell from my experience, hebrew and roman letters work well for us 18:57:03 ...so all this talk of "Solr changes everything in searching" is a bit scary. 18:57:04 okay 18:57:23 Sekjal: said your peace? 18:57:27 sekjal, what we say is "well, you get the feature X at the expected date, but we can't guarantee when it will be integrated in official Koha. So you may have to wait, or, even, have to abandon your feature. Or stay with your fork" 18:57:28 slef++ 18:57:33 Clerly not. The big work is to do is to add Zebra in parallel 18:58:07 slef, have you seen my mail on koha-devel about the work some ppl are doing to have zebra reintegrated ? 18:58:08 paul_p: your company can certainly make the contractual arrangements to have a feature on their server by X date 18:58:38 and then, yes, they would need to be aware that they'll either need to be on a fork for while, or possibly lose the feature if it never gets accepted 18:58:40 (s/can/must ;-) ) 18:58:42 paul_p: maybe not. I'm struggling to follow the lists recently. Got message-id? 18:58:44 Now Biblire has done a new API search on Solr. What we need to do is to develop the same API on Zebra 18:59:13 The feature are over the API 18:59:31 slef: our work on solr change a lot the internals of searching. tajoli & some others have started reintegrated zebra through this new API 18:59:52 the API is expected to be flexible enough to let us add other search engines later 18:59:53 the one thing everyone agrees on is that the new Koha::Search code works with both solr and zebra 18:59:58 Brooke: I believe I have presented my proposal in it's entirety. I welcome any further feedback or requests for clarification 19:00:27 slef = Message-ID: <4E5E3F88.1070508@biblibre.com> 19:00:27 if you could go through the log, pick out what you've said, and post it, that'd be fab. 19:00:36 cause there's a lot of side talk going on here 19:00:52 any further commentary? 19:01:08 slef, does it answer your concern ? 19:01:28 (well, if you need more clarification, ask on koha-devel or the way you want) 19:01:45 Not in the way you want. It sounds backwards. So the API has been designed for Solr and Zebra is being tacked on as an afterthought? I don't see why what works is being treated as second-class citizen. 19:02:42 slef, nope, you misunderstand = we've redesigned the search API to have it modular. And we made the solR stuff (because it was sponsored), tajoli has started the zebra stuff 19:02:49 reading that message to see if I've misunderstood it 19:03:09 tajoli++ 19:03:22 yep, definetly. 19:03:26 tajoli++ 19:03:35 ok, well, we wait and see... this vote should still be for 3.8 not 4.0 IMO 19:03:40 tcohen++ 19:03:45 It is for 3.8 19:03:50 I never said it was for 4.0 19:03:54 you clarified 19:03:58 the horse has been beaten 19:04:02 and beaten once more 19:04:07 I do not want to go for three. 19:04:17 well... but I plan to start 4.0 in nov (at least discussions about it) too. 19:04:22 Brooke: I think it has to be clarified because Paul's proposal is for both 19:04:25 so, my application is for both versions. 19:04:35 I realise, but I'm sayin vote on one release at a time 19:04:37 yep, I confirm it is. 19:04:41 cause our tiny brains can't handle it. 19:05:15 yeah and I had no answer to the direct question: Is paul_p willing to stand for reappointment next time? 19:05:15 Brooke: I think we have to figure this out first before we can vote 19:05:36 slef: I think that'd clear things up. 19:05:40 Brooke, the problem here is that either I don't start 4.0 because i've not been elected or I start anyway hoping everybody will thank me at the end. 19:05:54 I prefer saying things now. 19:07:04 Do we need an RM for 4.0 to start talking about what 4.0 is going to be? 19:07:11 can't we just brainstorm without an RM? 19:07:20 nengard++ 19:07:49 i understand that he wants to run in parallel 19:07:54 I feel that anything major enough to warrant a full version number jump is major enough to need as much community input as possible 19:08:11 paul_p: or you could start laying the ground as part of 3.8 and accept that maybe someone else will finish 4.0 or restart it. OK? 19:08:13 yep. brainstorm for, say, 2 months, then start works. And do works in // 19:08:17 and i think this is something we have to talk about 19:08:22 it really worries me about Paul's proposal 19:08:31 I like Ian's proposal better 19:08:32 i'm not following everything we're talking about - but am i right in my understanding that we'd be working on 4.0 and 3.8 at the same time ... essentially creating forks of our own? 19:08:41 I have a hard enough time testing patches for one version at a time 19:09:02 nengard: agreed - and maintenance for 3.4 19:09:19 right! 19:09:24 and why 3.0 why not 3.10? 19:09:25 just too much to maintain for our small group 19:09:38 ColinC you mean 4.0? 19:09:42 yes 19:09:51 nengard, good point. and sekjal suggestion to have 3.10 / 3.12 ... while workin on 4.0 also has this kind of problem 19:09:51 i think we don't need to commit to a 4.0 release in 12 months, too 19:10:19 ... koha 4.0 should be released when its done 19:10:28 paul_p: with ian's proposal we would not have diverging branches 19:10:33 ++mtj 19:10:37 mtj++ 19:10:44 my proposal would have 3 main branches at once: 3.4.x, 3.6.x and master. this would change to 3.6.x, 3.8.x and master when 3.4 is EOLed 19:10:45 ColinC, we use to change the 1st number when there is a major structural change 1=>2 = MARC 2=>3 = zebra 19:11:18 3 > 4 gamification! 19:11:25 I think we can agree to change to 4.0 once we have rewrote the search api for zebra and solr 19:11:28 * Brooke throws up the horns! 19:11:30 the question is how to make that happen 19:11:35 sekjal, it's also my proposal. So I don't understand where our propositions differ ? 19:11:51 paul_p: I do not agree with the 1 year timeline for 4.0 19:11:58 paul you said you'd start 4.0 in november ... that's one month after we start 3.8 19:12:08 but we arn't tied to that ... numbers are marketing making things dependent on a magic number holds things up 19:12:09 so here's what I'm gonna say 19:12:12 it's 3.12 19:12:14 nengard, did I said that ? 19:12:16 over here. 19:12:26 I think we table this part. 19:12:30 Paul: Where is published the new search API implement by your SolR search engine? 19:12:37 unless someone comes to summat brilliant in like 5 minutes. 19:12:42 fredericd, git.biblibre.com 19:12:50 sekjal: Do you think that one year is too short for 4.0? 19:12:53 (branch solR or something like that) 19:12:56 paulp: you did...(2:03:12 PM) paul_p: well... but I plan to start 4.0 in nov (at least discussions about it) too. 19:12:57 Brooke: s/table/postpone/ :) 19:12:58 and, consequently, I do not think that it's necessary to loosen QA procedures on the road to 4.0, since we can release features as they're truly done and stable 19:13:15 paul_p: Could it be available outside the code? 19:13:32 I was meaning discussions about what should be in 4.0 and how to reach the goal. not doing things 19:13:34 thd: I feel that, yes, 1 year may be too short. I feel we should, as a community, define what features will make 4.0 first, and then start working on them 19:13:35 paul_p ... i thought i read that ... now i'm confused so i'm going to read and stay quiet 19:13:58 fredericd, yep. And it should be in english (for instance, docs are in french) 19:14:24 so 19:14:30 #topic Translation Manager 19:14:31 sekjal: I prefer the way you put it last that we release what is ready without loosening standards 19:14:38 found it - (2:03:12 PM) paul_p: well... but I plan to start 4.0 in nov (at least discussions about it) too. 19:14:52 nengard, I was meaning discussions about what should be in 4.0 and how to reach the goal. not doing things 19:15:04 sekjal: I agree with that too 19:15:22 paul_p: are you open to discuss points from your proposal and have the community vote on them? 19:15:33 anyone have objections to Frédéric Demians? 19:15:53 i think a smooth way to integrate solr ... would be to get Koha:Search:Zebra working first on 3.x 19:15:54 i'm always open to discussions. I'm usually complaining for silence, not for discussion ;-) 19:16:26 cait, i'm always open to discussions. I'm usually complaining for silence, not for discussion ;-) 19:16:42 so you are willing to change plans eventually? 19:17:20 cait, if you convince me the plan you propose is better than mine, of course ! but if I still think my plan is better, then i'll continue to argue. 19:17:36 TIMTOWTDI ! 19:17:57 Brooke: no objections 19:18:47 paul_p: I think that you should set ambitious goals and if they are all realised then that will be great. As long as we have a reasonable procedure for the quality and not abandoning users I am all for every possible great improvement. 19:18:55 Brooke: I'm curious about the technical details of Frédéric Demians' proposal 19:19:15 fredericd++ 19:19:16 but I have no objection 19:19:29 Brooke: objections to fredericd are absent. 19:19:32 no objection 19:19:54 k 19:20:03 hearing none, I'm going to move down the slate to 19:20:03 i would be willing to assist 19:20:07 same for me. I like the idea ! (although technically, how to do it is another question, I agree) 19:20:08 sekjal: please ask about your curiosity while fredericd is here to answer 19:20:11 #topic Documentation Manager 19:20:16 sekjal: as translation manager? 19:20:24 fredericd: yep 19:20:35 fredericd, the idea to remove po from main package I think 19:20:38 chris and paul said that i was doc manager until i died .... so i promise to continue doing my job for 3.8 :) 19:20:40 As I explained on the wiki I would like to continue the task 19:20:57 The big challenge will be to succeed to extract .po files from Koha main git repository and manage them in a git submodule. 19:21:02 fredericd: yes, I'm curious about the git submodule set up you propose. I'm not sure this meeting is the most appropriate time to go into it, though 19:21:09 This will slim down git repository size 19:21:21 maybe a thread to start on koha-devel ? 19:21:28 sekjal: I can't enter into technical details yet 19:21:52 I also would like to propose a solution to allow Perl command-line scripts translation: scripts like bulkmarcimport.pl or zebraidx.pl. 19:22:04 But it must be discussed first. I'm not sure it's a necessity. 19:22:05 fredericd, not sure it will slim that much the repo size, as what has been put in is in the repo forever. even if removed from the tree 19:22:11 fredericd: Is the intent that for those who only want untranslated Koha they can avoid the larger size code base? 19:22:21 thd: yes 19:22:29 I'm going to put this out there in the big wide open 19:22:32 paul_p: you may be correct... 19:22:35 that could help having ppl sumitting patches more easily 19:22:58 ie : you can push patches on the submodule, while the RM push on koha 19:23:03 so we would need to restart a new repo? I don't know 19:23:08 I think you can shallow checkout if you want to save space. 19:23:11 meetings are getting longish, and I think that's happening from folks getting slammed at work. Pop in, talk to each other more. Should make for shorter meetings and better communication. 19:23:13 workflow for translations / workflow for Koha 19:23:19 I move that we move discussion of the git submodule to the koha-devel list 19:23:25 Brooke++ 19:23:28 agreed 19:23:29 and continue with the rest of this meeting's agenda 19:23:43 also 19:23:46 the agenda is a wiki 19:23:53 so if you think of summat, post it 19:24:04 and if I don't honour it sufficiently, bring it up again next meeting :) 19:24:30 any objections to Nengard being Documentation Manager for Life? (or at least 3.8?) 19:24:35 LOL 19:24:39 no objection 19:24:43 no 19:24:46 nengard++ 19:24:48 no objection 19:25:02 +1 19:25:06 nengard++ 19:25:09 +1 19:25:10 +1 19:25:10 go go gadget nengard 19:25:19 ha ha sucker! 19:25:23 oh wait 19:25:24 nengard, claire should catch you in the next weeks to see how it is possible to split the docbook in smaller parts 19:25:25 +1 19:25:27 we're adding more ha ha 19:25:38 that would be much esier for translators to deal with smaller files 19:25:47 paul_p - i'd love a way to do that - but then links from section to section are much harder - which is why i haven't done it 19:25:47 * jcamins = Jared Camins-Esakov, C & P Bibliography Services #intro 19:25:48 Am I to assume there is also no objection to Documentation of the DB as Nengard too in 3.8? 19:26:02 regarding db documentation bug 6716 tracks my work on that 19:26:02 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6716 enhancement, PATCH-Sent, ---, nengard, ASSIGNED , Database Documentation 19:26:17 yes, hdl told us. So she's looking for a solution/suggestion/idea to that. 19:26:22 awesome!! 19:26:40 (dunno if she will find something though. Say awesome once she's found ;-) ) 19:26:46 hehe 19:26:56 I appreciate help even if it doesn't come to a positive result :) 19:27:03 not hearing any so you're saddled for DB stuff too. 19:27:11 Bug Wranglers 19:27:11 okey dokey 19:27:17 Ima go with whoever wants it gets it 19:27:22 shouldn't we be doing #info for the voting? 19:27:27 cause we don't have a finite number of slots 19:27:29 prolly 19:27:39 define the job please? 19:27:52 we are not voting today, are we? 19:27:55 nominations 19:28:00 #info Nicole C Engard is the Documentation Manager and also Documenting the DB 19:29:50 wizzy, I'm taking my play on that from Magnus: Sign off patches, close bugs, keep an eye out for duplicates, help organize 19:30:18 sorry cait, wrong word i guess 19:30:25 also linking 'depends on' and 'blocks' bugs, if possible 19:30:46 *nod* got it 19:31:09 * wizzyrea volunteers 19:31:11 nengard: not thinking voting would me a difference here :) 19:31:21 wizzyrea++ :) 19:31:45 katrin and magnus already do it, regardless of a formal role 19:31:52 ^^ 19:32:07 which is why we <3 them marcel :) 19:32:18 oh :) 19:32:19 <3? 19:32:26 it's a heart, sideways 19:32:56 #topic QA Ian Walls 19:33:00 oh I wondered why everyone was redirecting fd/3 online! 19:33:09 any objections with Ian? 19:33:24 Everybody is a bug wrangler when he work on bz... 19:34:24 Brooke: seems not 19:34:33 on a related note: Ian, do you have a problem with 2 minions instead of just one? 19:34:37 ian++ 19:34:37 no objections 19:34:40 sekjal++ 19:34:44 I'm unclear on the process going on here. I thought elections are in October. What is this? 19:34:54 Elections are in the beginning of October 19:34:58 this is nominations. 19:35:02 nominations... talking about plans and candidates I think 19:35:15 and what is involved doing the job 19:35:15 can someone object to a nomination? 19:35:16 I have no objections; as many helpers as I can get is a good thing 19:35:43 you can, but it's kind of silly. I've been putting up with it, because I think it's a good idea for a candidate to not be blindsided at an election. 19:35:53 ok, thanks 19:36:41 that said, any objections to having both Marcel and Jonathan Druart on the slate? 19:36:57 none here 19:37:07 no objection 19:37:12 no objection 19:37:23 no objection 19:37:24 #info QA manager has Ian Walls 19:37:25 agreed 19:37:44 #info Assistant QAs are slated as Marcel de Rooy and Jonathan Druart 19:38:02 #topic Mason James as Packaging Manager 19:38:23 anything? 19:38:23 anything is possible with enough development work :) 19:39:23 i have to assume here, that robin forgot to add himself for this role? 19:39:34 what does "packaging task" contain, exactly ? 19:39:34 which role? 19:39:51 packaging manager 19:39:52 debian/RH/... packages ? 19:40:05 the role of Packaging Manager 19:40:26 eythian in the house yet? 19:40:49 guess not 19:40:53 i assume its creating .deb and .rpm files from koha releases 19:41:28 ^^ 19:42:26 I'm going to assume there aren't too many folks that are interested and move back to the whole icky RM discussion, because I did say I'd go back 19:42:36 I just wanted to get a few things off the list for morale 19:42:56 #topic Back to RM 19:43:11 keeping in mind it's nominations 19:43:46 * oleonard gets his internet back 19:43:48 I think we have to have a good think about the 3.8 / 4.0 thing 19:44:06 should be discussed further on ml? 19:44:12 I also think this might be related to the numbering item that is next on the agenda 19:44:24 yes, that is a good idea 19:44:34 Brooke: yes, that agenda item has already been covered to the poster's satisfaction 19:44:36 yep, I think that too 19:45:20 keep in mind, ye of incredible procrastination capacity, that 3.8 hits on 22 October, and we've KohaCon on the horizon. 19:45:26 so 19:45:35 are we agreed that this is moved to the list temporarily? 19:46:06 ok... I'll make more effort to catch up on list 19:46:14 agreed 19:46:25 agreed 19:46:40 agred 19:47:15 #agreed further discussion of the RM slot is going to be move to the list 19:47:18 hooray 19:47:32 I will consolidate my proposal as laid out here into an email to koha-discuss and koha-devel 19:47:42 #topic Numbering for post 3.8 releases 19:49:25 no one? 19:49:26 hmmm... no one is working on kiritakikoha 19:49:43 back 19:49:49 welcome back 19:50:03 do you have a burning desire to discuss numbering post 3.8? 19:50:06 hmmm - 3.10 , and then 3.12 ?? 19:50:17 brooke scroll back 19:50:29 sekjal answered already 19:50:46 arrighty then 19:50:48 ahh, ok :) 19:50:58 #topic KohaCon2011 19:51:05 I always saw the specifics as being for the rm 19:51:11 Bear in mind that kmkale has a broken arm and is typing with the wrong hand 19:51:22 ow! 19:52:08 could link to programme here? 19:52:18 I would but im on the bus 19:52:39 I;m at dinner so similarly limited for 10mins 19:52:42 #link http://wiki.koha-community.org/wiki/Kohacon2011 19:52:44 sping. 19:52:53 kmkale around? 19:52:58 Brooke++ 19:53:03 pfft 19:53:07 that's rangi and cait for ye 19:53:37 ? 19:53:51 beautification project 19:54:00 my wki was uglay 19:54:05 anyhoo 19:54:10 get to conference 19:54:14 it will be a blast 19:54:47 there is your programme. We will probably continue to tweak that as the date draws near, but it's a nice overview. 19:55:33 any questions, please ask, and hopefully kmkale will address them if I don't know the answers 19:56:33 #topic KohaCon2012 19:56:57 we have two bids, one from Reno, NV, USA and one from Scotland, UK 19:57:21 #info Voting starts 1 October 19:57:29 now how do we manage? 19:57:44 the suggestion is that we butter up nengard and ask for her survey setup another time 19:58:37 nengard: You are being volunteered. 19:58:43 nengard:plz? :) 19:58:50 * oleonard checks the fridge for butter 19:58:51 nengard isn't here at the moment, so we can volunteer her for anything... right? 19:59:16 2 options, so I think it's a straight choice of approval or either/or voting. Anyone remember what we used last time? 19:59:16 in french we say "missing person are always wrong". So yes, we can volunteer her ;-) 19:59:34 we used voting 19:59:46 jcamins: yes, I see no objection from her. 20:00:05 jcamins, I concur. ;) 20:00:19 paul_p: yes, what sort? I forget and can't look for an hour :) 20:00:30 anyway nm 20:00:31 slef ranked votes last time 20:00:33 but in this case, shouldn't we think to a rule to avoid having KohaCon in US just 3 years after the previous KohaCon in US 20:00:45 if she doesn't read this by like next week and let us know, we'll figure out a fallback, yes? 20:01:06 stv almost 20:01:07 nengard is going to insist (understandably) that the exact wording of the questions be provided by someone else. 20:01:12 stv? 20:01:14 (not that I don't want to go to NV) 20:01:17 paul_p: don't change the rules mid-process. Even if I'd like the result, not really fair :) 20:01:33 jcamins: recycle last year's? 20:01:50 paul_p: If we exclude the US and one of two proposals is from the US then there is nothing to vote upon. 20:01:50 yep, I agree (and I agree my sentence was not correctly written) 20:02:20 rangi: ta 20:02:21 thd, let me rephrase : I think for KohaCon13 and later, we should define a rule to avoid repeated countries 20:02:23 slef: there were objections to the questions last year. 20:02:35 Paul, I tried and was shot down. 20:02:38 jcamins: got links/detail? 20:02:42 so community wins. :) 20:02:53 slef: not off the top of my head. I'm at work now. 20:02:56 jcamins: and was I one? ;) 20:03:04 well, maybe it's OK (but i'll ask all biblibrarians and french libraries to go & vote for UK ;-) ) 20:03:24 slef: yes, you were one of the people objecting, as I recall. 20:03:31 well I can't really phrase it unless nancyk wants to help me :) 20:03:42 Brooke: Was no same country in the following year shot down? 20:03:55 that wasn't. 20:03:56 paul_p: this USian will be voting for the UK, too. :) 20:04:07 having a rotating slate was. 20:04:22 In fact as Italian a prefer UK 20:04:27 I didn't phrase that right at all 20:04:29 but any how 20:04:57 #agreed Nengard will hopefully once again be our saviour and create a survey based on what we did last time. 20:05:04 paul_p: Reno is by woods and a lake but much of Nevada is an arid desert. 20:05:06 jcamins: ooh I wonder why? :) 20:05:10 and if not, someone else will figure it out in time for the first. 20:05:40 * slef looks for his memory, but has forgotten where he left it 20:05:53 slef: I think the objection was about rank voting. thd may remember, I think he was the one who answered the objection. 20:05:53 i suspect it's backed up on disk somewhere 20:06:38 we're at the two hour mark 20:06:48 #topic Global Bug Squashing Days 20:07:04 well rank voting boils down to either/or here anyway. lots are equal with only 2 choice 20:07:06 smashing success so far if ye ask me 20:07:43 http://wiki.koha-community.org/wiki/2011-09-02_Global_bug_squashing_day 20:07:57 the twitter feed was neat 20:08:01 magnuse++ 20:08:05 I favour score voting in a manner which removes motivation for false strategic voting but that is a topic for the mailing list and a different vote. 20:08:19 yep, gbsd++ 20:08:49 #link http://wiki.koha-community.org/wiki/2011-09-02_Global_bug_squashing_day 20:08:54 slef: We should encourage more bidders. 20:09:39 thd: next time... 20:09:39 i think next time is in 87 years or something... ;-) 20:09:53 rangi: some further plugging of Koha planned as part of the my ACCEPTED proposal to talk about the academy at LCA in Jan. 20:09:53 that gives us plenty of time 20:10:11 ibeardslee: awesome! 20:10:16 kohacon2098 20:10:34 As slef identified, the voting method hardly matters if there are only two candidates. 20:10:42 #topic Old Business (Actions from Last Meeting) 20:11:16 any objection to a mid month bug squash next time? thoughts on a weekend one? 20:12:01 hi magnuse 20:12:13 weekend one would be nice 20:12:18 but we have one every 2 weeks 20:12:26 #info Magnus Enger, Libriotech, Norway 20:12:38 * magnuse drops by briefly 20:12:57 slef: feel free to propose dates for gbsd! 20:13:01 #topic time and date of next meeting 20:13:02 slef, at BibLibre, we have a bug squashing session once every 2 fridays, in the morning 20:13:16 k movin' on 20:13:30 5th October 10 UTC? 20:14:27 10UTC is what we've decided = 18UTC (today) -8 20:14:52 * jcamins won't be there, but it seems fair to me. +1 20:15:00 looks ok at a glance 20:15:11 going once 20:15:14 will be in switzerland on 5th 20:15:14 +1 20:15:24 +1 20:15:30 going twice... 20:15:36 but someone else from BibLibre will be able to attend (11AM in France) 20:15:37 paul_p: oh nice 20:15:51 #agreed 5 October 10 UTC 20:15:52 meeting has already ended, but any thoughts about rmaint? 20:15:55 #endmeeting