IRC log for #koha, 2008-08-12

All times shown according to UTC.

Time S 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
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 to something like 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 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 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
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[…]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 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 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:[…]442a921a2e66d5b1d
04:00 cnighs appears to make the ver number 3.01 rather than 3.1
07:19 chris
11:21 gmcharlt_away cnighs: just the way the version string works - would have been Koha 3.10

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary