#duraspace IRC Log


IRC Log for 2010-10-06

Timestamps are in GMT/BST.

[1:19] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[1:29] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[1:35] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[1:56] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[2:05] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 276 seconds)
[2:32] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Quit: Leaving.)
[2:57] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[2:58] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:17] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[3:49] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[6:03] * Tonny_DK (~thl@ has joined #duraspace
[6:06] * stuartlewis (~stuartlew@ has joined #duraspace
[6:06] * Tonny_DK (~thl@ Quit (Client Quit)
[6:07] * Tonny_DK (~thl@ has joined #duraspace
[6:13] * stuartlewis (~stuartlew@ Quit (Quit: stuartlewis)
[6:35] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[6:43] -card.freenode.net- *** Looking up your hostname...
[6:43] -card.freenode.net- *** Checking Ident
[6:43] -card.freenode.net- *** Found your hostname
[6:43] -card.freenode.net- *** No Ident response
[6:43] [frigg VERSION]
[6:43] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:43] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:43] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[11:23] * Tonny_DK (~thl@ Quit (Quit: Leaving.)
[11:34] * bradmc (~bradmc@static-64-115-208-50.isp.broadviewnet.net) has joined #duraspace
[12:04] * bradmc (~bradmc@static-64-115-208-50.isp.broadviewnet.net) Quit (Quit: bradmc)
[12:18] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:55] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[13:20] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:46] * Tonny_DK (~thl@ has joined #duraspace
[14:03] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:31] * eddies (~eddies@ has joined #duraspace
[14:37] * Tonny_DK (~thl@ Quit (Quit: Leaving.)
[14:45] * achelous (~tom@ has joined #duraspace
[14:50] * bess (~bess@ has joined #duraspace
[14:50] * jaron (~jason@ has joined #duraspace
[14:50] * dougkim (~dougkim@ has joined #duraspace
[14:50] * flyingzumwalt (~matt@ has joined #duraspace
[14:50] * alxp (~aoneill@ has joined #duraspace
[14:50] * mikek_ (~mkorcy01@ has joined #duraspace
[14:50] * dougkim (~dougkim@ has left #duraspace
[15:08] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[15:24] * jaron (~jason@ has left #duraspace
[15:26] * mikek_ (~mkorcy01@ Quit (Quit: mikek_)
[15:44] * flyingzumwalt (~matt@ Quit (Read error: Connection reset by peer)
[15:50] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Read error: Operation timed out)
[15:51] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[16:30] * eddies (~eddies@ Quit (Read error: Connection reset by peer)
[16:30] * eddies (~eddies@ has joined #duraspace
[16:30] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[16:31] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:58] * bess1 (~bess@ has joined #duraspace
[16:58] * bess (~bess@ Quit (Read error: Connection reset by peer)
[17:29] * alxp_ (~aoneill@ has joined #duraspace
[17:29] * alxp (~aoneill@ Quit (Read error: Connection reset by peer)
[17:29] * alxp_ is now known as alxp
[17:57] * achelous (~tom@ Quit (Ping timeout: 264 seconds)
[18:42] * HardyPottinger (80ce8627@gateway/web/freenode/ip. has joined #duraspace
[19:26] * robint (5229fd08@gateway/web/freenode/ip. has joined #duraspace
[19:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[19:53] * cccharles (~user@ has joined #duraspace
[19:53] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:58] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[19:58] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[19:58] <tdonohue> Hi all -- DSpace Devel mtg start here in just a few minutes. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-10-06
[19:59] <stuartlewis> I'll be here for the first time in.... too many months! :) We've just entered daylight saving, so the meeting time is shifted by 1 hour.
[19:59] * richardrodgers (~richardro@ has joined #duraspace
[19:59] <tdonohue> hey! welcome back, stuartlewis :)
[20:00] * John__ (83bb6606@gateway/web/freenode/ip. has joined #duraspace
[20:00] <PeterDietz> I was just getting used to auto-assigning things to stuartlewis that nobody else grabbed
[20:00] <tdonohue> Ok, looks like we are at the top of the hour. First up, JIRA reviews. Here's a list of recent issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-13w&assigneeSelect=&sorter/field=created&sorter/order=ASC
[20:00] <tdonohue> We'll be starting shortly with DS-632
[20:01] * John__ (83bb6606@gateway/web/freenode/ip. Quit (Client Quit)
[20:01] <tdonohue> Batch Metadata Import needs to validate metadata fields specified in CSVs : http://jira.dspace.org/jira/browse/DS-632
[20:01] * JohnDavison (83bb6606@gateway/web/freenode/ip. has joined #duraspace
[20:01] <stuartlewis> Assign that one to me :)
[20:01] <tdonohue> (looks like this is one assigned to stuartlewis)
[20:01] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has left #duraspace
[20:01] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[20:01] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has left #duraspace
[20:02] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[20:02] <tdonohue> does this require any review, stuartlewis?
[20:02] <stuartlewis> Don't think so - its just a bit of error checking that is missing.
[20:02] <tdonohue> ok. we'll skip then for now, and we can always re-review later if you need it
[20:03] <tdonohue> Improvment to OAI-PMH + OAI-ORE harvesting support : http://jira.dspace.org/jira/browse/DS-634
[20:03] <stuartlewis> Nice to have, but no patch.
[20:03] <tdonohue> this looks like a new feature request -- probably needs to have it's "type" changed to "Feature Request"
[20:04] <mhwood> Do I recall that someone said recently on one of the MLs that this was being worked on?
[20:04] <tdonohue> hmm...not sure? if so, we should link thread up to this issue.
[20:04] <robint> I know this guy, he works in our national library. I'll chase it up.
[20:05] <tdonohue> ok -- assign to robint for investigation. revisit later
[20:05] <tdonohue> Rendering MathML code in abstracts : http://jira.dspace.org/jira/browse/DS-635
[20:06] <stuartlewis> This is more of a deeper issue about how we store metadata as plain text.
[20:06] <richardrodgers> embedded markup is tricky
[20:07] <mhwood> This and others like it will come up again and again until it is either done or stated that it will never happen. There's something about the abstract that makes people want markup.
[20:07] <stuartlewis> A topic for a special meeting one day?
[20:07] <tdonohue> perhaps -- definitely needs more discussion, at the very least
[20:07] <PeterDietz> on the ML, I mentioned I was using some JS, to transform LaTeX to a graphic display: http://picasaweb.google.com/pdietz84/OSULibraries#5469790115043107506
[20:08] <tdonohue> DS-635 : Needs more discussion. How does this impact DSpace -- should 'abstracts' (or other fields) support markup inherently
[20:08] <stuartlewis> Or do we add a new input-forms.xml type, or rich-text?
[20:08] <stuartlewis> s/or/of
[20:08] <robint> PeterDietz: My repo admin got all excited when he saw that
[20:08] <tdonohue> PeterDietz -- can you link that mailing list discussion into this issue as a comment? That'd be worth noting to this person
[20:08] * keithgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[20:09] <mdiggory> hello
[20:10] <tdonohue> I'll move on for now to next issue (hi mark)
[20:10] <mdiggory> Its always been an unspoken rule that dc not contain xml markup
[20:10] <tdonohue> Error Check Needed for handle.prefix in Dspace.cfg : http://jira.dspace.org/jira/browse/DS-636
[20:10] <tdonohue> (mdiggory -- yea, that is true -- metadata librarians are adamant about that)
[20:11] <stuartlewis> No harm in adding that - a small tweak that might help someone.
[20:11] <tdonohue> what do folks think about DS-636 -- should we add in this simple error check to see if 'handle.prefix' is set in dspace.cfg?
[20:12] <mhwood> At least it should not NPE.
[20:12] <mdiggory> agree
[20:12] <PeterDietz> would we default to 123456789?
[20:12] <stuartlewis> But it won't stop the NPE, just report on it.
[20:13] <tdonohue> sounds like we have a consensus on some sort of check. Does someone want to take lead on it?
[20:13] <richardrodgers> +1 should be logged
[20:13] <stuartlewis> Or should we default to something like "missing.handle.prefix"?
[20:14] <tdonohue> I'm fine with just logging it, and potentially just adding a 'throw new Exception()' in there that says it is missing.
[20:14] <mdiggory> tbh, the handle prefix really is a critical design flaw with DSpace....
[20:14] <mhwood> Have configuration manager check it at startup and exit if missing?
[20:14] <mdiggory> what if you do not want to have /handle/123456..../1
[20:15] <mdiggory> what if your not using handles?
[20:15] <tdonohue> mdiggory -- that's a bigger flaw in DSpace which will take longer to resolve. Right now, don't we *require* a handle prefix?
[20:15] <mdiggory> what should the default value be there, and shouldn' it be something agnostic to hadles
[20:15] <mhwood> dspace.example.com
[20:15] <mdiggory> how would there "not" be one
[20:16] <mdiggory> maybe there should be a hardcoded default rather than working about NPE and wanrings
[20:17] <mdiggory> working = worrying .... wanrings = warnings
[20:17] <mhwood> I don't think it should be a warning; it should either default or quit cleanly.
[20:17] <tdonohue> sounds like either mhwood or mdiggory is about to volunteer :)
[20:18] <tdonohue> I think we just need a volunteer to propose a well-tested solution, that we can approve. anyone?
[20:19] <mhwood> Any consensus on default/quit/keep NPE?
[20:19] <PeterDietz> I'm in favor of having the code default to default of 123456789
[20:20] <tdonohue> technically we already default to 123456789 in dspace.cfg -- this only happens, if you explicitly clear out that default
[20:20] <keithgilbertson> warn if no value, but default
[20:20] <mdiggory> I love that ConfigurationManager has no method.... getProperty("key", "default");
[20:20] <richardrodgers> I'm not crazy about default values - too much risk of mis-assigning lots of items...
[20:20] <stuartlewis> Yes, so defaulting to the same value in two places might make it harder to track down
[20:20] <mdiggory> but tons of other convenience methods
[20:21] <tdonohue> yea, i'd rather throw an error here, or refuse to startup (quit), since we already have a default elsewhere
[20:22] <keithgilbertson> I guess so. Why run the hdl server at all if you're not using a real prefix
[20:22] <keithgilbertson> maybe best to quit
[20:22] <mdiggory> but the value is also used in the interface and all the local URL
[20:23] <mdiggory> so if I do not want to run a handle service, why would I suggest I am publishing handles by using a handle prefix?
[20:24] <stuartlewis> Is this bit of code in handlemanager, in which case is it only invoked it your are using handles?
[20:24] <mdiggory> Thats conflated
[20:24] <PeterDietz> its also in ItemUpdate
[20:24] <mdiggory> you have to use Handlemanager as its hardcoded
[20:25] <tdonohue> so -- no agreement here? not even on just the 'quit' option? It seems like the way DSpace currently behaves, we are *requiring* that handle.prefix has a value (even if it's a dummy value).
[20:25] <mhwood> Sounds like we need two tickets: this one, to fix the crash, and another to revamp the guts of DSpace so that Handles can be replaced with something else, or nothing.
[20:26] <mdiggory> HandleManager is used within DSpace as a means to resolve any /handle/xxxx value to an Object
[20:26] <mhwood> If no one else wants it, I will fix to complain and exit.
[20:27] <tdonohue> ok, assign DS-636 to mhwood. We may also want to open a new ticket to look into making DSpace less dependent on Handles (a larger project)
[20:27] <mdiggory> agreed
[20:27] <tdonohue> One more for today...
[20:27] <tdonohue> 1.6.2 browse index bug/fix for authority index : http://jira.dspace.org/jira/browse/DS-637
[20:28] <richardrodgers> +1 if Andrea agrees
[20:28] <richardrodgers> (which I think he did)
[20:28] <tdonohue> +1 as well -- assign to Andrea to test/confirm?
[20:29] <mhwood> +1
[20:29] <keithgilbertson> +1
[20:29] <tdonohue> yea, from email thread, it looks like Andrea already "volunteered" to fix it. I'll assign this to him for investigation/verification and then commit to trunk
[20:30] <tdonohue> DS-637 - assign to andrea for verification & commit
[20:30] <PeterDietz> Whats the solution to DS-636, add log / error reporting / quit... or set default value?
[20:30] <mhwood> I was going to have it quit with a clear error
[20:30] <mdiggory> Define quit?
[20:31] <richardrodgers> System.exit
[20:31] <mhwood> Good point, I have to see where-all it is used.
[20:31] <mhwood> Can't System.exit in a webapp.
[20:31] <mhwood> Well, you *can*....
[20:31] <tdonohue> I'd suggest for DS-636, mhwood investigate the best way to 'quit' and log an error, and make a suggestion for an appropriate fix
[20:32] <mhwood> Will do.
[20:32] <mdiggory> Calling System.exit in our code, even in the cli is bad
[20:32] <tdonohue> Ok, next up on agenda -- 1.7 updates, take it away PeterDietz
[20:33] <mdiggory> I recommend just setting a default... the code replacement would be minimal and it would assure that the system is running always in the expected state
[20:33] <PeterDietz> Hi All, I've seen some progress of some svn commits on works in progress, so +1 to all
[20:33] <PeterDietz> Also, I've gotten Pere to grab a task, and he's submitted a patch, on pretty quick time, thats likely to be added to 1.7 features (login to current page)
[20:34] <mhwood> mdiggory: will bear that in mind if there is no good way out, but I think this should prevent starting if that doesn't require too much violence to the code.
[20:34] <PeterDietz> There is a DSUG 2010 in Baltimore,MD,USA next month
[20:35] <PeterDietz> I'll be talking to whoever is there about the release.
[20:35] <tdonohue> FYI PeterDietz -- someone already commented that Pere's patch is limited, so we may need a new version there. http://jira.dspace.org/jira/browse/DS-570
[20:35] <keithgilbertson> I think I can make the DSUG meeting; not the rest of the conference
[20:35] <richardrodgers> Baltimore dates?
[20:35] <PeterDietz> In the mailing-list, I've tried to get an effort behind adding xmlui-themes, as I had hoped to have a wordpress-esque theme gallery
[20:36] <mdiggory> PeterDietz: we've been planning a similar contribution
[20:36] <PeterDietz> DSUG is W- NOV 10.. Some other conference is M-8 and Tues-9
[20:36] <tdonohue> the DSUG 2010 is immediately after SPARC: http://www.arl.org/sparc/meetings/dr10/ (on Nov 10)
[20:36] <richardrodgers> K thanks
[20:37] <mdiggory> at least an improved theme that may have some improvements to the current Reference and make a better starting point for branding
[20:37] <mdiggory> a good selection of basic colors and CSS formatting.
[20:38] <PeterDietz> yeah, another hopefully nice thing to get out of xmlui would be how to have multiple themes for a single site, that follow some common characteristics. So, that you can have MyUniversityLayout, and then other themes just lay on top of it.
[20:38] <tdonohue> There's also a related thread on mailling lists about the complexity and confusion of the 'structural.xsl' in the Reference theme -- so, if we could find someone to break that up better, it'd be a nice thing to have
[20:38] <PeterDietz> ...without having to copy and paste the same junk into each theme
[20:39] <mdiggory> So what portions are getting the most complaints>
[20:39] <mhwood> Can't just include/import the common stuff?
[20:39] <PeterDietz> My thinking with structural.xsl is that someone took Occam's Razor to it too much. Like here's how to do it in 100 lines of code, here how to do it in 1 line of code
[20:40] <kshepherd> hi all
[20:41] <robint> The complaint is that its not broken into homepage.xsl, itempage.xsl etc
[20:41] <mdiggory> well, right now, I think that the tough parts are an overliance on modes
[20:41] <mdiggory> robint: but that was a design feature
[20:41] <tdonohue> here's the whole thread that digs into the issues with structural.xsl -- basically the main issue is it's highly confusing, and hard to change a single page's content -- http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg12099.html
[20:42] <robint> Just being the messenger
[20:42] <mdiggory> hmm
[20:42] <tdonohue> I think there may be a place for two options here -- the current Reference theme (with current structural.xsl), and an "Easy Start" theme, which uses almost page or section-based XSLTs
[20:42] <tdonohue> the feedback was that the structural.xsl is way too daunting and scary when you first get started
[20:42] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:43] <robint> Structural.xsl largely has generic matchers so its doesn't lend itself to being broken down by page.
[20:43] <PeterDietz> Ok, so hopefully everything that is assigned to everyone tagged as 1.7 is making progress, as we're going to "freeze" for an RC in 2 weeks
[20:43] <tdonohue> right -- but, the main point is that you don't *have* to use structural.xsl. You can create an alternative "Easy Start" theme from scratch, which uses a different set of XSLT
[20:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:44] <mdiggory> Theres a larger topic there as well....
[20:45] <mdiggory> inbetween "pages" and "components" there "functionalities"
[20:45] <mhwood> There's a good point: Reference is nice but tries too hard to be interesting. A plainer, more conservative (even stodgy) Theme might be a better starting point for customizing, at least w.r.t. understanding what is going on.
[20:45] <mdiggory> for instance browse, search, ItemView, Recently Added, etc
[20:46] <mdiggory> what I've learned in the process of working on discovery is that classes like CommunityViewer
[20:46] <tdonohue> PeterDietz -- actually, Oct 22 is just a 'feature freeze' -- no Release Candidate yet. The RC1 is scheduled for a week later on Nov 5 (to leave time for some quick testing/stabilizing and bug fixes before RC1)
[20:46] <mdiggory> that Communityviewer hardwires a set of functionalities together
[20:46] <mdiggory> such as Recently Added and Summary List... I'd like to see breaking that up a bit
[20:47] <PeterDietz> tdonohue, Thats why I said "freeze", kind of like how one can say theres been some "discussion" about dspace performance on tomcat
[20:47] <tdonohue> haha :) gotcha
[20:48] <robint> mdiggory: As seperate classes/transformers ?
[20:48] <mdiggory> this would be in preparation for a capability to separate the existing Browse system completely out of the XMLUI and turning on Discovery in its place.
[20:48] <mhwood> On LKML they used to talk about "code slush".
[20:48] <tdonohue> Do we have other updates for 1.7.0 from others? how are we looking on outstanding features?
[20:48] <mdiggory> robint: yes, separate transformers... possibly even separate aspects
[20:48] <kshepherd> mdiggory: i thought we already split recentsubmissions into a seperate aspect?
[20:48] <kshepherd> if not, i think i have that patch lying around..
[20:49] <kshepherd> i agree with the principle.. it'd be easier to build things with sitemap if we split that functionality up
[20:50] <mdiggory> that might make the individual page think more feasible too
[20:50] <mdiggory> think = thing
[20:50] <keithgilbertson> was thinking I might have powerpoint text extraction in the media filter by 1.7, but ran into some dependency conflicts with POI that might not let that happen on time
[20:50] <mdiggory> keithgilbertson: if not, just start it as a module project
[20:51] <mdiggory> then we can publish how to add it in easily via ones maven build
[20:52] <keithgilbertson> mdiggory: wondering if I shouldn't do that anyway. If it's a module, does that mean I won't have to worry about conflicting requirements for library versions?
[20:52] <mdiggory> whats the current conflict?
[20:52] <PeterDietz> keithgilbertson, I'm ok with touching the org.textmining, so long as we don't add the opossums
[20:52] <keithgilbertson> thanks Peter
[20:53] <tdonohue> here's the email thread about the POI conflict: http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg12184.html
[20:53] <keithgilbertson> mdiggory: I wrote the powerpoint filter to use POI, but it requires at least version 3.5 to support XML version of powerpoint files
[20:54] <keithgilbertson> while the WordFilter uses an old org.textmining package which requires POI 2.5 to work - some changes in POI with a method signature broke binary compatibility
[20:55] <mdiggory> keithgilbertson: I would say to fix the word filter and upgrade the usage of poi to be a more current version
[20:55] <keithgilbertson> I'll try that :)
[20:56] <mhwood> Is there a Maven plugin to report "the following dependencies are really old and should be upgraded"?
[20:56] <mhwood> Because we tend to pin everything down to a specific release, which sits there growing older while the world moves on.
[20:56] <tdonohue> Ok, looks like we're running short on time here. any last 1.7 updates? Also, do we all agree with the currently proposed "how we will manage Docs on the Wiki" (see agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-10-06)?
[20:57] <mdiggory> I agree +1
[20:58] <kshepherd> yep +1, i'm on-board for doco on the wiki
[20:58] <mhwood> So how do we make minor fixes to old doc.s? People find errors and omissions.
[21:00] <tdonohue> mhwood -- we'd archive a 'read-only' version of old wiki docs for a time period. But, we'd only make fixes that are deemed necessary. What ones are "deemed necessary" is up to us -- but the idea is that we'd discourage fixes to old docs (which quickly is a mgt problem) unless necessary
[21:01] <tdonohue> I think we have to balance two ideas here -- we don't want to be managing multiple versions of the docs on the wiki (we already have enough problems getting one set of docs consistent), but we may want to keep old ones around for a while if there are glaring issues (causing us to need to remake the HTML or PDF)
[21:01] <mhwood> I still have some difficulty with the notion that everybody switches to the new release on day 1.
[21:02] <mdiggory> nobody does... but that doesn't mean that we need to maintain the docs as if they are code
[21:02] <tdonohue> they don't have to though -- the old docs will still be there for a while -- and at the very least we'll *always* have the HTML and PDF version
[21:02] <tdonohue> (i.e. we will never remove HTML or PDF versions of old docs from our website.)
[21:03] <mdiggory> a read only wiki would allow room for adding "comments"?
[21:03] <tdonohue> we can make comments possible while also keeping the rest of it "read-only" -- at least, I think those are two separate permissions in Confluence
[21:03] <mdiggory> but also commenting on the living doc would allow for "caveats" per version to be documented within it
[21:03] <mhwood> Or a live errata page. Something to capture the inevitable (IMO) small discoveries that come later.
[21:04] <HardyPottinger> php.net keeps one set of docs online, and notes differences (sometimes...) between different versions, and the live comments tend to pick up where the docs drop the ball
[21:04] <tdonohue> I just verified -- we can allow for comments to be posted to a 'read-only' wiki space
[21:05] <tdonohue> so, we could leave comments on -- and we could also create an errata page somewhere in our main docs, if we felt that worthwhile
[21:06] <mhwood> OK, that sounds good.
[21:06] <PeterDietz> lastly, jira upgrade?
[21:06] <tdonohue> excellent.
[21:06] * achelous (~tom@ has joined #duraspace
[21:07] <tdonohue> jira upgrade is delayed a bit -- turns out to be more complex than initially thought to merge two jira's together. Chris Wilper & I are working more on it on Fri -- hoping to work out the last kinks, and *possibly* schedule for sometime next week (assuming we are able to work out kinks on friday)
[21:07] <tdonohue> So -- i'll keep you all posted
[21:08] <mdiggory> per asynchronous releasing.... I've been doing quite a bit of testing, but the work is leaning more towards (1) getting switched over to use sonatype, (2) cleaning up maven build process so its a little less confusing and there are fewer levels (3) trying to create incremental releases of dspace submodules.
[21:09] <tdonohue> is this something still for 1.7 mark? or is it sounding more like post-1.7?
[21:09] <mdiggory> I've been working on things I can get into 1.7.
[21:09] <tdonohue> ok, cool. just checking
[21:09] <mdiggory> I'll also add that I've been sitting in the fedora meetings and they are dealing with similar issues in the mavenization of fedora
[21:10] <tdonohue> Ok -- we're 10 minutes over now.
[21:10] <tdonohue> mdiggory -- yes, thaanks for that! I've heard good feedback through Chris as well. glad you can touch base with them on maven stuff
[21:11] * JohnDavison (83bb6606@gateway/web/freenode/ip. Quit (Ping timeout: 265 seconds)
[21:12] <tdonohue> Shall we end for today? I know we didn't discussion DSpace Performance discussions -- but, you can all read those on the listservs for now :) (And I'm talking with Cambridge offlist, and had discussions with Graham as well today)
[21:12] <mdiggory> I'll followup where I can offlist
[21:12] <mhwood> Yeah, I gotta go. Performance stuff should perhaps slide over to dev list for now.
[21:12] * kshepherd isn't brave enough to get caught up in that one
[21:13] <tdonohue> ok -- we'll end there then. have a good one! I'll stick around for a while in case anything comes up
[21:13] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:13] <PeterDietz> it would be nice is mvn package / ant update, didn't cause me such blindness while watching them build. this however is a separate concern. blindness being lots of scrolling of useless to me while watching it build
[21:13] <stuartlewis> +1 for Tim's statesman like diplomatic skills recently.
[21:13] <kshepherd> heh, yes, +1
[21:14] * tdonohue needs a beer tonight :)
[21:14] <kshepherd> PeterDietz: you can tell mvn just to report WARN or higher, instead of INFO
[21:14] <robint> stuartlewis: Cant think what you could mean :)
[21:16] <robint> Go to go, cheers.
[21:17] * robint (5229fd08@gateway/web/freenode/ip. has left #duraspace
[21:18] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[21:22] * keithgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has left #duraspace
[21:25] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 252 seconds)
[21:29] * HardyPottinger (80ce8627@gateway/web/freenode/ip. Quit (Quit: Page closed)
[21:33] * bess1 (~bess@ Quit (Quit: Leaving.)
[21:35] * alxp (~aoneill@ Quit (Quit: alxp)
[21:42] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[21:43] * richardrodgers (~richardro@ Quit (Quit: richardrodgers)
[21:58] * bess (~bess@173-160-115-74-Minnesota.hfc.comcastbusiness.net) has joined #duraspace
[21:59] * eddies (~eddies@ Quit (Quit: eddies)
[22:10] * bess (~bess@173-160-115-74-Minnesota.hfc.comcastbusiness.net) Quit (Quit: Leaving.)
[22:10] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:28] * bess (~bess@173-160-115-74-Minnesota.hfc.comcastbusiness.net) has joined #duraspace
[22:29] * bess (~bess@173-160-115-74-Minnesota.hfc.comcastbusiness.net) Quit (Client Quit)
[22:40] * interloper_uq (~uqckorte@lib-ckmacbook.library.uq.edu.au) has joined #duraspace
[22:41] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[22:50] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[23:13] * eddies (~eddies@c-71-63-238-11.hsd1.mn.comcast.net) has joined #duraspace
[23:14] * eddies (~eddies@c-71-63-238-11.hsd1.mn.comcast.net) Quit (Client Quit)
[23:29] * achelous (~tom@ Quit (Ping timeout: 252 seconds)
[23:58] * alxp (~aoneill@173-160-115-74-Minnesota.hfc.comcastbusiness.net) has joined #duraspace

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.