Time Nick Message 12:31 danny hello #koha 12:37 kados hiya danny 12:44 hdl hi kados: 12:44 hdl Congratulations to koha3.0 release. 12:46 kados thanks hdl 12:46 hdl could be in topic 12:46 hdl who is ? 12:46 hdl (I can see none) 12:50 kados http://kohadocs.org/ 12:50 kados I've added a link to the 3.0 manual as it stands 12:52 gmcharlt greetings #koha 12:57 acmoore good moning. 13:12 hdl hi gmcharlt 13:12 hdl will there be a new branch for koha 3.2 ? 13:13 gmcharlt hdl: branch will be for 3.0-maintenence 13:14 gmcharlt patches for 3.2 will go to HEAD 13:14 gmcharlt will be set up later today 13:14 hdl hi acmoore 13:15 acmoore hi hdl. 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:16 kados heh 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:19 gmcharlt acmoore: a good reason to add a more sophisticated DB patch manager sooner rather than later 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 acmoore would the person who has experience with that please step forward? ;) 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:20 kados hehe 13:20 acmoore SQL::something-or-orhter 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: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:21 gmcharlt for the short-term, DB version updates for 3.0-maint should be frozen 13:21 kados yep 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:22 kados acmoore: perhaps, if in your judgement the patch belongs in 3.0 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 gmcharlt acmoore: I'd prefer to hold off on sending separate patch versions until absolutely required 13:22 acmoore kados: yep. 13:22 kados yea, put the burden on the RMaintainer 13:22 kados for now 13:22 acmoore gmcharlt: OK. and we're not splitting the patches@ list, right? 13:23 kados let the devs focus on developing good software :-) 13:23 kados I am happy to cherry pick off HEAD for 3.00.NN 13:23 gmcharlt acmoore: correct, patches@ is to stay unified for now 13:23 acmoore kados: I hope you didn't have anything else planned for a while! 13:23 acmoore gmcharlt: good. 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:26 hdl gmcharlt: should we not add a tag to patch sent so that it can include the branch it is dedicated to ? 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 gmcharlt and 3.0 RMaint is responsible for cherry-picking 13:27 hdl ok. 13:27 gmcharlt as time passes, there may be a need for more patches done directly against 3.0-maint's tip 13:28 hdl Who took RMaint position ? 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:33 hdl Paul proposed that we took it. 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: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: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:37 acmoore perhaps it's not necessary and only adds complexity. 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:43 gmcharlt acmoore: although certain the SQL statements need to be split out 13:43 gmcharlt and managed differently 13:55 acmoore and they must be idempotent. 13:56 gmcharlt idempotency++ 13:58 kados gmcharlt: should 3.0-maintenance be 3.00-maintenance, or is that just silly? 13:58 gmcharlt kados: it's just silly ;) 13:58 kados hehe 13:58 nengard hehe 13:59 gmcharlt i.e., as far as sorting as concerned, we'll hit 4.0 before we hit a 3.11 13:59 kados yea, the chances of us doing more than 9 versions is unlikely 14:03 acmoore gmcharlt: so, do you think we should start splitting out the SQL statements going forward? 14:12 gmcharlt acmoore: not just yet, but idempotency should be aimed for starting now 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:14 gmcharlt acmoore: yes, I will send an RFC 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 ? 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:51 ryan hrmm. same process. 15:51 ryan nengard: thanks for testing 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:53 ryan rhcl: it does assign a default, but the bug is still considered open until the assignee 'accepts' it. 15:53 rhcl Ah 15:54 rhcl And is that what the boldface type indicates? 16:09 nengard bah - focus on equinox - will get koha 3.0 announcement in!!! 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? 17:38 gmcharlt acmoore: for moment, rel_3_2 17:39 acmoore OK, thanks! 18:01 Sharon is working currently being done on granular patron permissions? 18:01 Sharon the order keeps changing on me. 18:02 gmcharlt Sharon: order of what is changing? 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:04 gmcharlt Sharon: I suppose I can't pass it off as a feature to exercise one's mouse skills? :) 18:04 gmcharlt Sharon: possibly a bug for you to file 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:05 gmcharlt Sharon: that is in fact the case 18:05 Sharon yep, that's what it's doing 18:05 gmcharlt meant to make it clear in one glance what permissions a patron has 18:05 gmcharlt but perhaps moving them around is counterproductive 18:06 Sharon for a visual person like me, it confuses me. 18:06 nengard gmcharlt - i'm on the counterproductive side of things 18:06 nengard i too an visual 18:06 nengard an = am 18:06 gmcharlt ok - please file a bug, then 18:07 Sharon will do. another one I found is that the permission of "Borrow" doesn't do anything. 18:07 Sharon i can turn it off and then turn around and check something out to that account. 18:08 nengard sharon can you add me to the CC for the permission bugs you submit 18:08 nengard nicole.engard@liblime.com 18:08 Sharon will do. 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:32 Sharon newbie question - is there a way to check an item's status (is it checked in, checked out, on hold, etc.)? 18:33 Sharon nevermind, figured it out. 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:47 Sharon or put the overdue report into the reports module, where it can be locked down 18:47 nengard yep 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? 20:21 chris morning 20:21 gmcharlt morning chris 20:25 hdl hi gmcharlt 20:25 gmcharlt hi hdl 21:22 chris ok, released a 3.0 deb (actually 3.0.0-05) now i better get back to work 21:23 pianohacker chris++ 22:56 rach I like the new little koha "flower" on the login screen for the intranet 23:20 chris flower? 23:21 chris got a url rach? 23:26 gmcharlt chris++ for offering to be translation manager 23:26 chris itd be my pleasure 02:05 gmcharlt cat has forgiven me 02:05 chris good :) 02:06 chris http://stuff.co.nz/blogs/passthesource/2008/08/12/last-post-richard-stallman-and-freedom/ <-- good quote here 02:06 gmcharlt cool 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:09 gmcharlt chris: I'd like packaging stuff to live in the main repo if at possible 02:09 chris sweet as 02:09 chris that was my intention, was just waiting for the 3.0 branch 02:09 chris ill send some patches over the next few eveings 02:10 chris evenings too :) 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: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:11 chris if vincent is still keen to do it, im more than willing to help him instead 02:11 gmcharlt cool 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:12 chris im working on the preinst and .config files 02:12 chris so that we can use debconf to allow the user to choose their passwords etc 02:13 chris rather than get the standard ones, and have to change them 02:13 chris id like to get it so if you go dpkg-reconfigure koha you can add a new site 02:13 gmcharlt sweet 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:14 chris but it does suck in all the dependencies 02:15 chris ohh first commit for 3.1 :) 02:16 chris hmm yeah, 2 secs 02:18 chris you now have the power 02:19 chris figure makes sense for the RM to be able to edit stuff in bugzilla 02:19 gmcharlt thanks! 02:22 cnighs g'evening 02:23 chris hey cnighs 02:23 gmcharlt hi cnighs 02:24 chris fun 02:24 chris i used to have radio.bigballofwax.co.nz running for a while .. but it takes a lot of work 02:24 cnighs bad motherboard, so I took the opportunity to move off of FC7 to Ubuntu server along w/some other upgrades 02:25 cnighs yeah, this one handles intranet streams, we use a hosting service to handle internet streams due to bandwidth issues 02:25 chris all up and going again? 02:25 cnighs yep 02:25 chris cool 02:26 cnighs as long as everything is running ok, the IT man is forgotten ;-) 02:26 chris heh yep 02:27 chris i never get phonecalls saying "nothing broke today, well done" :) 02:27 cnighs hehe 02:36 chris gah phelps 02:36 chris load average: 54.08, 25.79, 17.04 02:37 chris thats what happens when he wins another gold 02:37 gmcharlt hee - finish a lap, make servers fall over 02:38 chris he's his own slashdot effect 03:35 cnighs especially in light of the total lack of an associated error in koha-error_log 04:00 cnighs gmcharlt_away:http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commitdiff;h=1387904cdbc44173463c628442a921a2e66d5b1d 04:00 cnighs appears to make the ver number 3.01 rather than 3.1 07:19 chris http://koha.org/about-koha/news/nr1218524472.html 11:21 gmcharlt_away cnighs: just the way the version string works - 3.10.000.000 would have been Koha 3.10