Timestamps are in GMT/BST.
[0:51] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[1:45] * edInCo (~edInCo@174.51.171.25) has joined #duraspace
[4:04] * hpottinger (~hpottinge@216.106.41.140.reverse.socket.net) has joined #duraspace
[4:05] <hpottinger> @decide xoai or Zenddb?
[4:32] * hpottinger (~hpottinge@216.106.41.140.reverse.socket.net) Quit (Quit: Later, taterz!)
[6:08] * edInCo (~edInCo@174.51.171.25) Quit (Quit: Leaving.)
[6:43] -adams.freenode.net- *** Looking up your hostname...
[6:43] -adams.freenode.net- *** Checking Ident
[6:43] -adams.freenode.net- *** Found your hostname
[6:43] -adams.freenode.net- *** No Ident response
[6:43] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:44] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:44] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:35] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:35] * edInCo (~edInCo@174.51.171.25) has joined #duraspace
[13:01] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:31] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[16:13] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[18:09] * edInCo (~edInCo@174.51.171.25) Quit (Quit: Leaving.)
[18:41] * edInCo (~edInCo@seta.coalliance.org) has joined #duraspace
[18:57] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:59] * KevinVdV (~KevinVdV@apu.imelda.be) has joined #duraspace
[19:59] <hpottinger> grats, KeveinVdV!
[20:00] <KevinVdV> Thx, still at the maternity so if I don't answer quickly give me a sec ;-)
[20:00] <tdonohue> Hi all, as usual, it's time for our weekly DSpace Developers Mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-31
[20:00] <kompewter> [ DevMtg 2013-07-31 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-31
[20:00] * bollini (~chatzilla@host56-223-dynamic.181-80-r.retail.telecomitalia.it) has joined #duraspace
[20:01] <tdonohue> KevinVdV...dang, surprised you made it. congrats though! Would it be helpful to skip your discussion to "first topic" today? (So you can logoff after that)
[20:02] <helix84> I'm sure Tim is surprised you made it to the DevMtg, not your other accomplishment earlier today ;)
[20:02] <tdonohue> I'm gonna do that anyhow...let's give KevinVdV a break here and skip down to topic #3 on agenda
[20:03] <tdonohue> So, KevinVdV wanted to get a discussion around DS-1272 going, for DSpace 4.0
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1272 ] - [#DS-1272] Enable Discovery By Default - DuraSpace JIRA
[20:03] * kstamatis_ (5b8c64da@gateway/web/freenode/ip.91.140.100.218) has joined #duraspace
[20:03] <tdonohue> also related Pull # 218: https://github.com/DSpace/DSpace/pull/218
[20:03] <kompewter> [ [DS-1272] Enable Discovery By Default for the XMLUI by KevinVdV · Pull Request #218 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/218
[20:04] <tdonohue> Namely, I think the idea here is that KevinVdV (and I) would like to see this in 4.0 and preferably get it committed/merged into "master" soon to allow for testing/stabilization (and a JSPUI version to be built to)
[20:04] <bollini> KevinVdV: the change at the browse artifact for xmlui are just a refactoring or there are any changes?
[20:06] <tdonohue> So, the first question is: Is everyone in favor of enabling Discovery by default? (IIRC we had talked about this for 3.0 already, but it had to be rescheduled)
[20:06] <bollini> +1 to enable by default for both UIs
[20:06] <tdonohue> The second question is: Any questions/concerns/feedback? (and I see bollini already added some)
[20:06] <hpottinger> I'm still +1 enable by default for both UIs
[20:06] <tdonohue> +1 from me to enable Discovery by default for both UIs
[20:07] <mhwood> +1
[20:08] <tdonohue> so it sounds like we're generally in favor of this change...just a matter of getting the PR some feedback and work to get this feature merged sooner rather than later
[20:08] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Ping timeout: 246 seconds)
[20:10] <tdonohue> My only question around this work (which I asked in the PR itself) was whether we also should *disable* Lucene and Browse DB indexing by default (so that we are not indexing twice). That is assuming that we no longer need Lucene or Browse DB tables for any features (wasn't sure if that's the case)
[20:10] <bollini> As a general note, in this phase, I will prefer that PR will be merged as soon as possible... just wait for a general agreement about the PR and 1 other committer that make a fast test or also only review code
[20:11] <bollini> tdonohue: if we enable discovery by default also on JSPUI we can (should) disable the search consumer (lucene). The browse consumer is a different thing (actually the PR don't change the browse provider)
[20:11] <KevinVdV> I believe another solution is possible for the browse
[20:11] <KevinVdV> We leave it enabled but use discovery as the backend
[20:12] <KevinVdV> I believe Andrea Bollini made this possible (correct me if I'm wrong)
[20:12] <bollini> KevinVdV: are you talking about enabling the SolrBrowseDAOs as default provider?
[20:12] <KevinVdV> This way we keep that functionnality but lose the browse & search consumer
[20:12] <bollini> yes, it is
[20:12] <KevinVdV> bollini: YES exactly !
[20:13] <KevinVdV> & I made it so that the people who can disable the browse artefact completely with a single comment in the xmlui.xconf !
[20:13] <tdonohue> that all sounds reasonable. I just really wanted to clarify how many indexes we are generating. I wanted that answer to be that we are creating just one search index and browse index (both in Discovery)
[20:14] <bollini> yes, in this way we only have one index (in the solr search core)
[20:14] <tdonohue> So, I'm in favor of merging this PR in...we may need to do some additional "cleanup" in other PRs (e.g. get a JSPUI version ready, then disable Lucene, etc)
[20:14] * l_a_p (~chatzilla@91.252.228.80) has joined #duraspace
[20:14] <KevinVdV> Agreed tdonohue !
[20:15] <hpottinger> Only thing I can think of is any "home grown" scripts that might hit the DB for data from the browse index... but, you know, things change
[20:15] <KevinVdV> You can all start testing & debug later but make sure to log the consumer & browse dao change
[20:15] <tdonohue> So, this PR is a good starting point...but we should admit there's a bit more work to do before we can "close" the Ds-1272 ticket completely.
[20:16] <KevinVdV> bollini: can you handle the JSPUI side of things ? (don't really know that much about discovery in JSPUI)
[20:16] <tdonohue> hpottinger: good point. We'd need to add some docs about this change (obviously) and also document how people can choose to (manually) enable Lucene & DB tables again, if they really really wanted that.
[20:16] <bollini> tdonohue: I will prefer to close the DS-1272 and open two new issues for jspui and browse
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1272 ] - [#DS-1272] Enable Discovery By Default - DuraSpace JIRA
[20:16] <bollini> yes, I can make the two PR for Discover JSPUI and SolrBrowse as default
[20:17] <KevinVdV> bollini: that would be great
[20:17] <hpottinger> so, who wants to press the button on the merge?
[20:17] <tdonohue> bollini: we can close Ds-1272 if we change its title to say "Enable Discovery by Default in XMLUI". Currently though, it's covering both XMLUI & JSPUI...so we'd need to edit that issue and create a new "Enable Discovery by Default in JSPUI" ticket.
[20:18] <mhwood> I have the button showing right now.
[20:18] <bollini> tdonohue: yes, I will proceed in this way... but It is only because I think 1 jira 1 PR
[20:18] <bollini> mhwood: push!
[20:19] <tdonohue> bollini: sounds good! I just wanted to make sure we make that small change to the current ticket, otherwise it's misleading :)
[20:19] <mhwood> It's in.
[20:19] <bollini> jira title updated
[20:20] <hpottinger> DSpace Committers, getting work DONE.
[20:21] <tdonohue> excellent!
[20:21] <KevinVdV> I had another small issue I wanted to address, concerning solr this time
[20:21] <KevinVdV> If everybody is up for it & has the time that is
[20:22] <tdonohue> ok, go ahead...sure, we should have some time
[20:22] <KevinVdV> I wanted to broach the subject of making dspace-solr & part of the solr core.
[20:23] <mhwood> Merging DSpace/DSpace and DSpace/dspace-solr?
[20:23] <KevinVdV> Yes
[20:23] <KevinVdV> It would make upgrading solr easier
[20:24] <bollini> we have already upgraded dspace-solr to solr 4
[20:24] <KevinVdV> Since now if a new solr version is released we have to wait for the dspace-solr artefact to deploy before we can even think about testing
[20:24] <bollini> we plan to contribute this for 4.0 actually it is on the DSpace-CRIS project
[20:24] <mhwood> No more waiting for Maven Central before taking up changes to dspace-solr. I like it. I can't think why we should not.
[20:25] <tdonohue> yea, merging: https://github.com/DSpace/dspace-solr (which is really just ~2-3 java custom java files overlayed on Solr) into our main codebase
[20:25] <kompewter> [ DSpace/dspace-solr · GitHub ] - https://github.com/DSpace/dspace-solr
[20:25] <mhwood> The one thing I would ask: I have a pending PR on dspace-solr and would like to get it pulled or rejected before rearranging the projects.
[20:25] <tdonohue> I'm fine with merging dspace-solr into the main codebase as well
[20:25] <hpottinger> +1 to merging dspace-solr
[20:26] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:26] <tdonohue> I agree with mhwood though...best to finish up any pending PRs for 'dspace-solr' and *then* do the merger...it's a bit less messy that way
[20:26] <KevinVdV> Agreed, I think we can accept & merge mhwood changes & THEN start the merging process
[20:26] <mhwood> Thank you.
[20:27] <bollini> how complex/long will be the merging process?
[20:27] <tdonohue> sounds good to me. Anyone want to volunteer to create a JIRA ticket for this merger?
[20:28] <mhwood> Not long but may be complex. If there are N git users, it seems that there are at least N opinions on how to merge two repositories.
[20:28] <mhwood> I can write the ticket. I'm not up to speed on how to do the work.
[20:29] <tdonohue> yea, we'd need to investigate the best way to migrate (and hopefully keep the history). Though, to be clear, we've done this before with "dspace-services" which used to be at "DSpace/dspace-services" in GitHub
[20:30] <tdonohue> I can probably help some with migration. I've done some of this in the past, and after the Git part is figured out, it's mostly just "wiring up" the POMs correctly (which isn't hard actually)
[20:30] <KevinVdV> I probably won't have time to do the merge myself though … so I hope somebody can help...
[20:31] <mhwood> Does dspace-solr PR#3 need discussion, sometime soon? I kind of took the original idea and ran with it....
[20:31] <tdonohue> https://github.com/DSpace/dspace-solr/pull/3
[20:31] <kompewter> [ [DS-1460] Add SOLR logging config file by mwoodiupui · Pull Request #3 · DSpace/dspace-solr · GitHub ] - https://github.com/DSpace/dspace-solr/pull/3
[20:32] <tdonohue> I'm fully in support of your changes mhwood. They at least make log settings easier to work with (by moving them all to log4j). We can always improve upon the default settings later as needed
[20:34] <KevinVdV> +1 for this change also, again if we do this quickly enough we can easily alter anything that may not work properly
[20:34] <KevinVdV> (Although I doubt much changes are required)
[20:34] <helix84> +1
[20:35] <tdonohue> +1 to merge quickly/soon
[20:35] <mhwood> I'm less concerned with the code than with acceptance of the whole approach, but that looks like enough votes unless someone objects.
[20:36] <bollini> +1 to merge... only I question: is the lucene-core/solr-solrj dependencies really needed in the pom? https://github.com/DSpace/dspace-solr/pull/3/files#L6R117
[20:36] <kompewter> [ [DS-1460] Add SOLR logging config file by mwoodiupui · Pull Request #3 · DSpace/dspace-solr · GitHub ] - https://github.com/DSpace/dspace-solr/pull/3/files#L6R117
[20:36] <KevinVdV> Hmmm agreed, good catch
[20:37] <mhwood> mvn dependency:analyze doesn't seem to mind it.
[20:37] <KevinVdV> But I don't think we need to worry, these should only end up in the solr webapp
[20:37] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:37] <KevinVdV> So shouldn't conflict with DSpace itself
[20:38] <mhwood> That's a point to consider during the merging of the projects, though.
[20:39] <tdonohue> Yea, it's possible we could reanalyze those dependencies during project merger (could also try removing them immediately to see if it still builds, but I'm guessing their must have been a reason mhwood added them initially)
[20:39] <bollini> yes, I'm just curious to know if solrj is really needed by the solr webapp from one side... and the other as we are doing an overlay of a standard solr webapp we should not declare a dependency from lucene-core (we should just rely on the base webapp)
[20:41] <bollini> my last (old) concern is... do we really need a dspace-solr webapp? isn't it more simple to document well how to setup a standard solr distribution?
[20:42] <KevinVdV> I think the web app makes it easier for user to test queries
[20:42] <bollini> actually the dspace-solr webapp only add basic security option (and with this PR default log4j configuration)
[20:42] <tdonohue> bollini: regarding dspace-solr. I think it's better to "ship with Solr" to lessen the number of things you have to install to get DSpace running. But, we should document how folks could (optionally) instead use a standard solr
[20:42] <aschweer> tdonohue +1
[20:43] <bollini> tdonohue: it could be a simplification... but we will need to provide new version of dspace-solr any time that solr go ahead
[20:44] <tdonohue> bollini: that depends on your point of view. It's a "simplification" for us (developers)...but it potentially makes it harder on users/installers (as they need to figure out how to install/setup Solr before they can run DSpace)
[20:45] <tdonohue> this becomes especially true as we "enable Discovery by default". If we don't have Solr provided in DSpace, then we are essentially shipping a DSpace that is "broken" until you install & configure Solr
[20:45] <helix84> let me remind you of our single strongest point: DSpace is an IR out-of-the-box
[20:45] <tdonohue> helix84: +1
[20:45] <bollini> there is a lot of documentation about solr setup and installation... we only need to be sure that user make the solr server secure
[20:46] <bollini> it is matter to add a row in the context.xml file something like the URIEncoding in tomcat
[20:46] <tdonohue> Personally, I also wish we "shipped with Tomcat" at times (e.g. Fedora does, or at least gives you the option to use embedded Tomcat vs. external)...but, that might be even more controversial :)
[20:46] <hpottinger> I'd be OK with shipping with Tomcat
[20:46] <helix84> tdonohue: not necessarily tomcat, jetty is an option, as we just discussed
[20:46] <aschweer> We get a lot of questions on dspace-tech that are quite basic even at this point. This would get a lot worse if people had to figoure out how to sort out solr themselves.
[20:46] * hpottinger ducks
[20:46] <bollini> when the dspace-solr was added there were additional requirement (support for grouping) that was not available in out-of-box solr installation
[20:47] <KevinVdV> I did have to add a bug fix to the solr 3 to get our statistics working with it though, so I'm still in favor of keeping dspace-solr around.
[20:48] <hpottinger> actually, I may have nightmares about Solr + Fedora + Drupal tonight (sorry Discovery Garden)
[20:48] <tdonohue> Noticing the time here... I think we need to get back "on track"
[20:48] <bollini> ok, just raised the question to see if the general opinion was changed
[20:49] <bollini> I will try next year :-)
[20:49] <tdonohue> bollini: no problem. It's fine to raise the question. I just know that I'm fully on the bench that DSpace should be "easy to install"... So, I'm currently -1 anything that causes an extra step in the installation process :)
[20:50] <tdonohue> but, I'm not against offering an *option* to install DSpace without Solr (and instead configure it to use a Solr you installed elsewhere)
[20:50] <helix84> so, on to our next point about migrating from postgres to sqlite... :D
[20:50] * hpottinger faints.
[20:50] <tdonohue> Ok...going back to the agenda now...want to try to fit a few more small things in here :)
[20:51] <tdonohue> DS-1609 bug -- via the hard work of hpottinger & mhwood, we have a PR ready for Lyncode (Joao) to fix this bug
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1609 ] - [#DS-1609] DSpace 3.2 OAI-PMH Functionality needs JDK 1.7 (Java 7) - DuraSpace JIRA
[20:52] <tdonohue> So, I don't think there's much to discuss here... mostly we need to get in touch with Joao to see if he's willing to release a new version of the Lyncode XOAI module (which supports JDK 1.6+).
[20:52] <bollini> tdonohue: talking about easy adoption/installation... I have the vagrant software in my to-do list http://docs.vagrantup.com/v2/why-vagrant/index.html
[20:52] <kompewter> [ Vagrant Documentation ] - http://docs.vagrantup.com/v2/why-vagrant/index.html
[20:52] <tdonohue> Then, we may need to release a quick DSpace 3.3
[20:53] <hpottinger> bollini, let's talk about Vagrant
[20:53] <tdonohue> bollini: ha..regarding Vagrant, hpottinger & I have been talking about that frequently (but more for a Developer Environment...and not for *Production* systems)
[20:53] <helix84> aschweer: what about our discussion of a proper debian package? shall we bite the bullet and try to become a DD?
[20:54] <mhwood> I suppose I'll have to work out how to make a Gentoo ebuild then....
[20:54] <hpottinger> and an RPM for us corporate types
[20:54] <aschweer> helix84: I think it might make sense first to find a DD to work with and figure out how far we can get. You don't have to be DD just to create the package(s)
[20:54] <mhwood> Meanwhile, XOAI?
[20:54] <aschweer> hpottinger: yeah ironically my repos all run on RPM-based systems, but I know a little more about debs
[20:54] <helix84> aschweer: agreed
[20:55] <tdonohue> bollini & all: I have also been playing with Vagrant -- and I plan to post a very rough Vagrant config file I've been playing with to GitHub (stay tuned). It doesn't yet install all of DSpace though... just does some basics to "get ready" for installing DSpace.
[20:55] <tdonohue> but, mhwood is right...the topic here is XOAI ;)
[20:55] <tdonohue> Is someone in touch with Joao regularly? If not, I can try and get him via email to see if he can push out a new XOAI, so that we can fix it and release DSpace 3.3 immediately
[20:56] <aschweer> I'm happy to help test vagrant stuff (now that I see it works on Linux too) if required
[20:56] <KevinVdV> I'm going offline, I'm afraid my women need me. Until next time everybody !
[20:56] <hpottinger> Vagrant stuff: http://lso.umsystem.edu/~pottingerhj/article/24/my-new-toy-vagrant
[20:56] <kompewter> [ article: hardy@lso: my new toy: Vagrant ] - http://lso.umsystem.edu/~pottingerhj/article/24/my-new-toy-vagrant
[20:56] <helix84> Joao is pretty much unreachable now. The best way to contact him is email and I already did that.
[20:57] * KevinVdV (~KevinVdV@apu.imelda.be) Quit (Quit: KevinVdV)
[20:58] <hpottinger> hmm... do we run off with the XOAI code at some point?
[20:58] <tdonohue> helix84: If Joao is unreachable, do you know if there is someone else (at Lyncode) filling in for him that we could work with?
[20:59] <helix84> I can try that, but I think xoai is Joao's child
[21:00] <helix84> Yep, I just confirmed that
[21:00] <tdonohue> XOAI is Apache 2 Licensed -- we could "fork" it & modify if we absolutely needed to. But, I'd obviously rather Joao work with us on it :)
[21:01] <bollini> the main question is what we want do with dspace 4 and java version
[21:01] <hpottinger> OK, so, it's a possibility.... how long did we wait on Cocoon before we absorbed it?
[21:01] <tdonohue> ok.. well, I'll try and email Joao too, see if we can track him down
[21:01] <helix84> I'd prefer to stay conservative
[21:01] <helix84> regarding Java version requirements
[21:02] <helix84> think of RHEL
[21:02] <bollini> we can also provide in some way a xoai version that work on java 6 for the dspace 3.3 but it is not reasonable to work in this way too long (dspace 4.x)
[21:02] <hpottinger> +1 boll ini, just keeping track of 6 and 7 is difficult for testing
[21:02] <tdonohue> With DSpace 4, I'd recommend we actually look towards Java 7+. Java 6 is EOL.
[21:03] <hpottinger> apologies, bollini, OSX Mountain Lion has its sights set on your name...
[21:04] <tdonohue> I don't think we should continue to try to support versions of software which are "End of Life". So, I think DSpace 3.x is the last version of DSpace that needs to support Java 6. With DSpace 4, we can move that requirement up to Java 7.
[21:04] <hpottinger> +1 tdonohue
[21:04] <aschweer> I've had DSpace 1.8.2 crash on Java 7, but I think that was a problem with the local environment somehow, not with DSpace itself. And I haven't tried 3.x
[21:05] <helix84> so is this only a support problem or is there something in Java 7 that you really really want?
[21:05] <hpottinger> Travis-CI builds only with Java 7, BTW
[21:06] <bollini> I'm 0 with this... as developer I'm in favour to move up but I'm concerned about people that will wait to update dspace due to the java update self
[21:06] <tdonohue> demo.dspace.org is running DSpace 3 on Java 7 (OpenJDK). We're also doing DSpace 3 + Java 7 for DSpaceDirect service. As far as I've seen so far (admittedly these aren't huge sites yet), DSpace 3 + Java 7 works fine.
[21:06] <aschweer> tdonohue: good to hear, thanks
[21:06] <aschweer> anyway, gotta run
[21:06] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:07] <helix84> tdonohue: my concern is not whether java 7 works fine, but that we may be moving too fast for institutions to keep up with OS upgrades
[21:07] <hpottinger> most of this Java 6 stack is going EOL
[21:07] <tdonohue> There's nothing I absolutely *need* in Java 7...but as everything else is starting to require Java 7 as well, we shouldn't "limit ourselves" to having to support an older, End-of-life, Java 6. It simplifies our development if we can concentrate on Java 7 and not need to test also against Java 6
[21:07] <helix84> i'mnot against supporting java 7 (which we already do) but against doing things that intentionally break backwards compatibility - unless there is a good reaso
[21:08] <bollini> helix84: actually we have problem to compile code for a library required by dspace-cris on openjdk6 but it works perfectly on oracle6,7 and openjdk7... so support for old VM require extra efforts
[21:08] <tdonohue> helix84: my "works fine" answer was for aschweer actually...she asked if Java 7 now worked ok with DSpace 3
[21:09] <helix84> I'll try to take a look at common platforms and their supported Java version, then we'll have some data to decide
[21:09] <tdonohue> what are we breaking backwards compatibility with? older operating systems (which only have a Java 6 option)? I guess I'm unclear how moving to Java 7 could be bad for us.
[21:09] <helix84> tdonohue: yes
[21:09] <tdonohue> helix84: data would be good
[21:09] <hpottinger> after rummaging around in what Joao was doing with Java 7, I think it has pretty nice improvements to exception handling
[21:10] <tdonohue> I'm not convinced that there are recent operating systems that don't support Java 7 (I'm not aware of any offhand, especially since we also now support OpenJDK).... but if there's data to point to otherwise, then we can revisit.
[21:10] <helix84> hpottinger: honestly, would you upgrade your OS to get that? (I'm not trying to imply that upgrading the OS is the only way)
[21:11] <hpottinger> helix84, no, I'd upgrade my OS because my whole stack went EOL
[21:12] <hpottinger> patches are nice :-)
[21:12] <tdonohue> Ok...we're overtime here, but I was wanting to at least try and keep the discussion going around DSpace 4.0 Release Schedule. abollini gave a suggested schedule, which we should all look at and comment on (either here or on dspace-release later)
[21:13] <helix84> from last year's experience, if we do adopt Andrea's schedule, the RT will have to be very strict about the Feature Freeze deadline and all code already being ready by then
[21:13] <hpottinger> I've been tinkering with Java 7 a bit, as it supports creating hard links, which is helpful for managing creation of batch loads of large bitstreams... no reason to eat up disk space just to get a SAF batch set up.
[21:14] <tdonohue> I think my main comment on abollini's suggested schedule is that, because it is a relatively "tight" schedule, we'd have to be pretty strict about the "Feature Freeze"... and we'd also need to make the "Feature Freeze" the date that stuff must be MERGED into the code.... folks would need to have PRs submitted well in advance (weeks or a month) before the "Feature Freeze" to get a proper review
[21:14] <helix84> hpottinger: excuse my ignorance - what does java have to do with hard links? that's an OS-specific feature, isn't it?
[21:14] <tdonohue> helix84 & I just said essentially the same thing about the 4.0 suggested schedule :)
[21:15] <mhwood> I want to see us working with contributors to get stuff in early.
[21:15] <hpottinger> helix84, it *is* OS-specific, Java 7 just supports it on operating systems that support them
[21:15] <tdonohue> mhwood: yea, I think that's a great idea.
[21:15] <hpottinger> I like bollini's schedule
[21:15] <mhwood> I've made a note to get my head out of the code and give scheduling proper attention tomorrow. And this seems a reasonable starting point.
[21:16] <hpottinger> mhwood: I'll pop on here tomorrow if you want to chat about it
[21:16] <mhwood> Thanks.
[21:16] <tdonohue> I think my main point around the "Feature Freeze" is that with the 3.0 release, there was some confusion around whether the "Feature Freeze" deadline referred to "last date new feature code can be merged/committed" OR the "last date new feature Pull Requests can be submitted". We just need to clarify (to developers & committers) that it's the former rather than the latter.
[21:17] * l_a_p (~chatzilla@91.252.228.80) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
[21:17] <mhwood> Right now I do need to go. Thanks, all! Good point tdonohue. WIll remember.
[21:17] <tdonohue> yep. sounds good. we'll bring 4.0 to dspace-release list
[21:18] <tdonohue> and I'll also be on IRC tomorrow as needed
[21:18] <bollini> tdonohue: +1 Feature Freeze -> last date to merge
[21:18] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:19] <tdonohue> So, with that, I don't think we have anything else to discuss today. Obviously we're well over time here. I'll still be around for a little bit, but the official meeting is closed
[21:19] <bollini> I will try but probably you will start chat on IRC too late for me (your morning is afternoon in Italy)
[21:20] <bollini> bye. Good night to all
[21:20] * bollini (~chatzilla@host56-223-dynamic.181-80-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
[21:20] <hpottinger> night!
[21:22] * kstamatis_ (5b8c64da@gateway/web/freenode/ip.91.140.100.218) has left #duraspace
[21:25] <helix84> can anyone with some experience with maven please take a look at [Dspace-tech] FW: DSpace 3.2 Failed to resolve artifact ?
[21:26] <helix84> this missing artifact message pops up every now and then and I'm not sure what causes it
[21:26] <helix84> and I meant it always did pop up randomly, I can remember it since 1.8.x
[21:35] <tdonohue> helix84: I just answered...to me it sounds like he's got the wrong version of the code. Either that, or some POM (somewhere in his code) is pointing at 4.0-SNAPSHOT (when it shouldn't be).
[21:36] <tdonohue> helix84: I just looked around at the 3.2 tagged code...the root POM and the POM he got the error from both say version "3.2". So, I'm not sure where the 4.0-SNAPSHOT is coming from
[21:37] <hpottinger> he's compiling from source, probably
[21:40] <hpottinger> if he's compiling, it might help to first run a mvn install
[21:41] <tdonohue> but to clarify, he shouldn't need a "mvn install" if he's compiling from a tagged (stable) version, as Maven should go grab the dependencies from Maven Central.
[21:42] <tdonohue> The only way (I can think of) to get this 4.0-SNAPSHOT error would be to (1) Checkout "master" (2) cd [src]/dspace/ (3) mvn package (without first running "mvn install") -> this should error as the 4.0-SNAPSHOT dependencies won't be found in Central or in your ~/.m2 (until you run mvn install, or build from [src] root directory
[21:56] <hpottinger> Gotta run, bye!
[21:56] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:00] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:23] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[23:17] * edInCo (~edInCo@seta.coalliance.org) Quit (Quit: Leaving.)
[23:59] * edInCo (~edInCo@c-174-51-171-25.hsd1.co.comcast.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.