← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
12:31 | danny | hello #koha |
12:37 | kados | hiya danny |
12:44 | hdl | hi kados: |
12:44 | Congratulations to koha3.0 release. | |
12:46 | kados | thanks hdl |
12:46 | hdl | could be in topic |
12:46 | who is ? | |
12:46 | (I can see none) | |
12:50 | kados | http://kohadocs.org/ |
12:50 | 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 | will there be a new branch for koha 3.2 ? | |
13:13 | gmcharlt | hdl: branch will be for 3.0-maintenence |
13:14 | patches for 3.2 will go to HEAD | |
13:14 | will be set up later today | |
13:14 | hdl | hi acmoore |
13:15 | acmoore | hi hdl. |
13:15 | 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 | would the person who has experience with that please step forward? ;) | |
13:20 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | acmoore: although certain the SQL statements need to be split out | |
13:43 | 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 | 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 | 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 | 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 | 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 | 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 | i too an visual | |
18:06 | 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 | 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 | nicole.engardliblime.com | |
18:08 | Sharon | will do. |
18:10 | 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 | newbie question - is there a way to check an item's status (is it checked in, checked out, on hold, etc.)? | |
18:33 | 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 | 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 | http://stuff.co.nz/blogs/passt[…]lman-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 | that was my intention, was just waiting for the 3.0 branch | |
02:09 | ill send some patches over the next few eveings | |
02:10 | 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 | 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 | im working on the preinst and .config files | |
02:12 | so that we can use debconf to allow the user to choose their passwords etc | |
02:13 | rather than get the standard ones, and have to change them | |
02:13 | 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 | but it does suck in all the dependencies | |
02:15 | ohh first commit for 3.1 :) | |
02:16 | hmm yeah, 2 secs | |
02:18 | you now have the power | |
02:19 | 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 | 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 | 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 | i never get phonecalls saying "nothing broke today, well done" :) | |
02:27 | cnighs | hehe |
02:36 | chris | gah phelps |
02:36 | load average: 54.08, 25.79, 17.04 | |
02:37 | 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 | gmcharlt_away:http://git.koha.org/cgi-bin/gi[…]442a921a2e66d5b1d | |
04:00 | 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 |
← Previous day | Today | Next day → | Search | Index