Timestamps are in GMT/BST.
[2:50] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[3:31] * eddies (~eddies@bb219-74-197-50.singnet.com.sg) has joined #duraspace
[3:31] * eddies (~eddies@bb219-74-197-50.singnet.com.sg) Quit (Changing host)
[3:31] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:56] -card.freenode.net- *** Looking up your hostname...
[6:56] -card.freenode.net- *** Checking Ident
[6:56] -card.freenode.net- *** Found your hostname
[6:56] -card.freenode.net- *** No Ident response
[6:56] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:56] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:56] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:00] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[8:00] * eddies (~eddies@bb219-74-197-50.singnet.com.sg) has joined #duraspace
[8:00] * eddies (~eddies@bb219-74-197-50.singnet.com.sg) Quit (Changing host)
[8:00] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[9:03] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:17] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:08] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[16:45] <tdonohue> Note for Developers: https://bamboo.duraspace.org will be down shortly (for about 10mins) while I perform an upgrade to Bamboo. There was a recent critical security issue reported in our current version of Atlassian Bamboo.
[16:45] <kompewter> [ Dashboard - DuraSpace Bamboo ] - https://bamboo.duraspace.org
[16:53] <tdonohue> https://bamboo.duraspace.org is back up, and Bamboo has been upgraded.
[16:53] <kompewter> [ Dashboard - DuraSpace Bamboo ] - https://bamboo.duraspace.org
[17:02] <tdonohue> If anyone has DSpace topics to chat about, feel free to ping me. My official "office hours" are now until our Developer Meeting: https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[17:02] <kompewter> [ DSpace Office Hours - Tim Donohue - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[17:09] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:47] * helix84 (a@195.113.97.174) has joined #duraspace
[19:47] <tdonohue> Hi all, reminder that we have our DSpace Developers Mtg here at the top of the hour (~12mins): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-29
[19:47] <kompewter> [ DevMtg 2012-08-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-29
[19:49] * bollini (~chatzilla@host176-111-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[19:50] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:53] <tdonohue> Hi DSpace Devs -- apologies in advance of our upcoming meeting. I have some workers here today trying to fix a roof leak. So, I may have to step away at a moment's notice as needed. I will let you all know if I need to step away so that meeting can hopefully continue on without me.
[20:00] <tdonohue> Hi all, DSpace Developers mtg is starting now. Today's agenda is up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-29
[20:00] <kompewter> [ DevMtg 2012-08-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-29
[20:01] <tdonohue> seems like a rather semi-small crowd again today...but hopefully we'll get some more folks filtering in here in the next few minutes
[20:01] <bollini> hi all
[20:01] <mhwood> Sorry, I was out of town last week and a promised network connection didn't work.
[20:02] <tdonohue> as has been the case the last few weeks, we'll concentrate on 3.0 stuff today. I didn't have any specific topics to tackle, other than I know we have a lot of Feature pull requests that still require some sort of review before the "freeze" on Sept 7 (just over a week)
[20:03] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:03] <helix84> i have a small status update. XOAI is in good shape, small fixes still coming in, I rebased the branch to merge easily.
[20:03] <tdonohue> The other topic we could discuss are the odd build/test problems noticed by both helix84 and mhwood in recent days, as this is causing potential merge issues
[20:04] <bollini> is it a good practice rebase the branch before merge?
[20:04] <helix84> as announced, I opened a pull request for the ldap improvements, which include DS-1078 and merging LDAPAuthentication and LDAPHierarchicalAuthentication. DS-1180 was already merged previously.
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1078 ] - [#DS-1078] Assign users in LDAP group to DSpace group on login - DuraSpace JIRA
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1180 ] - [#DS-1180] LDAP: if no adminUser is set, build the DN using the object_context - DuraSpace JIRA
[20:05] <helix84> bollini: in my opinion, it's what we should do. in my case, it wouldn't merge otherwise. in general, it helps keep clean history (without parallel branches).
[20:06] <tdonohue> So, where do we want to start today? Any suggestions from the Release Team members (so that we can make the most of our time here & make sure we are on-track to meet upcoming deadlines)?
[20:06] <mdiggory> I saw the recent dialog concerning maven and property replacement, I've not had a moment to look into it however.
[20:06] <bollini> helix84: we are new to git but someone could have already started to fork and make experiments also starting from branch that we are currently merging... rebasing could cause issue to them
[20:07] <tdonohue> mhwood -- is the maven / property replacement stuff worth touching on today? Is additional help/support needed? I'll admit, I haven't had time to look at it this week either.
[20:07] <helix84> I also made a pull request for DS-1084, I still expect minor fixes there. And for DS-1193, where still noone volunteered to make separate endpoints for rights, so I went ahead in its current form.
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1084 ] - [#DS-1084] Handle authority and confidence fields in Bulk Editing - DuraSpace JIRA
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1193 ] - [#DS-1193] display bitstream read access permissions on item page - DuraSpace JIRA
[20:08] <helix84> bollini: you are right. But this branch is essentially moments before merge, so I don't expect any changes (except for from Lyncode and I coordinate with him). I also warned about the rebase in comments.
[20:09] <mhwood> I've been putting bits of my investigation on dspace-devel as I find stuff. I think I know why it's misbehaving but haven't got it fixed yet. I just worked out the problem a few minutes ago.
[20:09] <helix84> if most of you agree, we can discuss the benefits of rebase vs. merge
[20:10] <mdiggory> there are also dangers unfortunately.
[20:11] <mdiggory> just to be fair, I do use rebasing, I don't mean to present a negative viewpoint.
[20:12] <mhwood> I expect that rebase vs. merge will come down to personal taste. I don't rebase because I like plenty of history on small, self-contained commits (and because I don't want to think about the issues you get into with rebasing).
[20:12] <tdonohue> helix84 -- to be honest, I'd rather make sure we get our build/test problems resolved as currently our pull request queue is a bit "stuck", as our unit tests are hanging indefinitely, and as you noted, rebuilding (mvn package) DSpace currently causes it to grow exponentially in size to several GB
[20:13] <helix84> tdonohue: okey dokey. we may discuss rebase in the meiling lists if anyone wants.
[20:13] <mdiggory> There is a detail in the diagram I put up at the conference that makes use of rebase / squash a little less problematic for other users, and that is to always use a "release candidate" to squash/rebase the work you will contribute to a Pull Request" rather than the original feature branch
[20:13] <tdonohue> I do however think we should update our Git Documentation to talk about Rebase Vs. merge: https://wiki.duraspace.org/display/DSPACE/Development+with+Git (As mhwood mentions though I think it is a matter of preference in some ways)
[20:13] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git
[20:14] <helix84> mdiggory: that's a good practice and in a way I do that. we can discuss the details via email.
[20:15] <mhwood> So which goes first? Configuration Wars, or the Incredible Expanding DSpace Build?
[20:15] <mdiggory> Sounds like the next episode of Star Wars
[20:16] <bollini> just to add a point to our agenda, I'm interested in receiving a "final" direction for the JSPUI/browse discovery contributions (enabled by default? which strategy use for enabling/disabling them?)
[20:16] <tdonohue> I think we talk about Configuration Wars. That currently has our Unit Tests hanging forever, so it probably gets a slightly higher priority
[20:16] <helix84> lyncode figured out a solution to the expanding build, but someone with maven experience may want to look at it.
[20:16] <helix84> (the solution is presented in the last comment on pull request #40)
[20:16] <mdiggory> I think we should change the title before we talk about it... we were starting to get productive...
[20:17] <mdiggory> "The Future of Configuration"
[20:19] <tdonohue> we need to be geared towards 3.0 here :) We have only this week & next to also give the final votes on every outstanding pull request (if we are to make our Feature Freeze deadline). So, we need to stay on track with limiting discussion around 3.0
[20:19] <helix84> "Maven Build: Clone Wars"
[20:20] <mdiggory> ha, ok... that smells like maybe the processed files are getting included back into the processing during the next maven build
[20:20] <helix84> tdonohue: If the idea is to vote on _every_ new feature / improvement, I can make a list of outstanding pull requests. And suggest a few right now.
[20:20] <mhwood> OK. DSpaceConfigurationService is looping forever when it sees a combination of a circular reference (dspace.dir = ${dspace.dir}) and a reference to the circularly-defined property in another property's value. That's the hang. I want to fix that by changing the way we test for circularity. But that leaves the tests broken.
[20:21] <mdiggory> maybe try putting an excludes "target" here
[20:21] <mdiggory> https://github.com/DSpace/DSpace/pull/40/files#L1R29
[20:21] <kompewter> [ Pull Request #40: DS-1208 Build time filtering to allow multi developer/environment builds by steveswinsburg · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/40/files#L1R29
[20:23] <mhwood> The reason the code is seeing this unfortunate situation is that ConfigurationManager and DSpaceConfigurationService don't find the "master" config. in the same way. I want to fix that by teaching DSpaceConfigurationService to look for the same system property that ConfigurationManager uses to override the path to the "master". It looks as though Ant is depending on this alternate-configuration stuff.
[20:23] <tdonohue> mdiggory -- are you talking about the other Maven issue? There are two -- the Ever-Expanding DSpace Build (which seems to be a web.xml filter issue), and the Infinite Loop Configuration Problem (what mhwood is talking about)
[20:23] <helix84> mdiggory: i've really done my best figuring out what's wrong. fixing it is another story, it's beyond my skills. if you can prepare a fix, I'm sure Steven will be happy to review it.
[20:24] <tdonohue> mhwood -- that fix sounds reasonable to me (though admittedly, I haven't had a chance to look in much detail)
[20:25] <mhwood> I should check, but I think that the DS-1208 substitution isn't done yet. We're in "test" phase.
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1208 ] - [#DS-1208] Build time filtering to allow multi developer/environment builds - DuraSpace JIRA
[20:26] <mhwood> Actually I hope that substitution isn't done yet. Unit testing shouldn't depend on local configuration!
[20:27] <tdonohue> I'm not sure I understand what you mean by Ds-1208 not being "done". It's committed/merged, and it (initially) passed Unit tests after the merge.
[20:28] <mhwood> "done" as in "executed by Maven".
[20:28] <mdiggory> now I'm confused
[20:28] <mdiggory> I was referring to " Ever-Expanding DSpace Build "
[20:28] <hpottinger> Hi, I should apologize for being very distracted, we've got a development server acting up on us today, am trying to keep an eye on the inbox, as well as this meeting, sorry for blurting this out of context, but figured I should say *something* about being distracted.
[20:29] <tdonohue> mdiggory -- yea, there's two different Maven issues. We're also having an issue in Bamboo. The unit testing hangs forever (hits an infinite loop in attempting to load configurations) -- this is the one mhwood has been looking into
[20:30] <helix84> suggestion - let's start messages with issue's we're talking about (loop:, target:, bamboo:)
[20:31] <mhwood> #define bamboo: loop:
[20:31] <helix84> ...
[20:31] <mdiggory> I think one challenge is that the notes are all over the place and mixed in with the contributions dialog
[20:32] <mdiggory> I"m not even fully aware of the details of proposals to resolve, can we have someone summarize the first issue (loop:)
[20:32] <tdonohue> Here's the dspace-devel thread about the Unit Testing Infinite loop: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg09597.html
[20:32] <kompewter> [ Re: [Dspace-devel] [DSpace-changelog] [DuraSpace Bamboo] DSpace > Master ] - http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg09597.html
[20:33] <tdonohue> Here's the separate issue around the "Ever expanding DSpace build" (target recursion) -- it's mostly in the comments at the end of this pull request: https://github.com/DSpace/DSpace/pull/40
[20:33] <kompewter> [ Pull Request #40: DS-1208 Build time filtering to allow multi developer/environment builds by steveswinsburg · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/40
[20:34] <mdiggory> hmm, I get the sense that ConfigurationService is unaware of the attempts to do value replacement on key=${key}
[20:35] * mdiggory note this seems a good example of why I didn't like the approach originally and suggested value replacement based on key
[20:35] <mhwood> If you mean the Ds-1208 filtering -- ConfigurationService shouldn't know or care. It's either done by the time ConfigurationService inits, or not.
[20:36] <mhwood> When not, we see the problem.
[20:37] <mdiggory> So the problem is that he configuration isn't getting filtered properly and ConfigurationService spins out of control due to the indirect loop.
[20:37] <mdiggory> So, the primary problem is that theres a bug in DS 1208
[20:37] <mhwood> I think it's not filtered *yet*. Doesn't test phase happen before the filtering? I'm trying to find the filtering in the POM....
[20:38] <mdiggory> and the result of that bug exposed a shortfall in ConfigurationService
[20:39] <mdiggory> Since this is happening in test, I assume that the build.properties filtering isn't getting processed on the test environment because it wasn't designed to do so?
[20:40] <tdonohue> The thing I find odd in this Config infinite loop issue is that after the Ds-1208 feature (build.properties) was initially committed, the Unit tests worked fine (they succeeded). The oddity is this problem didn't manifest itself until after the Salt PasswordAuth stuff also was merged (https://github.com/DSpace/DSpace/pull/41)
[20:41] <mhwood> Probably that contained the first unit test that triggers ConfigurationService?
[20:41] <tdonohue> could be, mhwood.
[20:42] <mhwood> I've been pushing myself to use the Services wherever possible.
[20:43] <tdonohue> Yea, you're probably right then. Maybe no other unit tests called the ConfigurationService until the Salt PasswordAuth, and thus the problem emerged there
[20:43] * ruebot (~ruebot@LB-SC-S1B4DB.library.yorku.ca) has joined #duraspace
[20:43] <mdiggory> Maybe.... I think there was also an adjustement we made to have the dspace.cfg be in the appropriate location such that the ServiceManager could properly start during tests
[20:45] * tdonohue is now wondering if maybe we move on to other topics? Now that we've gotten these issues in several of our minds, maybe it's best to bring discussion & resolution to the mailing lists?
[20:45] <mhwood> Perhaps so. Don't want to waste time thinking silently while we are gathered.
[20:45] <mdiggory> mhwood: is this something you will continue to attack?
[20:46] <mhwood> Yes, I'm still on it.
[20:46] <tdonohue> yep, exactly. I think if we can get a few volunteers to help out, we should take the rest of this work to mailing list
[20:47] <tdonohue> Do we have a volunteer to also look at the Maven 'target' recursion problem (the Ever Expanding DSpace Build)?
[20:48] <tdonohue> again, described here: https://github.com/DSpace/DSpace/pull/40
[20:48] <kompewter> [ Pull Request #40: DS-1208 Build time filtering to allow multi developer/environment builds by steveswinsburg · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/40
[20:48] <mhwood> Rather, look at 'target' recursion *solution*?
[20:48] <tdonohue> mhwood : yea, you know what I mean :)
[20:48] <helix84> there already is a solution suggested, but someone who speaks maven needs to implement it
[20:49] <helix84> and mdiggory just suggested a solution, too (is it different from lyncode's?)
[20:49] <tdonohue> So who is this "someone who speaks maven"? Shouldn't we all be willing to try and dig into some maven? (considering so much of DSpace build depends on it) ;)
[20:49] * helix84 applauds tdonohue for volunteering :)
[20:50] <tdonohue> I'll admit, I won't have time between now and next week's meeting. (I'm taking a long weekend with the family & have Fri-Tues off)
[20:51] <mdiggory> what is lyncodes soltuon?
[20:51] <tdonohue> mdiggory: lyncode put a solution here: https://github.com/DSpace/DSpace/pull/40#issuecomment-8130486
[20:51] <kompewter> [ Pull Request #40: DS-1208 Build time filtering to allow multi developer/environment builds by steveswinsburg · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/40#issuecomment-8130486
[20:51] <mhwood> I'm still only a pidgin-Maven speaker, alas.
[20:51] <hpottinger> well, I was intending to backport 1208 to my fork of DSpace 1.8, so it's possible I'll be able to dive in and help out
[20:52] * hpottinger does not speak Maven at all, relies entirely on a guide book, much to the entertainment of the mvn exectuable, surely
[20:53] <tdonohue> ok, it sounds like we have some interest from possibly hpottinger and possibly mdiggory. Hopefully we can find someone to dig in and try out some things.
[20:54] <helix84> moving on; tdonohue: If the idea is to vote on _every_ new feature / improvement, I can make a list of outstanding pull requests. And suggest a few right now.
[20:55] * tdonohue thinks more of us should get your "feet wet" in debugging Maven issues. Maven's really not all that scary. :) It's mostly just a bunch of XML config files called "POMs" which tell Maven what to do.
[20:55] <mdiggory> the thing is, as was commented, if this is done at the maven level, then the ant build doesn't get a proper chance at putting the correct values in the web.xml
[20:55] <mhwood> Yes, we are doing install-time things at build-time. Bad.
[20:55] <mdiggory> so if anyone runs ant -Dconfig=....../dspace.cfg pointing somewhere else, their wars will be incorrect
[20:55] <mhwood> And I do that all the time...!
[20:56] <helix84> we have that in docs, too
[20:56] * mdiggory grumbles under breath that he never got rid of Ant
[20:56] <tdonohue> helix84 -- I'm leaving that decision to the Release Team. I feel like the Release Team members should suggest how they'd like us to vote / make final decisions on all outstanding pull requests. I don't think it's my role to dictate that :)
[20:56] <mhwood> However, I also override that stuff in the Context, so maybe it doesn't hurt *me*.
[20:57] <mdiggory> mhwood: true
[20:57] <hpottinger> at the risk of derailing the conversation, didn't someone mention at some point the possibility of us writing our own installer?
[20:57] <mhwood> Ant: we still need an installer of some sort, and Maven is not an installer. Ask over on maven-users if my word won't do.
[20:58] * helix84 thinks configuration really got messy... I hope we can solve this by 4.0 with something like the dynamic configuration idea
[20:58] <tdonohue> hpottinger: yea, I tried writing our own installer about 6-8 mos ago (essentially wrapping Maven) and my direction sorta "failed" (didn't work so well). I've never gotten back to it, but the code & docs are still out there
[20:58] <tdonohue> s/Maven/Maven & Ant/
[20:58] <kompewter> tdonohue meant to say: hpottinger: yea, I tried writing our own installer about 6-8 mos ago (essentially wrapping Maven & Ant) and my direction sorta "failed" (didn't work so well). I've never gotten back to it, but the code & docs are still out there
[20:59] <mhwood> Dynamic configuration will make it worse, not better. What will make it better is starting a clean sheet of paper and asking: where should configuration data come from, and which sources have priority over which?
[20:59] <helix84> mhwood: that's what lyncode's dynamic configuration is about, as i understand it...
[20:59] <mhwood> I'm not against dynamic configuration; I just think it will pull in even more complexity.
[20:59] <mhwood> Until we drive the complexity out again.
[21:00] <tdonohue> FWIW my old "failed" installer is described at: https://wiki.duraspace.org/display/DSPACE/Installer+Prototype Some of the ideas could still be useful, but it didn't work so well how I tried it initially.
[21:00] <kompewter> [ Installer Prototype - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Installer+Prototype
[21:00] <mhwood> I just started looking at http://java.net/projects/openinstaller/ but can't find the doco. yet.
[21:00] <helix84> mhwood: there's this exploratory code: https://github.com/DSpace/DSpace/pull/61
[21:00] <kompewter> [ Pull Request #61: Enabling Dynamic DSpace Configuration Manager by lyncodev · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/61
[21:00] <kompewter> [ Open Installer framework for buildin ... — Java.net ] - http://java.net/projects/openinstaller/
[21:00] <bollini> we are hitting the hour
[21:01] <tdonohue> (admittedly though my ideas may have failed cause I tried to do *too much*. I attempted to make a completely offline installer, which is nearly impossible with Maven)
[21:01] <tdonohue> yea, we are at the hour.
[21:01] <tdonohue> Are there big 3.0 questions we need/want to ask here or on mailing lists?
[21:02] <helix84> well, my question to the release team (anyone here?) is if we still need to vote on issues submitted before the deadline
[21:02] <helix84> or we can just go ahead and merge them
[21:02] <mdiggory> sorry I was digging into the web.xml filtering issue and got distracted...
[21:03] <bollini> I have one question about the JSPUI discovery that I like to discuss here
[21:03] <tdonohue> 3.0 Release Team = sandsfish (not here), hpottinger & robintaylor (not here)
[21:03] <mdiggory> I think that we all agree that more dialog and work needs to happen around Pull 61
[21:03] <hpottinger> ooh, I get to make some decisions :-)
[21:03] * hpottinger rubs his hands with glee
[21:04] * mdiggory looks a little worried
[21:04] <helix84> mdiggory: i agree
[21:04] <tdonohue> hpottinger -- has the RT discussed how you'd like to vote on remaining pull requests? Or should we pose that question to dspace-release? Just noticing we only have a little over one week until "freeze"
[21:04] <bollini> mdigorry: absolutely, #61 need more eyes
[21:05] <hpottinger> tdonohue: all discussions of the RT are public, are are held on the dspace-release yet, no out of band discussions have ocurred on this subject, to the best of my knowledge
[21:06] <tdonohue> mdiggory, I think I'd also be inclined to delay #61 for "post-3.0 / 4.0": https://github.com/DSpace/DSpace/pull/61
[21:06] <kompewter> [ Pull Request #61: Enabling Dynamic DSpace Configuration Manager by lyncodev · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/61
[21:06] <tdonohue> hpottinger: Ok, that's good to know. I wasn't sure whether you'd met separately or not. So, shall we ask on dspace-release what process we'd like to establish for the remaining 30 pull requests that are open? https://github.com/DSpace/DSpace/pulls
[21:06] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls
[21:07] <helix84> we really need to tame configuration, but I think the issue to too big to make it before 3.0
[21:07] <mdiggory> hpottinger: tdonohue I've avoided going deeper into the voting dialog because i thin there are larger fish to fry...
[21:07] <hpottinger> tdonohue: yes, I think that's the best approach, bring it up before the whole RT
[21:08] <tdonohue> I guess I'd like to see Pull Requests get categorized (soon) as either: (a) Accepted for 3.0 or (b) Delayed / Needs more work (not sure if there are other categories)
[21:08] <mdiggory> if voting on PR doesn't get started (preferably in dev) I don't think theres time to complete a full review of the list by the new date
[21:09] <mdiggory> likewise, I notice a few more PR have trickled in since last friday
[21:09] <tdonohue> +1 mdiggory -- that's my concern as well. We don't want to be looking at this same list of 30 next weds without any decisions having been made
[21:09] <helix84> i agree that triage is needed, a wiki page for that would be best
[21:09] <helix84> probably on the release notes page
[21:09] <helix84> i'll draft it up
[21:09] <mdiggory> I'd recommend they be addressed in the order they were opened.
[21:10] <hpottinger> point of clarification, RT doesn't really hold authority over what makes it into the release, just over what they are willing to commit to ensuring gets into the release, yes?
[21:10] <mdiggory> correct, they just need to facilitate and moderate the dialog
[21:11] <mdiggory> well, tdonohue may speak to this...
[21:12] <tdonohue> hpottinger: correct. As mdiggory said, your role is to facilitate & moderate the dialog. I'm stepping back here & expecting you all to start these votes & make the announcement of what is in/out based on those votes (I'm glad to help/provide tips, but I'm not acting as facilitator of these votes)
[21:12] <tdonohue> does that make sense hpottinger?
[21:13] <tdonohue> Essentially the Release Team needs to make sure that discussions that need to happen are happening (and I'll help prompt you as will other committers if we see things that need discussion). But, the main facilitator of these 3.0 discussions should be the RT.
[21:13] <helix84> tdonohue: i'll make the triage and I'll list the outstanding issues in one email and call a vote for all of them, so you can send votes for multiple issues in one email
[21:14] <tdonohue> As such, the RT is more than welcome to tell me what you'd like to talk about in Developer Meetings, if there are topics that need tackling
[21:14] <helix84> does that sound good?
[21:14] <hpottinger> yes, it does make sense, tdonohue, just want to be sure the RT knows what it is they're being asked to do: call a vote on remaining PRs
[21:14] <hpottinger> and if helix84 isn't on the RT already, I think he just volunteered. :-)
[21:15] <tdonohue> hpottinger -- yep, exactly
[21:15] <helix84> um, i'll need to read up on RT responsibilities, but I can do what I suggested
[21:15] <tdonohue> helix84 -- yea, that's again a RT decision. RT is calling the vote, not I
[21:16] <helix84> ok. i'll prepare the vote, contact RT before sending it
[21:17] <bollini> applauds helix84 :-)
[21:18] * helix84 says goodbye to his beauty sleep tonight
[21:18] <KevinVdV> Also needs his beauty sleep !
[21:18] <tdonohue> To clarify for everyone: I'm not on the Release Team for a very specific reason. We're trying to get into the process of establishing a ongoing Release Team system that doesn't necessarily depend so much on my time. Although I'm glad to help out, many past releases really took too much of my time away, and we're trying to establish a more "community-driven" release process (not so "DuraSpace-led" per say, though we'll still b
[21:18] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Chicks dig it)
[21:19] <hpottinger> helix84: I'm sending a note to the dspace-release list right now, asking them to look at today's transcript, and also letting them know that you'll be drafting a note for calling the vote; as an aside, welcome to the RT
[21:19] <mhwood> Sleep won't help my looks, but I need to leave anyway. Thanks, all!
[21:19] <tdonohue> In future releases, there may be times I'll sit on the Release Team...but, I want to try at least 1-2 where we get more community folks involved :)
[21:20] <tdonohue> thanks helix84 & hpottinger! Looking forward to the discussion!
[21:20] <helix84> sounds reasonable, tim, you're already doing a lot! thanks for leading DevMtgs and taking care of infrastructure among other menial developer tasks
[21:20] <tdonohue> (yea, speaking of infrastructure -- expect a JIRA upgrade soon...critical security issues there as well. I had to upgrade Bamboo today for the same reasons)
[21:21] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:23] <bollini> ok, before all of us leave I try to post a question about the JSPUI discovery porting
[21:23] <bollini> my question is, when discovery is disabled do you want the dspace-discovery-jspui-api.jar in the jspui.war or not?
[21:24] <helix84> bollini: you may want to coordinate with mdiggory on that as he'll be doing a maven cleanup (modularization and dependencies) after the freeze
[21:24] <tdonohue> bollini -- I believe the Discovery XMLUI API is in the xmlui.war even when discovery is disabled. But, mdiggory could likely correct me if I'm wrong.
[21:24] <bollini> actually for xmlui the dependency on discovery-xmlui-api is "hardcoded" so the jar is always here
[21:25] <mdiggory> tdonohue: it is already even
[21:25] <mdiggory> there
[21:25] <bollini> tdonohue: right (but I don't like this, so in the current pull request the jspui work diffrently)
[21:26] <mdiggory> bollini: can you expand on that
[21:26] <bollini> dependency is activated by a maven profile
[21:27] * tdonohue notes obviously "official mtg" is ended. If you need to head out, obviously feel free. I'll stick around here for a bit though.
[21:27] <bollini> the profile is (currently) active by default, you can turn off using -Dlucene=true (as in current pull request discovery is enabled by default in jspui)
[21:27] <hpottinger> note to dspace_release sent
[21:28] <helix84> tdonohue: did you survive the meeting without a leak? ;)
[21:28] <tdonohue> helix84 -- roof is fixed now (fingers crossed). It was only leaking when it rains
[21:29] <hpottinger> rain in the forecast, that's for sure
[21:29] <bollini> I have also used the same canonical name for the servlets (simple/advanced search) so that classpath overlay do the magic to enable discovery servlet when jar is present without changing the web.xml
[21:30] <tdonohue> bollini -- one thing that is different about the XMLUI is that Discovery is enabled/disabled *after* you build/install DSpace (in the [dspace]/config/ xmlui.xconf file). So, I think the Discovery API has to be included in the build of the XMLUI.war
[21:30] <bollini> tdonohue: right, good point.
[21:30] <helix84> bollini: question: so you can't disable JSPUI/Discovery without rebuilding?
[21:31] <tdonohue> hpottinger -- yea, that's why we wanted to get this roof leak fixed ASAP. We're supposed to get hit by the remnants of Hurricane Isaac this weekend (no longer a hurricane obviously, but we may still get 3-5 inches of rain or more)
[21:32] <bollini> I'm only worried about having dependency (jars) in the wars that someone not need (the war will become larger and larger)
[21:32] <hpottinger> tdonohue: lots of folks around here worried about that rain, too... ground is so dry it will likely run off, many people are pre-watering lawns
[21:33] <bollini> helix84: yes, with the current approach enabling/disabling require a build
[21:34] <tdonohue> bollini -- I can understand that worry. But, I think it's also a question of how easy it will be for people to enable/disable Discovery, and whether the Discovery JSPUI API actually takes up that much space
[21:35] <mdiggory> thisis why we put it on /discovery not /search, /browse / etc
[21:35] <mdiggory> you can run all approaches in parallel
[21:36] <mdiggory> enabling them is a choice in config.
[21:36] <helix84> mdiggory: hmm, i didn't know that one could have both aspects enabled
[21:36] <bollini> mdiggory: the issue with jspui is that mapping is (currently) defined in web.xml
[21:37] <bollini> tdonohue helix84 putting together your thought I think that you will prefer if I change strategy so that discovery-jspui-api will be always included and servlets (simple/advanced) use different logic basis on a property in the dspace.cfg file
[21:38] <helix84> bollini: I indeed like that in xmlui discovery can be enabled by changing config and restarting. I never thought about the added size - no problem for me.
[21:39] <mdiggory> bollini, I have a proposition, add support for spring servlet and enable discovery as a Controller....
[21:39] <bollini> mdiggory: +1 ...
[21:39] <mdiggory> :-)
[21:40] <bollini> we could also move to servlet 2.5 and use annotations mapping
[21:40] <tdonohue> bollini -- I think that approach sounds fine to me (config in dspace.cfg). I don't feel very strongly either way though, it's more a matter of what is reasonable for 3.0
[21:41] <helix84> on the other hand, I'm always thinking about build time - apropos, mdiggory, i've been meaning to ask you - will your post-freeze maven work enable me to build only modules which I choose? IOW reduce module interdependencies?
[21:41] <mdiggory> the only big modules interdependency atm is the sword client stuff...
[21:42] <helix84> or let me ask another way - what's the minimal list of profiles I need for just xmlui?
[21:42] <mdiggory> which sucks all of the sword-api and dependencies into the xmlui
[21:44] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:46] <helix84> ping?
[21:47] <bollini> I hope that in future we can find a (convenient) way to only include in the war the dependencies that the user really need (i.e. if the user don't need the oai harvester these classes should not be in the war, etc.)
[21:49] <bollini> but at the current stage I think that it is not really possible, so as far as I know helix84 to build xmlui you need to build more or less anything (just avoid the other webapplication)
[21:49] <helix84> note: lyncode is also working on something related - dspace distributions - downloading only a selected set of modules, i.e. not like dspace-src, but like dspace-release with variations
[21:50] <mdiggory> pong
[21:50] <mdiggory> it will be more minimal than it currently is
[21:51] <mdiggory> effectively it should be "dspace-api, dspace-xmlui"
[21:51] <mdiggory> but if we keep solr stats separate, then it could require additionally "dspace-solr"
[21:51] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:51] <mdiggory> "dspace-solr-stats"
[21:51] <helix84> great. I was trying it a few days ago and I ended up with maven talking back to me until I ended up with almost every profile
[21:51] <mdiggory> I mean
[21:52] <mdiggory> this is the problem when you have profiles enabled by default... they are disabled as soon as you start to add profiles
[21:53] <mdiggory> tbh... theres no need for a postgres profile, including postgres jar wouldn't impact oracle
[21:53] <helix84> but the stupid thing about maven is that it won't just get the dependencies, it will fail and tell me just one which it needs...
[21:53] <helix84> i didn't realize we had a postgres profile
[21:54] <helix84> so good to hear it's going to get better
[21:55] <mdiggory> the only reason we have an oracle profile is because the dependence isn't in maven...
[21:55] <bollini> I think that we should avoid to put any jar that we *could* need in the dependencies
[21:55] <helix84> mark, what about the target/ problem, can I expect you to prepare a fix? or should I just try to apply lyncode's approach?
[21:56] <bollini> postgres not impact oracle but this is a specific consideration
[21:57] <bollini> we should make the same analysis for any library against any other, and I hope that in a future the dspace platform could have a repository of third part plugin
[21:58] <mdiggory> bollini: I'm not going hog wild here, I wouldn't generalize it so
[21:58] <helix84> bollini: i've been toying with the idea for some time now. i'll propose something after 3.0 is out of the door.
[21:59] <mdiggory> I'm just talking about the database jars that dspace does need to operate based on its current capabilities. I'm not going to stick mysql in there until someone show support for it
[22:00] <bollini> helix84: I'm curious now
[22:01] <helix84> bollini: although i'm not completely sure we're thinking the same thing. My idea is something like a contrib repository where addons would live and more people could commit, that wouldn't be released along with dspace.
[22:01] <helix84> bollini: so we could have LNI, REST, SRW and the like in contrib and a really lean and basic dspace distribution.
[22:02] <bollini> helix84: oh yes, your are talking about the place where the addons should live
[22:03] <helix84> bollini: yes, is that different from what you were thinking?
[22:03] <bollini> helix84: but imho we also need to think about a way to make easy for end-user (not developer) to add this contribution to their repository
[22:04] <bollini> installing a plugin for word press is *very* easy
[22:04] <helix84> bollini: yes, that's the goal. and the challenge.
[22:04] <mdiggory> helix84: mark, what about the target/ problem, can I expect you to prepare a fix? or should I just try to apply lyncode's approach? .... its not sufficient, ...
[22:04] <helix84> lyncode's approach is not sufficient?
[22:04] <mdiggory> the problem is that the original contribution switched away from "default." as a prefix
[22:05] <mdiggory> and so now where the web.xml was only filtered when someone actually intentionally used dspace.dir in the pom properites. now its all the time....
[22:05] <bollini> ok, I need to go... in Italy it's midnight (my carriage could become a pumpkin)
[22:06] <bollini> good night
[22:06] <helix84> bollini: good night, watch your shoes
[22:06] <mdiggory> I don't want to know about your dress...
[22:06] <mdiggory> sorry
[22:06] <bollini> :-D
[22:06] <mdiggory> have a good night
[22:06] * bollini (~chatzilla@host176-111-dynamic.16-87-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
[22:07] <helix84> mdiggory: i really know little about all that. i don't even know what filtering is needed for. just tell me if you're going to fix it or I should be looking for someone else
[22:08] <mdiggory> can I say that overall I don't like the solution... heres an example of what I said in commiters list... isn't it the responsibility of the original contributor to fix or it should be ejected?
[22:08] <helix84> that's what I'd say
[22:09] <mdiggory> sorry, I've lost confidence in the solution that was provided.
[22:09] <helix84> i've never had it to begin with :)
[22:10] <helix84> it just added complexity to configuration and configuration need an overhaul from the ground up
[22:12] <helix84> so, next steps?
[22:45] <helix84> mark, i sent you an email asking about next steps to take in this
[22:45] <helix84> good night
[22:45] * helix84 (a@195.113.97.174) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.