2011-08-02T01:06:27 *** dbwells has quit IRC 2011-08-02T02:14:06 *** dbwells has joined #evergreen 2011-08-02T02:34:00 *** dbwells has quit IRC 2011-08-02T03:30:57 *** charltgm__ has joined #evergreen 2011-08-02T03:34:22 *** charltgm_ has quit IRC 2011-08-02T03:41:25 *** dbwells has joined #evergreen 2011-08-02T04:35:45 *** dbwells has quit IRC 2011-08-02T05:43:17 *** dbwells has joined #evergreen 2011-08-02T06:03:04 *** dbwells_ has joined #evergreen 2011-08-02T06:05:31 *** eeevil has quit IRC 2011-08-02T06:06:15 *** dbwells has quit IRC 2011-08-02T06:06:15 *** eeevil has joined #evergreen 2011-08-02T06:06:27 *** dbwells_ is now known as dbwells 2011-08-02T07:10:10 *** bjwebb has joined #evergreen 2011-08-02T07:10:10 *** bjwebb has joined #evergreen 2011-08-02T07:20:25 *** collum has joined #evergreen 2011-08-02T07:30:30 *** dbwells has quit IRC 2011-08-02T07:36:09 *** artunit_ has joined #evergreen 2011-08-02T07:37:07 *** artunit has quit IRC 2011-08-02T07:37:16 *** artunit_ is now known as artunit 2011-08-02T08:08:57 *** dbs has joined #evergreen 2011-08-02T08:08:57 *** dbs has joined #evergreen 2011-08-02T08:32:59 I threw an agenda for today's meeting together at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-08-02 and extended the calendar entries to 50 meetings. thanks for the heads-up tsbere 2011-08-02T08:35:19 dbs++ 2011-08-02T08:35:20 *** bjwebb has quit IRC 2011-08-02T08:35:44 Figured I would throw the TT OPAC discussion onto the agenda as it has had some heat recently 2011-08-02T08:36:08 Any thoughts as to what page on the dokuwiki I should throw a few "custom git commands" on? 2011-08-02T08:37:13 there's already a dev:git I think 2011-08-02T08:37:25 Wasn't sure if I should throw them there, or on a new page 2011-08-02T08:37:49 I'd say on dev:git, if that's going to be our canonical page for how Evergreen operates with git 2011-08-02T08:38:15 These are the pushworking/pushcollab/url scripts. I figure they should live somewhere other than paste.lisp.org. 2011-08-02T08:38:54 *** dbwells has joined #evergreen 2011-08-02T08:39:03 sounds good :) 2011-08-02T08:40:06 dbs++ # t-pac item 2011-08-02T08:41:18 berick: yeah, not sure if you have a better integration branch for the t-pac than my longish-in-the-tooth one 2011-08-02T08:42:15 dbs: i don't, but as long as branches are regularly merging w/ their parents, i'm not too concerned 2011-08-02T08:42:27 s/merging with/pulling from/ 2011-08-02T08:44:03 dbs: in regard to the conifer branches, i think they should all be merged w/ the possible exception of the ttopac-display-uris-and-cps, which I think needs some discussion before merging 2011-08-02T08:44:38 we tried to make them all merge-y 2011-08-02T08:45:47 Sure, I would be happy to discuss dispaly-uris-and-cps. Seems that there has to be a more sane way to get that result (although eeevil did post a link to a possible optimization for in-db unapi way back) 2011-08-02T08:46:35 i tested that patch. it may have helped large recs, i don't know, i'm still just worried about regular-sized records 2011-08-02T08:47:13 which it didn't affect 2011-08-02T08:48:23 *** bjwebb has joined #evergreen 2011-08-02T08:48:25 So just general sluggishness? 2011-08-02T08:51:46 right, 'acp' adds a good chunk of time to the query for records w/ modest numbers of copies. that alone may not be a deal breaker, but I think it could probably be faster 2011-08-02T08:51:55 i think more important is solveing the paging issue 2011-08-02T08:52:43 and providing a way to disable the feature, which is simple enough, once we decide on a path (org setting?) 2011-08-02T08:55:16 *** mrpeters-isl has joined #evergreen 2011-08-02T08:55:20 there's also the broader question of how best to leverage unapi. on the detail page, for now anyway, we are not using unapi for copy display, because it doesn't offer enough paging/sorting control at the cn/copy level 2011-08-02T08:56:18 org setting certainly seems like the right option for turning a given feature on/off; I think we had agreed that we would go that route as much as possible, tolerating TT settings in code as a stepping stone to OU settings 2011-08-02T08:56:58 Yeah, I still have no idea how to handle the display of circulating serials 2011-08-02T08:57:10 k. in some cases, though, where it does not affect the back-end, TT settings in the code may be better than managing a pile of UI-specific org settings 2011-08-02T08:57:39 but, meh 2011-08-02T08:57:55 if we're opening the door anyway, org settings are more flexible 2011-08-02T08:57:56 heh 2011-08-02T08:59:37 ultra-flexibility lives next door to flimsy :) 2011-08-02T08:59:53 it does 2011-08-02T09:01:02 *** Dyrcona has joined #evergreen 2011-08-02T09:01:07 where's our steve jobs? 2011-08-02T09:01:13 right here. 2011-08-02T09:01:18 excellent! 2011-08-02T09:01:29 swimming through his silo of cash 2011-08-02T09:01:36 * Dyrcona wishes. 2011-08-02T09:01:55 Dyrcona: your task is to tell us what is the one OU setting that we're allowed to keep; we have to get rid of all the rest of the OU settings. 2011-08-02T09:02:09 And the remaining one OU setting is only allowed to have one value. 2011-08-02T09:02:16 600 ou settings enter, 1 leaves 2011-08-02T09:02:31 * berick starts coding The Button to control it 2011-08-02T09:03:16 ui.read_my_mind 2011-08-02T09:04:04 http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git#helpful_scripts 2011-08-02T09:04:31 (later on, we'll add an OUS Store where you can buy additional, optional OU settings - once they have been approved by the cabal) 2011-08-02T09:05:22 At $1.00 each. 2011-08-02T09:05:52 circ.holds.angry_birds 2011-08-02T09:06:17 What is that, the person with the best angry_birds score gets their hold first? ;) 2011-08-02T09:06:38 now that's a hold-queuing scheme I can understand 2011-08-02T09:07:48 * Dyrcona is still waiting on the Xorg patches for focus follows mind. 2011-08-02T09:08:58 * dbs glares at conifer skin that, when you click "Advanced Search" on the home screen, changes the depth to 0 and bounces you back to the Home screen 2011-08-02T09:10:04 *** Meliss has joined #evergreen 2011-08-02T09:13:34 dbs does it kind of "flash" over to advanced search and then quickly back to home? 2011-08-02T09:13:58 mrpeters-isl: yep, looks rather like the org tree is out of sync 2011-08-02T09:14:03 *** dbwells has quit IRC 2011-08-02T09:14:36 you know, we have that often in FF. best thing I can tie it to is when the staff client has been running in the background for a long time. 2011-08-02T09:15:11 happening in Chromium and FF atm - and we just had some new libraries brought on board, so I'm guessing caching is an issue 2011-08-02T09:15:26 time to go read up on my blog post about caching :) 2011-08-02T09:19:43 *** jenny1 has joined #evergreen 2011-08-02T09:24:48 wow. everything I try resets the depth to 0 and pops me back to the home page. expired cookie wreaking havoc? 2011-08-02T09:25:02 (is this sounding like the issue that bshum's patron was having?) 2011-08-02T09:25:52 I think my patron is just broken. 2011-08-02T09:26:15 yeah - clearing the ses cookie solved the problem 2011-08-02T09:26:18 I tested a patron with over 250 copies checked out to them, and things were just fine. 2011-08-02T09:26:36 The ses cookie thing, I think I've seen that happen alot especially when using staff logins for report viewing 2011-08-02T09:26:45 Then trying to view the OPAC in the same browser session. 2011-08-02T09:27:39 and of course I keep browser sessions around for days 2011-08-02T09:27:45 I think that's why the cookies are cleared automatically now when you close out of the browser 2011-08-02T09:27:52 We lowered the time for the cookie 2011-08-02T09:28:41 right, session cookies last only for the duration that the browser is open 2011-08-02T09:28:49 * tsbere has seen session cookies do that after org tree changes before 2011-08-02T09:29:17 tsbere: that would be precisely the issue, in this case 2011-08-02T09:31:18 jeff: did you ever get your added content via record ID instead of ISBN branch working / submitted? 2011-08-02T09:31:55 mrpeters-isl: Bracket hell for POs. I really feel your pain now :( 2011-08-02T09:33:15 *** yboston has joined #evergreen 2011-08-02T09:34:44 bshum: did you test the patron with 250 copies checked out over a simulated dial-up connection? :) 2011-08-02T09:35:12 dbs: Heh, that's something I didn't get to account for, but it did cross my mind earlier this morning on the drive into work. 2011-08-02T09:35:22 Hmmmm 2011-08-02T09:35:38 * tsbere has noticed a problem with 950.data.seed-values.sql, in master at least 2011-08-02T09:35:54 Though truly, if this patron is using dial-up and calling himself a "web developer" I'd be a little sad for them. 2011-08-02T09:36:25 Still, will try to test that next time. Thanks dbs. 2011-08-02T09:36:54 config.metabib_field ids 29 and 90 have oils_i18n_gettext numbers of 28. Should I just fix and push, or should I fix, push to a working branch, and have someone sign off? 2011-08-02T09:36:57 *** charltgm_ has joined #evergreen 2011-08-02T09:37:58 tsbere: I think we're agreed that with something obvious like that, just fix and push 2011-08-02T09:38:29 tsbere++ 2011-08-02T09:38:59 fix_and_push++ 2011-08-02T09:38:59 all my fault :( 2011-08-02T09:39:22 mrpeters-isl: Damnit, I guess we can add question marks to the list of characters that POs die on. 2011-08-02T09:39:48 *** charltgm__ has quit IRC 2011-08-02T09:41:04 * dbs is "looking forward" to trying to set up acquisitions & EDI this fall 2011-08-02T09:42:50 dbs: Well, for whatever it's worth, mrpeters-isl, tspindler, and I have been poking at this doc that we'll be adding to wiki soon that details where we've gone so far with Acq and EDI. 2011-08-02T09:43:19 So at least you can try to catch up quick ;) 2011-08-02T09:44:35 bshum++ mrpeters-isl++ tspindler++ 2011-08-02T09:44:43 Right now I'm debugging our PO translations by hand. 2011-08-02T09:44:59 To parse out bad characters that prevent EDI messages from being created. 2011-08-02T09:45:01 sounds like some escaping needs to happen in either or both of the EDI scripts 2011-08-02T09:45:33 if éèà and the like are "bad", I don't wanna be good 2011-08-02T09:45:33 we need to add a custom filter to tt, something like this: https://github.com/nanto/perl-Template-Plugin-JSON-Escape/blob/master/lib/Template/Plugin/JSON/Escape.pm. that can be used inside the template for the PO JEDI event definition to avoid these problems, if i understand what's happening correctly 2011-08-02T09:45:53 not sure about the license on that particular implementation 2011-08-02T09:45:59 dbs: At the moment, I'm only hitting it on things like ", [, ], and ? 2011-08-02T09:46:13 dbs: Which says to me that some strange things are happening with the json string parsing 2011-08-02T09:46:14 but if it's a problem, whipping up something that accomplishes the same should not be a big deal 2011-08-02T09:57:52 bshum: ya, its bad. we're not going to be able to use ACQ until that stuff is fixed. 2011-08-02T09:58:03 i think we just have too many bibs with those special characters 2011-08-02T09:58:15 mrpeters-isl: I just pulled out brackets from the page number part of the PO output. 2011-08-02T09:58:26 mrpeters-isl: So it's not just titles either :) 2011-08-02T09:58:43 yeah, there are "workarounds" but for 90 libraries i won't be able to debug each po on a daily basis 2011-08-02T09:59:05 but, on the bright side i did successfully send a PO to B&T and they said it was perfect 2011-08-02T09:59:12 Sweet. 2011-08-02T10:00:32 * mrpeters-isl now has fun cleaning out all of the random "Providers" that got added but have no way of working due to no associated EDI Account 2011-08-02T10:06:46 *** rri has joined #evergreen 2011-08-02T10:20:03 *** dbwells has joined #evergreen 2011-08-02T10:23:41 *** _dkyle_1 has joined #evergreen 2011-08-02T10:27:15 *** dkyle has joined #evergreen 2011-08-02T10:27:40 *** _dkyle_1 has left #evergreen 2011-08-02T10:28:53 *** dkyle has quit IRC 2011-08-02T10:31:52 *** dkyle has joined #evergreen 2011-08-02T10:49:08 *** dbwells has quit IRC 2011-08-02T10:55:17 Anyone interested in my collection of aliases I use when testing stuff? 2011-08-02T10:59:13 * dbs isn't sure what that means 2011-08-02T11:00:59 http://paste.lisp.org/display/123735 2011-08-02T11:02:26 tsbere: nice! 2011-08-02T11:02:49 * dbs is interested to the limited extent that some of those might be suitable for standard Makefile targets 2011-08-02T11:03:31 90% of the time I end up using just reinstall or reinstall_reload in the end. Makes blowing in a new version for testing easier. 2011-08-02T11:05:14 * csharp wishes he had more time to experiment with Evergreen 2011-08-02T11:05:33 alas - supporting it takes up all my time atm 2011-08-02T11:10:24 *** SrTW has joined #evergreen 2011-08-02T11:10:29 *** SrTW has left #evergreen 2011-08-02T11:18:27 *** joseph_ has joined #evergreen 2011-08-02T11:20:08 *** bwicksall has joined #evergreen 2011-08-02T11:23:16 * berick grabs 0588 2011-08-02T11:26:31 * tsbere would test the locale generating issues in master and dbs's fix if he understood that process. At all. <_< 2011-08-02T11:26:42 Instead I guess I move onto something else 2011-08-02T11:27:00 Did moodaepo sign off on it yet? Maybe I should try it later.. 2011-08-02T11:27:10 tsbere: how about my "README complete" branch (includes a tiny fix to Makefile.install)? 2011-08-02T11:27:57 * tsbere looks for that one in the list 2011-08-02T11:27:59 http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/README-complete 2011-08-02T11:28:09 Just found the launchpad bug 2011-08-02T11:28:20 * tsbere likes to assign the launchpad bugs to himself when he is going to test them 2011-08-02T11:28:42 bshum: I have not signed-off but confirmed it in the launchpad bug entry - https://bugs.launchpad.net/evergreen/+bug/818270 2011-08-02T11:29:38 * moodaepo goes to check the dev:git page to lookup sign-off instructions 2011-08-02T11:30:10 *** bwicksall has quit IRC 2011-08-02T11:30:22 * dbs should probably add something to the README about bumping up memcached RAM allocation, but that's probably better suited for a more complex README.production document or something (along with NFS shares, multi-server configs, etc) 2011-08-02T11:31:32 * tsbere found out about the memcached bit there this past weekend and finally fixed it locally <_< 2011-08-02T11:35:27 * dbs lols at "config.xml_transform stores large chunks of XML. Fetching it angers Ejabberd on my test system" 2011-08-02T11:35:56 max_stanza_size not big enough? there are so many ways to anger ejabberd... 2011-08-02T11:38:08 dbs: You intend your README-complete to go back to 2.1 as well, or just for master for now? 2011-08-02T11:38:37 *** rogan_ has joined #evergreen 2011-08-02T11:38:49 * bshum waves hello at rogan_ 2011-08-02T11:39:26 dbs: Also, I think that the autogen.sh ref should probably become cachec-generator.sh 2011-08-02T11:39:57 tsbere: yep, it could be backported to rel_2_1 2011-08-02T11:40:35 well, for a correctly spelled cache-generator.sh 2011-08-02T11:41:40 also, as far as cache-generator.sh goes - I'm not convinced that we couldn't just roll that function into autogen.sh and avoid breaking 5 years of instructions 2011-08-02T11:42:43 * tsbere will push as-is for now and let the debate over autogen vs cache-generator happen later 2011-08-02T11:44:37 Hmmmm. Conflict in rel_2_1. Hmmmmm..... 2011-08-02T11:45:02 tsbere: Would it be ok to have an alias autogen to cache-generator so the docs will be valid but in future docs we refer to it as cache-generator? 2011-08-02T11:45:40 moodaepo: cache-generator.sh *calls* autogen.sh, uses the autogen.sh output, and then writes a cache key. 2011-08-02T11:45:41 Also I can't find instructions for folks testing patches to just sign-off...help? 2011-08-02T11:45:56 Ah ok 2011-08-02T11:47:03 moodaepo: sort-of http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git#adding_a_sign-off_to_a_new_feature_in_a_collab_branch 2011-08-02T11:47:04 Never mind think I found something.. 2011-08-02T11:47:52 except I'm not really a fan of the "commit --amend -s" approach, that only works if there's only one commit to sign off on in the entire branch 2011-08-02T11:49:47 I'm wondering about the process (with git) to make patches/commits for multiple branches (rel_2_0, tag_2_0_7, rel_2_1, &c) 2011-08-02T11:51:15 * dbs generally creates branches like /user/dbs/feature-master, /user/dbs/feature-2_0, /user/dbs/feature-2_1 if they're supposed to be backported 2011-08-02T11:51:42 Then you commit -as and then format-patch and attach to your bugs in LP? 2011-08-02T11:51:45 dbs: So after the amend do I push it to a new working branch of my own? 2011-08-02T11:52:19 moodaepo: /me would recommend "git checkout -b local_branch_name origin/master" and "git cherry-pick -s " for each commit that you want to sign off on in your local branch 2011-08-02T11:52:31 and then push it to a new working branch of your own, yes 2011-08-02T11:52:59 (sub origin/master for the appropriate core branch that you're applying the commits against, naturally) 2011-08-02T11:53:09 dbs++ # Now to see if I have access to creating a branch 2011-08-02T11:53:43 edoceo: I don't format-patch, because I push working branches to git.evergreen-ils.org 2011-08-02T11:53:47 dev meeting in 7 mins? 2011-08-02T11:54:13 and yes, I "commit -s" (sometimes "commit -as") as I work on those branches, before pushing them 2011-08-02T11:54:22 Dyrcona: yep, that's the rough plan 2011-08-02T11:54:38 Dyrcona: Yup dbs threw together a quick agenda do you have anything to add? http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-08-02 2011-08-02T11:57:37 * dbs goes to grab foods 2011-08-02T11:58:36 *** dbwells has joined #evergreen 2011-08-02T12:00:52 tsbere: I don't think I have access to pushing to working could you check when you get a chance? Graci! (I have access to Evergreen_Website) 2011-08-02T12:01:33 nope. wanted to talk about TT OPAC, too. 2011-08-02T12:01:33 who's going to run this meeting? 2011-08-02T12:01:55 * moodaepo Signs up 2011-08-02T12:02:37 Ok folks meeting time! 2011-08-02T12:02:43 moodaepo++ 2011-08-02T12:02:48 * berick checks in 2011-08-02T12:02:56 * mrpeters-isl checks in 2011-08-02T12:03:05 moodaepo++ 2011-08-02T12:03:06 * tsbere checks in 2011-08-02T12:03:18 Oh, and moodaepo: You have access if you have a key on the server *at all* 2011-08-02T12:03:20 * phasefx here 2011-08-02T12:03:26 Any volunteers for notes? 2011-08-02T12:03:56 moodaepo: I'll help with notes. 2011-08-02T12:04:02 bshum++ 2011-08-02T12:04:19 Moving on to action items 2011-08-02T12:04:31 * Dyrcona goes for a plate. 2011-08-02T12:04:34 * eeevil here 2011-08-02T12:04:42 gmcharlt: Any updates on LP 740320 and LP 520175? 2011-08-02T12:04:44 * senator is here 2011-08-02T12:04:48 * joseph_ aqui 2011-08-02T12:05:29 * Dyrcona has returned 2011-08-02T12:06:54 moodaepo: 740320 - eeevil had assigned that to himself - any updates? 2011-08-02T12:07:11 *** edoceo has quit IRC 2011-08-02T12:07:22 no update, cut I can merge that into trunk today 2011-08-02T12:07:33 eeevil++ 2011-08-02T12:07:49 s/cut/but 2011-08-02T12:07:59 eeevil++ 2011-08-02T12:08:00 520175 - will compare with work that Bob Wicksall did, merge probably not until Thursday/Friday 2011-08-02T12:08:21 gmcharlt++ 2011-08-02T12:08:48 Then moving on to LP 787162, LP 758945 - gmcharlt 2011-08-02T12:10:43 Actually looking at 787162 it's assigned to joseph_ 2011-08-02T12:10:46 Any updates? 2011-08-02T12:11:29 I see it as assigned to nobody... 2011-08-02T12:11:53 it is now assigned to gmcharlt as of 30 secs ago 2011-08-02T12:11:55 * gmcharlt has just assigned 787162, looks mergeable in the next day or two 2011-08-02T12:12:12 gmcharlt++ dbs++ 2011-08-02T12:12:18 joseph_: you commented about something hardcoded? 2011-08-02T12:12:38 Ah, yes, I believe it was an i18n issue. 2011-08-02T12:13:21 * dbs can help with that, but couldn't find the hardcoded string when he skimmed over the patch 2011-08-02T12:14:01 * joseph_ Is baffled at what the comment refers to :) 2011-08-02T12:14:10 758945 - is Jason BOyer about? 2011-08-02T12:14:15 he's not 2011-08-02T12:14:26 hah 2011-08-02T12:14:27 * gmcharlt was lazily wondering if the patch was sitting in a Git repo 2011-08-02T12:14:29 joseph_++ 2011-08-02T12:14:41 i'll add it to one and let him know i did 2011-08-02T12:15:44 *** dbwells has quit IRC 2011-08-02T12:16:33 So just to clarify for notes the patch is available for 758945 and there is no hardcoded value issues? 2011-08-02T12:17:35 gmcharlt: will update bug with repo, pullrequest later today 2011-08-02T12:17:44 *** mrpeters-isl has left #evergreen 2011-08-02T12:17:48 *** mrpeters-isl has joined #evergreen 2011-08-02T12:17:50 whoops 2011-08-02T12:18:06 mrpeters-isl: don't bother, I'm pushing it in a moment after I finish testing 2011-08-02T12:18:09 ok 2011-08-02T12:19:36 Next item is about pullrequests review meeting. I assume gmcharlt will bring it up on the mailing list when he gets a chance (unless I missed the discussion) 2011-08-02T12:20:06 I think it was an unresolved action item from last time too 2011-08-02T12:20:15 Looking for a volunteer to get that ball rolling 2011-08-02T12:20:20 Well gmcharlt or a volunteer to be found. 2011-08-02T12:20:43 well, let's do a straw poll 2011-08-02T12:21:09 who's in favor of trying a meeting dedicated to just pullrequests, say next Tuesday? 2011-08-02T12:21:22 * mrpeters-isl is 2011-08-02T12:21:24 +1 2011-08-02T12:21:26 +1 2011-08-02T12:21:29 +1 2011-08-02T12:21:33 +1 2011-08-02T12:21:43 +1 2011-08-02T12:21:43 idea would be to (a) try pushing through them and (b) get the non-major pullrequests off the dev mtg agenda 2011-08-02T12:21:51 * dbs notes that he will be on vacation next Tuesday, but I am in favour 2011-08-02T12:22:05 in principle 2011-08-02T12:22:09 s/vacation/working vacation/? ;) 2011-08-02T12:22:13 +1 2011-08-02T12:22:19 gmcharlt++ 2011-08-02T12:22:29 definitely a non-working vacation :) 2011-08-02T12:22:36 ok, 12:00 p.m. EDT? 2011-08-02T12:22:50 +1 2011-08-02T12:22:58 +1 2011-08-02T12:23:11 +1 2011-08-02T12:23:38 gmcharlt: This would be mostly for core devs? (12 EST works fine for me if I have to be there) 2011-08-02T12:23:44 +1 2011-08-02T12:23:51 +1 2011-08-02T12:24:21 * tsbere assumes that anyone who can test stuff is useful 2011-08-02T12:24:22 moodaepo: it would be for anybody who can sign off on patches, but yes, main goal is for the core devs to clear the pullrequest queue 2011-08-02T12:24:44 Ok So pullrequests meeting next Tuesday at 12 EST 2011-08-02T12:25:34 Last action item phasefx tsbere any updates on git commands? 2011-08-02T12:25:38 * phasefx defers to tsbere 2011-08-02T12:25:46 * tsbere points at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git#helpful_scripts 2011-08-02T12:26:22 tsbere++ 2011-08-02T12:26:27 tsbere++ # Ah right you posted that earlier on IRC 2011-08-02T12:26:36 And next to the action item <_< 2011-08-02T12:26:51 *** dbwells has joined #evergreen 2011-08-02T12:27:06 Ok TT OPAC discussion - dbs eeevil berick 2011-08-02T12:27:31 let's merge it 2011-08-02T12:27:33 moving on! 2011-08-02T12:27:34 ;) 2011-08-02T12:27:39 +1 2011-08-02T12:27:48 berick++ 2011-08-02T12:27:52 hah 2011-08-02T12:28:04 "it" being which branch / set of branches? 2011-08-02T12:28:58 some TT-supporting QP work coming soon (likely from senator) to deliver a easy-to-use serialization of the QP instance structure ... my update is complete :) 2011-08-02T12:29:23 eeevil: Any rough dates for 2.2? 2011-08-02T12:29:25 we're discussing putting some resources into tt-opac here. 2011-08-02T12:29:25 i'd like to do one more quick review, but I think esi/templtate-toolkit-opac plus all of the conifer topic branches, minus ttopac-display-uris-and-cps until it's done 2011-08-02T12:29:34 * dbs didn't know if senator's reference to equinox work on tt-opac meant that that was actually ongoing or dating back to pre-Conifer hack-infestation 2011-08-02T12:29:46 good to know 2011-08-02T12:30:07 eeevil: QP? my brain fails me 2011-08-02T12:30:57 dbs: Quantum Physics, I'm sure ;) 2011-08-02T12:30:58 QueryParser 2011-08-02T12:31:01 heh 2011-08-02T12:31:07 @google QP 2011-08-02T12:31:07 moodaepo: Error: "google" is not a valid command. 2011-08-02T12:31:16 Qatar Petroleum 2011-08-02T12:31:29 berick: do you have any thoughts about alternatives to unapi for display-uris-and-cps, or is the outstanding work on that the need for OUS to enable/disable it? 2011-08-02T12:31:30 QP = Quality Progress 2011-08-02T12:31:48 * dbs time-travelled to "Query Patroller" (DB2 product) 2011-08-02T12:32:01 moodaepo: no, QueryParser 2011-08-02T12:32:03 sorry 2011-08-02T12:32:10 looked away 2011-08-02T12:32:24 dbs: i'd like to stick w/ unapi if at all possible for consistency, etc, so my only thoughts so far has been to improve the current implementation 2011-08-02T12:32:28 dates for 2.2 ... ha! 2011-08-02T12:33:02 oh, I have a patch that makes unapi2 easier to use, btw, and marginally faster 2011-08-02T12:33:06 berick: okay, cool - maybe open a bug against the branch with some comments about what needs to be done, once the rest is merged? 2011-08-02T12:33:15 I'll push a branch soon 2011-08-02T12:33:45 eeevil: we're all skipping 2.1, so we only care about 2.2 :) 2011-08-02T12:33:46 eeevil: any thought toword nested object paging? IOW, give me at most 5 callnumbers and on each give me at most (say) 10 copies 2011-08-02T12:34:18 berick: that's what the patch provides 2011-08-02T12:34:29 mmm, nice 2011-08-02T12:34:31 awesome 2011-08-02T12:34:44 via a bitmask, hopefully 2011-08-02T12:34:47 dbs: I'll open a bug 2011-08-02T12:34:51 dbs: heh 2011-08-02T12:34:54 * moodaepo heard KCLS was going to go to 2.1 2011-08-02T12:35:09 moodaepo: they are w/ tt-pac, no less 2011-08-02T12:35:16 Ok folks anymore TT OPAC discussion to be had? 2011-08-02T12:35:36 Dyrcona: you said MVLC was going to be doing some testing, you have what you need? 2011-08-02T12:36:01 Dyrcona stepped away from his desk for a moment 2011-08-02T12:36:06 cool 2011-08-02T12:36:15 If he doesn't he can ask later, I suppose ;) 2011-08-02T12:36:21 tsbere++ 2011-08-02T12:36:22 A few other thoughts about what we're losing via tt-pac 2011-08-02T12:36:28 opensearch? 2011-08-02T12:36:46 links to atom / rss feeds? 2011-08-02T12:37:05 dbs: no losing, just TODOs, no? 2011-08-02T12:37:12 eeevil: losing until TODONE 2011-08-02T12:37:15 heh 2011-08-02T12:37:16 he 2011-08-02T12:37:17 k 2011-08-02T12:37:19 back. 2011-08-02T12:37:25 right, should they block merging is the question 2011-08-02T12:37:39 I don't think it should block merging, just wanted to get it on the radar 2011-08-02T12:37:55 If goal 1 is "replace slimpac"....how many of those does slimpac have? 2011-08-02T12:38:03 well, we're not losing opensearch, just need to put the description doc in there 2011-08-02T12:38:13 if tt-opac and relevant branches are meged, we'd be more able to add some developer time to it. 2011-08-02T12:38:22 tsbere: it has opensearch and links to atom/rss feeds 2011-08-02T12:38:41 it /is/ opensearch and feeds ;) 2011-08-02T12:38:48 we've got some cash and plan to hire someone part time to start, and tt-opac is one project we're considering putting them on. 2011-08-02T12:38:54 so, replace is the wrong term ... 2011-08-02T12:39:06 Dyrcona++ 2011-08-02T12:39:24 nice 2011-08-02T12:39:35 as for testing, i just loaded the equinox branch and not others yesterday. if you have something specific that you want me to look at, let me know. 2011-08-02T12:39:39 "obviate the need for any html transforms in the slimpac" might be closer to the truth 2011-08-02T12:40:36 it sounds like we need a single pre-master merge branch for testing (a la conifer -merge branch). unless someone else wants it, I can get that set up. 2011-08-02T12:40:56 berick++ 2011-08-02T12:41:06 berick++ 2011-08-02T12:41:06 *** edoceo has joined #evergreen 2011-08-02T12:41:15 i can definitely test a pre-merge branch. 2011-08-02T12:42:18 any preference on where said branch lives? 2011-08-02T12:42:27 * dbs has no pref 2011-08-02T12:42:28 So berick will setup a pre-master TT OPAC branch and we will re-visit this in two weeks? (Hopefully Dyrcona gets time to test by then,) 2011-08-02T12:42:33 me, no? just soemone I can get. 2011-08-02T12:42:48 someone++ 2011-08-02T12:43:03 i will be on vacation with no immediate wifi for two weeks starting the 13th. 2011-08-02T12:43:23 oops. s/someone/somewhere/ 2011-08-02T12:43:31 berick: probably a stupid question, but are skins/locales settable via GET params or URI? (not right now but with a minimum of TT hackery) 2011-08-02T12:44:50 dbs: not yet. definitely another TODO 2011-08-02T12:45:09 * dbs was thinking of running multiple apache instances, each with their own oils_web.xml config file, but that would be a nasty hack 2011-08-02T12:46:31 presumably we want skins to leverage the override path behavior 2011-08-02T12:47:00 yep, for sure 2011-08-02T12:47:21 one approach would be to register skins in oils_web and for each skin, specifiy one ore more pre-paths 2011-08-02T12:47:23 I'd like to move on to patch review now unless someone has a big protest sign. 2011-08-02T12:47:32 paths that are shoved onto the front of the default override paths 2011-08-02T12:47:50 moodaepo: well, as long as berick and I (and anyone else) can hash this out sometime 2011-08-02T12:48:09 multiple skins on a single t-pac instance is pretty important to us 2011-08-02T12:48:09 dbs++ berick++ 2011-08-02T12:48:33 Or we can always set patch review to next week's pullrequest meeting. 2011-08-02T12:48:40 bshum++ 2011-08-02T12:48:52 And talk more about TT-OPAC stuff :) 2011-08-02T12:49:08 (or just listen in some cases) 2011-08-02T12:49:19 Was there anything else on the agenda? 2011-08-02T12:49:47 In which case the only thing to go over would be Evergreen release statuses - any updates? 2011-08-02T12:49:51 bshum: patch review and release statuses 2011-08-02T12:49:54 * Dyrcona would like to talk about tt-opac some more after the meeting and how best to spend US$10,000 (while it is still worth something) to get tt-opac closer to TODONE. :) 2011-08-02T12:50:25 eeevil: bshum proposed moving over patch review to next weeks pullrequest meeting (I second that) 2011-08-02T12:50:38 i third that. 2011-08-02T12:50:41 oh 2011-08-02T12:50:42 do we need to get a 2.0.8 release out before next week? 2011-08-02T12:50:44 sorry, sure 2011-08-02T12:50:58 dbs: probably 2011-08-02T12:51:00 that's the only case where we'd want to focus on 2.0-specific patches 2011-08-02T12:51:18 yeah, lots of stuff built up in 2.0.8 2011-08-02T12:51:54 I'll rebroadcast my request for series/milestone targetting (especially for bugs w/ patches, and especially for 2.0 bugs!) 2011-08-02T12:52:00 dbs: We want to cut 2.0.8 this week? 2011-08-02T12:52:16 that'll really help organize patch/branch pushing 2011-08-02T12:52:39 so, if you own or submitted a bug, purty please target it? 2011-08-02T12:53:08 *** jamesrf has joined #evergreen 2011-08-02T12:53:24 * tsbere appears to have a nominate button for series, nothing for milestone? 2011-08-02T12:53:40 oh, wait, there is a target to milestone above that 2011-08-02T12:53:44 yeah 2011-08-02T12:53:47 *** dbwells has quit IRC 2011-08-02T12:54:05 pity that it's not a multi-select 2011-08-02T12:54:39 pity that milestones don't tie to series 2011-08-02T12:54:39 * dbs targets a couple of bugs for 2.0 series 2011-08-02T12:54:45 dbs++ 2011-08-02T12:54:59 So eeevil will rebroadcast request and we cut end of this week? 2011-08-02T12:55:04 *** brian_f has joined #evergreen 2011-08-02T12:55:12 eeevil: target to the 'newest' milestone, then nominate for series for the desired backports work? 2011-08-02T12:55:48 or other way around? 2011-08-02T12:56:10 gmcharlt: if it's a bug fix, nominate to all series (or target if you have that) and then target to the appropriate milestone within the series 2011-08-02T12:56:25 s/all series/all series that need it/ 2011-08-02T12:56:37 if it's a new feature, target to master series (IMO) 2011-08-02T12:57:34 * dbs gets woozy 2011-08-02T12:57:44 crap ... I edited the wrong bug 2011-08-02T12:57:49 hah 2011-08-02T12:57:51 I think bug team folks can only target to milestones and suggest nominate for series for the release team managers. I'll remember to do that for bugs I come across that I think should point to specific series then... 2011-08-02T12:58:22 So for the notes 2.0.8 status? 2011-08-02T12:59:02 eeevil: nominating to all relevent series is easy 2011-08-02T12:59:17 but since (unless I"m missing something) you can target a bug to only one milestone 2011-08-02T12:59:30 gmcharlt: one milestone per targetted series 2011-08-02T12:59:43 so for something that's really destined for 2.2 (or 2.3, etc.), we need to flag that as such? and lack of a flag means it's undecided where it's supposed to land? 2011-08-02T12:59:52 gmcharlt: IIUC 2011-08-02T13:00:12 phasefx: master ... we have one feature receptical ;) 2011-08-02T13:00:25 * moodaepo notes that the meeting is reaching the one hour mark 2011-08-02T13:00:47 not-master series are for "bugfix only" 2011-08-02T13:01:04 hrmm.. so once there is a 2.2 branch, it's feature-frozen out of the gate? 2011-08-02T13:01:05 ok ... so, 2.1-rc2. can I? should I? 2011-08-02T13:01:25 phasefx: once it goes into beta 2011-08-02T13:01:26 eeevil: At least one bug I think needs to be fixed first 2011-08-02T13:01:28 * phasefx is game for that, fwiw, since master is more stable than it used to be 2011-08-02T13:01:43 eeevil: Or reviewed, as the case may be 2011-08-02T13:01:44 eeevil: gotcha -- though targetting the milestone can be done only by release team 2011-08-02T13:01:48 gmcharlt: The members of https://launchpad.net/~evergreen-release have the powers to assign series targets. 2011-08-02T13:02:11 gmcharlt: really? bah ... let's all be release team members! 2011-08-02T13:02:39 eeevil: agreed - I think all core committers should be, at least, and probably all bug warnglers, too 2011-08-02T13:02:41 tsbere: I'll wait on a targetted bug from you sir! (or nominated, I guess) 2011-08-02T13:02:41 eeevil: So 2.1-rc2 next week? 2011-08-02T13:02:50 moodaepo: or some time 2011-08-02T13:03:03 eeevil: I targeted it (on the main list, because I can only nominate for 2.1 right now). 2011-08-02T13:03:10 that's my question ... I get ready to pull the trigger and see a pile come in (GOOD!) 2011-08-02T13:03:22 * dbs can add bug-wranglers team to release-team 2011-08-02T13:03:27 is there a sense that it's stablized, then? 2011-08-02T13:03:54 I think that has a lot more power beyond just targeting series though 2011-08-02T13:03:57 With that I am tempted to declare meeting adjourned....objections? 2011-08-02T13:04:52 dbs: probably ... we can't just give series targetting to non-release-team? 2011-08-02T13:04:56 moodaepo: none 2011-08-02T13:04:57 Ok next meeting will be in two weeks (agenda page needs to be updated) since the pull requests meeting will be next week. Thanks all. 2011-08-02T13:05:02 are we sure bug-wranglers don't have the ability to target series? 2011-08-02T13:05:13 dbs: Oh very sure 2011-08-02T13:05:21 bah 2011-08-02T13:05:28 I started putting tags of 2.0 / 2.1 on things to keep track on my own 2011-08-02T13:05:32 * tsbere knows he doesn't, but doesn't know what groups he is in now 2011-08-02T13:05:48 eg-release-team is currently just dbs, eeevil, and Dyrcona 2011-08-02T13:05:49 tsbere: you're a bug wrangler 2011-08-02T13:05:50 moodaepo: I'll update the various pages. 2011-08-02T13:06:02 who wants to get off launchpad? 2011-08-02T13:06:05 * dbs ducks 2011-08-02T13:06:07 moodaepo++ for attempting to bring us all in on schedule 2011-08-02T13:06:21 is there a queue of nominations? 2011-08-02T13:06:24 back to bugzilla we go :) 2011-08-02T13:06:24 dbs: BZ instead? ;) 2011-08-02T13:06:30 can't find it if there is 2011-08-02T13:07:04 dbs: I have no problems with ditching launchpad.....provided we have a replacement and don't lose the open bugs *on* launchpad 2011-08-02T13:07:15 moodaepo++ 2011-08-02T13:07:17 bshum++ 2011-08-02T13:07:36 Right, is there any way to migrate existing information? 2011-08-02T13:07:56 We're still trying to get a handle on all the dusty bug reports 2011-08-02T13:08:02 https://help.launchpad.net/Projects/SeriesMilestonesReleases says "only a project owner, series release manager or bug contact can target a bug or blueprint to a milestone: other people cannot nominate a chunk work for a milestone" 2011-08-02T13:08:22 is our problem with launchpad as a service, or as software? I believe we can run it ourselves if it's the former 2011-08-02T13:08:22 bshum: there is, there's an API 2011-08-02T13:09:05 I don't actually have a problem with launchpad, other than occasionally its assumed workflow conflicts with ours 2011-08-02T13:09:38 phasefx: definitely the latter 2011-08-02T13:09:38 Has anyone had experience with Redmine as a tracker? I'm a big fat of that one 2011-08-02T13:09:43 *fan 2011-08-02T13:09:51 * phasefx notices delays with email, but thinks that intentional (to consolidate actions around a ticket) 2011-08-02T13:09:53 "Only the bug supervisor for a project can nominate a bug or blueprint as affecting a particular series with the Nominate for release link." 2011-08-02T13:10:05 phasefx: yeah, I think that's intentional too 2011-08-02T13:11:43 * dbs thinks that all bug tracking systems suck, and really doesn't want to waste energy on migrating to a different one that sucks differently 2011-08-02T13:11:55 dbs +1 2011-08-02T13:12:12 dbs: sometimes emails seem to come out right away though, as in things changed during the dev meeting. 2011-08-02T13:12:14 dbs wants to write his own ;) 2011-08-02T13:12:14 dbs: agreed 2011-08-02T13:12:50 as an OpenSRF service. bug tracker goes down, you know what to work on 2011-08-02T13:13:49 phasefx: Fossil. it's a distributed bug-tracking / wiki / code-management system; you can work disconnected then sync your work up centrally 2011-08-02T13:13:49 heh 2011-08-02T13:15:10 * phasefx remembers reading Fossil irked someone and they left it 2011-08-02T13:15:13 Perhaps gmcharlt's suggestion to include all core committers as part of the release managers team would be a good start for now. Followed by any bug wranglers deputized by Dyrcona (big cheese). Until we further explore alternatives to LP. 2011-08-02T13:17:02 phasefx: yes, I linked to that I think 2011-08-02T13:17:18 * dbs can't believe that one person, somewhere, had a bad experience with one project 2011-08-02T13:17:25 I know 2011-08-02T13:17:30 crazytown 2011-08-02T13:17:31 and _blogged_ about it! 2011-08-02T13:17:36 No! 2011-08-02T13:17:41 what kind of world do we live in? 2011-08-02T13:17:52 * edoceo leaves planet 2011-08-02T13:17:58 need to join the tweeting masses.. complain in 40 characters or less 2011-08-02T13:18:53 *** wolf29 has joined #evergreen 2011-08-02T13:19:00 * tsbere is part of the tweeting masses.....and almost never tweets, despite a growing list of followers 2011-08-02T13:19:30 * dbs has disconnected identi.ca -> twitter replication, thus no more tweets 2011-08-02T13:19:31 tweeting appears to be one of the more evil timewasters, tsbere 2011-08-02T13:20:03 I have twitter to follow others. Mostly. Even then I ignore 90% of what goes by. 2011-08-02T13:20:08 dbs: will this give me all the conifer t-pac branches? git branch -a | grep "dbs/tt" 2011-08-02T13:20:11 and happily fedora's latest chromium updates make it crash on plus.google.com so no more G+ for me (not sure if csharp is getting hammered by that too) 2011-08-02T13:21:21 berick: looks like it 2011-08-02T13:21:31 dbs: thanks. should any be ignored? 2011-08-02T13:22:30 user/dbs/tt-opac-perl-prereqs got merged I think? 2011-08-02T13:22:32 I'm trying to make patches against the 2.0.x and 2.1.x branches - I've got a `git clone` of evergreen but I'm unsure how to properly switch branches around - to generate a patch against "remotes/origin/rel_2_0" for example. 2011-08-02T13:23:09 If I wanted to get patches ready for the next 2.0 and also the 2.1 release (or stuff that others could use) - am I in the correct branches? 2011-08-02T13:23:18 edoceo: git checkout rel_2_0 should be enough in that case 2011-08-02T13:23:25 dbs: k. if so, it shouldn't be a problem. 2011-08-02T13:23:35 will keep an eye out, though 2011-08-02T13:23:41 berick: actually, no, that wasn't merged 2011-08-02T13:23:43 * tsbere likes that git checkout when that branch doesn't exist will auto-clone origin/ 2011-08-02T13:23:45 merge'em'all 2011-08-02T13:23:50 So, that would switch my local/working - rigth? I hack, `commit -as` and then `format-patch` for LP? 2011-08-02T13:24:03 general note to folks whose Git username is of the form foo@example.org - if you would prefer to have a shorter name (specifically, your IRC nick), please drop a line to gitadmin@evergreen-ils.org 2011-08-02T13:24:04 The I would `git checkout rel_2_1` and repeat? 2011-08-02T13:24:23 *** dbwells has joined #evergreen 2011-08-02T13:24:27 should result in something approaching /user/dbs/template-toolkit-integration-on-master (but more up to date, and possibly more conflict-y) 2011-08-02T13:24:44 edoceo: At that point you may want to get us a SSH key so you can just push to the working repos. Makes it easier for us to grab your patches. 2011-08-02T13:25:19 dbs: yep, that's about what I'm expecting 2011-08-02T13:25:55 tsbere: I don't have perms for that (yet) - and I've not been around long enough to deserve that (I don't think) 2011-08-02T13:26:24 * berick thinks food is a super idea 2011-08-02T13:27:45 What I think is odd, maybe just because I'm still pretty new to git is that after I switch my branch, my edits are still there - so I need to switch & some how revert, to then re-create the patch-set (it seems) 2011-08-02T13:27:46 edoceo: The working repos don't need anything special, due to a lack of being allowed to do anything dangerous by default. 2011-08-02T13:27:48 edoceo: working repos are just a communication mechanism 2011-08-02T13:28:13 edoceo: try git stash before switching. 2011-08-02T13:28:24 might take away commit access if you're committing illegal material / petabytes of crud, but otherwise ... :) 2011-08-02T13:29:04 Or constantly adding meaningless stuff to collab branches. Although then I might just make a "no collab for you" permission group. 2011-08-02T13:29:35 speaking of collab.... 2011-08-02T13:29:43 berick: did you already escape to the food farm? 2011-08-02T13:29:49 * Dyrcona runs off to start a branch for LP 816672 2011-08-02T13:30:00 * dbs thinks that food beyond an apple + a pickle would be a good idea 2011-08-02T13:30:14 pickled apple..... 2011-08-02T13:30:25 Yeah. Ick. 2011-08-02T13:31:40 So, I just bug the gitadmin then for that access? 2011-08-02T13:31:59 yep, and they're both in the channel right now. :) 2011-08-02T13:32:29 edoceo: and specifically, send your SSH public key(s) to gitadmin@evergreen-ils.org 2011-08-02T13:32:43 *** mrpeters-isl has quit IRC 2011-08-02T13:32:47 dbs: http://evergreen-ils.org/dokuwiki/doku.php?id=acq:edi_configuration for later. Still refining the contents on there and adding some more procedural steps. 2011-08-02T13:33:02 bshum++ 2011-08-02T13:33:09 done 2011-08-02T13:33:23 *** mrpeters-isl has joined #evergreen 2011-08-02T13:33:38 Now I need to get a bit more comfortable with git - I've not used it for so much branching & switching & stuff yet 2011-08-02T13:34:54 * Dyrcona shudders when he thinks about development before git. 2011-08-02T13:35:19 I'm still a 90% SVN environment 2011-08-02T13:37:38 I'd like to talk about tt-opac some more, but I think berick and dbs are not in right now. 2011-08-02T13:39:16 Dyrcona: can we PM about some git stuff? 2011-08-02T13:40:28 edoceo: I may not actually be the best person to ask about git. there are others here with more git experience, like tsbere. 2011-08-02T13:40:41 edoceo: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git is a good place to start 2011-08-02T13:41:09 ask here so we can all contribute/benefit from the answers 2011-08-02T13:41:14 kk 2011-08-02T13:42:15 So, I've got a fresh clone right now and want to make a patch for the one called "refs/heads/rel_2_0" (I think) 2011-08-02T13:43:01 if you do "git branch" is rel_2_0 in the list? 2011-08-02T13:43:25 remotes/origin/rel_2_0 2011-08-02T13:43:34 edoceo: Try "git checkout rel_2_0" 2011-08-02T13:43:37 so you should be able to checkout 2011-08-02T13:43:39 It should auto-clone master if needed 2011-08-02T13:43:46 or origin, rather 2011-08-02T13:44:08 That remotes/ shows when I do `git branch -a` but when I do just `git branch` I see only master 2011-08-02T13:44:49 Tried tsbere's command, seems to work as expected: Branch rel_2_0 set up to track remote branch rel_2_0 from origin 2011-08-02T13:44:59 git branch only shows you the stuff that's locally on the machine I think. 2011-08-02T13:45:10 That you've already checked out / cloned 2011-08-02T13:45:12 yeah, good call bshum 2011-08-02T13:45:21 So, now I hack huh? Let's pretend I finished that hacking and now want to make a patch for LP 2011-08-02T13:45:30 bshum: *everything* other than a fetch, pull, or push is local to the machine in git 2011-08-02T13:46:10 tsbere: Oh, right :) 2011-08-02T13:46:15 `git commit -as` is what the wiki says - so I'll do that.... 2011-08-02T13:46:35 Now I've committed (locally) to rel_2_0 of evergreen huh? 2011-08-02T13:46:37 i think "git checkout --track -b lp2345 origin/rel_2_0" where 2345 is the bug number would work? 2011-08-02T13:46:53 then you can hack away 2011-08-02T13:47:00 mrpeters-isl: I just do git checkout -b origin/ 2011-08-02T13:47:12 I think --track is a default 2011-08-02T13:47:17 ah might be 2011-08-02T13:47:41 yep. git always tells me it is tracking the remote branch and seems to even when I omit it. 2011-08-02T13:47:53 "it" being --track 2011-08-02T13:47:56 edoceo: but if you have your ssh key on the server, you can push to a "working" branch owned by your user 2011-08-02T13:48:08 makes things easier when it comes to submitting the patch if it's publicly available 2011-08-02T13:50:24 * tsbere installed edoceo's key 2011-08-02T13:51:22 and there was much rejoicing! 2011-08-02T13:51:27 (yay) 2011-08-02T13:53:10 *** edoceo has quit IRC 2011-08-02T13:53:56 Install the key, he times out. 2011-08-02T13:53:57 Go figure. 2011-08-02T13:56:03 tsbere: no doubt just logging off to give 100% concentration to his next patch 2011-08-02T14:02:48 Dyrcona: I have real cheese-based food in my belly 2011-08-02T14:03:17 *** joseph_ has quit IRC 2011-08-02T14:04:00 *** joseph_ has joined #evergreen 2011-08-02T14:04:28 agJohn: in your java code, are you actually running more than 1 thread? 2011-08-02T14:04:42 Nope. 2011-08-02T14:05:03 k, then threading shouldn't be an issue 2011-08-02T14:05:15 it supports only 1 xmpp connection per thread, but any number of ClientSession's 2011-08-02T14:06:30 OK. So, it sounds like it should work--although I'm a little unclear on how. I've got an open-ils.auth, open-ils.cstore, and an open-ils.cat ClientSession. 2011-08-02T14:06:48 incoming messages should be linked to the original ClientSession via the session "thread". 2011-08-02T14:06:59 this matching happens in Stack.java when it calls findCachedSession() 2011-08-02T14:07:07 that is, it should be 2011-08-02T14:07:35 "thread" in this sense (a term granfathered in from the perl) is really just a session stamp 2011-08-02T14:07:40 not a thread in the Java sense 2011-08-02T14:07:53 in findCachedSession(String thread), i mean 2011-08-02T14:08:30 Gotcha. I think that thread value (assigned to the ClientSession) is getting disrupted somewhere--it's ending up using a value that's not unique to do the lookup at some point. I'll keep digging. Thanks much! 2011-08-02T14:08:47 probably so 2011-08-02T14:08:51 no problem 2011-08-02T14:09:16 Should the XMPP message that comes back know what ClientSession "thread" it belongs to--that appears to be a multi-step lookup? 2011-08-02T14:10:02 yes, it should. we're actually using the xmpp element (FYI) 2011-08-02T14:11:37 OK. I should be able to make some more progress now. (Very weird; looked like a race condition to begin with because the behavior changed depending upon which ClientSession was opened last--so I synchronized the heck out of everything--didn't help...:~P 2011-08-02T14:11:59 tsbere: So you said before the meeting that I should have access to working since my key was installed for evergreen-ils.git but I am getting "fatal: The remote end hung up unexpectedly" 2011-08-02T14:12:41 moodaepo: You add the working repo with the git:// url? (git remote -v to see urls) 2011-08-02T14:12:54 The git:// url is read-only. You need a ssh variant. 2011-08-02T14:13:08 agJohn: the xmmp thread is extracted from the inbound XML in XMPPReader.java and inserted into the newly constructed XMPPMessage. it's then accessed again in Stack.java in Session.findCachedSession(msg.getThread()) 2011-08-02T14:13:16 the value's probably just getting clobbered somewhere 2011-08-02T14:13:55 So, who's going to do the tech presentation at the conference next year on how to git stuff? (Yes, I'm recruiting!) 2011-08-02T14:14:02 berick: Much obliged. 2011-08-02T14:16:52 thanks to a policy change and a quick and dirty script to call open-ils.actor.user.penalties.update, ~2200 patrons get their borrowing privileges back! 2011-08-02T14:17:26 (we upped the PATRON_EXCEEDS_FINES standing penalty threshold) 2011-08-02T14:18:32 * tsbere wouldn't be against doing git stuff demonstrations at the conference 2011-08-02T14:18:36 tsbere: Here's my git config and an attempt to fix the remote url - http://paste.lisp.org/display/123741 2011-08-02T14:19:18 moodaepo: you could edit .git/config directly 2011-08-02T14:20:12 git remote set-url working git@git.evergreen-ils.org:working/Evergreen.git 2011-08-02T14:21:15 moodaepo: ^^ (I prefer that to manual config munging) 2011-08-02T14:23:28 jeff: What was the dirty script you used? 2011-08-02T14:24:44 jeff: That sort of policy change happens for us as we continue to tweak the actual running of things. So far, I've been doing manual remove/updates against the table. Sounds like your approach is probably better. 2011-08-02T14:25:37 bshum: I assume a "load those with penalties" json query to get ids followed by a pile of opensrf calls to the named function. 2011-08-02T14:25:53 Or a "ask the database, dump the IDs, make srfsh script" 2011-08-02T14:25:58 Both can be quick and dirty 2011-08-02T14:28:58 *** rogan_ has quit IRC 2011-08-02T14:29:38 *** edoceo has joined #evergreen 2011-08-02T14:30:51 tsbere: Still issues, I annoted the paste linked ^^ Am looking at http://www.btaz.com/misc/fatal-the-remote-end-hung-up-unexpectedly/ which says to edit remote.origin.url which we didn't change. 2011-08-02T14:32:25 moodaepo: Is your SSH key on the machine? 2011-08-02T14:32:34 Well, I likely missed the last 30 minutes of what was said, so - thanks for the near real-time IRC logs - I see my key was added to git - thank you, thank you. 2011-08-02T14:32:57 Apparently there was much rejoicing - but I could not participate as my internet connection crapped out for the 5th time today 2011-08-02T14:33:16 Clear "4G" service is unreliable 2011-08-02T14:33:16 Yup and on push git asked me to enter my pass phrase to access the key 2011-08-02T14:33:40 tsbere: ^^ edoceo missed the rejoicing and thanks you : ) 2011-08-02T14:34:22 moodaepo: I appear to be using git@git.evergreen-ils.org:working/Evergreen for the remote (no .git on the end). Beyond that....hmmm 2011-08-02T14:34:32 (the .git or lack thereof shouldn't change things) 2011-08-02T14:35:29 moodaepo: I see a problem. Your key isn't installed as "moodaepo". Do you want it to be? 2011-08-02T14:35:44 tsbere: No worries what's it installed as? 2011-08-02T14:36:04 An email address. Makes launchpad iffy when people aren't logged in, and we are in "change to IRC nicks if people want" mode. 2011-08-02T14:36:27 Would only take me a sec 2011-08-02T14:36:37 What would you suggest? : ) 2011-08-02T14:37:02 If no one else is using email address please do change it to moodaepo 2011-08-02T14:37:55 Will I have to change anything on my end? Maybe for the Evergreen_Website repo? 2011-08-02T14:38:22 moodaepo: All done. You shouldn't have to change anything. 2011-08-02T14:38:31 I've got a SIP Server question.... 2011-08-02T14:38:40 tsbere+= 2011-08-02T14:38:51 tsbere++ 2011-08-02T14:38:55 csharp: What's up? 2011-08-02T14:39:01 there has been a lot of development, which I'm happy to see, but is the SIP Server being versioned at all? 2011-08-02T14:39:17 That is a concern at this point, yea. 2011-08-02T14:39:30 if I were to download the SIP server today, how would I be sure that it's what we're currently using? 2011-08-02T14:39:31 To my knowledge the answer is basically "no" 2011-08-02T14:39:40 ok understood 2011-08-02T14:40:06 Tis on todo lists, though 2011-08-02T14:40:14 * tsbere has no clue where to start on that, though 2011-08-02T14:40:36 dbs: are you guys using a timeout of 1 for added content? 2011-08-02T14:40:39 has it basically been adopted by the Evergreen project at this point? 2011-08-02T14:40:58 not seeing Koha folks around, I'm assuming so.. 2011-08-02T14:41:16 unless ours is a fork? 2011-08-02T14:41:21 gmcharlt mentioned wanting to integrate some koha fixes at some point. 2011-08-02T14:41:37 phasefx: no, i think we're still using 45 :) 2011-08-02T14:42:00 dbs: ah :) thanks 2011-08-02T14:42:33 csharp: Not sure what the koha people are using for a repo, though. I know of an ancient cvs and the git that we migrated to git.evergreen-ils.org. 2011-08-02T14:42:41 csharp: I would definitely say it has been adopted by the Evergreen project ("it" being the version on git.evergreen-ils.org) but your support provider's support may vary 2011-08-02T14:43:03 tsbere: dbs: thanks to both of you for the information 2011-08-02T14:43:29 fwiw, I corrected the wiki page to point to git.evergreen-ils.org for the SIPServer code, but I think the official docs still point to atz's repo 2011-08-02T14:44:03 good topic, csharp. definetly would like to see an actual "version" of SIP cut so we have a concrete idea of what SIP code we're using. I'm honestly confused, at this point. It seems like we "upgraded" to something when upgrading to 2.0 but I'm not sure to what. 2011-08-02T14:44:33 will be really nice to say oh, we're on "Evergreen SIP 1.0" or something like that 2011-08-02T14:44:54 bshum: i did it this way -- tsbere suggested similar ways to you already: see recalc_penalties.pl here: https://github.com/tadl/eg-scripts/ 2011-08-02T14:45:31 mrpeters-isl: that's currently spelled "we're on Evergreen 95902b7866a3b15f2a07a4abc64e6597e51cf373" 2011-08-02T14:45:47 well, is would the general consensus be that the SIP server git is stable, or more volatile? 2011-08-02T14:46:09 * csharp seeks to know the unknown unknowns 2011-08-02T14:46:27 csharp: We try and keep SIPServer functional, as we tend to be running the latest copy in production. 2011-08-02T14:46:32 actually, that's a good point dbs i hadn't thought of using the hashes as versioning for now 2011-08-02T14:46:33 csharp: does PINES use Envisionware PCReservation? if so, do you know if you're using any of their validation rules based on birthdate/age? 2011-08-02T14:46:35 * dbs votes for git.evergreen-ils.org SIPServer with his feet 2011-08-02T14:47:07 jeff: Neato, thanks Jeff! 2011-08-02T14:47:30 jeff: individual PINES libraries do use PCReservation. I'm pretty sure they do use the birthdate field, but I don't know for sure 2011-08-02T14:48:29 we have some using PCReservation too 2011-08-02T14:48:55 but i'm also unknown on what they validate on 2011-08-02T14:49:13 jeff: many PINES folks subscribe to Open-ILS-General - you might get some useful responses there 2011-08-02T14:52:43 thanks, I'll pass it on. 2011-08-02T14:54:05 jeff: we also have an internal (to Georgia public libraries) technical discussion list - I'd be happy to pass something on 2011-08-02T14:54:19 and relay the followups 2011-08-02T14:54:21 *** bwicksall has joined #evergreen 2011-08-02T14:56:58 double thanks. you may hear from one of my co-workers. :-) 2011-08-02T15:00:07 Does anyone know why we are using jscalendar rather than dijit._Calendar (which turned to dijit.Calendar in dojo 1.4)? 2011-08-02T15:00:46 joseph_: we've mostly tried to get rid of jscalendar 2011-08-02T15:01:11 dbs: so it would be welcome if I tried to finish it off? 2011-08-02T15:01:30 * tsbere has no objections to that plan 2011-08-02T15:02:39 tsbere: just making sure before I kill off ~6k lines of code :) 2011-08-02T15:03:08 yeah, I think I did the first proof-of-concept (and slightly flawed) dijit._Calendar usage with the goal of wiping out jscalendar 2011-08-02T15:03:14 but, priorities... 2011-08-02T15:03:23 arg ... oh, great git admins ... please kill the top-level QP_bucket_filter branch in the main repo? 2011-08-02T15:03:39 * tsbere will do so 2011-08-02T15:03:44 dbs: ah 2011-08-02T15:03:52 tsbere: thanks 2011-08-02T15:04:21 a quite peek suggests that a number of the remaining uses of jscalendar are in dead code anyway (ue.xhtml, for example) 2011-08-02T15:04:25 eeevil: Done 2011-08-02T15:04:38 thanks 2011-08-02T15:04:56 joseph_: Feel free to kill off large amounts of code, so long as anything using that code before you do so still works when you are done ;) 2011-08-02T15:05:15 actually, that's only 2.0 2011-08-02T15:05:30 tsbere: What, I actually have to test? ;) 2011-08-02T15:05:32 in master, it's just a few bits of the reports UI, it looks like 2011-08-02T15:05:52 joseph_: go ahead and rip out craftsman while you're at it 2011-08-02T15:06:03 dbs++ 2011-08-02T15:06:05 joseph_++ 2011-08-02T15:06:46 oh, a few of the admin tools use it too. okay. joseph_++ 2011-08-02T15:06:52 I don't know if anyone saw this, it mostly works and has made things kind of nice: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:tools:web_reporter 2011-08-02T15:07:47 The only things it is stumbling on is the <#echo oils_js_base> sort of statements. 2011-08-02T15:07:48 joseph_: yeah, saw your blog post about it! i'm still mostly wedded to ack but nice to have that around 2011-08-02T15:07:49 joseph_++ # that looks neat 2011-08-02T15:08:01 ack++ 2011-08-02T15:08:21 though i find i have to alias ack to ack-grep on some systems and ack-grep to ack on others. ;-) 2011-08-02T15:08:33 *** dbwells has quit IRC 2011-08-02T15:17:25 *** dbwells has joined #evergreen 2011-08-02T15:24:57 am I missing something, or is craftsman really just sitting there unused? 2011-08-02T15:24:58 * dbs thinks... mmm, does t-pac have serials display yet? 2011-08-02T15:25:06 (save for the makefiles) 2011-08-02T15:25:49 joseph_: we announced plans to deprecate craftsman a long time ago, unless a maintainer stepped up - but nobody with the required skills to maintain it has stepped forward 2011-08-02T15:26:45 dbs: thanks 2011-08-02T15:26:59 given the rise of t-pac and the likely eventual deprecation of the ajax-pac (albeit much further down the road), it would make little sense to invest maintenance effort there now 2011-08-02T15:27:03 would be cool to see some of that look incorporated in the new OPAC 2011-08-02T15:27:19 it really gave the OPAC a certain polish, but I understand the difficulty in maintaining two skins 2011-08-02T15:27:21 mrpeters-isl: oh, the t-pac does have some of the same horrible anti-features 2011-08-02T15:27:30 lol 2011-08-02T15:27:32 buttons made from GIFs with text 2011-08-02T15:27:42 ew i never noticed that 2011-08-02T15:28:51 * joseph_ thinks animated gifs should be brought back! 2011-08-02T15:28:59 dbs: re serials, not the kind i imagine you're looking for. only basic support for listing held "issuances" so far 2011-08-02T15:29:09 and placing holds on them 2011-08-02T15:30:05 senator: okay, we'll have to add that to the to-do (not that slimpac has serials coverage display yet - so for the ajax-pac replacement todo) 2011-08-02T15:30:08 thanks 2011-08-02T15:33:01 *** charltgm_ has quit IRC 2011-08-02T15:33:01 * csharp thinks we should add these to any future OPAC: http://www.gifs.net/gif/index.php3?n=subcat_images.php3&id=25&start=0&end=20&cat_name=Books 2011-08-02T15:33:28 *** charltgm_ has joined #evergreen 2011-08-02T15:34:07 Thought 2011-08-02T15:34:42 Most of the time, an item that's marked as deleted/missing in the system would have an edit_time of the moment of the change. 2011-08-02T15:34:51 yes. 2011-08-02T15:34:54 But then if the item is altered after that, the edit time changes 2011-08-02T15:35:03 And it's no longer tied to the event of marking the item as deleted/missing 2011-08-02T15:35:22 And any report we write to track edit_time + status of missing (or deleted = true) becomes... unhinged 2011-08-02T15:35:23 yes, though the cases where it could/would be edited post-deletion may be rare/fewer 2011-08-02T15:35:28 yes. 2011-08-02T15:35:51 I'm trying to tell people that reports we write will be inaccurate for these reasons. 2011-08-02T15:36:04 And also because they're deleting items before they check them in properly. 2011-08-02T15:36:09 Using overrides 2011-08-02T15:36:15 yeesh 2011-08-02T15:36:22 And so, when they check them in, it alters the edit_time 2011-08-02T15:36:26 Since that's a status change 2011-08-02T15:36:35 But leaves it deleted, which is what we want 2011-08-02T15:36:38 wait til they start setting item status using a copy template, overriding the system-protected statuses such as "checked out". 2011-08-02T15:36:39 But now all the report data is screwy 2011-08-02T15:36:41 We have issues with deleted items being checked out too 2011-08-02T15:36:59 we trust the edit_time on deleted items since they can no longer access those items after they are set to deleted 2011-08-02T15:37:22 bshum: I thought edit_time only triggered on manual edits. Circ actions, not so much? (status changed time, on the other hand...) 2011-08-02T15:37:47 tsbere: Oh, right, maybe I'm getting my fields mixed up... hmm 2011-08-02T15:37:56 circ actions do create an edit_time (at least in <= 1.6.1.8) 2011-08-02T15:38:02 Hmmm 2011-08-02T15:38:06 Either way, it's all weird and writing reports for our libraries saddens me. 2011-08-02T15:38:25 bshum: Get the list of deleted/missing items by ID, then get the last time they *weren't* deleted or missing from the audit tables! 2011-08-02T15:38:52 a hack which works until your audit tables are purged. 2011-08-02T15:39:06 True. 2011-08-02T15:39:06 tsbere: I'm asking on behalf of a colleague who's attempting to write the report using the reporter module. 2011-08-02T15:39:25 bshum: Ahhh. Good luck. All our libraries seem to want things the reporter module can't do. 2011-08-02T15:39:27 tsbere: I figured the auditor table would tell me the truth 2011-08-02T15:40:01 tsbere: have any examples? they might make good things for me to demo jasperreports. 2011-08-02T15:40:55 jeff: Most of them involve crazy ideas in their heads about how the system works that didn't even apply to the previous system. 2011-08-02T15:41:04 ah. that doesn't help. :-) 2011-08-02T15:41:10 Sounds about right. 2011-08-02T15:44:04 well, obviously, you just go to your paper files. You _do_ print out a copy of the database every night, right? 2011-08-02T15:44:14 Ha 2011-08-02T15:44:55 It wouldn't be wise to add new tables/triggers to create a trail of events, right? 2011-08-02T15:44:58 dbs: Well, might have to get out the quarterly full print and the nightly diffs ;) 2011-08-02T15:45:17 Like adding a table to record actions taken, such as marking of items as deleted / missing and putting a timestamp 2011-08-02T15:45:41 well, for some status-changing events it might be useful to have an event trail that's in between audit tables and record-as-exists 2011-08-02T15:45:42 bshum: I would just run that kind of thing off of the auditor tables. <_< 2011-08-02T15:45:56 bshum: why not? that's essentially what we did in Conifer to build a list of "bibs added/changed since whenever" for an external Solr-sucking index 2011-08-02T15:46:51 "copy became available", "copy was deleted", "copy was brought back from the dead somehow" kinds of events might be useful to track in an event table somehow. 2011-08-02T15:47:15 it would solve some problems. i'd expect more thought be put into it than my babbling, though. :-) 2011-08-02T15:48:23 dbs: Just wondering if there'd be any bad consequences from cobbling something like that together. 2011-08-02T15:48:34 And also because we'd never tried it before. 2011-08-02T15:49:04 bshum: Fair warning, if your triggers fail for some reason, things will likely grind to an absolute halt ;) 2011-08-02T15:50:00 PINES would be interested in any DB-based staff accountability improvements, as long as they can scale up 2011-08-02T15:50:17 anything that keeps us from digging through syslogs makes me happy ;-) 2011-08-02T15:50:23 Issues I see: The DB has no clue who is doing it 2011-08-02T15:50:29 tsbere: That sounds scary, heh 2011-08-02T15:51:21 we started a rudimentary log searching bash program a while back, but never fleshed it out 2011-08-02T15:52:05 in the olden days, berick had designed a web interface that trolled through OpenSRF logs for "who did what when" type stuff 2011-08-02T15:52:07 http://svn.open-ils.org/trac/ILS-Contrib/browser/conifer/branches/rel_1_6_1/src/sql/Pg/solr.sql tracks when DELETE was issued against a given bib, amongst other things 2011-08-02T15:52:19 I feel like I need to adjust our syslog to break up stuff into 15 minute intervals now instead of hourly. Files are getting too big. 2011-08-02T15:52:22 it's defunct, but we still have the code 2011-08-02T15:54:08 if I could ever get the time to focus on it, I would tinker with the log filters to create more useful logs 2011-08-02T15:55:10 If our members weren't so insistent on generic, shared accounts I would try and get more tracking in. But pretty much all staff accounts are generic accounts with no one person that *can* be held accountable. 2011-08-02T15:55:26 * tsbere really dislikes that 2011-08-02T15:55:30 tsbere: that will likely change - it has in PINES 2011-08-02T15:55:59 once somebody does something really wrong using the generic users, they'll want more accountability 2011-08-02T15:56:56 Maybe, we'll see. 2011-08-02T15:57:03 csharp: It will likely take at least 3 such incidents, at a minimum, before anything will happen. Unless someone does something really horrible. 2011-08-02T15:57:07 I won't hold my breath for the death of our generic accounts. 2011-08-02T15:57:39 * mrpeters-isl tried to get Reese's cups from the vending machine. Imagine my dissapointment when a bag of unsalted peanuts appaered! :( 2011-08-02T15:58:41 those things need an "are you sure?" button! 2011-08-02T15:58:58 * tsbere now wants a Reese's cup, but has no vending machine to visit that he knows of 2011-08-02T15:59:12 i can offer you some of these terrible peanuts! 2011-08-02T15:59:53 *** Meliss has quit IRC 2011-08-02T16:05:20 * tsbere is tempted to go and merge https://bugs.launchpad.net/evergreen/+bug/820010 now 2011-08-02T16:05:43 unsalted? 2011-08-02T16:05:54 yes...awful 2011-08-02T16:06:24 tsbere: do it! do it! :P 2011-08-02T16:06:28 two peanuts were walking down the street, one of them was a salted 2011-08-02T16:06:33 haha 2011-08-02T16:07:15 Alas, poor Craftsman. I knew him well, Horatio. 2011-08-02T16:07:31 joseph_: Looks like the Makefile.am changes aren't in the patch file, though. 2011-08-02T16:07:40 joseph_: So I can't merge it as-is ;) 2011-08-02T16:08:16 tsbere: That is strange, I'll send in another patch. 2011-08-02T16:10:01 probably should link to http://libmail.georgialibraries.org/pipermail/open-ils-dev/2010-August/006269.html in the bug report (almost exactly a year ago today) 2011-08-02T16:10:12 tsbere: git format-patch origin doesn't include them, but git diff does; I must be missing something. 2011-08-02T16:10:26 joseph_: Did you, perhaps, forget to commit that change? 2011-08-02T16:11:19 Or, if it is a different commit, did you forget that format-patch may make multiple output files? 2011-08-02T16:11:30 * joseph_ *facepalm*, I did a commit and it said nothing to commit, but not commit -a, still getting used to git vs svn :) 2011-08-02T16:13:03 dbs: Should we be trying to move it into a contrib location, or just relying on "we can get at it in the history anyway"? 2011-08-02T16:13:26 * dbs would go with history 2011-08-02T16:13:42 given that our version control env has changed 2011-08-02T16:13:52 ok 2011-08-02T16:17:27 *** bwicksall has quit IRC 2011-08-02T16:19:43 Hmm. We have a single hold that hasn't been able to be targeted for nearly a month 2011-08-02T16:19:57 Poor orphaned holds. 2011-08-02T16:20:11 Tis a metarecord hold.....with one format. 2011-08-02T16:21:11 I have to find out if we have any holds stuck in limbo with our tweaked hold rules keeping them from ever finding a target. 2011-08-02T16:22:15 bshum: Look for prev_check_time more than, say, 2 days in the past with null cpature time, null fulfillment time, null cancel time, and not frozen? 2011-08-02T16:22:30 *** bwicksall has joined #evergreen 2011-08-02T16:23:55 Was thinking I could email the person, but they have no email. And I am not in the mood to call them. <_< 2011-08-02T16:25:42 Oh, hey, they have a proper title hold on the thing as well. I should just cancel the metarecord one that will never match. 2011-08-02T16:26:31 berick: Well, it's a timing problem after all, seemingly. But I think I caused it myself. 2011-08-02T16:26:33 If you create two connections one right after the other, they can end up with the same "thread" ID. Here's some output I added to try to see what's going on. 2011-08-02T16:26:34 The output shows the node & service and the thread ID--so, I've got two sessions that have the same ID: 2011-08-02T16:26:36 ClientSession.initSession(): router@private.localhost/open-ils.cstore/1610305014-5437590813123160418231 2011-08-02T16:26:37 ClientSession.initSession(): router@private.localhost/open-ils.cat/1610305014-5437590813123160418231 2011-08-02T16:27:13 I was trying to simplify the ClientSession code by putting some common elements of two different constructors into one method. I think that didn't work out so well! 2011-08-02T16:28:11 That ID seems to be just a string. Does it have to be numbers? How long is it allowed to be? 2011-08-02T16:28:51 agJohn: yep, just a string. the only restriction is that it be globally unique 2011-08-02T16:29:43 Well, this is a case of: take careful aim at foot; pull trigger! Thanks for your help--I don't know why I wasn't seeing this, but walking away from it helped... 2011-08-02T16:29:46 Hmm. joseph_: Probably annoying at this point, you didn't sign off on the patch(es). 2011-08-02T16:30:07 * tsbere isn't sure it is really needed with what is effectively a mass delete, though 2011-08-02T16:30:13 tsbere: just attach a DCO? 2011-08-02T16:30:15 agJohn: that's why we have 2 feet! glad you tracked it down. 2011-08-02T16:30:30 Hop, hop, hop... 2011-08-02T16:30:47 joseph_: a sign-off (say do a git commit --amend -s followed by a force-push) is sufficient 2011-08-02T16:31:07 a sign-off explicitly signifies the DCO with our current patch conventions 2011-08-02T16:31:35 gmcharlt: Technically he is handing out format-patch files. I don't mind, they import easily enough. ;) 2011-08-02T16:31:55 as tsbere implies, it's perhaps less signfiicant for a patch that *deletes* code, but for the sake of regularity, signing off all patches you mean to contribute is a good idea 2011-08-02T16:32:55 a simple cat file | git am -s and I get commits. :D 2011-08-02T16:34:24 tsbere: yep; which (roughly speaking), is actually how the Koha project handles the vast majority of patches contributed ot it 2011-08-02T16:38:27 so gmcharlt, should I just throw the "goodbye craftsman" patch in without signoff from him, or wait for him to figure out the signoff? 2011-08-02T16:39:07 tsbere: wait for the signoff, please 2011-08-02T16:39:20 * tsbere plays with some git stuff while waiting, then 2011-08-02T16:42:24 and then we can blame Google for the death of craftsman 2011-08-02T16:43:04 tsbere: should be coming your way shortly. 2011-08-02T16:43:17 as soon as LP gets it out. 2011-08-02T16:45:29 https://bugs.launchpad.net/evergreen/+bug/820010/+attachment/2250216/+files/0001-Removed-craftsman-skin.patch 2011-08-02T16:45:55 * tsbere runs a make and make install cycle to make sure the makefile didn't die for sanity check reasons 2011-08-02T16:46:12 * joseph_ crosses fingers 2011-08-02T16:46:30 Nothing died. :D 2011-08-02T16:48:19 * tsbere adds some extra details to the commit message, though 2011-08-02T16:51:50 That makes for one long commit email, doesn't it 2011-08-02T16:53:13 Indeed, but you can point the finger at me. Ha, I _just_ got that last patch... 2011-08-02T16:54:08 joseph_++ 2011-08-02T16:55:17 * tsbere didn't push it back to rel_2_1, but could do so quickly if we think it is a good idea to 2011-08-02T16:55:52 Well, ok, not so quickly. It doesn't apply cleanly to rel_2_1. 2011-08-02T16:57:23 I believe that makefile was updated since then. 2011-08-02T16:57:52 Specifically that last for loop was added (the one I just got rid of) 2011-08-02T16:58:58 Tis a different portion that is conflicting 2011-08-02T17:01:24 dbs: at some point, i could use your assistance extracting the relevant commits from some of the t-pac branches, ones that are mixes of various other topic branches 2011-08-02T17:01:52 berick: sure 2011-08-02T17:01:52 * tsbere decides that someone else can fight with backporting craftsman removal 2011-08-02T17:01:54 tomorrow? 2011-08-02T17:02:05 If anyone ever does 2011-08-02T17:02:07 dbs: tomorrow is good 2011-08-02T17:03:45 would make some sense to rip craftsman out of 2.1, as it is non-functional 2011-08-02T17:04:15 +1 2011-08-02T17:07:27 *** dbwells has quit IRC 2011-08-02T17:08:46 *** edoceo has quit IRC 2011-08-02T17:09:39 * tsbere has figured out the conflicts, then 2011-08-02T17:10:12 * tsbere is waiting on a sanity check reinstall, though 2011-08-02T17:13:44 One less skin for 2.1 2011-08-02T17:14:26 tsbere++ 2011-08-02T17:14:38 *** dbwells has joined #evergreen 2011-08-02T17:18:10 *** wolf29 has quit IRC 2011-08-02T17:26:46 * gmcharlt sends off fair warning 2011-08-02T17:27:40 gmcharlt++ 2011-08-02T17:28:24 joseph_++ 2011-08-02T17:28:26 gmcharlt++ 2011-08-02T17:30:40 *** Dyrcona has quit IRC 2011-08-02T17:31:18 *** joseph_ has quit IRC 2011-08-02T17:45:10 *** jenny1 has left #evergreen 2011-08-02T18:00:42 *** yboston has quit IRC 2011-08-02T18:07:45 *** matt_carlson has joined #evergreen 2011-08-02T18:29:31 *** dbwells has quit IRC 2011-08-02T18:31:36 *** dbwells has joined #evergreen 2011-08-02T18:54:28 *** dbwells has quit IRC 2011-08-02T19:39:23 *** bjwebb has quit IRC 2011-08-02T20:03:52 *** dbwells has joined #evergreen 2011-08-02T20:53:21 *** dbwells has quit IRC 2011-08-02T22:01:00 *** dbwells has joined #evergreen 2011-08-02T22:22:01 *** dbwells has quit IRC 2011-08-02T23:31:24 *** dbwells has joined #evergreen 2011-08-02T23:46:06 *** dbs has quit IRC