10:00:30 <Brooke> #startmeeting
10:00:30 <huginn> Meeting started Wed Jul 18 10:00:30 2012 UTC.  The chair is Brooke. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:00:30 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:00:31 <wahanui> if there is a meeting then Brooke must want me
10:00:34 <slef> mmm lunch... not for 2h and I've no food with me :/
10:00:49 <Brooke> #introductions
10:01:06 <slef> Brooke: not #topic?
10:01:15 <Brooke> #topic introductions
10:01:16 <wahanui> #info wahanui, a bot that has become sentient
10:01:24 <oleonard> #info Owen Leonard, Athens County Public Libraries
10:01:27 <jwagner> #info Jane Wagner LibLime/PTFS
10:01:29 <Brooke> slef: half the time I get to do both ;)
10:01:30 <drojf> #info Mirko Tietgen, Language centre @ HU Berlin, Germany
10:01:35 <slef> #info MJ Ray, software.coop, mobile in England :/
10:01:36 <thd> #info Thomas Dukleth, Agogne, New York City
10:02:02 <davidnind> #info David Nind, Wellington, New Zealand
10:02:03 <mtompset> #info Mark Tompsett, SIL Asia Area, based in Philippines
10:02:10 <dpavlin> #info Dobrica Pavlinusic, Croatia
10:02:34 <eythian> #info Robin Sheat, Catalyst IT
10:03:07 <paul_p> #info paul_p Marseille, BibLibre, France, current Koha RM
10:03:11 <thd> #info Thomas Dukleth, Agogme, New York City
10:03:24 <paul_p> good (early) morning USA !
10:03:26 <thd> s/Agogne/Agogme/
10:03:28 <slef> (standing in line at the bank)
10:04:31 <Amit_Gupta> #info Amit gupta Nucsoft
10:05:17 <Brooke> #topic Announcements
10:06:01 <thd> ALA would like to announce that MARC was murdered at their executive meeting.
10:06:08 <oleonard> Agenda: http://wiki.koha-community.org/wiki/General_IRC_meeting,_18_July_2012#Agenda
10:06:24 <thd> MARC's ghost is recovering ;0
10:06:33 <Brooke> #link http://wiki.koha-community.org/wiki/General_IRC_meeting,_18_July_2012
10:06:52 <Brooke> speaking of that sort of thing...
10:07:00 <Brooke> #topic Roadmap for 3.4
10:07:05 <Brooke> Are we killing this?
10:07:38 <mtompset> I thought that was the consensus from what I read of last meetings logs.
10:07:51 <slef> who's rm? polled the list?
10:08:04 <oleonard> Did we even have a quorum last time?
10:08:11 <Brooke> don't believe it has one
10:08:24 <Brooke> #help someone poll the list about end of life for 3.4
10:08:47 <thd> Brooke, it is never necessary to formally kill a branch.  Branches like standards die their own quiet death eventually.
10:08:48 <eythian> I kinda thought that 3.4 would have dies when 3.8 came out.
10:08:52 <Brooke> we don't have a formal quorum Owen, so it's a bit hard to count if we've got one.
10:08:57 <slef> (sorry, slow web here)
10:09:12 <eythian> thd: I think it's good too kill them, just to announce that people should be moving now.
10:09:37 <slef> if anyone wants to fund 3.4 rm nd someone will workl on it, let them, else call it orphaned?
10:09:58 <paul_p> I think Koha 3.4 is de-facto orphaned
10:09:59 <oleonard> It should at least be known that there will be no more releases unless someone takes charge of it
10:10:17 <Brooke> I'm pretty sure someone sent that out to listserv months back, lemme see if I can dig it up
10:10:25 <thd> Exactly, orphans are merely orphaned.  There is no need to try to kill them.
10:10:28 <eythian> I'm of the opinion it'd be best to declare an end-of-life for things like that.
10:10:35 <slef> paul_p: make it official, encourage more upgrades
10:10:36 <eythian> thd: there is, or people don't know they're orphaned
10:10:45 <paul_p> slef agreed
10:11:18 <thd> We should announce an orphan but not a killing.
10:11:27 <thd> Killing is unnecessary.
10:11:36 <thd> ... and mean.
10:11:41 <oleonard> If no one has done it by then I'll send a message to the list in 3hrs. We can have the discussion there
10:11:45 <eythian> Too many people are still using old versions as it is.
10:12:42 <Brooke> think this is exhausted
10:12:43 <slef> see
10:12:53 <Brooke> #topic Roadmap to 3.6
10:13:07 <slef> #link http://www.debian.org/wnpp for debian Orphan and RFA examples
10:13:08 <thd> Announce that the orphans are exhausted.
10:13:32 <paul_p> slef = page not found :\
10:13:41 <oleonard> A few beatings usually eke out a little more effort from exhausted orphans
10:13:57 <thd> :)
10:14:06 <Brooke> #info there will be no more porridge for 3.4
10:14:31 <Brooke> anyone have anything on 3.6
10:14:45 <slef> paul_p: drat.
10:15:00 <eythian> There's now a debian repo tracking 3.4
10:15:01 <eythian> err
10:15:02 <eythian> 3.6
10:15:14 <paul_p> eythian = debian repo ? which url ?
10:15:23 <Brooke> Sweet As, bro. :)
10:15:27 <slef> #link http://www.debian.org/devel/wnpp for debian Orphan and RFA examples
10:15:33 <eythian> http://wiki.koha-community.org/wiki/Koha_3.6_on_Debian_Squeeze <-- the usual place
10:16:22 <eythian> Which means we have packages for oldstable (3.6) squeeze (3.8) and squeeze-dev (master)
10:16:30 <eythian> I know those names don't make sense.
10:16:57 <slef> docs > sense
10:17:38 <Brooke> any other noteworthy 3.6 news?
10:18:19 <mtompset> There was a string freeze announced recently for 3.6.7 coming out shortly.
10:19:04 <paul_p> dashboard says 2012-07-15 - String freeze for 3.6.7
10:19:09 <Brooke> #info There's a Debian repo tracking
10:19:10 <paul_p> and 2012-07-22 - Release date for 3.6.7
10:19:21 <Brooke> #info and 2012-07-22 - Release date for 3.6.7
10:19:34 <Brooke> #info 2012-07-15 - String freeze for 3.6.7
10:19:55 <Brooke> #info http://wiki.koha-community.org/wiki/Koha_3.6_on_Debian_Squeeze for the repo link
10:20:07 <Brooke> #link http://wiki.koha-community.org/wiki/Koha_3.6_on_Debian_Squeeze
10:20:34 <Brooke> sorry, want to get all of that in the minutes, so I've to be a bit spammy :)
10:21:04 <paul_p> Brooke = I think it's better for readers of minutes to have it, so it's not spammy imo
10:21:40 <Brooke> anything else on 3.6 or are we movin' on?
10:22:06 <paul_p> move on !
10:22:19 <mtompset> Only jcamins would have more.
10:22:20 <Brooke> crawlin' out of the stone age then...
10:22:36 <Brooke> #topic Roadmap for 3.8
10:24:28 <davidnind> 2012-07-15 - String freeze for 3.8.3
10:24:47 <davidnind> 2012-07-22 - Release date for 3.8.3
10:25:08 <slef> can someone repaste that with #info please?
10:25:13 <Brooke> #info 2012-07-15 - String freeze for 3.8.3
10:25:19 <Brooke> you're someone too slef :P
10:25:28 <Brooke> #info 2012-07-22 - Release date for 3.8.3
10:25:42 <slef> yeah bopy paste while walking from post office to bakery not good
10:25:54 <drojf> lol
10:25:55 <slef> even typing not good
10:26:27 <slef> and I've one of the kohacon signs tied to my back ;)
10:27:07 <Brooke> rangi have anything to add?
10:27:32 <paul_p> rangi sleeping it seems ;-)
10:28:03 <Brooke> lies, he never sleeps, and I've reams of IRC logs to show it
10:28:09 <Brooke> he, like Galen, is prolly a bot...
10:28:12 <slef> left bakery - sorry if you wanted anything
10:28:27 <mtompset> I don't believe he did an intro, so probably not likely to add anything. :)
10:29:12 <thd> mtompset++
10:29:36 <Brooke> #topic Roadmap for 3.10
10:29:38 * slef pokes you
10:29:39 <Brooke> take it away paul
10:29:50 <paul_p> yep, i'm here -and not a bot- ;-)
10:29:58 <mtompset> thank you, thd.
10:30:06 * oleonard thanks paul_p for being here
10:30:10 * mtompset scowls at slef. ;)
10:30:23 <paul_p> You've seen in my previous monthly RM newsletter that a very important patch has been pushed, to start the move to solr.
10:30:50 <paul_p> it causes jenkins to be unstable atm, but that's a not a "big" unstability, and there are some patches underway to fix it.
10:30:55 <slef> move to, or move to add support for?
10:31:12 <oleonard> the latter
10:31:19 <slef> phew
10:31:21 <paul_p> for now, my main concern is bug 8251 that we haven't killed yet, and is a big problem for all libraries using fines in days
10:31:22 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8251 critical, P1 - high, ---, koha, Passed QA , Patrons are systematically debarred at checkin
10:31:56 <Brooke> which would be like heaps of libraries :(
10:32:04 <paul_p> this bug is mostly caused by the switch to hourly loan, and changes in date comparisons.
10:32:38 <paul_p> for now, 4 patches have been submitted to fix the problem, but it still not fixed. I plan to work this afternoon on this one.
10:32:51 <paul_p> (and it's a 3.8 problem, because 3.8 has the bug !)
10:33:14 <slef> paul_p++ and should that be a blocker for 3.10?
10:33:41 <paul_p> I've started a thread on koha-devel about release process, a lot of discussion here, I think i'll continue the discussion soon.
10:33:44 <Brooke> #help help Paul with bug 8251 - libraries that record fines in days really need you!
10:33:56 * mtompset notes that is a reason why we're only upgrading to 3.6.7 next.
10:33:59 <paul_p> slef = I strongly hope it will be before 3.10 !!!
10:35:13 <paul_p> The pile of ENH waiting for a signoff is very large, and I wouldn't like to see all of them being signed-off & passing QA & pushed too close from the release.
10:35:33 <Brooke> paul I have stuff for this under its proper topic. Don't let me forget :)
10:35:34 <paul_p> that's the problem the thread still don't address
10:36:32 <paul_p> saying 2 months before the release "I won't push any ENH" mean that the freeze will occur in august, 22, which is "tomorrow"
10:36:43 <paul_p> I don't want to do that.
10:37:03 <paul_p> OTOH, ppl seem not to be happy with the idea of saying .0 is a announced as beta
10:37:11 <paul_p> is there a 3rd option ? which one ?
10:37:29 <paul_p> that's my biggest point for 3.10 for now.
10:38:19 <Brooke> #info problem with release cycle
10:38:36 <paul_p> another one = I had not a lot of feedback on my POC for thread "http://wiki.koha-community.org/wiki/Koha_Namespace_RFC, moving ahead"
10:38:41 <mtompset> So when is 3.10 tentatively coming out?
10:39:16 <paul_p> mtompset = that's my personal debate atm !
10:39:50 <paul_p> either keep oct 22, say there will be a 2 months freeze for large enh, meaning everything must be in before aug, 22
10:40:11 <paul_p> or keep oct 22 as .0 release, but clearly announce it will be a beta
10:40:18 <paul_p> or a 3rd option I don't see atm
10:40:48 <paul_p> (4th option = change nothing, but I think it's not a good option !)
10:41:03 <slef> paul_p: why 2mo freeze? could we shorten if lots pledge to test+fix a lot?
10:41:23 <slef> paul_p: and can we be braver at reverting buggy enh?
10:41:26 <paul_p> slef = it has been proven for 3.4 and 3.8 that it does not work well
10:41:33 <mtompset> pledges don't mean anything. Don't count the chickens before they hatch.
10:41:49 <paul_p> slef = it's hard to revert ENH, because they usually have DB updates
10:41:51 <Brooke> we could do a 9 or 12 month release cycle #justsayin
10:41:55 <rangi> worked for 3.6 though
10:42:06 <rangi> longer cycle just shifts the problem
10:42:08 <paul_p> hey, rangi is not sleeping ;-)
10:42:15 <paul_p> I agree it just shifts the problem.
10:42:32 <slef> paul_p: leave db update hope to reintro in x.1 or x.2, but revert code?
10:42:54 <mtompset> that isn't always possible, slef.
10:42:54 <thd> slef++
10:43:03 <paul_p> slef ... maybe ... i'll think a little bit more of this option... not sure
10:43:05 <rangi> it is more often than not
10:43:06 <slef> mtompset: no, not always
10:43:17 <slef> mtompset: but 90% I suspect
10:43:26 <thd> mtompset: When is it not possible to revert code?
10:43:26 <paul_p> agreed with slef
10:43:27 <Brooke> shifting the problems to the next release just shifts the problem.
10:43:33 <davidnind> First option seems sensible to meet six month release cycle, and provide a stable release..
10:43:34 <slef> mtompset: this is release engineering not utopia
10:43:42 <mtompset> timestamp vs. date (db change)
10:43:49 <slef> thd: when someone built on it
10:44:10 <rangi> ppl running from dev .. not from releases will be the only ones affected by db updates anyway
10:45:22 <thd> slef: We need more independence between features to avoid building on untested code.
10:45:35 <rangi> 3.6.0 had one month feature freeze
10:45:42 <davidnind> Better to have fewer enhancements and a stable release, rather than a buggy release (for reputation as a great product, if nothing else)
10:45:55 <rangi> davidnind++
10:46:07 <Brooke> I agree david
10:46:10 <thd> davidmind++
10:46:19 <mtompset> Quite true.
10:46:22 <Brooke> also, Librarians are patient people. I can't say this enough
10:46:26 <rangi> lol
10:46:27 <rangi> they are not
10:46:37 <rangi> they are like every other client
10:46:38 <Brooke> perhaps some of the enhancements should be chunked smaller than they are
10:46:54 <oleonard> davidnind++
10:47:09 <slef> anyway, more list discussion?
10:47:10 <slef> RAINING  HARD HERE NOW
10:47:13 <rangi> ive had huge media megacorps more patient than tiny libraries
10:47:43 <thd> However, if enhancements run independently of other code for a period of time, then it would be easy to exclude them if they are discovered to actually be buggy even after passing QA.
10:47:49 <paul_p> other option/idea = branch 3.10 earlier (in august), to let enhancements being pushed in master, while stabilizing the 3.10 . atm, during freeze, ENH continues to be submitted, but are not pushed anymore, which tend to have ENH pushed later (not sure i'm very clear ...)
10:48:26 <rangi> you'd have to run that by the RM for 3.12 .. since once 3.10 is branched, master is hers/his
10:48:30 <slef> sorry all, I must get indsooers... pls postpone kohacon12 for me? bbi10
10:49:13 <paul_p> rangi = right. I'll rise the idea on the mailing list
10:49:18 <rangi> you could always push them to experimental or something, after the feature freeze
10:49:37 <jcamins> #info Jared Camins-Esakov, C & P Bibliography Services
10:49:42 <mtompset> Do things ever come out of experimental?
10:50:36 <rangi> i think given the currently instability of master
10:50:49 <rangi> freezing sooner and bugfixing is the best plan
10:51:18 <eythian_> Branch an -rc?
10:51:20 <oleonard> It doesn't make sense to seek to push more enhancements just for the sake of making the release "more different"
10:51:41 <thd> oleonard++
10:51:52 <mtompset> I agree, oleonard
10:51:55 <dpavlin> Q: would things like Bug 8418 would go in while in bugfix freeze?
10:51:56 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8418 critical, P5 - low, ---, koha-bugs, Needs Signoff , Koha::Calendar is_holiday ignores all user data
10:52:17 <rangi> dpavlin: we are talkign feature freeze
10:52:20 <paul_p> dpavlin = "critical" means it's not an ENH
10:52:26 <dpavlin> ack
10:52:29 <rangi> there is never a bugfix freeze
10:52:34 <rangi> only feature and string
10:52:46 <rangi> and string is soft
10:53:00 <rangi> critical bug fixes that change strings usually get pushed anyway
10:53:25 <thd> Making the release "more different" is only what should be done for releases which are not based on a calendar schedule.  We are doing calendar schedule releases.
10:53:39 <Brooke> thd that's the problem
10:53:47 <jcamins> But if the fix can be done without changing strings, that's to be prefered after string freeze.
10:53:48 <rangi> no its the solution
10:53:52 <Brooke> there's no logical rotation between enhancement and bugfixing versions
10:54:01 <Brooke> we try it all at once in 6 months and that's madness.
10:54:13 <rangi> to the problem of doing not calendar releases and 3.5 year releases
10:54:54 <mtompset> Actually, 6 months is a good length of time, because this means there are two bursts of fixes as releases are coming out.
10:54:58 <rangi> i disagree its madness, i think there are areas of improvement
10:54:59 <paul_p> I don't want to switch back to feature releases ! the 6 months seems a good periodicity. We must stick with it !
10:55:06 <rangi> paul_p++
10:55:31 <slef> back
10:55:31 <oleonard> Agreed, and that means sticking to an early feature freeze
10:55:56 <mtompset> but does the feature freeze need to be 2 months? is 1 month enough?
10:55:58 <oleonard> The enhancements can wait, but the bug fixes can't
10:56:01 <paul_p> and I think that the early Feature Freeze goes with branching stable soon !
10:56:10 <paul_p> s/soon/early/
10:56:23 <oleonard> mtompset: That has not been the case historically
10:56:45 <Brooke> we could rotate. we could have 6 months for bugfixing
10:56:51 <Brooke> and 9 or 12 for enhancements
10:56:56 <rangi> eeewww
10:56:57 <paul_p> mtompset = anyway, i'll be in holiday from aug 4th to 26th, so the FF won't be on aug 22, because it would mean Aug 4th, that's too early !
10:57:08 <thd> I think that the six month releases allow incremental improvement and encourage much more care in commits to not break things for major changes.
10:57:15 <Brooke> I think the sticking to the deadline bit is way more important than picking an insane deadline and fitting services to it
10:57:20 <oleonard> Brooke, I don't think this is the time or place to propose changes to the release cycle
10:57:33 <paul_p> maybe switch from april/oct releases to may/nov, and have feature freeze sept 22 ?
10:57:36 <Brooke> when is Owen? I bring it up, and I'm nearly always patronised.
10:58:00 <oleonard> It should be discussed as part of the process of choosing a new RM
10:58:10 <paul_p> oleonard right
10:58:17 <jcamins> What is the benefit of May/November?
10:58:18 <oleonard> ...not within the current release cycle
10:58:39 <paul_p> jcamins = not feature freeze during summer holidays
10:58:46 <jcamins> paul_p: ah.
10:58:49 <jcamins> Got it.
10:58:50 <mtompset> And this 6 month cycle, is it in stone, or flexible by a given amount of time?
10:59:14 <rangi> hmm i would have thought holidays is perfect freeze time :)
10:59:18 <thd> I have overcome my past objection to calendar releases with the commitment to continued bug fixes after release.
10:59:20 <paul_p> mtompset = I would say nothing is in stone, but i'm strongly against changing it again !
10:59:34 <rangi> and course thats only the northern summer :)
11:00:00 <paul_p> rangi right. when are the southern summer holidays ?
11:00:07 <rangi> december
11:00:14 <rangi> january
11:00:15 <rangi> march
11:00:18 <rangi> whenever :)
11:00:31 <eythian_> Whichever day summer falls on that year
11:00:51 <Brooke> hang on, Kiwis come *off* holiday?
11:00:57 <paul_p> are you implying it's always summer in NZ ? ;-) ( not what eythian_  is saying :D )
11:01:00 <davidnind> We get summer? Yeh!
11:01:13 <thd> Some projects work poorly with calendar releases.  Koha seems OK thus far.  Some GNU/Linux distributions using calendar releases cannot be trusted to actually work in my experience.
11:01:44 <eythian_> Calendar releases also makes planning possible which is good.
11:01:49 <rangi> thd: koha is a zillion times more stable now (even with the 3.8 bugs) than it was ever before
11:02:00 <rangi> 3.0.0 was a night mare
11:02:21 <rangi> and it took 3 years
11:02:34 <thd> rangi: I am making that point of concurrence.
11:02:49 <Brooke> note that I've never proposed 3 years, and that was from constantly moving goalposts instead of honestly assessing things
11:03:10 <Brooke> I think it's just as bad to introduce a buggy as version just to hit 6 months
11:03:24 <mtompset> So it seems we all want stability.
11:03:36 <rangi> yep, so longer feature freeze it is
11:03:45 <oleonard> Yes
11:03:46 <thd> I had previously, objected based on projects which are so large that they can never have a feature freeze early enough to fix all bugs which should be blockers.
11:04:01 <paul_p> Brooke = when 3.8 was released, everything had been tested and it was supposed to be OK. Except there was some side effect the QA process has not detected.
11:04:02 <rangi> thd: thats what happens with longer cycles
11:04:27 <mtompset> Actually, has anyone actually developed a test plan for every module in Koha?
11:04:32 <rangi> the more you cram in, the more likely it is to break
11:04:48 <paul_p> mtompset = I know bywater is working on that atm.
11:04:56 <rangi> mtompset: we have 57% subroutine coverage
11:05:03 <paul_p> mtompset = and the problem is that there are so many options/sysprefs !
11:05:10 <rangi> the most useful thing anyone can do for koha
11:05:13 <rangi> is write more tests
11:05:30 <rangi> it trumps features
11:05:37 <jcamins> And we can do functionality regression tests, too!
11:05:42 <rangi> yep
11:05:47 <jcamins> #link wiki.koha-community.org/wiki/Interface_testing_with_WWW::Mechanize
11:05:52 <rangi> the problem is no one wants to pay anyone to do that
11:06:01 <rangi> they want to pay for new features
11:06:01 <jcamins> Brooke: will that link work?
11:06:03 * mtompset was thinking the same thing, jacmins.
11:06:04 <paul_p> for example, I just failed QA bug 6874, look at comment 32 to see why ! that's something I just discovered by chance !
11:06:05 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6874 enhancement, P3, ---, julian.maurice, Failed QA , File upload in MARC
11:06:20 <jcamins> I didn't include the http://
11:06:23 <thd> We need a road maintenance tax.
11:06:28 <paul_p> rangi ++ for the problem of no one want to pay for that...
11:06:31 <slef> rangi: someone gave a talk about that at kohacon...
11:06:36 <Brooke> dunno, so I'll redo
11:06:39 <rangi> :)
11:06:56 <Brooke> #link http://wiki.koha-community.org/wiki/Interface_testing_with_WWW::Mechanize
11:07:25 <rangi> the tests catch more and more stuff, and with http::recorder and mechanize we can test js too
11:07:33 <Brooke> so if that's happened in perpetuity
11:07:44 <Brooke> can we work in a bugtesting fee to new features?
11:07:48 <paul_p> discussing of this for 40mn now. Maybe we can close the discussion, I'll do a summary on koha-devel, and continue trying to find the best solution ?
11:07:49 <Brooke> something has to address that gap.
11:08:00 <Brooke> paul this is important
11:08:09 <Brooke> which is why I've let it go for 40 minutes
11:08:22 <rangi> paul_p: i think the feature freeze is all we can do for this release, too late in the cycle to do anything else
11:08:37 <paul_p> Brooke = of course it's important ! (and I started it ;-) ) but we could discuss for hours !
11:08:54 * mtompset nods.
11:08:57 <Brooke> but it's not too late for next go
11:10:16 <rangi> thats up to the people who write their proposals to be the next RM
11:10:59 <rangi> if we are going to elect someone to the thankless task that it is, we should try to let them decide how they want to run it
11:11:18 <rangi> and like if paul_p has, they ask for advice, we give it, but ultimately it's their release
11:11:46 <joann> nodding here
11:11:49 <mtompset> If we've agreed that there is a 2 month feature freeze and no freezes in summer, then wouldn't some time in November be the tentative release date for 3.10?
11:12:03 <rangi> mtompset: we havent agreed anything
11:12:21 <nengard> Okay - the results are in
11:12:29 <paul_p> I think i'll discuss of this also with jcamins (unless there's another crazy that want to be RM ;-) )
11:12:39 <rangi> the current release date is october 22, but paul_p can shift that as is his perogative
11:12:41 <mtompset> but the 2 month feature freeze is a side effect of the desire for stability.
11:12:42 <joann> drum roll;
11:12:47 <nengard> I'm about to share the survey results
11:12:54 <nengard> but the winner is Reno, NV
11:12:55 <jcamins> paul_p: my fingers are crossed. :P
11:13:10 <rangi> jcamins: not me :)
11:13:13 <nengard> Unless someone thinks my math is wrong - which is why I'll share
11:13:16 <paul_p> jcamins = which is really a bad thing to type on a keyboard ;-)
11:13:32 <thd> please share
11:13:43 <jcamins> paul_p: I know... thank goodness for tab complete!
11:13:50 <slef> ok well if kohacon13 won't wait, I won't either. kohacon12 update 2/3rds of bills in, still + or - £200, too soon to tell. vids delayed by my move (no dsl hinders uploading), doing as time permits but it's hard
11:13:57 <paul_p> nengard = you jump in the middle of the monthly meeting, and KohaCon13 is the next point ;-)
11:14:00 <rangi> or we could put it on the agenda and le the meeting continue
11:14:01 <Brooke> hang on
11:14:04 <nengard> oops
11:14:06 <nengard> sorry all
11:14:07 <Brooke> lemme at least get the right topic up XD
11:14:09 <slef> now I must go to mdeal with an unexpected problem. bye.
11:14:13 <Brooke> #topic KohaCon 12
11:14:31 <thd> It was on the agenda when I looked.
11:14:54 <Brooke> It was also awesome, from what I heard ;)
11:15:09 <thd> However, hugininn had not changed the topic yet.
11:15:09 <Brooke> I wish slef had stuck around to qualify that billing bit
11:16:10 <mtompset> I think he mentioned the other day that one of the places you stay hadn't sent the bill yet.
11:16:35 * jcamins will rephrase: two-thirds of the bills have been received, and based on what they're expecting for the last couple bills (from the University of Edinburgh), they're expecting a shortfall of ~200GPB.
11:16:36 <mtompset> stayed at...
11:16:55 <mtompset> Right.
11:17:15 <mtompset> Donations still welcome. ;)
11:17:28 <jcamins> Exactly.
11:17:47 <jcamins> GBP
11:18:25 <Brooke> #help please donate to cover the last of KohaCon expenses. Just need 200ish quid
11:18:36 <Brooke> #topic KohaCon 2013
11:19:29 <rangi> Brooke: its + or -  200
11:19:32 <rangi> so they may not
11:20:10 <rangi> they need the final bill to come in, then he will let us know
11:21:17 <mtompset> he said bills, not revenues. ;)
11:22:02 <rangi> yes
11:22:21 <rangi> they have money, it may cover it and have 200 left over, or they may have a shortfall
11:22:34 <rangi> its too soon to know
11:22:49 <nengard> Votes for KohaCon 13 (which I think I can post now) have been put on the wiki: http://wiki.koha-community.org/wiki/Kohacon2013
11:23:27 * oleonard must leave for work
11:23:43 <rangi> those tally with my count
11:24:41 <joann> night all
11:24:50 <eythian> later joann
11:25:35 <rangi> night joann
11:25:43 <thd> The desert seems extraordinarily popular.
11:26:06 <rangi> it had a huge flurry, nigeria was leading until about 4 days out
11:26:39 <rangi> but as long as those 297 ppl who voted for reno in first place turn up, all good
11:27:17 * thd was busy raising money for FSF and failed to vote before the polls closed.
11:27:52 <nengard> rangi, there are a lot of librarians in CA and NV that I think voted so they'll be there
11:28:36 <Brooke> #info Congratulations Reno
11:28:37 * thd is from California originally and has spent much time in Reno.
11:29:02 <nengard> can I email the lists with this info?
11:29:10 <nengard> I have the email ready to go
11:29:25 <mtompset> It's been announced, why not?
11:29:26 <paul_p> nengard = I don't see why it should be delayed ;-)
11:29:31 <drojf> that is gonne be one large kohacon
11:29:31 <nengard> Okey dokey :)
11:29:54 <Brooke> that'd be awesome
11:29:56 <Brooke> nengard++
11:30:32 <nengard> I'll post to the website as well
11:30:39 <nengard> and the last one in the US was pretty darn big too
11:31:04 <paul_p> drojf = why do you way it will be large ?
11:31:30 <eythian> I assume we have to shoot a man just to watch him die, eh?
11:31:45 <rangi> paul_p: so many votes, surely people only voted for something in first place if they intend to go .. 297 first place for reno
11:31:54 <paul_p> (for KohaCon11, 600+ ppl voted for Mumbai. there were not 600 ppl attending, from far ;-) )
11:32:15 <Brooke> yes eythian ;)
11:33:16 <rangi> paul_p: exactly, so we dont want that again
11:33:47 <mtompset> That's why I decided not to vote, because it is very unlikely that I will be going.
11:33:54 <Brooke> I think there will be tonnes of Yanks on budgets that don't let them travel outside the US that will come
11:33:59 <Brooke> plus a heap of Canadians :)
11:34:09 * Brooke crosses her fingers for Mexico, too.
11:34:17 * mtompset cheers for his home country of Canada. :)
11:35:02 <Brooke> so let's do the bug signing off bit
11:35:11 <Brooke> #topic Old Business - Bug Signoff
11:35:14 <Brooke> so
11:35:18 <Brooke> I went to wikimania
11:35:23 <Brooke> which was super cool and super cheap
11:35:28 <Brooke> (trust me this is related)
11:35:35 <Brooke> and the Wikihow folks
11:35:38 <Brooke> had this dashboard
11:35:45 <Brooke> that was totally intuitive
11:35:58 <Brooke> and I remember magnus and chris doing some visualisation work
11:36:07 <Brooke> and how successful just the red, yellow, and orange bits were
11:36:17 <Brooke> so I think that if we cross breed the bug list
11:36:20 <Brooke> with the wiki dashboard
11:36:26 <Brooke> it will be the coolest thing evar
11:37:10 <mtompset> Sounds like a feature request. Is there a feature freeze in effect. ;)
11:37:29 <rangi> http://dashboard.koha-community.org/
11:37:38 <rangi> you can clone it and send patches
11:38:07 <Brooke> they have weather mapped theirs
11:38:17 <Brooke> so that there are picture sections
11:38:34 <Brooke> and for say article writing, there are a billion waiting, so it's a thunderstorm
11:38:41 <tweetbot`> [off] Twitter: @27point7: "interesting uniform idea (by @Tredok ) for koha teams all around the world? http://t.co/yiPSchdl ;-) #kohails"
11:39:02 * mtompset smirks, "clone it and send patches. Sounds like enter a maze of doom."
11:39:03 <Brooke> it's very clever for getting a really quick visual
11:39:44 <jcamins> mtompset: actually, it's really simple.
11:40:22 <mtompset> It's what rangi said to me regarding bug 5515.
11:40:23 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5515 major, P5 - low, ---, gmcharlt, NEW , Leading 'and' in search never returns a result
11:40:58 <jcamins> mtompset: okay, that one's a little scarier.
11:40:59 <mtompset> Thankfully, I doubt it is like C4::Search.
11:41:06 <thd> Brooke: Does this WikiMedia bug dashboard have a proper name?
11:41:19 <rangi> you're mad if you are tyring to fix C4::Search
11:41:24 <Brooke> thd I suspect it might live behind a small wall
11:41:33 <Brooke> I will try and fish it up and post or link a pic someplace
11:41:35 <rangi> you should be working in Koha::SearchEngine::*
11:41:46 <Brooke> but I wanted to mention it cause I saw it and immediately thought "Koha!!!"
11:41:54 <paul_p> @quote add rangi you're mad if you are tyring to fix C4::Search
11:41:54 <huginn> paul_p: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command).
11:42:09 <mtompset> And you had a typo, paul_p.
11:42:10 <paul_p> hey, I thought I was registred !
11:42:27 <paul_p> @quote 211
11:42:28 <huginn> paul_p: I've exhausted my database of quotes
11:42:36 <rangi> prolly need to identify
11:42:46 <paul_p> nevermind.
11:42:47 <rangi> @quote search identify
11:42:47 <huginn> rangi: 1 found: #73: "<chris_n> owen: try /msg munin identify nick..."
11:42:59 <rangi> @quote get 73
11:42:59 <huginn> rangi: Quote #73: "<chris_n> owen: try /msg munin identify nick password" (added by owen at 12:38 PM, April 29, 2010)
11:43:10 <rangi> s/munin/huginn/
11:43:43 <Brooke> so the next thing on here is marking bugs that can be tested in the sandboxes
11:43:50 <Brooke> I know there was just a sandbox improvement
11:45:31 <Brooke> I don't see how a keyword would hurt
11:45:35 <Brooke> does anyone else?
11:45:43 <Brooke> if we authorise it, people should use it, yeah?
11:46:16 <rangi> should != will
11:46:31 <Brooke> nope. it's usually better the other way round
11:46:44 <Brooke> authorised entries derived from the crowd
11:46:46 <Brooke> but no matter
11:47:03 <Brooke> any objections to keywords for bugzilla?
11:47:14 <paul_p> not from me ;-)
11:47:18 <jcamins> None from me.
11:47:29 <mtompset> No, but how will people know the keyword(s)?
11:47:36 <davidnind> not from me
11:48:21 <drojf1> you can see the keywords, somewhere. i know that there is only "regression" in it, so i must have found it somehow
11:48:33 <Brooke> how about just using sandboxtest?
11:48:44 <thd> Brooke: what do you mean in terms of the specific application of keywords?
11:48:52 <Brooke> look at the agenda
11:49:01 <Brooke> I'll quote it
11:49:04 <jcamins> thd: adding a keyword so that people can find bugs that can be tested in the sandbox.
11:49:07 <Brooke> Use a keyword in Bugzilla to mark bugs/patches that can be tested with the sandboxes
11:49:41 <mtompset> Okay, next uninformed question... what sandboxes?
11:49:55 <Brooke> so I'm thinking if we used sandboxtest that could differentiate stuff that can be tested and not get it mucked up with bugs with sandboxen or general tests, but am I right?
11:50:28 <Brooke> sandboxen are things that let me test stuff without having to do a whole heap of git schtuff
11:50:41 <eythian> mtompset: look through your email from today
11:50:48 <Brooke> should say folks where I said me XD
11:50:49 <mtompset> okay...
11:51:06 <davidnind> http://wiki.koha-community.org/wiki/Sandboxes
11:51:31 <thd> jcamins: I what way do keywords differ from the existing categories for bugs in bugzilla?
11:51:37 * rangi wanders off to sleep
11:51:42 <Brooke> night
11:51:43 <jcamins> thd: they cut across categories.
11:51:59 <jcamins> This is not for bugs in the sandbox implementation, it's for bugs that can be tested in sandboxes.
11:52:46 <thd> I am all in favour of more metadata for bibliographic materials and bugs.
11:53:01 <mtompset> davidnind++
11:54:17 <mtompset> Why wouldn't all bugs be tested in the sandboxes?
11:54:37 <jcamins> So, sandboxtest sounds good to me. What's next?
11:54:38 <jcamins> mtompset: the sandboxes can't handle all types of modifications.
11:54:39 <drojf1> mtompset: it does not work for all
11:54:58 <mtompset> Ah, okay.
11:55:01 <Brooke> Put the names of testers/signoffers in the release notes (more status)
11:55:09 <Brooke> by the way, thanks for everyone's patience
11:55:24 <Brooke> this feels long because it is: we essentially skived off with no meeting last time.
11:55:50 * libsysguy will have to catch up in the logs
11:55:51 <Brooke> I think this one is cool as long as someone *wants* acknowledgement
11:56:26 <mtompset> Isn't this related to jcamins suggestion of Sponsored-by?
11:56:27 <paul_p> mtompset = sandboxes can't handle update database very well atm, and don't handle any zebra configuration change
11:56:32 <thd> 2 UTC is a problematic time for much of the current distribution of participants in Koha.
11:56:49 <jcamins> Anyone who doesn't want acknowledgement can easily be removed from the release notes.
11:56:56 <jcamins> mtompset: yes. It's all of a piece. :)
11:56:59 <eythian> thd: that's why things rotate
11:57:01 <paul_p> if someone want to improve them, he's welcomed, of course ;-)
11:57:12 <Brooke> it's plum for Kiwis
11:57:41 <thd> Even much of NZ was absent from the last meeting.
11:57:51 <davidnind> but not always ... midnight now
11:57:59 <eythian> yeah, it's not a good time for kiwis
11:58:35 <eythian> but next time may be better
11:58:54 <Brooke> is 2 UTC bad for you all, too, then?
11:58:58 <drojf1> 13 June 2012 at 18:00 UTC+0
11:59:05 <drojf1> it was not at 2
11:59:10 <drojf1> the next one would be
11:59:36 <drojf1> so, next alibi :P
11:59:37 <Brooke> someone said 2, so that's what I was talking about XD
11:59:50 <Brooke> anyway
11:59:58 <thd> Brooke, we should return to the topic for now but I once tried to show that much of 2 UTC lands in the largely unpopulated ocean.
12:00:05 <Brooke> yes I think this is sort of related to the jcamins patch
12:00:35 <jcamins> The idea is to make sure that the people and institutions who contribute to Koha are acknowledged.
12:01:38 <davidnind> for NZ 2 UTC = 2pm, depends whether you have to work or not;-)
12:01:58 <eythian> well, I work on koha, so...;)
12:01:59 <jcamins> Doesn't sound like there's much discussion on that. Anyone who doesn't want their name in the release notes can easily ask for it to be removed.
12:02:06 <Brooke> ^
12:02:13 <Brooke> moving on
12:02:21 <Brooke> Put the monthly signoff stats from Chris C. on koha-community.org (more status)
12:02:22 <thd> Acknowledgement++
12:02:26 <Brooke> same thing would apply, methinks
12:02:30 <Brooke> yes folks?
12:02:31 <wahanui> folks are prone to overstay hackfest so I wouldn't worry too much about that given a friendly open wifi connection
12:03:39 * Brooke once again considers the tyrannical tenet of no objection as a sign of assent...
12:04:04 * mtompset apologizes, "Replying to work email at 8pm at night."
12:04:11 <Brooke> this one is my fav cause I put it there, but I expect folks will hate it
12:04:13 <Brooke> Offer prizes/bounties for signing off - either on individual bugs or for doing the most signoffs in a given time frame (Mechanical Turk?)
12:04:34 <Brooke> I will offer Diablo or WoW gold if there's a dev that actually wants any of either :)
12:04:34 <jcamins> Yes.
12:04:37 <jcamins> +1
12:04:38 <mtompset> I like the idea, but where will the prizes come from?
12:04:53 <jcamins> It can't just be for signing off.
12:05:00 <jcamins> It has to be for testing.
12:05:24 <thd> Aside from virtual gold, what prizes or bounties might anyone be prepared to offer?
12:05:31 <Brooke> so do we conflate those, or do we separate and honour both?
12:05:53 <mtompset> Can you sign off without testing, jcamins?
12:06:04 <eythian> you_can_
12:06:04 <Brooke> one would _hope_ not
12:06:06 <eythian> but you shouldn't
12:06:13 <thd> Would offering prizes actually lead to the wrong motivation and poor quality control?
12:06:36 <paul_p> thd that's a risk, you're right
12:06:44 <mtompset> Actually....
12:06:49 <mtompset> that gives me an idea.
12:07:00 * libsysguy prefers bribes of testing other devs
12:07:03 <mtompset> We were talking about testing and www::mechanize earlier, right?
12:07:24 <mtompset> What if as proof of the testing, they include a mechanize script?
12:07:34 <drojf1> how is that supposed to work? a price per bug? where do all the prizes come from? what if i am poor and cannot set a fancy prize for testing my patch?
12:07:53 <paul_p> mtompset = you can't expect that from a librarian using sandbox...
12:08:05 <Brooke> but you could get bonus points :)
12:08:39 <mtompset> an apache log file of their testing page requests?
12:08:55 <jcamins> drojf1: chocolate?
12:08:56 <wahanui> reiveune ate them all
12:09:05 <reiveune> lol
12:09:20 <eythian> mtompset: now you're just adding difficulty so you can have proof
12:09:34 <jcamins> Yeah, I don't think making it more difficult to test is the way to go.
12:10:10 <mtompset> then how to deal with thd's valid concern of potentially poorer quality control?
12:10:13 <jcamins> My point was, you can't say "here's a batch of fudge for whoever signs off on this patch," you have to say "here's a batch of fudge for whoever offers useful testing and feedback on this patch."
12:10:20 <eythian> Even recognition of things like: most signoffs, most QA actions, most patches in the release might be a place to start
12:10:30 <jcamins> Exactly.
12:10:35 <Brooke> where it's wanted
12:11:30 <Brooke> I just think we are up against a wall with testing, because I would wager that it's not fun for most people.
12:11:32 <mtompset> like that bug which is haunting paul_p with the impending release of 3.10 looming in his mind. :)
12:11:57 <Brooke> I don't think it's a Koha specific problem
12:12:08 * mtompset nods in agreement.
12:12:35 <Brooke> and I think if it bumps about in me head long enough, I might actually try and research (or more likely accidentally stumble on) what might work from elsewhere
12:12:36 <thd> drojfi: Poor developers may still be developing features which many parties want including relatively wealthy libraries.
12:13:10 <eythian> thd: or they might be developing something for a school in Africa...
12:14:08 <Brooke> I like the idea of a foundation, even if the origin of the idea was disliked
12:15:05 <eythian> I think it's overkill for a situation like this. I'd suggest start small, with a byline in release notes or just an email to the lists, and then build on that if there's reception to it.
12:15:16 <thd> eythian: I suspect that if the feature is well considered, a feature useful for schools in Africa will be useful for schools everywhere.
12:15:38 <thd> eythian++ start small
12:15:55 <Brooke> moving on to
12:15:57 <Brooke> Organize bug hunts: try to shake out all bugs in module x, and document tests on the wiki and look at the bugs for that module so we could clean up bugzilla and get some serious testing done + get some written test plans that we could try to automate later on
12:16:14 <thd> However, lack of testing is a big and not a small problem.
12:16:32 <mtompset> How about bug hunt through bugzilla?
12:16:53 <mtompset> There are lots of things needing sign off, or just sitting there.
12:17:06 <Brooke> hate to be a downer here, but how much testing can we actually do with the number of manhours we've got?
12:17:29 <jcamins> Not a lot more than we are already doing.
12:17:34 <thd> Brooke: We need to entice librarians to participate.
12:17:50 <mtompset> And that's where sandboxes come in.
12:17:53 <thd> ... or even library users.
12:18:34 <mtompset> I may end up going to the main office in the near future to see if I can get the library person there to participate in sandbox testing. :)
12:18:36 <thd> There is no shortage of library patrons, some of them must be motivated to improve the library.
12:19:17 <Brooke> their local library, perhaps
12:19:26 <Brooke> it's a tougher sell getting them to look at koha
12:19:33 <Brooke> in especial with no central body to donate to
12:20:23 <Brooke> almost done
12:20:24 <Brooke> More ideas? Do other project have systems that work? (Achievement system for Developers OR better use of an existing tool like Ohloh or Chorewars for status and karma?)
12:21:01 <Brooke> wikihow has a quick thumbs up thing for edits that other people find useful
12:21:28 <eythian> launchpad has karma points
12:21:39 <Brooke> I think chorewars was uber effective for a while, and might still be so :)
12:21:50 <eythian> though, we'd probably have to patch them into bugzilla if we wanted them, that would be a notable amount of work
12:22:06 <thd> I worry much about prizes giving wrong motivation but libraries could easily donate greater circulation periods or other privileges.
12:22:23 <Brooke> fine forgiveness might be an attractive thing
12:22:36 <drojf1> thd: do you really expect patrons to learn the library system of the library they are using?
12:22:47 <Brooke> a tiny percent do and will
12:22:49 <eythian> thd: I'm sure we've all built in "if (username eq "robin") { $fines = 0.00; } ;)
12:23:14 <jcamins> eythian: heh.
12:23:37 <cait-m__> heh
12:24:10 <Brooke> moving on, and this one is key
12:24:11 <Brooke> Is the wiki login working for new folks now?
12:24:33 <thd> drojf1: Obviously, patrons should not be expected to evaluate all features properly, no one is best at all features.  However, patrons may be good candidates for testing many features.
12:26:05 <thd> I never noticed it not working, but I had not been giving attention.
12:26:17 <oleonard> Whoa, long meeting
12:26:31 <Brooke> #help please ensure that the wiki login is working for new accounts
12:26:54 <thd> oleonard: Cumulated issues from lack of participation in the previous meeting.
12:26:59 <mtompset> quite long.
12:27:15 <oleonard> previous meeting_s_
12:27:27 <drojf1> long enough for me to bake a bread. it's done now :D
12:27:52 <mtompset> and reply to a work email, and make note of that chorewars site.
12:28:18 <mtompset> Brooke++
12:28:25 <Brooke> moving on
12:28:27 <Brooke> Move to Gerrit to streamline and optimize workflow?
12:28:46 <Brooke> is the Chris it was referring to asleep now, or is it other Chris, and if it is, is he here?
12:29:25 <jcamins> rangi.
12:29:45 <Brooke> sleeping it is
12:30:02 <mtompset> We did push a lot to this meeting. I think a couple things could get pushed to the next. ;)
12:30:09 <Brooke> any other actions from last meeting?
12:30:13 <Brooke> we're almost done
12:30:27 <thd> gerrit++ mahara?
12:31:34 <Brooke> Miscellaneous
12:31:39 <Brooke> anyone?
12:32:18 <mtompset> Nothing from me.
12:32:26 <Brooke> right!
12:32:35 <Brooke> #topic time and date of next meeting
12:32:55 <Brooke> I bollocksed this up last time
12:33:03 <Brooke> so I'd appreciate oleonard helping this time
12:33:06 <Brooke> so I don't do it again
12:33:13 <mtompset> Since we were noting that a lot of Kiwis were asleep, I suggest a Kiwi friendly time be chosen.
12:33:18 <Brooke> I'm equally knackered, so I think it's equally likely
12:33:22 <jcamins> We have a regular location.
12:33:33 <jcamins> *rotation
12:33:36 <jwagner> The rotation would have the next meeting at 2:00 UTC -- last two were 10:00 and 18:00
12:33:44 <jcamins> I vote we follow that, so 2:00 UTC.
12:33:53 <Brooke> which is friendly for kiwis, yes?
12:34:13 <Brooke> cause its everyone's turn eventually
12:34:16 <mtompset> I think that puts it around supper for them.
12:34:29 <Brooke> that's before tea
12:34:39 <Brooke> smack midafternoon
12:34:56 <oleonard> Terrible for Europe though
12:34:59 <mtompset> So, if that is the rotation, seems good to me.
12:35:00 <oleonard> 4AM?
12:35:05 <Brooke> it's always shite for someone
12:35:18 <mtompset> Well, what day will the next meeting be?
12:35:33 <mtompset> Because paul_p may or may not have an update on 3.10
12:35:34 <eythian> I think that's about 4pm NZ time or so
12:35:36 <davidnind> rotation is good, 2 UTC = 2pm in NZ
12:35:46 <eythian> 2 then
12:35:52 <eythian> I never remember which way it goes :)
12:35:55 <jwagner> We got away from the first Wednesday of the month. Since paul_p is out all of August, maybe skip to early Sept?
12:36:41 <thd> jwagner: The danger would then be an extra long meeting next time.
12:36:50 <Brooke> not only that
12:36:55 <thd> Koha should never have a holiday.
12:36:56 <paul_p> thd = isn't this one extra long already ? :D
12:36:57 <Brooke> but string freeze is coming up soonish, yes?
12:37:26 <cait-m__> will paul be there at 4 am?
12:37:34 <Brooke> doubt it
12:37:35 <thd> paul_p: Yes, but partly for the reason which jwagner cited.
12:38:06 <oleonard> 4AM and during your vacation eh paul_p?
12:38:06 <mtompset> perhaps keep it to august, because the next rotation may be europe friendlier?
12:38:11 <cait-m__> so can be aug
12:38:30 <paul_p> oleonard lol !
12:39:13 <Brooke> 1 August is still vaguely august
12:39:32 <mtompset> That's too close.
12:39:34 <oleonard> 1 August is in two weeks
12:39:42 <Brooke> yep
12:39:49 <thd> Exactly, whether during the summer leaving period or not, 2 UTC would be a difficulty for paul.
12:40:18 <paul_p> thd = well, in fact it's less difficult during holidays = I can go back to bed hereafter ;-)
12:40:25 <oleonard> I suggest 15 August
12:40:29 <thd> :)
12:40:32 <paul_p> the main question being = will I have internet where I go in fact !
12:40:37 <paul_p> (still not sure)
12:40:59 <mtompset> If we do August 8, it would be easier to bump back to first wednesday of month.
12:41:23 <thd> mtompset++
12:42:04 <mtompset> Let's see 2 UTC is...
12:42:15 <Brooke> 8 August 2 Utc
12:42:24 <Brooke> plus 1 please
12:42:24 <wahanui> 1
12:42:36 <thd> +1
12:42:40 <jwagner> +1
12:42:46 <jcamins> +1
12:42:49 <libsysguy> +1
12:42:50 <davidnind> +1
12:43:05 <eythian> wahanui: you don't even have a timezone
12:43:06 <wahanui> eythian: sorry...
12:43:15 * paul_p don't vote
12:43:35 * eythian probably won't be able to make that time this time around, but that's OK.
12:43:53 <mtompset> +1
12:44:05 <cait-m__> 0
12:44:06 * mtompset is still trying to figure out the time difference to Manila.
12:44:13 <Brooke> #agreed next meeting is 8 August 2 UTC
12:44:18 <Brooke> #endmeeting