Time  Nick       Message
08:58 mason      go team cormack!
08:54 chris      thank you :)
08:54 paul_p     i've seen you'll have another kind of deadline in some months. congrats !
08:54 chris      hi paul
08:54 paul_p     hello chris
08:53 chris      hdl: just deadlines
08:53 hdl        hi mason
08:53 mason      heya guys...
08:53 hdl        troubles ?
08:52 chris      at work still unfortunately
08:52 chris      yep
08:52 hdl        chris around ?
02:52 jaakkome   anyone there?-)
00:56 mason      anyone about for a git clue?
23:22 hdl        gmcharlt: have you read ILS-DI draft ?
22:57 chris      that'd work, ive never needed to though
22:56 SelfishMan One of the options I tend to use with Apache::DBI is to have my startup script initialize the DB connection and perform the keepalive
22:55 chris      i love it :)
22:55 chris      Do NOT change anything in your scripts. The usage of this module is absolutely transparent !
22:55 SelfishMan yeah
22:54 chris      it just works *tm*
22:54 chris      thats the beauty of it
22:54 SelfishMan You aren't initializing Apache::DBI?
22:54 chris      i have PerlModule Apache::DBI in my virtualhost
22:53 SelfishMan Hmm
22:53 chris      theres not a lot to it :)
22:53 chris      1;
22:53 chris      use lib qw(/home/chris/git/koha.git);
22:53 chris      if ( ! {MOD_PERL}) { die "GATEWAY_INTERFACE not Perl!"; }
22:53 SelfishMan have fun
22:53 acmoore    OK, I'd better jet. See y'all tomorrow.
22:52 chris      2 secs
22:52 SelfishMan What does your startup script look like for it?
22:51 acmoore    yep, Apache::DBI buys you a lot.
22:51 chris      before id recommend it for any 'real' use
22:51 chris      but it needs a lot more testing, with concurrent users
22:50 chris      the connection pooling alone is worth it
22:50 chris      ive been running my dev koha with Apache::PerlRun and Apache::DBI
22:49 SelfishMan one of my biggest complaints is that there is a lot of overhead to the startup of each script so I think I might look into making it play nice with mod_perl
22:48 chris      http://freshmeat.net/projects/mod_perlite/
22:48 SelfishMan Apache::PerlRun is the one I was thinking of
22:48 chris      this looks interesting
22:48 gmcharlt   Apache::PerlRun, maybe, but I haven't tested that
22:48 acmoore    but, now I can't recall which.
22:48 gmcharlt   it wouldn't be safe under Apache::Registry
22:48 chris      id suspect the short answer is no
22:48 acmoore    I've heard that there is at least one module that koha requires that doesn't play well with mod_perl.
22:47 chris      having not tested it enough
22:47 chris      im not prepared to confirm nor deny that :)
22:47 SelfishMan is it safe under mod_perl with the apache::registry and similar modules?
22:46 SelfishMan let me rephrase that
22:46 SelfishMan is koha mod_perl safe?
22:44 chris      heh
22:44 acmoore    oh no. you just added about 94 zillion hours of work.
22:44 chris      we should probably start using taint at least on the opac too
22:43 ryan       acmoore: nice
22:43 chris      sweet
22:43 acmoore    so, if you're patching a file that doesn't use warnings, it prints something at you.
22:43 acmoore    while we're on topic, here's a post-commit hook to let you know when files in your commit don't 'use warnings': http://arwen.metavore.com/~acm/git/post-commit-use-warnings
22:42 chris      there are zillions of ways to do it :)
22:41 chris      git is the perl of vcs
22:41 chris      yep
22:41 ryan       i am so glad though that we moved to git...  can do _so_ many things that just weren't possible with cvs.
22:41 acmoore    nothing improves learning like a good screw up.
22:41 chris      its all stuff ive learnt from screwing things up :-)
22:40 chris      np
22:40 ryan       thx chris
22:40 ryan       ah, that makes sense.
22:40 acmoore    oh, interactive is probably the best idea.
22:40 chris      or commit then do amend
22:40 chris      with interactive on
22:39 chris      git commit -a
22:39 chris      you can also do
22:39 ryan       that may be all i'm missing.
22:39 chris      before the commit
22:39 chris      then a bunch of git rm -f
22:39 chris      then git status
22:39 chris      --all
22:39 chris      i often do a git add
22:38 ryan       one of those things i always forget to experiment on until it's really not a good time to be experimenting :)
22:38 areinmeyer hence, the --all, i guess
22:37 areinmeyer there's a git add --all but that's pretty inclusive
22:36 ryan       i recall doing a git add * before, with unpleasant results.
22:36 acmoore    but I don't want to add the ton of unrelated files in my working directory.
22:36 acmoore    I wonder if you can 'git add .'
22:35 acmoore    ryan: I'd love to know the answer to that, too. I have to hope that I "format-patch" before hand so that I can look at what should be added in that patch.
22:34 ryan       is there a way to add everything that changed to the index without doing it explicitly?
22:34 acmoore    ok, gmcharlt. I just patchbombed about 5 patches for refactoring and warnings and such. If any of them don't seem to be OK, I can work on them before I send in this feature.
22:34 ryan       before i can do the --continue .
22:34 ryan       i need then to add everything i changed to the index, the way that 'git commit -a' would do
22:34 ryan       while we're on random git usage...  i sometimes have conflicts or on an 'edit' in rebase -i, i need to change a bunch of things, then do a rebase --continue...
22:33 acmoore    my favorite part is when I "git fetch ; git rebase origin" and discover that there are *fewer* differences than before. That means that one of my prerequisite patches has been accepted and pushed. so, I have to manage fewer in my branch.
22:31 acmoore    heh. time to edit my "my git workflow" page.
22:31 ryan       :)
22:31 ryan       acmoore: don't be embarrassed.  i've been guessing at about how many patches to go back against, too
22:30 ryan       ah, it makes sense now.
22:30 acmoore    I guess I can make a new branch and try that.
22:30 acmoore    ryan: I don't really know. If I were up to date with the origin, I'd exect there to be no commits to rebase.
22:30 acmoore    perhaps I used "master' or something weird before.
22:29 ryan       acmoore: does that work even if you're up to date with origin?
22:29 gmcharlt   lol - yeah, I use git rebase --interactive origin all the time
22:28 ryan       heh
22:28 acmoore    how embarassing.
22:28 acmoore    oh, I guess that actually works. I thought I had usuccesfully tried it before.
22:27 acmoore    like "git rebase --interactive origin" or somesuch, maybe.
22:27 acmoore    Do you know how to format that for "git-rev-parse" or whatever parses that?
22:27 acmoore    while I'm asking you oddball stuff... I use 'git rebase --interactive HEAD^10' to get the last 10 commits and change them. And I sort of guess 10 being a good number. But, what I really want is all of the commits that aren't in the origin.
22:22 acmoore    oh, I forgot about 2505, or maybe I didn't know about it. OK
22:22 acmoore    OK. that makes sense.
22:22 gmcharlt   except that you can use shared bugs like 2505 for turning on warnings
22:21 gmcharlt   they should either have no bug number or a bug number for that indivdual improvement
22:21 acmoore    So, should I attribute them to the koha bug that caused me to write them, or give them no bug numer at all?
22:21 acmoore    they stand alone. I try to "percolate" them up to the newest of my patches, so that my functinoality depends on them.
22:20 gmcharlt   i.e., a refactoring patch shouldn't add new functionality at the same time
22:20 gmcharlt   I'd prefer them sooner, assuming that they stand alone
22:18 acmoore    gmcharlt: I may have asked this before, but forgot. In the course of developing a large feature, I've produced some "refactoring patches" like adding warnings to scripts I'm just about to edit, or something like that. Do you care if you get those patches as I create them, or if you get them all along with the patches that add my feature?
20:48 chris      oh i found out yesterday, that the senate library in thailand runs koha
20:44 chris      yes, that makes sense, very important
20:44 paul_p     so it's a "quite ou double" project. If it's a success, the next 3 years or so will be easy. Otherwise, they'll probably be hard...
20:44 chris      let me know if there is anything i can do to help
20:43 chris      awesome
20:43 paul_p     chris: yes. and we know at least 20 french universities looking at this project.
20:42 chris      that will be a lot of work i bet
20:39 chris      *nod*
20:39 paul_p     in the next quarter, we will be dedicated to Marseille Universities project.
20:39 chris      i think there is quite a bit of work here for him too, so thats good
20:39 chris      cool
20:39 paul_p     we are quite happy to work with him, and we are thinking to continue our cooperation, if we have some stuff that could be done by him
20:38 chris      hehe
20:38 paul_p     yep. Mason is a "never sleeping" man...
20:38 chris      excellent :)
20:38 chris      ive seen mason working at all hours too
20:38 paul_p     - create the patches & send them to patches@ for inclusion into 3.2
20:38 chris      cool
20:38 paul_p     - write a doc (in english) for the community
20:38 paul_p     once they're live :
20:37 paul_p     and there are still a lot of annoying problems
20:37 paul_p     chris: yep. we have to finish new acq module for the SAN-OP. they go live on jan, 12th !
20:34 chris      busy after getting back from lyon?
20:34 chris      congratulations paul :)
20:33 gmcharlt   paul_p: happy anniversary!
20:33 paul_p     hi chris
20:25 chris      right, back after a bus ride, a coffee and a meeting
20:25 acmoore    well, not pushing it into git, but looking at them and passing them along to the patches list.
20:22 acmoore    gmcharlt: thanks for putting the branch transfer limits stuff in. I can't believe those patches still applied. They were a month or 2 old, I think.
19:47 liz        oi, chris wasnt kidding...
18:48 atz_       chris: yeah...
18:47 chris      wow, what a crud pile to wake up too
16:28 liz        understanding*
16:28 liz        this was my undrstanding, thanks
16:25 gmcharlt   and the holds email notification in particular will make it in official 3.2
16:25 gmcharlt   yes
16:21 liz        hypothetically?
16:21 liz        that will go in the release version of 3.2?
16:21 gmcharlt   in which case settling on a common version makes sense
16:20 liz        that's what I thought
16:20 gmcharlt   barring cases where two groups contribute the same feature
16:20 liz        lets take as an example some enhancements you've done for us, say the holds email notify one
16:20 gmcharlt   ultimately, all contribs of sufficiently quality should make it in
16:20 gmcharlt   liz: what do you mean?
16:20 liz        up to the RM?
16:19 liz        So, how do we know if a given enhancement (purchased or contributed) is considered "canonical" enough for a version upgrade?
16:19 liz        question kind of in that vein
16:13 acmoore    oh, that's too bad.
16:13 owen       Our 27 year bookmobile feature was pencil and paper. Our bookmobile never lived to see offline circ.
16:12 acmoore    maybe it's like a volume knob that goes up to 11, instead of just 10.
16:11 acmoore    I guess the current implementation is only good for 26 years.
16:09 paul_p     hi owen
16:09 paul_p     ???
16:08 owen       "27 year bookmobile feature?"
12:46 gmcharlt   it's only 07:45, not that early ;)
12:46 paul_p     hi gmcharlt. early wake up for you it seems
12:46 gmcharlt   hi hdl
12:45 hdl        hi gmcharlt
12:45 hdl        hi gm
12:45 gmcharlt   hi paul_p
12:45 paul_p     hello world