Timestamps are in GMT/BST.
[4:05] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:54] * kshepherd (firstname.lastname@example.org) Quit (Read error: 113 (No route to host))
[7:50] * bradmc (email@example.com) has joined #duraspace
[8:03] * mhwood (firstname.lastname@example.org) has joined #duraspace
[9:25] * tdonohue (email@example.com) has joined #duraspace
[14:26] * grahamtriggs (firstname.lastname@example.org) has joined #duraspace
[14:54] * caryn (i=80c8e115@gateway/web/freenode/x-idzesztiaovssfmg) has joined #duraspace
[14:56] <tdonohue> hey all...we'll be starting the DSpace Developers meeting here in a few minutes.
[15:01] <tdonohue> Looks like we're at top of the hour. The main agenda item for today is to update on 1.6 timeline/planning. stuartlewis do you want to take the lead on the discussion?
[15:01] * richardrodgers (email@example.com) has joined #duraspace
[15:01] <stuartlewis> Ok. No problem.
[15:02] * bollini (firstname.lastname@example.org) has joined #duraspace
[15:02] <stuartlewis> Just looking up some JIRA links...
[15:02] * lcs (email@example.com) has joined #duraspace
[15:02] <tdonohue> (for those just entering, we're going to start with 1.6 timelines/discussion)
[15:02] <stuartlewis> Are we going to start with a quick JIRA review? Not too many issues to go through I don't think, and I've got 3 new one's I'd like to propose for 1.6
[15:03] <richardrodgers> ok by me
[15:03] <tdonohue> Sure, we could do a quick Jira review
[15:03] <bollini> ok
[15:04] <lcs> good, if we can tack on ds-400
[15:04] <stuartlewis> (can anyone remember where we got up to last time?)
[15:04] * kshepherd (firstname.lastname@example.org) has joined #duraspace
[15:04] <tdonohue> DS-437 According to this: http://wiki.dspace.org/index.php/Developer_Meetings#Last_Issue_Reviewed
[15:05] <stuartlewis> Only 15 to do then, some should be quic
[15:05] <stuartlewis> k
[15:05] <stuartlewis> DS-438 is resolved
[15:06] <stuartlewis> http://jira.dspace.org/jira/browse/DS-438
[15:06] <stuartlewis> http://jira.dspace.org/jira/browse/DS-439 Build a simple way to verify if a DSpace upgrade was "successful"
[15:06] <stuartlewis> +1, post 1.6
[15:06] <tdonohue> +1, post 1.6 as well (this is more of an idea still...no patch)
[15:07] <richardrodgers> +1 post-1.6
[15:07] <lcs> +1 post 1.6
[15:07] <caryn> +1 post 1.6
[15:07] <mhwood> +1 post 1.6
[15:07] <lcs> (really good idea, tho)
[15:07] <bollini> +1, post 1.6
[15:07] <tdonohue> DS-439: +7, mark post 1.6
[15:07] <stuartlewis> http://jira.dspace.org/jira/browse/DS-440 spiders.txt empty
[15:08] <stuartlewis> Need input from mdiggory here
[15:08] <stuartlewis> My guess would be to ship a preconfigured list with 1.6, and look at an update process for post 1.6
[15:08] <lcs> there's also a list of spider user-agent keywords in one of the sitemaps to identify spiders..
[15:08] <mhwood> Anything we ship will be outdated. We need to document that in big red letters.
[15:08] <lcs> would be good to merge that logic
[15:09] <tdonohue> +1 to shipping with some sort of list (or at least documentation on how to format that spiders.txt file)
[15:09] <mhwood> +1 some list is better than no list
[15:09] <stuartlewis> Yes - 1.6.1 would need an update mechanism, a preconfigured list should catch 90% until then
[15:09] <lcs> how about adding references to recommended websites to obtain current lists of spider names?
[15:10] <stuartlewis> IIRC spiders.txt works on IP adresses. Could be upgraded to include user-agent strings too.
[15:11] <tdonohue> So, should we leave assigned to mdiggory and come up with some sort of list (even if it's just an example)?
[15:11] <stuartlewis> Yes - sounds sensible in the short timeframe we have
[15:11] <tdonohue> DS-440 Summary: Talk to mdiggory. Need to have some sort of list and or recommendations on how to get a current list.
[15:11] <stuartlewis> (any spider filtering is better than the current situation of no spider filtering)
[15:11] <stuartlewis> http://jira.dspace.org/jira/browse/DS-441 - resolved
[15:11] <richardrodgers> +1 provided we make clear it needs maintenance..
[15:11] <lcs> see dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap for some detection logic
[15:12] <stuartlewis> http://jira.dspace.org/jira/browse/DS-442 - awaiting documentation
[15:12] <stuartlewis> http://jira.dspace.org/jira/browse/DS-443 Flag in search and browse results to indicate whether (accessible) bitstreams are available for an item
[15:13] <tdonohue> +1 post-1.6
[15:13] <richardrodgers> post 1.6
[15:13] <bollini> post 1.6 there is no patch
[15:13] <stuartlewis> post 1.6
[15:13] <caryn> +1 post 1.6
[15:13] <lcs> post 1.6, needs code
[15:13] <mhwood> +1 post 1.6
[15:14] <tdonohue> DS-443: mark post 1.6 - needs a patch or someone to take lead on
[15:15] <richardrodgers> has anyone reproduced?
[15:15] <tdonohue> this needs followup, more information -- sounds like it could be a config problem?
[15:15] * mdiggory (email@example.com) has joined #duraspace
[15:16] <stuartlewis> Yes - let's leave a comment for the submitter and ask for more info
[15:16] <tdonohue> it looks like submitting directly to a collection in XMLUI works at http://testathon.net/xmlui/
[15:17] <tdonohue> DS-444: Needs more information. Followup with submitter (volunteer to do followup?)
[15:17] <stuartlewis> http://jira.dspace.org/jira/browse/DS-445 New Bitstream.findAll() method
[15:17] <stuartlewis> (this patch is required for DS-364)
[15:17] <mdiggory> hmmm
[15:17] <lcs> good idea, i implemented it in the (now lost) PLEDGE AIP prototype
[15:18] <tdonohue> +1 looks reasonable enough, and if it's necessary for DS-364
[15:18] <mhwood> +1 makes sense
[15:18] <richardrodgers> do we have a use for it , or just speculative?
[15:18] <stuartlewis> It just copies the code from the findAll method in collection and community etc
[15:18] <stuartlewis> I use it in the dspace.log -> solr log converter.
[15:18] <mdiggory> we should pull the aip prototype over into the sandbox
[15:18] <stuartlewis> THe converter has a 'local' mode so that you can run someoneelse's logs through your system.
[15:18] <lcs> +1
[15:18] * michaeldb (n=michaeld@CPE00222d540978-CM00222d540975.cpe.net.cable.rogers.com) has joined #duraspace
[15:19] <tdonohue> richardrodgers: probably best to have a use for an API addition...though, i could be convinced otherwise if it seemed logical enough
[15:19] <stuartlewis> So I need to find all items, colls, comms, and bitstreams to randomly pick them for stats.
[15:19] <mdiggory> in fact there are a number of prototypes sitting in google we should be doing some housekeeping on
[15:19] <lcs> mdiggory: there's probably a patch on the wiki still, but it would need updating; you're welcome to do it, i won't be able to.
[15:19] <tdonohue> mdiggory and lcs: i'm playing with AIP prototype a bit re: DuraCloud stuff...I can pull into prototype on sandbox when I get a chance
[15:20] <mdiggory> tdonohue: excellent
[15:20] <tdonohue> DS-445: +3 - commit it
[15:20] <mdiggory> +1
[15:20] <stuartlewis> Thanks :)
[15:21] <lcs> tdonohue: yeah, great news!
[15:21] <stuartlewis> The next two patches are designed to help the fresh install process:
[15:21] <stuartlewis> http://jira.dspace.org/jira/browse/DS-446 New ant step - test_database
[15:21] <stuartlewis> This patch adds a new ant target 'test_database'. It adds a main() method to DatabaseManager.java which tests a connection to the database and prints out any error messages.
[15:21] <stuartlewis> Ant's build.xml is updated to run this target as the first dependency of fresh_install, so that if the database connection defined in dspace.cfg is not good nothing else will happen (e.g. dspace.home and its directories will not be created) and an error message will appear. There is no point in performing any subsequent step if the DB isn't configured correctly.
[15:22] <bollini> +1
[15:22] <mdiggory> +1
[15:22] <lcs> +1 excellent idea
[15:22] <tdonohue> +1 great idea
[15:22] <caryn> +1
[15:22] <richardrodgers> +1
[15:22] <mhwood> +1
[15:22] <tdonohue> DS-446: +7 - commit it
[15:22] <stuartlewis> http://jira.dspace.org/jira/browse/DS-447 Email test script
[15:23] <stuartlewis> So this is the same, but for email. But not included in build.xml as you can run dspace without email working.
[15:23] <bollini> +1
[15:23] <richardrodgers> +1
[15:23] <lcs> +1 also a fine idea
[15:23] <caryn> +1
[15:23] <tdonohue> +1 also seems like a great idea
[15:23] <tdonohue> (can you run this via the 'dspace' commandline script as well?)
[15:24] <stuartlewis> Yes - will do.
[15:24] <mhwood> +1 heads off a lot of ML questions
[15:24] <stuartlewis> [dspace/bin/dspace test-email (or test-database)
[15:24] <mdiggory> http://jira.dspace.org/jira/browse/DS-444 Adding request to get full stacktrace, need more detal
[15:25] <tdonohue> DS-447: +6 - make it also run via 'dspace' (dspace test-email), and commit it
[15:25] <stuartlewis> http://jira.dspace.org/jira/browse/DS-448 - marked as duplicate and closed
[15:25] <stuartlewis> http://jira.dspace.org/jira/browse/DS-449 Command line utility org.dspace.app.harvest.Harvest -S throws AuthorizeException
[15:25] <tdonohue> mdiggory: thanks for responding to DS-444
[15:25] * Dan_Davis (i=43f11873@gateway/web/freenode/x-fixskjtwhedxqvnj) Quit (Ping timeout: 180 seconds)
[15:26] <stuartlewis> +1 pending testing
[15:26] <mhwood> User 0?
[15:26] <tdonohue> 0 - not sure I fully understand this one
[15:27] <richardrodgers> 0 same here
[15:27] <stuartlewis> I think this is a script to perform an OIA-PMH harvest manually
[15:27] <stuartlewis> (the OAI-PMH harvest code contributed by Texas A&M)
[15:27] <stuartlewis> Normally a harvest is kicked off by the UI.
[15:27] <tdonohue> ok, but why is OAI-PMH harvest updating a collection?
[15:28] <stuartlewis> Adds new items?
[15:28] <mhwood> That's harvesting INTO DSpace, not FROM DSpace.
[15:28] <stuartlewis> Yeah - that's what the new OAI-PMH facility does.
[15:28] <tdonohue> oh, yea. forgot about that new feature. thanks mhwood
[15:28] <mhwood> I get confused myself, on this one.
[15:29] <stuartlewis> In a collection, you can set it to be a "regular" collection, or as a mirror of another collection using OAI-PMHJ
[15:29] <tdonohue> +1 to fixing this, assuming someone else can verify this problem.
[15:29] <stuartlewis> Assign to me if you want, and I'll investigate and put some more comments in.
[15:30] <mdiggory> I think we are ramping up work on testing the harvester... we may be able to review this in the process.
[15:30] <mhwood> +1 needs investigation
[15:30] <tdonohue> DS-449: assign to stuartlewis. He'll investigate further
[15:30] <stuartlewis> http://jira.dspace.org/jira/browse/DS-450 XMLUI checkboxes hardcoded in Java
[15:30] <bollini> stuartlewis: take a look at this line - String harvestAdminParam = ConfigurationManager.getProperty("harvester.eperson");
[15:30] <stuartlewis> bollini: Thanks :)
[15:31] <mdiggory> ha, that could quite possibly be thier issue
[15:31] <stuartlewis> +1 post 1.6
[15:31] <richardrodgers> +1 post 1.6
[15:31] <tdonohue> +1 post 1.6
[15:31] <lcs> +1 post 1.6
[15:31] <bollini> +1 post 1.6
[15:31] <mhwood> +1 post 1.6, "there could be others"
[15:31] <tdonohue> DS-450 Summary: +6, mark post 1.6 - needs patch/volunteer
[15:32] <stuartlewis> http://jira.dspace.org/jira/browse/DS-451Brazilian Portuguese (pt_BR) translation for XML-UI and JSP-UI v1.5.2
[15:32] <stuartlewis> Ask Claudia if she is happy to lead on this one?
[15:32] <tdonohue> Sounds right to me...we can assign it to her for scheduling
[15:32] <richardrodgers> yes - or find a Brazillian crorespondent
[15:33] <tdonohue> DS-451: Assign to Claudia. Needs verification
[15:33] * mhwood wonders how to attract a stable of translators who will commit to maintaining translations as the software evolves.
[15:33] <stuartlewis> http://jira.dspace.org/jira/browse/DS-452 dspace 1.5.2, the bug is occur when the DSpace installation package by running from commandline from C:\dspace-1.5.2-src-release\dspace>mvn package
[15:33] <stuartlewis> I've put a comment on this one - awaiting answer.
[15:34] <stuartlewis> http://jira.dspace.org/jira/browse/DS-453 Update paths in [dspace-source]\dspace\config\dspace.cfg
[15:34] <tdonohue> Sounds like that's all we can do right now...followup for more info
[15:34] <mdiggory> one of the benefits of the maven site documentation on the i18n packages is that it lists a page with missing tags... some documentation guiding i18n maintainers would possibly get more involved.
[15:35] <tdonohue> DS-453 - is this a documentation issue? Those log4j settings look old
[15:36] <tdonohue> (or am I misunderstanding DS-453)
[15:36] <stuartlewis> Yeah - I don't understand it
[15:36] <stuartlewis> Not sure where he found out about those.
[15:36] <mdiggory> I think it is documentation
[15:37] <stuartlewis> Close the issue with a comment saying they aren't needed?
[15:37] <tdonohue> I think those "config.template.*" settings are old dspace.cfg settings from pre-1.5...but, I could be wrong
[15:37] <mdiggory> correct
[15:37] <tdonohue> DS-453: Close this issue. Refer user to newly updated documentation (thanks to Jeff)
[15:37] <stuartlewis> http://jira.dspace.org/jira/browse/DS-454 A community with the name "Untitled" that can't be deleted
[15:38] <mhwood> I've been meaning to ask -- recent versions apparently come with both Properties and XML configuration for log4j -- are we migrating?
[15:38] <stuartlewis> This is probably the old jspui bug where a collection gets created as soon as you click on 'create collection'.
[15:38] <stuartlewis> ...and then metadata gets added (e.g. collection name) once you fill in the "new collection" form
[15:38] * bradmc (firstname.lastname@example.org) Quit (Read error: 104 (Connection reset by peer))
[15:39] <stuartlewis> Just needs a comment about how to delete, and close the issue.
[15:39] <tdonohue> stuartlewis: this is XMLUI issue though, not JSPUI?
[15:39] <bollini> some investigation is needed... the handle is "null" and this is strange for me
[15:39] <mhwood> Is the bug fixed?
[15:39] <mdiggory> I think we should just settle on one log4j file format, having both there was to exemplify that there was a choice.
[15:40] <stuartlewis> mhwood: Don't think so - more of a 'feature' than a 'bug' perhaps :)
[15:40] * bradmc (email@example.com) has joined #duraspace
[15:40] <stuartlewis> bollini: Good point.
[15:40] <tdonohue> Someone want to volunteer to followup on DS-454?
[15:40] <mhwood> I've been caught at least once wondering, "why don't my log4j config updates happen? -- oh, there are two configs and it chooses the other one."
[15:41] <tdonohue> (as for log4j stuff -- i'm all for going for just one. Anyone want to add a Jira issue and create a patch?)
[15:41] <tdonohue> DS-454: Needs followup, verification, volunteer
[15:42] <stuartlewis> OK - 1.6 update?
[15:42] <stuartlewis> Outstanding issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10020&fixfor=10020
[15:42] <lcs> how about ds-400?
[15:42] <bollini> I could try to take a look to it (DS-454) this week, if before the end of the week I have missed it - please reassign
[15:42] <stuartlewis> OK - ds-400
[15:42] <tdonohue> DS-454: assign to bollini (thanks!)
[15:42] <lcs> (never mind, it's on taht list you just put up)
[15:43] <stuartlewis> Is there any issues on that list that shouldn't be, or not on the list that should be?
[15:44] <tdonohue> Not to my knowledge. It looks like the current "open" count is 27
[15:44] <stuartlewis> OK - next question: When can everyone get their assigned issues completed by?
[15:44] <lcs> that gives us 30 seconds each, let's go!
[15:45] <stuartlewis> Do we need to review them? We can review particular ones is required (e.g. ds-400, ds-295)
[15:45] <richardrodgers> I can within 2 weeks
[15:45] <stuartlewis> 2 weeks sounds good. Is that OK by everyone?
[15:45] <lcs> whatever i can do will be done by 8-jan.
[15:45] <stuartlewis> 21st Jab
[15:46] <tdonohue> I think some need a quick patch review. I just added a patch to DS-399.
[15:46] * tdonohue is looking towards mdiggory, who seems to have 10 assigned to him
[15:46] <stuartlewis> s/Jab/Jan
[15:47] <tdonohue> I think 21st Jan sounds like a reasonable goal.
[15:47] <stuartlewis> Ok - we can review that date next week, and perhaps set a final release schedule
[15:47] <stuartlewis> DS-400 - what did you want to discuss Larry?
[15:48] <stuartlewis> http://jira.dspace.org/jira/browse/DS-400 Webui item browse (date, title or similar) reduces displayed issue date by one day
[15:48] <lcs> has anyone had a chance to test it? i'm not much of a jspui user.
[15:48] * mdiggory whistles looking at the ceiling
[15:48] <stuartlewis> Sorry - not had a chance.
[15:48] <stuartlewis> Anyone happy for this to be assigned to them for testing?
[15:48] <stuartlewis> If not, assign to me.
[15:48] <lcs> if someone can test within the next couple days, i'll commit it -- it ought to go into 1.6, though.
[15:49] <richardrodgers> I don't have a JSP UI handy
[15:49] <stuartlewis> OK - will try to find some time soon. Assign to me.
[15:49] <lcs> will do - then assign it back to me and i'll commit. can it get into 1.6?
[15:49] <mdiggory> I will go through all my tickets and organize them this week.
[15:49] <stuartlewis> lcs: OK
[15:49] <stuartlewis> Next issue for a quick review:
[15:49] <stuartlewis> http://jira.dspace.org/jira/browse/DS-295
[15:49] <stuartlewis> Read the last comment.
[15:50] <stuartlewis> We can most cleanly add some new bitstream formats by including a new file containing just those two.
[15:50] <stuartlewis> But this file will just be for "upgraders".
[15:50] <stuartlewis> We don't have any upgrade files other than the db upgrade scripts.
[15:50] <stuartlewis> So where should other upgrade files go?
[15:51] <lcs> the file could go in config/registries with an "upgrade" name so it's with the others.
[15:51] <stuartlewis> dspace/etc/upgrade-files/15-16/ ?
[15:51] <richardrodgers> sure
[15:51] <stuartlewis> I'm happy with either suggestion
[15:52] <lcs> a separate upgrade-files subdir is more tidy but wouldn't it take a lot of doc changes?
[15:52] <stuartlewis> lcs: No - as this is the only upgrade file so far (assuming we leave the db upgrade files where they are)
[15:52] <grahamtriggs> action for future - ideally, we should just have a single 'current' version of these registries, and tools that compare with an existing installation, add new entries (possibly remove old ones that aren't referenced)
[15:53] <mdiggory> For one of the upgrades theres actually java classes that are executed, like...
[15:53] <lcs> ah, i was thinking that the whole beauty of it is that future db upgrade files would go there too, but that gets complicated with oracle/pgsql..
[15:53] <mdiggory> https://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/administer/Upgrade11To12.java
[15:53] <tdonohue> seems reasonable to keep in separate upgrade-files folder. maybe we can eventually figure out a way to move the db upgrade files there as well
[15:53] <stuartlewis> Ok - so shall I create that dir, and use it just for this file for now?
[15:53] <mdiggory> I wonder if we should have a more java centric upgrade process here...
[15:54] <stuartlewis> "dsrun org.dspace.upgrade 1.5 1.6"?
[15:54] <mhwood> No objection here.
[15:54] <stuartlewis> ...but we can leave that for 1.7 :)
[15:55] <stuartlewis> Ok - I'll do that then.
[15:55] <tdonohue> or even better "dspace upgrade 1.6 1.7" - sounds like something for 1.7
[15:55] <mdiggory> true... I just think the config / etc dirs are getting a bit out of hand
[15:55] <stuartlewis> Any other issues on that list that need talking about?
[15:55] <lcs> maybe call the directory dspace/etc/upgrades/ since files is kind of assumed
[15:55] <stuartlewis> lcs: Good point
[15:55] <tdonohue> I'd like to ask a planning question. Are we doing a 1.6 RC2? Thoughts?
[15:55] <mdiggory> Ideally I was thinking put the update files in the resources of the dspace-api jar...
[15:56] <stuartlewis> If we can get patches completed by 21st Jan, we could cut an RC 2, check for any major bugs, then release mid feb?
[15:56] <mdiggory> so they are not floating around the config directory of the install
[15:56] <stuartlewis> (or earlier if not big bugs)
[15:56] <richardrodgers> tdonohue: I think there are enough changes that we can't label it FCS...
[15:57] <tdonohue> stuartlewis: sounds reasonable. that's what I was wanting to rough out :) I've had folks asking me "when is 1.6 coming out"
[15:57] <lcs> mdiggory: some sites with lots of backported patches will want to edit the upgrades, that's harder when they are in a jar..
[15:57] <stuartlewis> tdonohue: I've had that question asked since last summer! :)
[15:57] <tdonohue> richardrodgers: agreed...I wanted to suggest a 1.6 RC2
[15:58] * stuartlewis googles FCS
[15:58] <mdiggory> you realize that after the release the number just increments and the question never really goes away....
[15:58] <tdonohue> so, it sounds like...tentative dates: End of Jan - 1.6RC2, mid-Feb: 1.6.0 final -- I'll update our Roadmap on wiki
[15:58] <richardrodgers> Sorry for my corporate speak - First Customer SHip
[15:58] <lcs> What's a "customer"?
[15:58] <stuartlewis> richardrodgers: Thanks :)
[15:58] * tdonohue starts laughing...
[15:59] <stuartlewis> Any other business? (or have we managed to keep to 60 mins for once?!)
[15:59] <richardrodgers> 3 cheers for lcs?
[15:59] <stuartlewis> Yes!
[15:59] <stuartlewis> Thanks Larry!
[15:59] <mdiggory> Hear Hear
[15:59] <tdonohue> definitely 3 cheers for lcs!
[16:00] <mhwood> Sorry, was there a sense of whether we want the log4j config to be Properties or XML?
[16:00] <tdonohue> congrats again, larry!
[16:00] <stuartlewis> You've done loads for 1.6, for which we are truly grateful.
[16:00] <lcs> aw, thanks. i've really enjoyed being part of this, and will still be lurking.
[16:00] <mhwood> Yes, cheers, please stay in touch.
[16:00] <richardrodgers> yes Larry , thanks a lot!
[16:00] <tdonohue> mhwood: I think we need to get a patch created for it.... XML seems more flexible, but I think we still use properties mostly right now
[16:00] <stuartlewis> ditto - properties for now
[16:01] <mhwood> Well, I can enter a JIRA and do a patch, but I want to know which way to patch it.
[16:01] <bollini> Larry has been a joy work with you
[16:01] <mdiggory> not much of a patch 'svn delete log4j.properites
[16:01] <richardrodgers> well we need a migration though...
[16:01] <tdonohue> mdiggory: you forgot the other log4j properties files
[16:01] <mdiggory> ???
[16:02] <lcs> bollini: thanks, you too, and thanks again for making choice/authority possible!
[16:02] <mhwood> log4j-console.properties, log4j-handle-plugin.properties
[16:02] <tdonohue> there's 3 log4j properties files -- log4j.properties, log4j-console.properties, log4j-handle-plugin.properties
[16:02] <stuartlewis> ...and all the documentation and wiki pages that need updating
[16:02] <tdonohue> there's only one in XML: log4j.xml (and I'm not sure if that one is even up-to-date)
[16:03] <mdiggory> yes it is, I use it
[16:03] <mhwood> Unfortunately I think it's the XML that is tried first.
[16:03] <mdiggory> but TBH, just remove the XML one then
[16:03] <mdiggory> stick with proerties files... theres no difference in the support
[16:03] <stuartlewis> Sounds sensible (remove.xml). An re-evaluate post 1.6
[16:04] <mhwood> OK, will do.
[16:04] <tdonohue> ok, sounds reasonable for now.
[16:04] <bollini> +1 remove xml
[16:05] <tdonohue> well, let's call the meeting to a close, and another thanks to Larry!
[16:05] <stuartlewis> THANKS LARRY!
[16:05] <tdonohue> (though feel free to continue discussions, as necessary)
[16:05] <bollini> bye all
[16:05] <lcs> thank you all -- bye for now!
[16:05] * bollini (firstname.lastname@example.org) Quit ("ChatZilla 0.9.85 [Firefox 3.0.16/2009120208]")
[16:05] * lcs (email@example.com) Quit ()
[16:06] <richardrodgers> mhwood: the xml log4j was a community donated patch - you might want to go back and look at it
[16:07] <mhwood> Thanks, I'll check it out.
[16:07] <richardrodgers> bye all
[16:07] * richardrodgers (firstname.lastname@example.org) Quit ()
[16:07] * caryn (i=80c8e115@gateway/web/freenode/x-idzesztiaovssfmg) Quit ("Page closed")
[16:08] <stuartlewis> DS-455 has been created to discuss log4j.xml
[16:09] <tdonohue> stuartlewis: excellent -- good idea
[16:10] <stuartlewis> mhwood: (Martin Hald)
[16:11] <stuartlewis> - Log4J enhancement to use XML configuration
[16:11] <stuartlewis> SF Patch #1224389
[16:11] <mhwood> Thanks!
[16:11] <stuartlewis> Added in 1.4
[17:10] * mhwood (email@example.com) Quit (Remote closed the connection)
[17:36] * grahamtriggs (firstname.lastname@example.org) Quit (Remote closed the connection)
[17:36] * grahamtriggs (email@example.com) has joined #duraspace
[18:10] * tdonohue (firstname.lastname@example.org) has left #duraspace
[18:17] * grahamtriggs_ (email@example.com) has joined #duraspace
[18:33] * grahamtriggs (firstname.lastname@example.org) Quit (Read error: 110 (Connection timed out))
[18:33] * grahamtriggs_ is now known as grahamtriggs
[18:44] * grahamtriggs (email@example.com) Quit (Remote closed the connection)
[18:44] * grahamtriggs (firstname.lastname@example.org) has joined #duraspace
[19:01] * grahamtriggs_ (email@example.com) has joined #duraspace
[19:04] * grahamtriggs (firstname.lastname@example.org) Quit (Read error: 60 (Operation timed out))
[19:04] * grahamtriggs_ is now known as grahamtriggs
[19:09] * grahamtriggs (email@example.com) Quit ()
[19:31] * michaeldb (n=michaeld@CPE00222d540978-CM00222d540975.cpe.net.cable.rogers.com) Quit ()
[21:57] * mdiggory (firstname.lastname@example.org) Quit ()
[22:38] * bradmc (email@example.com) Quit ()
[22:46] * bradmc (firstname.lastname@example.org) has joined #duraspace
[23:15] * cwilper (email@example.com) Quit ("Leaving")
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.