Timestamps are in GMT/BST.
[6:41] -leguin.freenode.net- *** Looking up your hostname...
[6:41] -leguin.freenode.net- *** Checking Ident
[6:41] -leguin.freenode.net- *** Found your hostname
[6:41] -leguin.freenode.net- *** No Ident response
[6:42] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:42] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:42] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:18] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[13:30] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[14:11] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has left #duraspace
[14:14] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[15:10] * barmintor (barmintor@specdl11.cul.columbia.edu) has joined #duraspace
[15:57] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) Quit (Ping timeout: 264 seconds)
[16:16] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[19:51] <tdonohue> Reminder all: DSpace Developers meeting here in about 10 minutes https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-10
[19:51] <kompewter> [ DevMtg 2011-08-10 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-10
[19:53] * KevinVdV (~KevinVdV@d54C14B16.access.telenet.be) has joined #duraspace
[19:56] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:57] * ablemann (~alexleman@147.226.130.14) Quit (Quit: leaving)
[19:59] <robint> tdonohue: Hi Tim, can we add another release version in Jira so that we can reassign stuff that we are sure won't make 1.8 ?
[20:00] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:00] <tdonohue> robint: sure. not a problem. I can create a "post-1.8" version after this meeting.
[20:00] <robint> Good stuff, thanks
[20:01] * sandsfish (~sandsfish@18.111.73.151) has joined #duraspace
[20:01] <tdonohue> Hi all, it's that time again...here's our agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-10
[20:01] <kompewter> [ DevMtg 2011-08-10 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-10
[20:01] * richardrodgers (~richardro@pool-96-237-109-89.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <sandsfish> hi all
[20:02] <tdonohue> we'll start off with JIRA reviews as usual. Here are the issues for review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-874+ORDER+BY+key+ASC
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-874 ] - [#DS-874] NullPointerException possible during item browsing - DuraSpace JIRA
[20:02] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-874+ORDER+BY+key+ASC
[20:02] <tdonohue> first up, DS-874
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-874 ] - [#DS-874] NullPointerException possible during item browsing - DuraSpace JIRA
[20:02] <tdonohue> hi sandsfish :)
[20:03] <sandsfish> sounds like a reasonable fix.
[20:03] <tdonohue> anyone want to volunteer to verify Ds-874 patch (again, as this is a bug, it can be committed *after* our feature freeze, if necessary)
[20:03] <robint> I'll grab it
[20:04] <tdonohue> ok, Ds-874 summary: assign to robint
[20:04] <robint> grabbed
[20:04] <tdonohue> next up, DS-876
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-876 ] - [#DS-876] Replication Task Suite (New Backup & Restore Curation Tasks) - DuraSpace JIRA
[20:04] <tdonohue> just an update here...This code is going to be released *separate* from 1.8.0 (as an addon)
[20:04] <richardrodgers> Isn't this aready committed?
[20:05] <tdonohue> yes..this ticket is more of a placeholder
[20:05] <tdonohue> just wanted to let everyone know that despite Ds-876 saying it will be in 1.8.0, it will *NOT* be out-of-the-box
[20:05] <richardrodgers> K, thanks
[20:05] <tdonohue> moving on from there...
[20:06] <tdonohue> (I'm skipping DS-877, as that's another placeholder for post-1.8 work)
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-877 ] - [#DS-877] Duracloud Storage Service - DuraSpace JIRA
[20:06] <tdonohue> next one will be DS-878
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-878 ] - [#DS-878] update_geolite timesout when downloading GeoLiteCity.dat.gz - DuraSpace JIRA
[20:07] <tdonohue> ugh, this is one of my biggest pet-peeves. I hate that if GeoLiteCity download times out, the entire DSpace installation fails
[20:07] <robint> I have also experienced this
[20:07] <mhwood> Those data do take a long time to fetch, even when my uplinks are FAST.
[20:08] <sandsfish> is this just due to that server being laggy?
[20:08] <richardrodgers> Does it make sense for us to consider proxying it?
[20:08] <sandsfish> exactly, just mirrored somewhere "local" to dspace?
[20:08] <tdonohue> well, it's also a problem that the path to GeoLiteCity is *hardcoded*. So, if maxmind.com suddenly changed the download point, all DSpace installs would fail
[20:09] <mhwood> Eww.
[20:09] <sandsfish> yuk
[20:09] <tdonohue> yea...we basically are missing error handling here. If the GeoLIteCity download fails or times out, we need to throw a Warning, but continue the install
[20:10] <mhwood> Making it configurable would fix two problems, then, and we could have a command to fetch the data that could slurp on that connection as long as it takes.
[20:10] <mhwood> What happens if there is no file?
[20:11] <tdonohue> If GeoLiteCity file is missing, then the Solr Stats won't work right, but everything else will work.
[20:11] <tdonohue> (i.e. it's only used by Solr Stats, to help display the country/location stats)
[20:11] <mhwood> Is it clear to the user that geo information is missing, or is it a mystery glitch?
[20:12] <tdonohue> not sure..it might just be an ugly error screen
[20:12] <tdonohue> I'd be willing to take this one on. I cannot promise it'd be ready by Feature Freeze, but should be able to get to it before Testathon.
[20:13] <mhwood> Sounds like: if we don't have it, then (a) we need to degrade the report gracefully, and (b) we may need to reindex when we do have geo data.
[20:13] <tdonohue> yes...likely.
[20:13] <sandsfish> or, the stats code fetches the data when it first realizes it's missing.
[20:14] <mhwood> +1 don't crash the build just because a network connection timed out.
[20:14] <aschweer> mhwood +1
[20:14] <sandsfish> +1
[20:15] <tdonohue> ok. Ds-878 summary: assign tdonohue. Minimally don't crash the build if connection times out or errors. Hopefully report errors gracefully from Stats if file is missing.
[20:16] <tdonohue> next up, DS-880
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-880 ] - [#DS-880] Better documentation for permissions - DuraSpace JIRA
[20:17] <tdonohue> ok, just a documentation request, though a good one. Anyone care to write some docs on this before 1.8.0 (wouldn't need to happen before Feature Freeze)
[20:18] <tdonohue> ok, hearing no volunteers. I'd suggest we still schedule this for 1.8.0, and see if we can find someone to help clarify docs before then
[20:18] <robint> Sounds good
[20:19] <tdonohue> Ds-880 summary: schedule for 1.8.0. Needs a volunteer to check current docs & enhance as necessary.
[20:19] <tdonohue> one last one.. DS-881
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-881 ] - [#DS-881] DSpace doesn't build properly with Maven 3 - DuraSpace JIRA
[20:20] <tdonohue> we talked about this last week, right? Didn't someone volunteer for this?
[20:20] <richardrodgers> yes, didn't mdiggory think he had a handle on it?
[20:21] <tdonohue> yea...that's how I remember it to. Since mdiggory isn't here today, he cannot argue otherwise :)
[20:21] * robint_ (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[20:21] <robint_> sorry, local problems
[20:21] <tdonohue> Ds-881 Summary: tdonohue will check with mdiggory & assign it to him. We need to get this resolved for 1.8.0 if possible.
[20:21] <robint_> Dont know what was siad but mdiggory is looking into the Maven 3 problem
[20:22] <tdonohue> robint_ : ok, cool. that's what we had thought
[20:22] <tdonohue> ok, that's it for JIRA review today
[20:23] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Ping timeout: 252 seconds)
[20:23] <mhwood> http://irclogs.duraspace.org/index.php?date=2011-08-03 at 20:57
[20:23] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2011-08-03
[20:23] <tdonohue> So, rest of the meeting is to tackle any reviews/discussion necessary for the 1.8.0 Feature Freeze (in just 9 days, on Aug 19)
[20:24] <KevinVdV> I have been working on a few things today
[20:24] <robint_> Looks like it will be the usual last minute flurry of commits
[20:24] <sandsfish> :)
[20:24] <tdonohue> yea...i think that's right, robint_
[20:24] <richardrodgers> that's why there are deadlines
[20:25] <robint_> :)
[20:25] <robint_> Whats up KevinVdV?
[20:25] <KevinVdV> https://jira.duraspace.org/browse/DS-989
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-989 ] - [#DS-989] Module directory maven property support - DuraSpace JIRA
[20:25] <kompewter> [ [#DS-989] Module directory maven property support - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-989
[20:25] <KevinVdV> For starters
[20:27] <tdonohue> KevinVdV, if I understand Ds-989 properly, this essentially just means you could modify that <default.solr.server> *before* running mvn package. Or you could modify Solr settings in both statistics.cfg and discovery.cfg afterwards.
[20:27] <KevinVdV> Yes
[20:28] <KevinVdV> It would work like the dspace.dir property works
[20:28] <KevinVdV> & the solr setting is just one example
[20:29] <tdonohue> right. my point here is that *most users* won't want to go into a pom.xml file to change settings. But, that's ok, cause they can still do the same changes to *.cfg files that they've always done. This patch just lets developers (or those who aren't scared of pom.xml changes) to centralize some settings.
[20:29] <KevinVdV> Indeed that is the point
[20:30] <richardrodgers> If I understand, this is what ConfigurationManager does for module config, but the CF does it dynamically (at property load time)
[20:30] <KevinVdV> Since the dspace.cfg already supports this I thought that the module config files should also support it
[20:31] <tdonohue> this sounds OK to me. I'd have no objections to it
[20:32] <mhwood> I suspect that the model configuration files will be much more heavily parameterized as we work toward installers and better testing and things like that.
[20:32] <richardrodgers> I'm not sure - it might limit abilities already present (as I mentioned)
[20:33] <tdonohue> richardrodgers: I'm not sure I understand what you said about ConfigurationManager...I'm confused, or maybe I don't know what it does exactly
[20:33] <richardrodgers> when a modular config property is requested, the file is *lazy-loaded* and the ${key} are filtered
[20:34] <richardrodgers> it I understand this change, they will be *pre-filtered* at build time
[20:34] <KevinVdV> It already "pre-filters" the dspace.cfg
[20:35] <richardrodgers> not dspace.cfg, but /modules/*.cfg
[20:35] <mhwood> The patch is selective, yes? If we want a token passed through unaltered, we can do that?
[20:35] <KevinVdV> Yes
[20:35] <KevinVdV> Ofc
[20:35] <KevinVdV> The patch just "allows" people to use this
[20:36] <KevinVdV> Since you have to know a little bit about the pom's
[20:36] <tdonohue> right..so, currently this patch *does* pre-filter at build time. But, the only thing it is pre-filtering is the solr.server (which is already hardcoded currently in /modules/*.cfg files). So, it's not prefiltering anything that requires lazy loading
[20:37] <tdonohue> or, richardrodgers, is it just the concept that someday this could conflict with "lazy loading" of /modules/*.cfg that bothers you?
[20:38] * tdonohue notes we probably should move on soon...this seems like a topic that we can bring offline
[20:38] <richardrodgers> I'm not sure I follow tdonohue - the assembly descriptor does config/modules/** (all files)?
[20:39] <richardrodgers> but I agree - we should table this
[20:40] <tdonohue> oh, wait. yea, you might be right, richardrodgers (i do see your point there). It'd be good to test this out and report back on the comments of this issue
[20:41] <KevinVdV> Feel free to comment on the issue I'm always willing to make some changes but I do hope it gets in DSpace 1.8.0
[20:41] <tdonohue> I suggest we table this and move DS-989 discussion to the issue comments itself. We need to move on..
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-989 ] - [#DS-989] Module directory maven property support - DuraSpace JIRA
[20:41] <KevinVdV> So moving on a really small improvement
[20:41] <KevinVdV> https://jira.duraspace.org/browse/DS-988
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-988 ] - [#DS-988] Consumers called in order of configuration - DuraSpace JIRA
[20:41] <kompewter> [ [#DS-988] Consumers called in order of configuration - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-988
[20:42] <richardrodgers> no objection KevinVdV - but what is the use case?
[20:43] <KevinVdV> Well for some of our clients we have found a need for this, it might be interesting to reindex the item into the search & call a custom consumer after that
[20:43] <mhwood> My first thought was: knowing that consumer order is arbitrary keeps people from writing consumers which interact, which might be the sanest thing to do.
[20:45] <tdonohue> i really have no objections here..but then again, I'd be a "0" vote (I don't feel strongly either way, right now)
[20:45] <mhwood> I can think of no reason why a consumer couldn't call another consumer and pass the same event to it, at a point of its own choosing. There's only a problem if you want to synchronize with another consumer in the plugin map.
[20:46] <richardrodgers> I'd say there is realistically always a determinant order, this patch just guarantees it. So I have no problem
[20:46] <KevinVdV> Again at the moment it won't make a difference but it would be more logical
[20:48] <tdonohue> anyone feel strongly here? +1/0/-1 (trying to speed this up..I have an issue I'd like to review too).
[20:48] <richardrodgers> +1
[20:48] <aschweer> +1
[20:48] <mhwood> I don't really have a firm objection. It's probably better anyway to document things you shouldn't do with consumer design.
[20:48] <mhwood> 0
[20:48] <aschweer> mhwood +1
[20:48] <tdonohue> ok, +2 votes. volunteer to commit then?
[20:49] <richardrodgers> I'll do it
[20:49] <tdonohue> assign Ds-988 to richardrodgers
[20:49] <KevinVdV> *Thanks richardrodgers*
[20:50] <tdonohue> I'd like to bring up DS-987 -- essentially, we have an issue with Solr Configuration upgrades
[20:50] <kompewter> [ https://jira.duraspace.org/browse/DS-987 ] - [#DS-987] By default, Solr Schemas & Configs don't upgrade properly & may cause instability - DuraSpace JIRA
[20:50] <tdonohue> But, in the comments, mdiggory suggests we may want to switch all Config updates to "overwrite=true" by default (which is a larger change, obviously) when running 'ant update'
[20:51] <tdonohue> I'm wondering how others react to this. Minimally, the Solr Schema *must* always auto-upgrade itself (overwrite=true). But, we could extend this to all configs in [dspace]/config/* if we felt it was worthwhile
[20:52] <mhwood> After 1.8.0 we may want to take a long look at the whole process of concretizing/installing/updating configuration data.
[20:53] <tdonohue> agreed, mhwood. The issue here though is that 1.8.0 upgrades may not work right if you just run 'ant update' (as your Solr Schemas & internal configs won't upgrade themselves)
[20:53] <robint_> If I understand correctly, I agree with mdiggory
[20:53] <robint_> I find it a pain changing all the xxx.new files to be xxx
[20:54] <tdonohue> so, robint_, you'd want to default 'ant update' to run in "overwrite=true" mode for everything?
[20:54] <robint_> Kneedjery answer, but yes
[20:54] <robint_> kneejerk
[20:54] <aschweer> I'd be happy with overwrite+backup too I think, unless there are issues with that which I'm overlooking
[20:54] <mhwood> Yes, keep it consistent. You have to examine and possibly edit, no matter what the names are. It's just a tweak in that process.
[20:55] <aschweer> (clarification: I mean for everything)
[20:55] <mhwood> However we need to announce this change *very loudly*.
[20:55] <tdonohue> I'd be fine with defaulting to 'overwrite=true' mode for everything as well.
[20:56] <tdonohue> my main reason for logging this ticket is that I think we *must* default to "overwrite=true" for the Solr configs (in [dspace]/solr/*/conf/ directories).
[20:56] <robint_> I think overwrite=true is more intuitive. Its what I expect to happen when I run update
[20:56] <tdonohue> +1 mhwood : it needs to be clear that we changed this
[20:57] * gaurav_kl (75c6215d@gateway/web/freenode/ip.117.198.33.93) has joined #duraspace
[20:58] <tdonohue> ok, well, I can create a new ticket which says we are changing *everything* to "overwrite=true" by default. This Ds-987 will be fixed by that broader scoped ticket.
[20:58] <richardrodgers> Can't we just define a build.xml property and everyone can have it their way?
[20:58] <aschweer> sorry, I have to leave. bye everyone
[20:58] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:59] <tdonohue> richardrodgers the "overwrite" setting is a build.xml parameter (currently it defaults to false, rather than true). Not sure I follow?
[20:59] <richardrodgers> If so, isn't this closer to a doc issue?
[21:00] <tdonohue> so, "ant upate" will run with "overwrite=false" by default. But, you can run "ant -Doverwrite=true update" to overwrite your configs by default (and copy old ones to *.old)
[21:01] <tdonohue> richardrodgers: no. actually not. The problem here is that Solr Configs are tied to the same system as normal configs, but they are *vastly different*. The Solr Configs in [dspace]/solr/*/conf/ directorys actually define our Solr Schema. If that Schema doesn't upgrade properly, then things may be unstable in DSpace.
[21:01] <tdonohue> Currently, the only way to ensure that Schema upgrades properly is to *always* run "ant -Doverwrite=true update"
[21:02] <richardrodgers> So global scope of overwrite is the issue, not true vs false
[21:02] <tdonohue> If you run "ant update" and there is a Solr Schema change, then it won't be picked up by Solr. You'll then be running an older Solr Schema, with newer DSpace code (which could be unstable)
[21:02] <robint_> Sorry all, go to go.
[21:02] <robint_> PS. Just noticed, no Hardy :(
[21:02] <tdonohue> richardrodgers: yes. actually, that is 100% correct
[21:02] <tdonohue> Hardy is on vacation/holiday this week :)
[21:03] <robint_> Ah! I'll save official welcome til later. Cheers
[21:03] * robint_ (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:03] <tdonohue> So, technically, we should *not* have "overwrite" have control over the Solr Schema upgrades (in my opinion). We need to always upgrade the Solr Schema when it needs to be upgraded
[21:04] <sandsfish> bye all
[21:04] * gaurav_kl (75c6215d@gateway/web/freenode/ip.117.198.33.93) Quit (Quit: Page closed)
[21:04] * sandsfish (~sandsfish@18.111.73.151) Quit (Quit: sandsfish)
[21:04] <richardrodgers> seems like it, Sorry I've got to run. thanks all
[21:04] * richardrodgers (~richardro@pool-96-237-109-89.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:04] <tdonohue> ok, I'll bring this discussion back to DS-987 then, since everyone is rapidly heading out :)
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-987 ] - [#DS-987] By default, Solr Schemas & Configs don't upgrade properly & may cause instability - DuraSpace JIRA
[21:05] <tdonohue> We'll call it a day, unless anyone has any final comments (though there are few of us that remain)
[21:05] <mhwood> I too must go. Thanks, all.
[21:05] <KevinVdV> Well I have one bugfix I don't want to see forgotten
[21:05] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[21:06] <KevinVdV> https://jira.duraspace.org/browse/DS-897 so if anybody wants to take this one, please go ahead
[21:06] <tdonohue> KevinVdV: bugfixes can actually wait until *after* feature freeze if need be. So, we have more time to get bugfixes into 1.8.0.
[21:06] <kompewter> [ https://jira.duraspace.org/browse/DS-897 ] - [#DS-897] Selecting "This Collection" in the sidebar search box produces a Page Not Found - DuraSpace JIRA
[21:06] <kompewter> [ [#DS-897] Selecting "This Collection" in the sidebar search box produces a Page Not Found - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-897
[21:06] <KevinVdV> Ok will do tdonohue *please ignore my comment*
[21:06] <tdonohue> It's only New Features & Improvements that need to be committed before Feature Freeze on Aug 19.
[21:10] <KevinVdV> Going offline now, thanks for the feedback on my JIRA's
[21:11] * KevinVdV (~KevinVdV@d54C14B16.access.telenet.be) Quit (Quit: KevinVdV)
[21:11] <tdonohue> Consider the meeting closed (obviously, as most everyone has left) :)
[21:12] * robertqin (~robertqin@bb116-15-204-27.singnet.com.sg) has joined #duraspace
[21:22] * robertqin (~robertqin@bb116-15-204-27.singnet.com.sg) has left #duraspace
[21:25] * robertqin (~robertqin@bb116-15-204-27.singnet.com.sg) has joined #duraspace
[21:26] * robertqin (~robertqin@bb116-15-204-27.singnet.com.sg) has left #duraspace
[22:10] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.