Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 64 Next »

[08:01:27 EST(-0500)] * bszabo_ (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[08:53:26 EST(-0500)] * jayshao (n=jayshao@ool-45731e0f.dyn.optonline.net) has joined ##uportal
[08:56:35 EST(-0500)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[08:57:25 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:16:02 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined ##uportal
[09:19:09 EST(-0500)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[10:13:22 EST(-0500)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[10:21:58 EST(-0500)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[10:24:14 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:25:16 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[10:49:04 EST(-0500)] * lennard1 (n=sparhk@uni1.unicon.net) has joined ##uportal
[10:56:42 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[11:22:37 EST(-0500)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:24:28 EST(-0500)] <awills> dstn:looking into your UncategorizedSQLException: PreparedStatementCallback issue, i see some references to oracle StatementCacheSize, which looks like a possibility
[11:24:33 EST(-0500)] <awills> http://forum.springframework.org/showthread.php?t=10221
[11:26:06 EST(-0500)] <athena7> does anyone know if the restriction range and enumeration elements in the channel type CPD are actually used for input validation?
[11:26:12 EST(-0500)] <athena7> i can't find any indication that they are
[11:26:47 EST(-0500)] <dstn> awills: thanks I'll look at that
[11:29:03 EST(-0500)] <athena7> EricDalquist: are we close to having a tag?
[11:29:25 EST(-0500)] <EricDalquist> working on it still
[11:29:30 EST(-0500)] <EricDalquist> probably 2-3 more hours
[11:29:40 EST(-0500)] <EricDalquist> didn't get much done last night, had a lot of house work to do
[11:30:34 EST(-0500)] <athena7> no rush, i was just curious for day-planning purposes (smile)
[11:30:45 EST(-0500)] <athena7> thanks for the info
[11:31:25 EST(-0500)] <athena7> i'd like to update our portlet administration portlet devel so that we can see if it still works w/ the current code
[11:33:07 EST(-0500)] <EricDalquist> ok
[11:33:11 EST(-0500)] <EricDalquist> is any of that in svn yet?
[11:36:30 EST(-0500)] <athena7> no
[11:36:36 EST(-0500)] <EricDalquist> ok
[11:36:51 EST(-0500)] <athena7> figured once the RC was out maybe i could send an email to the list to solicit some feedback about where we should put it
[11:36:52 EST(-0500)] <EricDalquist> I'm wondering if I should create the 3.1 patches branch when I cut the RC
[11:36:59 EST(-0500)] <EricDalquist> then that could happen on trunk
[11:37:09 EST(-0500)] <EricDalquist> and we can decide about putting it into a 3.1.x down the road
[11:37:17 EST(-0500)] <athena7> sounds reasonable
[11:38:03 EST(-0500)] <athena7> i don't know if people would want it to wait a while, or see it as a preview-only-not-in-use type thing earlier, or what
[11:38:14 EST(-0500)] <EricDalquist> yeah
[11:38:15 EST(-0500)] <holdorph> yeah, once you go into feature/api freeze, it would be useful to cut the branch, so that new features/api changes can be done somewhere.
[11:38:31 EST(-0500)] <EricDalquist> just what I was thinking too holdorph
[11:38:34 EST(-0500)] <athena7> yep
[11:38:39 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[11:39:20 EST(-0500)] <EricDalquist> well I'm working on updating everything for the release right now, I'll get the SVN work done first then work in jira & the wiki
[11:40:03 EST(-0500)] <athena7> sounds great - it'll be really nice to see the new rc (smile)
[11:40:39 EST(-0500)] <EricDalquist> oh and if you do an update from trunk today you'll see A LOT of changes
[11:40:54 EST(-0500)] <EricDalquist> I used the maven license plugin and updated the license headers across the project
[11:41:10 EST(-0500)] <EricDalquist> handy little plugin ... let me fix 1700 files in about 5 minutes including configuration time
[11:41:25 EST(-0500)] <dstn> lol, nice
[11:42:06 EST(-0500)] <EricDalquist> actually any maven project that uses the jasig-parent version 10 parent pom can use it for the Jasig license
[11:42:16 EST(-0500)] <EricDalquist> just run "mvn license:format"
[11:43:11 EST(-0500)] <athena7> yeah i already noticed that
[11:43:21 EST(-0500)] <athena7> tried running svn status -u and went ahHHHhh!
[11:43:22 EST(-0500)] <athena7> (smile)
[11:43:24 EST(-0500)] <EricDalquist> lol
[11:43:30 EST(-0500)] <athena7> and killed that command
[11:43:31 EST(-0500)] <athena7> lol
[11:43:46 EST(-0500)] <EricDalquist> I don't think I'm going to on the 3.0.3 because of all of the merge noise
[11:43:57 EST(-0500)] <EricDalquist> now it is done on trunk future updates won't be so horrible
[11:49:51 EST(-0500)] <colinclark> Is anyone who is going to the conference next week also interested in basketball, by chance? (smile)
[11:50:08 EST(-0500)] * athena7 likes basketball
[11:51:18 EST(-0500)] * holdorph likes college basketball
[11:53:23 EST(-0500)] <colinclark> The Raptors are in Dallas on Sunday night. I was thinking about going if anyone is interested in joining me.
[11:53:35 EST(-0500)] <colinclark> The Raptors are pretty terrible this year, but still. (smile)
[11:54:36 EST(-0500)] <athena7> i'm not getting in until about 5pm sunday, so i'll likely just go settle into the hotel and such
[11:54:58 EST(-0500)] <athena7> although if you wind up watching it from a bar somewhere or something, i'd stop by
[11:55:35 EST(-0500)] <dstn> so I'm getting this: http://uportal.pastebin.com/me7890a5 after an import ... it doesn't make sense to me though because it says it encountered an error reading layout for userId=6288 but there are only 15 users (id 1-15) in the database.
[11:56:11 EST(-0500)] <holdorph> i'll probably do the conference reception thing sunday evening. Not a big enough NBA fan to skip the reception for it
[12:02:21 EST(-0500)] <athena7> yeah, i'd like to be there and catch up with everyone as well
[12:02:40 EST(-0500)] <EricDalquist> dstn: not sure ... sounds like the sequence generation isn't right?
[12:03:03 EST(-0500)] <holdorph> now if michigan state was playing bball that night somewhere in the area, well, I'd definitely be going
[12:03:04 EST(-0500)] <EricDalquist> you're using the stock trunk import scripts?
[12:03:18 EST(-0500)] <colinclark> holdorph: (smile)
[12:07:27 EST(-0500)] <dstn> EricDalquist: I thought it was a problem with the sequence table but everything looks normal in up_sequence
[12:07:42 EST(-0500)] <dstn> no, I'm using 3.0.2 import scripts
[12:07:53 EST(-0500)] <EricDalquist> ah with a 3.0.2 codebase?
[12:07:57 EST(-0500)] <dstn> yes
[12:08:00 EST(-0500)] <EricDalquist> hrm
[12:10:20 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:03:17 EST(-0500)] <EricDalquist> ok code has been tagged & branched
[13:03:42 EST(-0500)] <EricDalquist> trunk is open again for work and rel-3-1-patches exists for 3.1 RC->GA work
[13:03:48 EST(-0500)] <EricDalquist> Jira will be updated next
[13:11:11 EST(-0500)] <holdorph> TRUNK IS WILD!!!! sorry, it had to be said.
[13:11:24 EST(-0500)] <EricDalquist> lol
[13:18:25 EST(-0500)] * athena7 cheers!
[13:18:29 EST(-0500)] <athena7> yay eric!
[13:25:46 EST(-0500)] <dstn> whoa, just stepped back in here
[13:25:48 EST(-0500)] <dstn> its like the wild west
[13:27:40 EST(-0500)] * athena7 hands dstn a hat and spurs
[13:27:50 EST(-0500)] <athena7> you're from the mountain west, you'll fit in just fine
[13:28:08 EST(-0500)] <dstn> EricDalquist: so oddly, one of my 15 users I imported didn't have a profile, the user is a fragment layout user. Added the profile to the user and re-imported and am no longer getting that error
[13:28:15 EST(-0500)] <dstn> athena7: ha!
[13:28:50 EST(-0500)] <dstn> I actually have a question related to that, should every user have a profile defined when exported?
[13:29:14 EST(-0500)] <athena7> hm, if they've never edited their layout, i don't know if they'd have one?
[13:29:39 EST(-0500)] <athena7> or do they get a profile and no layout in that case?
[13:30:14 EST(-0500)] <awills> yes, dstn, i believe so
[13:30:31 EST(-0500)] <EricDalquist> they should get an empty profile from just having a .user file
[13:30:37 EST(-0500)] <EricDalquist> I thought I had fixed that long ago
[13:30:58 EST(-0500)] <EricDalquist> brb
[13:31:09 EST(-0500)] <awills> isn't the <profile> element in the .layout file? or am i misremembering
[13:32:35 EST(-0500)] <dstn> I see it in .user files
[13:32:49 EST(-0500)] <dstn> and some users don't have <profile> defined at all
[13:33:13 EST(-0500)] <awills> dstn i'm afraid it's not unlikely that 2.x portals in the wild (esp. long-running 2.x portals) will need some "cleanup" to their data
[13:33:41 EST(-0500)] <awills> might be a good idea to add the <profile> – are they all the same?
[13:34:14 EST(-0500)] <dstn> Ya, they are all the same
[13:34:34 EST(-0500)] <dstn> that was gonna be my next question...if I could just hard code to add it everytime
[13:35:25 EST(-0500)] <holdorph> i think yale would classify as long-running 2.x portal
[13:35:28 EST(-0500)] <holdorph> (smile)
[13:35:29 EST(-0500)] <awills> when a portal DB has been running with uP codebase from 2.0 to 2.1 all the way through 2.6, it's tough to imagine the differences
[13:35:39 EST(-0500)] <dstn> lol
[13:36:23 EST(-0500)] <awills> yeah it may make sense to enhance the export so that a simple <profile> always comes along... no matter what the DB contains
[13:36:41 EST(-0500)] <awills> or enhance the import so one always gets created
[13:37:26 EST(-0500)] <awills> in either case, we may be able to base it on the system profile
[13:38:08 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[13:40:34 EST(-0500)] <EricDalquist> ok I'm back
[13:40:37 EST(-0500)] <EricDalquist> reading logs ..
[13:40:45 EST(-0500)] <EricDalquist> the original export had the profile in the user
[13:40:51 EST(-0500)] <EricDalquist> the problem is that doesn't match the data model
[13:40:55 EST(-0500)] <EricDalquist> so we moved it in 3.x
[13:41:28 EST(-0500)] <EricDalquist> a <user> doesn't have a <profile> but importing a <user> should create an empty but usable profile if one doesn't exist
[13:41:56 EST(-0500)] <EricDalquist> the .layout for the user should contain a <profile> so the user can use the imported layout
[13:44:03 EST(-0500)] <dstn> wait, the last 2 comments, are you referring to 3.x or 2.6?
[13:44:27 EST(-0500)] <EricDalquist> 3.x
[13:44:49 EST(-0500)] <EricDalquist> but you backported the 3.x export scripts to 2.6 right?
[13:45:20 EST(-0500)] <dstn> no, I actually didn't. awills suggested to use rel-2.6-patches as that was what they were designed for.
[13:45:27 EST(-0500)] <EricDalquist> ah
[13:45:52 EST(-0500)] <dstn> does creating the profile also apply to fragment users?
[13:45:57 EST(-0500)] <EricDalquist> yes
[13:46:15 EST(-0500)] <EricDalquist> but that may not happen on import from the 2.6 export scripts
[13:46:30 EST(-0500)] <EricDalquist> when we upgraded we used the scripts from that 2.6-export.zip file I posted
[13:46:36 EST(-0500)] <EricDalquist> which are much much closer to the 3.x scripts
[13:46:56 EST(-0500)] <EricDalquist> the original ones in 2.6-patches needed a lot of work to be reasonably performant for us
[13:47:15 EST(-0500)] <dstn> ok
[13:47:32 EST(-0500)] <dstn> beyond performance, did you guys change them?
[13:47:50 EST(-0500)] <EricDalquist> yeah ... just a sec and I can check
[13:48:04 EST(-0500)] <dstn> the performance for us isn't particularly bad, only takes about 45 to export and 35 to import
[13:48:07 EST(-0500)] <EricDalquist> I think they exported v3.0 style user, layout and channel files
[13:48:33 EST(-0500)] <dstn> but I'd be interested to know what functional changes you guys made
[13:48:57 EST(-0500)] <EricDalquist> I don't have a detailed log of that other than the results in that zip file
[13:49:13 EST(-0500)] <dstn> ok, np
[13:51:06 EST(-0500)] <EricDalquist> so for entity versions in the export scripts we used:
[13:51:06 EST(-0500)] <EricDalquist> channel - 2.6
[13:51:26 EST(-0500)] <EricDalquist> we did group_membership files which are 3.0
[13:51:53 EST(-0500)] <EricDalquist> layout was 3.0
[13:51:59 EST(-0500)] <EricDalquist> and user was 3.0
[13:52:23 EST(-0500)] <EricDalquist> for the layout export the 2.6 export doesn't really support many DLM features
[13:52:48 EST(-0500)] <EricDalquist> what we added was full DLM node referencing for dlm control nodes
[14:00:07 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined ##uportal
[14:33:34 EST(-0500)] <athena7> EricDalquist: how would you feel about using an svn configuration file to control things like newlines and file types and such?
[14:33:47 EST(-0500)] <EricDalquist> is this something on the server?
[14:36:32 EST(-0500)] <EricDalquist> guess I'm not that familiar with svn config files
[14:37:33 EST(-0500)] <athena7> no, it's something you have to have in your home directory
[14:37:38 EST(-0500)] <athena7> i really wish they were on the server
[14:37:39 EST(-0500)] <EricDalquist> ah
[14:37:52 EST(-0500)] <athena7> i know the sakai project distributes a standard one
[14:37:57 EST(-0500)] <EricDalquist> sure, we need to document more developer-centric stuff anyways
[14:38:01 EST(-0500)] <EricDalquist> that can be part of it
[14:38:05 EST(-0500)] <athena7> you can enforce desired newline types, file types, executable properties, etc.
[14:38:05 EST(-0500)] <athena7> yeah
[14:38:18 EST(-0500)] <athena7> i'd set up a page and attached a first stab at one a while ago, although i never got any feedback
[14:38:41 EST(-0500)] <athena7> trying to import the rc as a vendor drop and it keeps crashing on windows newlines
[14:38:42 EST(-0500)] <EricDalquist> ah hrm
[14:38:52 EST(-0500)] <EricDalquist> well maybe we can chat about it at the conference and push on it after that?
[14:38:58 EST(-0500)] <athena7> sure, that'd be great
[14:44:00 EST(-0500)] <dstn> awills: what is the scope of a cache element for cernunnos? i.e. how long does it last? is just for the execution of one script or for the entire execution of all scripts?
[14:44:25 EST(-0500)] <EricDalquist> dstn: it depends on the cache map you have configured
[14:44:33 EST(-0500)] <EricDalquist> what version of uPortal are you looking at?
[14:45:43 EST(-0500)] <EricDalquist> the trunk scripts (and I think the 3.0.3-RC1 scripts) have a line in both import.crn and export.crn near the top like:
[14:45:44 EST(-0500)]

<EricDalquist> <attribute key="Attributes.CACHE">${groovy(java.util.Collections.synchronizedMap(new org.jasig.portal.io.LoggingLRUMap($

Unknown macro: {CACHE_SIZE}

)))}</attribute>


[14:46:15 EST(-0500)] <EricDalquist> then in db/entities/import.properties or export.properties there is:
[14:46:15 EST(-0500)] <EricDalquist> CACHE_SIZE=500
[14:46:33 EST(-0500)] <EricDalquist> so the default there is to cache the 500 most recently used items
[14:48:22 EST(-0500)] <dstn> wait, are we talkin about the same thing? I'm referring to http://cernunnos.googlecode.com/svn/manual/entries/cache-TASK.html
[14:48:28 EST(-0500)] <EricDalquist> yup
[14:48:51 EST(-0500)] <EricDalquist> I wrote that (tongue)
[14:48:58 EST(-0500)] <dstn> LOL
[14:49:13 EST(-0500)] <dstn> So I'm using the latest cernunnos in rel-2.6-patches and using the <cache> element
[14:49:25 EST(-0500)] <dstn> I don't think I ever defined an attributes.CACHE
[14:49:29 EST(-0500)] <EricDalquist> ah
[14:49:31 EST(-0500)] <EricDalquist> ok
[14:49:35 EST(-0500)] <holdorph> athena7 it seems like there has to be a svn trigger script we can incorporate to check for this newline problem
[14:49:36 EST(-0500)] <dstn> is there one defined by default or something?
[14:49:39 EST(-0500)] <EricDalquist> trying to remebmer what the default does ...
[14:50:30 EST(-0500)] <athena7> yes, possibly
[14:50:57 EST(-0500)] <EricDalquist> // Set up Attributes.CACHE if not already provided...
[14:50:57 EST(-0500)] <EricDalquist> if (!tr.hasAttribute(Attributes.CACHE)) {
[14:50:57 EST(-0500)] <EricDalquist> tr.setAttribute(Attributes.CACHE, new HashMap<Object, Object>());
[14:50:57 EST(-0500)] <EricDalquist> }
[14:51:06 EST(-0500)] <EricDalquist> so that is in the ScriptRunner
[14:51:10 EST(-0500)] <EricDalquist> so by default
[14:51:18 EST(-0500)] <EricDalquist> if you don't configure a Attributes.CACHE attribute
[14:51:21 EST(-0500)] <EricDalquist> everything gets cached
[14:51:27 EST(-0500)] <EricDalquist> for the lifetime of the script
[14:51:48 EST(-0500)] <EricDalquist> well wait
[14:51:49 EST(-0500)] <EricDalquist> no
[14:52:03 EST(-0500)] <EricDalquist> the default cache model is ONE
[14:52:16 EST(-0500)] <dstn> the reason I ask, is I'm seeing stuff get re-loaded into cache
[14:52:22 EST(-0500)] <EricDalquist> yeah
[14:52:23 EST(-0500)] <dstn> i.e. loading users from file ...
[14:52:26 EST(-0500)] <EricDalquist> because cache model is one
[14:52:27 EST(-0500)] <dstn> then all is good
[14:52:36 EST(-0500)] <dstn> then later on loading users from file ...
[14:52:46 EST(-0500)] <EricDalquist> so for a cache tag only the last cached entry is actually stored
[14:52:57 EST(-0500)] <EricDalquist> so if you had
[14:53:08 EST(-0500)]

<EricDalquist> <cache cache-key="USER_ID.$

Unknown macro: {USER_NAME}

" key="USER_ID">


[14:53:22 EST(-0500)] <EricDalquist> if you ask for the same USER_NAME several times in a row it will only get loaded once
[14:53:32 EST(-0500)] <EricDalquist> but if you ask for two different user names and alternate them
[14:53:43 EST(-0500)] <EricDalquist> the cache would be pointless with the default cache model
[14:54:18 EST(-0500)] <EricDalquist> it still helps because it at least caches loaded XML/XSL documents and parsed CRN scripts
[14:54:32 EST(-0500)] <EricDalquist> but anything that gets cached with a dynamic key is rather pointless with a model of ONE
[14:54:43 EST(-0500)] <EricDalquist> the default 3.x scripts have the model set to ALL
[14:54:57 EST(-0500)] <EricDalquist> but replace the default HashMap with a LRUMap
[14:55:11 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[14:55:12 EST(-0500)] <EricDalquist> and only store the 500 most recently used entries overall (not per tag)
[14:55:44 EST(-0500)] * dstn is absorbing this all
[15:01:07 EST(-0500)] <EricDalquist> athena7: could you go through any issued you're listed on here http://www.ja-sig.org/issues/secure/IssueNavigator.jspa?reset=true&amp;pid=10020&amp;fixfor=10630 and move the ones that are 'new features' to the fixfor 3.2.0 version?
[15:01:17 EST(-0500)] <athena7> yes!
[15:01:21 EST(-0500)] <athena7> gladly
[15:01:24 EST(-0500)] <EricDalquist> thanks (smile)
[15:01:36 EST(-0500)] <EricDalquist> I did create a bunch of future 3.x versions too
[15:01:42 EST(-0500)] <athena7> there are probably some that aren't assigned to me that i can move as well
[15:01:42 EST(-0500)] <EricDalquist> so we can schedule things a bit better
[15:01:46 EST(-0500)] <EricDalquist> sounds good
[15:01:48 EST(-0500)] <athena7> awesome, much appreciated
[15:01:54 EST(-0500)] <EricDalquist> I also need to check with Gary & Matt
[15:02:04 EST(-0500)] <EricDalquist> I think they have some issues that may be able to be resolved against the RC
[15:02:30 EST(-0500)] <athena7> yes, potentially
[15:02:43 EST(-0500)] <athena7> any thoughts about what to do with matt's skin?
[15:02:59 EST(-0500)] <EricDalquist> I haven't even looked at it
[15:03:26 EST(-0500)] <EricDalquist> brb
[15:12:52 EST(-0500)] <dstn> new skin?
[15:14:33 EST(-0500)] <athena7> i don't think it's in - he held off because of the windows build issue
[15:15:47 EST(-0500)] <EricDalquist> ah
[15:23:14 EST(-0500)] * apetro_ (n=apetro@12.164.139.7) has joined ##uportal
[15:26:49 EST(-0500)] * apetro- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:16:51 EST(-0500)] * jayshao (n=jayshao@ool-45731e0f.dyn.optonline.net) has joined ##uportal
[16:25:29 EST(-0500)] * invisibill (i=80876350@gateway/web/ajax/mibbit.com/x-82acfd812b7a0be3) has joined ##uportal
[16:26:37 EST(-0500)] <invisibill> Greetings uPortal People: does anyone know off hand which portlet / admin tool displays the link to clear the stylesheet cache?
[16:36:43 EST(-0500)] <invisibill> ok thanks. I found this in the Channel Manage.
[17:15:38 EST(-0500)] * anastasiac (n=stasia@142.150.154.189) has left ##uportal
[17:34:50 EST(-0500)] <awills> EricDalquist still there?
[17:34:55 EST(-0500)] <EricDalquist> hry
[17:34:58 EST(-0500)] <EricDalquist> hey*
[17:35:14 EST(-0500)] <awills> wasn't sure if that was "hey" or "hardley"
[17:35:54 EST(-0500)] <awills> anyway – I've become aware of a snag on the JLM/JPA tech on Oracle 10g (and probably other flavors)
[17:36:27 EST(-0500)] <awills> namely this: hibernate creates tables with column names that are reserved words
[17:36:50 EST(-0500)] <EricDalquist> sounds like a bug
[17:36:58 EST(-0500)] <EricDalquist> can you file a jira issue against the RC
[17:37:04 EST(-0500)] <EricDalquist> and we can get it fixed before the GA
[17:37:06 EST(-0500)] <awills> i'm just sitting down now to address it... i can get a patch into trunk & rel-3-1-patches
[17:37:15 EST(-0500)] <EricDalquist> sounds good to me
[17:37:24 EST(-0500)] <awills> yeah, sure thing
[17:37:43 EST(-0500)] <awills> this is me keeping others in the loop (wink)
[17:37:57 EST(-0500)] <EricDalquist> (smile)
[17:51:32 EST(-0500)] * lennard1 (n=sparhk@uni1.unicon.net) has joined ##uportal
[18:00:41 EST(-0500)] * lennard1 (n=sparhk@uni1.unicon.net) has left ##uportal
[18:39:16 EST(-0500)] * tsnfoo (n=tsnfoo@cpe-65-24-108-125.columbus.res.rr.com) has joined ##uportal
[18:43:28 EST(-0500)] * bszabo1 (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[18:43:59 EST(-0500)] * bszabo1 (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[21:56:15 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[22:08:33 EST(-0500)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal

  • No labels