Time  Nick          Message
11:21 gmcharlt_away cnighs: just the way the version string works - 3.10.000.000 would have been Koha 3.10
07:19 chris         http://koha.org/about-koha/news/nr1218524472.html
04:00 cnighs        appears to make the ver number 3.01 rather than 3.1
04:00 cnighs        gmcharlt_away:http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commitdiff;h=1387904cdbc44173463c628442a921a2e66d5b1d
03:35 cnighs        especially in light of the total lack of an associated error in koha-error_log
02:38 chris         he's his own slashdot effect
02:37 gmcharlt      hee - finish a lap, make servers fall over
02:37 chris         thats what happens when he wins another gold
02:36 chris         load average: 54.08, 25.79, 17.04
02:36 chris         gah phelps
02:27 cnighs        hehe
02:27 chris         i never get phonecalls saying "nothing broke today, well done" :)
02:26 chris         heh yep
02:26 cnighs        as long as everything is running ok, the IT man is forgotten ;-)
02:25 chris         cool
02:25 cnighs        yep
02:25 chris         all up and going again?
02:25 cnighs        yeah, this one handles intranet streams, we use a hosting service to handle internet streams due to bandwidth issues
02:24 cnighs        bad motherboard, so I took the opportunity to move off of FC7 to Ubuntu server along w/some other upgrades
02:24 chris         i used to have radio.bigballofwax.co.nz running for a while .. but it takes a lot of work
02:24 chris         fun
02:23 gmcharlt      hi cnighs
02:23 chris         hey cnighs
02:22 cnighs        g'evening
02:19 gmcharlt      thanks!
02:19 chris         figure makes sense for the RM to be able to edit stuff in bugzilla
02:18 chris         you now have the power
02:16 chris         hmm yeah, 2 secs
02:15 chris         ohh first commit for 3.1 :)
02:14 chris         but it does suck in all the dependencies
02:14 chris         at the mo, you get a standard install, you have to edit the config file (to change db name and password etc) and make the database
02:13 gmcharlt      sweet
02:13 chris         id like to get it so if you go dpkg-reconfigure koha   you can add a new site
02:13 chris         rather than get the standard ones, and have to change them
02:12 chris         so that we can use debconf to allow the user to choose their passwords etc
02:12 chris         im working on the preinst and .config files
02:11 chris         theres still a little way to go before its ready for debian, at the moment it just does a standard install
02:11 gmcharlt      cool
02:11 chris         if vincent is still keen to do it, im more than willing to help him instead
02:11 chris         havent decided yet, im willing to do it if no one else wants to, i can get one of teh DD here to sponsor me/help
02:10 gmcharlt      as far as Debian project is concerned, will you be the DD responsible for the koha package, or will somebody else handle that?
02:10 chris         evenings too :)
02:09 chris         ill send some patches over the next few eveings
02:09 chris         that was my intention, was just waiting for the 3.0 branch
02:09 chris         sweet as
02:09 gmcharlt      chris: I'd like packaging stuff to live in the main repo if at possible
02:08 chris         gmcharlt: i currently have a packaging branch that has a debian dir, with rules, control files etc in it .. do you want that in the main repo, or shall i keep it seperate ?
02:06 gmcharlt      cool
02:06 chris         http://stuff.co.nz/blogs/passthesource/2008/08/12/last-post-richard-stallman-and-freedom/   <-- good quote here
02:05 chris         good :)
02:05 gmcharlt      cat has forgiven me
23:26 chris         itd be my pleasure
23:26 gmcharlt      chris++ for offering to be translation manager
23:21 chris         got a url rach?
23:20 chris         flower?
22:56 rach          I like the new little koha "flower" on the login screen for the intranet
21:23 pianohacker   chris++
21:22 chris         ok, released a 3.0  deb (actually 3.0.0-05) now i better get back to work
20:25 gmcharlt      hi hdl
20:25 hdl           hi gmcharlt
20:21 gmcharlt      morning chris
20:21 chris         morning
20:09 sharon        does anyone know why superlibrarian would be able to trigger overdue notices, but a staff account with schedule_tasks, edit_notices and edit_notice_status_triggers couldn't?  Is there another permission I need to have turned on?
18:47 nengard       yep
18:47 Sharon        or put the overdue report into the reports module, where it can be locked down
18:45 nengard       sharon that's an idea for a new permission - you're right there isn't one to stop people from clicking that link right now
18:33 Sharon        nevermind, figured it out.
18:32 Sharon        newbie question - is there a way to check an item's status (is it checked in, checked out, on hold, etc.)?
18:10 Sharon        I also noticed the new warning near the Overdue report, but there's no way to lock down access to that report that I can find.
18:08 Sharon        will do.
18:08 nengard       nicole.engard@liblime.com
18:08 nengard       sharon can you add me to the CC for the permission bugs you submit
18:07 Sharon        i can turn it off and then turn around and check something out to that account.
18:07 Sharon        will do.  another one I found is that the permission of "Borrow" doesn't do anything.
18:06 gmcharlt      ok - please file a bug, then
18:06 nengard       an = am
18:06 nengard       i too an visual
18:06 nengard       gmcharlt - i'm on the counterproductive side of things
18:06 Sharon        for a visual person like me, it confuses me.
18:05 gmcharlt      but perhaps moving them around is counterproductive
18:05 gmcharlt      meant to make it clear in one glance what permissions a patron has
18:05 Sharon        yep, that's what it's doing
18:05 gmcharlt      Sharon: that is in fact the case
18:05 Sharon        now i have to test something, it could be all the 'checked' features group themselves at the top, sort of a self-sort
18:04 gmcharlt      Sharon: possibly a bug for you to file
18:04 gmcharlt      Sharon: I suppose I can't pass it off as a feature to exercise one's mouse skills? :)
18:03 Sharon        the permissions. for example, "stage_marc_import" moved from near the bottom of the tools sub-menu to the top...in the last 30 minutes I've been working with them
18:02 gmcharlt      Sharon: order of what is changing?
18:01 Sharon        the order keeps changing on me.
18:01 Sharon        is working currently being done on granular patron permissions?
17:39 acmoore       OK, thanks!
17:38 gmcharlt      acmoore: for moment, rel_3_2
16:53 acmoore       I'm interested in opening a bug in bugzilla for an enhancement. What version do I specify in the "Version" field? rel_3_2, or HEAD, or something else?
16:09 nengard       bah - focus on equinox - will get koha 3.0 announcement in!!!
15:54 rhcl          And is that what the boldface type indicates?
15:53 rhcl          Ah
15:53 ryan          rhcl: it does assign a default, but the bug is still considered open until the assignee 'accepts' it.
15:52 rhcl          It appears that Koha bugzilla assigns a new bug to "somebody" by default; i.e., there is no open pool of bugs that coders select from for assignments?
15:51 ryan          nengard: thanks for testing
15:51 ryan          hrmm.  same process.
15:48 nengard       ryan i didn't get an error - what process did you go through?  i searched the catalog and clicked place hold and then searched for the patron and put a hold on the item - it worked a-ok
15:45 ryan          can anyone verify for me that placing a hold for any patron via the staff interface generates a 'patron card expired' warning  ?
14:14 gmcharlt      acmoore: yes, I will send an RFC
14:13 acmoore       OK. Do you think we should mention something about what idempotency means and some examples on the wiki or mailing list or something? I guess one would have to send out an RFC to the developers list before encouraging this kind of thing.
14:12 gmcharlt      acmoore: not just yet, but idempotency should be aimed for starting now
14:03 acmoore       gmcharlt: so, do you think we should start splitting out the SQL statements going forward?
13:59 kados         yea, the chances of us doing more than 9 versions is unlikely
13:59 gmcharlt      i.e., as far as sorting as concerned, we'll hit 4.0 before we hit a 3.11
13:58 nengard       hehe
13:58 kados         hehe
13:58 gmcharlt      kados: it's just silly ;)
13:58 kados         gmcharlt: should 3.0-maintenance be 3.00-maintenance, or is that just silly?
13:56 gmcharlt      idempotency++
13:55 acmoore       and they must be idempotent.
13:43 gmcharlt      and managed differently
13:43 gmcharlt      acmoore: although certain the SQL statements need to be split out
13:43 gmcharlt      acmoore: on other hand, advantage is that with one updatedatabase, same mechanism can support upgrade from 3.0 to Koha 7.2 in 2013
13:37 acmoore       perhaps it's not necessary and only adds complexity.
13:37 acmoore       kados: yep. the people upgrading from 3.0 to beyond don't really need the code that's in updatedatabase.pl right now. As it is, that file grows without bound. (I'm not arguing file size actually, but organization and complexity).
13:35 kados         acmoore: it could, or we could just rely on the different branches ... we'll also need updatedatabase to handle peopel upgrading from 3.0 to 3.1/3.2
13:34 acmoore       would it make it any easier to deal with database versioning stuff if we renamed updatedatabase.pl to something like updatedatabase-3.0.pl and made a new one?
13:33 hdl           Paul proposed that we took it.
13:32 kados         hdl: I'm not sure we have decided yet, I'm happy to do it if no-one else has time
13:28 hdl           Who took RMaint position ?
13:27 gmcharlt      as time passes, there may be a need for more patches done directly against 3.0-maint's tip
13:27 hdl           ok.
13:26 gmcharlt      and 3.0 RMaint is responsible for cherry-picking
13:26 gmcharlt      hdl: for now, I want to try a model where all patches are done against the 3.1/3.2 HEAD
13:26 hdl           gmcharlt: should we not add a tag to patch sent so that it can include the branch it is dedicated to ?
13:24 kados         most of the existing koha libraries will be quite happy with 3.0's functionality and stability, compared with 2.2 and dev_week IMO
13:23 acmoore       gmcharlt: good.
13:23 acmoore       kados: I hope you didn't have anything else planned for a while!
13:23 gmcharlt      acmoore: correct, patches@ is to stay unified for now
13:23 kados         I am happy to cherry pick off HEAD for 3.00.NN
13:23 kados         let the devs focus on developing good software :-)
13:22 acmoore       gmcharlt: OK. and we're not splitting the patches@ list, right?
13:22 kados         for now
13:22 kados         yea, put the burden on the RMaintainer
13:22 acmoore       kados: yep.
13:22 gmcharlt      acmoore: I'd prefer to hold off on sending separate patch versions until absolutely required
13:22 acmoore       gmcharlt: that's a great goal, but I'm certain we'll find something soon that needs to be fixed.
13:22 kados         acmoore: perhaps, if in your judgement the patch belongs in 3.0
13:21 acmoore       OK. I think we commiters can help you by also doing a format-patch against 3.0 and sending it to the the list.
13:21 kados         yep
13:21 gmcharlt      for the short-term, DB version updates for 3.0-maint should be frozen
13:21 kados         we will have to maintain two different versioning schemes, but that shouldn't be too hard, not too many of the updates will involve database updates I think
13:20 kados         acmoore: well, we won't know the patches are the same, so it will be up to me to comment heavily on the maintenance version pointing forward to the 3.2 git repo to establish the link
13:20 acmoore       SQL::something-or-orhter
13:20 kados         hehe
13:20 acmoore       I forget what it's called, but the tool that DBIx::Class uses behind the scenes apparently helps with that problem a lot.
13:19 acmoore       would the person who has experience with that please step forward? ;)
13:19 acmoore       for instance, if there are a handful of DB updates on the 3.1 branch, and then a bugfix DB update, we'll cherry pick htat one back to 3.0. But, we'll have to give it a new number there, I think. How do I know later that those two patches are the same?
13:19 gmcharlt      acmoore: a good reason to add a more sophisticated DB patch manager sooner rather than later
13:18 acmoore       I wonder what we'll do about DB version numbers on bugfixes. I don't think we can maintain the same DB version numbers in both versions, but we'll cherry pick some database updates back into 3.0 stable.
13:16 kados         heh
13:15 acmoore       is anyone taking bets on how many new people show up here this week to ask about new stuff in 3.0?
13:15 acmoore       hi hdl.
13:14 hdl           hi acmoore
13:14 gmcharlt      will be set up later today
13:14 gmcharlt      patches for 3.2 will go to HEAD
13:13 gmcharlt      hdl: branch will be for 3.0-maintenence
13:12 hdl           will there be a new branch for koha 3.2 ?
13:12 hdl           hi gmcharlt
12:57 acmoore       good moning.
12:52 gmcharlt      greetings #koha
12:50 kados         I've added a link to the 3.0 manual as it stands
12:50 kados         http://kohadocs.org/
12:46 hdl           (I can see none)
12:46 hdl           who is ?
12:46 hdl           could be in topic
12:46 kados         thanks hdl
12:44 hdl           Congratulations to koha3.0 release.
12:44 hdl           hi kados:
12:37 kados         hiya danny
12:31 danny         hello #koha