Timestamps are in GMT/BST.
[6:38] -hitchcock.freenode.net- *** Looking up your hostname...
[6:38] -hitchcock.freenode.net- *** Checking Ident
[6:38] -hitchcock.freenode.net- *** Found your hostname
[6:39] -hitchcock.freenode.net- *** No Ident response
[6:39] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:39] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:39] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:01] * Asger (~abr@nat.statsbiblioteket.dk) has joined #duraspace
[8:22] * Asger (~abr@nat.statsbiblioteket.dk) Quit (Remote host closed the connection)
[11:27] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:44] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[19:31] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:58] <tdonohue> Hi all, just a (late) reminder, we have our DSpace Developer Mtg starting here at the top of the hour (2mins). Main topic is 3.0 release
[20:00] * helix84 (a@195.113.97.174) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Mtg. Sorry again for the lack of agenda this week -- it's obviously just 3.0 Release topics today.
[20:01] * tdonohue notices that our attendance seems rather small, but hopefully more folks will filter in..
[20:03] <tdonohue> So, regarding 3.0, here's the issues that still remain open (including a few "blockers" still): https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.0%22+AND+resolution+%3D+Unresolved+ORDER+BY+priority+DESC
[20:03] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.0%22+AND+resolution+%3D+Unresolved+ORDER+BY+priority+DESC
[20:03] <tdonohue> Though, I should note that between robint & I, we have a fix for DS-1343 (one of the blockers) in Pull #119 : https://github.com/DSpace/DSpace/pull/119
[20:03] <kompewter> [ Ds 1343 - Add parent pom.xml and build.propertiesfiles into the binary release by tdonohue · Pull Request #119 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/119
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1343 ] - [#DS-1343] Non-source zip package of DSpace 3.0-rc1 is broken/invalid - DuraSpace JIRA
[20:04] <tdonohue> (just needs a button press)
[20:05] <tdonohue> So, is there anything 3.0 specific that anyone would like to touch on here? (Or am I just talking to myself so far....it's quiet thus far)
[20:05] <helix84> after last week's discussion on DevMtg I adjusted the schedule to accomodate rc3 and start 2nd round of testathon, does everyone think we're on track?
[20:06] <tdonohue> new 3.0 timeline is at: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-TimelineandProcessing
[20:06] <kompewter> [ DSpace Release 3.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes#DSpaceRelease3.0Notes-TimelineandProcessing
[20:07] <helix84> we'll need someone to actually do the rc3 release by the end of the week so that we can have t ondemo by Monday (testathon starts)
[20:07] <helix84> i still don't feel up to it, what about you, Hardy?
[20:08] * tdonohue would suggest doing the rc3 release on Thurs (tomorrow) if possible...just so you have Friday as a "backup release day", in case issues happen on Thurs.
[20:08] <helix84> i should be able to update demo again, say on Sunday night
[20:09] * tdonohue notes however that the build/release process has gotten a LOT of cleaning since rc1, so it should go MUCH more smoothly (I hope)
[20:10] <helix84> tim, remember our talk about testing release of the -lang projects?
[20:10] <tdonohue> helix84 -- yep, I recall. Those need some "love" & a release as well. I just haven't gotten too it, as I've been bogged down with cleaning up the main POMs so that the main release worked right :)
[20:11] <helix84> I noticed - big thanks for that!
[20:11] <tdonohue> No problem. The changes to the -lang projects should be MUCH smaller, as they include no Java code. Essentially their POMs just need minor updates to point at GitHub instead of SVN, and then we need to do a Release.
[20:12] <helix84> seems awfully quiet here today, anyone alive? :)
[20:12] <mhwood> No.
[20:12] <tdonohue> It seems like just two of us, helix84
[20:12] <helix84> oh, oh, mhwood turned into a zombie
[20:13] <mhwood> It *is* Hallowe'en....
[20:13] <tdonohue> kill -9 mhwood_zombie
[20:13] <helix84> ps -developers
[20:13] <helix84> mhwood [DEFUNCT} 98774
[20:13] <helix84> tdonohue: that wouldn't work :)
[20:14] <tdonohue> yea, I guess it may not... oh well
[20:14] <helix84> okay, i guess we're tired talking about the release, mind if I start a fresh topic?
[20:14] <mhwood> BRAAAAINSSS? OK | DISMISS
[20:15] <tdonohue> I do have a small point to bring up regarding the release testing still though...mainly a simple question:
[20:15] <helix84> sure, that's our main topic, please go ahead
[20:15] <tdonohue> Has anyone tested the "AIP Backup & Restore" functionality? I've been meaning to get around to it, but haven't. I'm slightly worried that it may not work anymore with all the new Item Versioning stuff.
[20:16] <helix84> i didn't
[20:16] <tdonohue> (So, that's just a warning, that we may have a "Blocker" there, waiting to be discovered. I hope to test it tomorrow, if I don't get to it just after this mtg)
[20:16] <mhwood> Not here.
[20:17] <tdonohue> Ok. Well, I'll try and get to it myself then. I'm hoping there's not a blocker there...but, I noticed today that the code didn't get an update alongside the Item Versioning stuff, and based on that, I worry it may be broken
[20:17] <helix84> i'm going to fix two easy issues with XMLUI - the CC license link and the Mobile theme
[20:17] <tdonohue> +1 helix84 sounds good
[20:18] <helix84> /seen mdiggory lately?
[20:18] <tdonohue> nope. he's been nearly non-existent on IRC these days.... just seen him in email & github
[20:18] <helix84> I was hoping he could help with the http://example.com/mobile/ URL - Cocoon stuff.
[20:18] <kompewter> [ IANA — Example domains ] - http://example.com/mobile/
[20:19] <tdonohue> you might want to email him to see if he has ideas/thoughts.
[20:19] * mhwood notes that Ds-1182 stands Open although fix is merged, to invite confirmation that it is fixed.
[20:19] <helix84> will do, I have very low success rate with that, though :D
[20:20] <helix84> > Per Joao's wish, reopening so that we keep it on the radar at least until 3.0 release.
[20:20] <tdonohue> helix84 -- could also send it to dspace-devel as well. maybe someone else will also have an idea
[20:20] <helix84> mhwood: that was about 1182
[20:21] <hpottinger> sorry, I wandered off for a sec, lots of distractions around here today, I'm more than happy to try my luck with RC3 release, though I'll need backup, as I clearly couldn't get RC2 out the door...
[20:22] <tdonohue> helix84, not sure I understand that answer about Ds-1182. Why open it back up if the fix is in?
[20:23] <helix84> tdonohue: it's in the comments. Joao wants to verify with one institution that it really works, so it's open just so that we don't lose track of it.
[20:23] <tdonohue> I guess I don't understand when it gets "closed" then? Why not just leave it "closed" and then verify with that institution that it works for them, and reopen if it doesn't work?
[20:24] <helix84> I give up, close it if you want :)
[20:24] <mhwood> This is why I Resolved it.
[20:24] <tdonohue> sorry, I just thought maybe there was a good reason that I wasn't understanding :)
[20:25] <helix84> mhwood: I know, but resolved is closed, we talked about it on the list
[20:25] * sands (~sandsfish@18.189.1.83) has joined #duraspace
[20:25] <mhwood> Two names for the same state? I thought they were separate.
[20:25] <helix84> tim, will you have time to back up hardy tomorrow on RC3?
[20:26] <helix84> http://stackoverflow.com/questions/4718471/jira-to-close-or-to-resolve
[20:26] <tdonohue> I will be lurking on IRC tomorrow, yea. Not sure I'd have time to actually cut the release though (which is what we had to do for RC2, as unfortunately it just wasn't working right in hardy's environment for whatever reason)
[20:27] <tdonohue> so, hpottinger, I'll be around if you want to try again with RC3 :)
[20:27] <helix84> mhwood: so I guess you were right to resolve it
[20:27] * hpottinger blames the user...
[20:27] <sands> i can be available tomorrow as back-up as well, or a second set of eyes at least.
[20:27] <tdonohue> that'd be helpful sands... I may have limited time tomorrow, but I will be lurking most of the day
[20:27] <hpottinger> cool, maybe another RT member wants to have a try? It's fun!
[20:28] * sands snorts
[20:28] * hpottinger stage whispers to sands "shhh, you!"
[20:30] * tdonohue notes that it sounds like helix84 & mhwood have decided to "resolve" Ds-1182. I just resolved it again
[20:30] <hpottinger> any more button pressing to be done before RC3?
[20:31] <tdonohue> Yes, I think we should press the button on pull #119: https://github.com/DSpace/DSpace/pull/119
[20:31] <kompewter> [ Ds 1343 - Add parent pom.xml and build.propertiesfiles into the binary release by tdonohue · Pull Request #119 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/119
[20:31] <tdonohue> This is a collaboration between robint & I to fix the problems with the "binary" release of DSpace in both RC1 & RC2.
[20:32] <tdonohue> I've done a TON of testing with it today (including doing a "dry run" release) and I think it's ready to go
[20:33] <tdonohue> It does change one minor thing about releases though.... the "mvn package -Pdistributions" command (to create the zip/tarball's for SourceForge) now must be run from [dspace-src]/dspace/ subdirectory.
[20:33] <hpottinger> I should note my boss is here in the room with me, and wants to talk non-dspace stuff, so I'm officially distracted
[20:33] <sands> thanks for all the extra testing tdonohue!
[20:34] <helix84> tdonohue: I wonder if we have a developer documentation where we could put your comment explaining that
[20:34] <tdonohue> helix84 -- that "mvn package -Pdistributions" command should really only be run by someone doing a DSpace release...it's documented in our Release Procedure: https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[20:35] <kompewter> [ Release Procedure - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Release+Procedure
[20:35] <tdonohue> (and I plan to update those Release Procedure docs with that minor change as soon as the button is pressed on #119)
[20:35] <helix84> hmm, I exclude components all the time to cut down on that damn maven build time. I hate that about Maven - there I said it.
[20:36] <helix84> who needs LNI and JSPUI anyway? :)
[20:36] <tdonohue> helix84: oh, you are talking about the -P stuff (which is mentioned in the comments of #119 for those not following)
[20:37] <helix84> oh, right, -Pdistributions is something else than -P with a webapp
[20:38] <tdonohue> yea, the other thing that changes with #119, is that you can no longer build just specific webapps by doing: "mvn package -Pdspace-api,dspace-xmlui"
[20:38] <tdonohue> However, you *CAN* exclude certain webapps from building by using "-P" with "!", like "mvn package -P!dspace-lni,!dspace-jspui" would build everything EXCEPT LNI & JSPUI
[20:39] <tdonohue> But, to be honest..those "-P" things are for highly advanced DSpace Developers...as you may actually cause build errors to happen if you excluded *too much*
[20:40] <helix84> yes, there are interdependencies between stuff you wouldn't expect
[20:40] <helix84> but maven is eager to point that out with some error or another
[20:41] <tdonohue> Not sure if this is really making much sense to everyone.... essentially the "-P" flag in Maven lets you turn "on/off" specific "profiles".... robint & I had to re-tweak some of our existing profiles to get the "binary" distribution of DSpace to actually work again...it's been broken since we added the "build.properties" stuff.
[20:41] <helix84> maybe we could put in that page that describes quick build vs. full build
[20:42] <tdonohue> helix84 -- yea, we could add a note there about disabling specific modules from building by doing "-P!dspace-lni" and similar
[20:43] <tdonohue> In any case...I think that Pull #119 is ready to go, unless anyone has any concerns.
[20:43] <sands> i think mdiggory was the first to craft and use those, so i'm not sure how he feels about all of this. just pointing it out since he's not here to say anything one way or another.
[20:44] <tdonohue> sands -- he commented on #119 regarding that stuff. I responded to his comment to let him know that you can still disable specific modules. But, I haven't heard back.
[20:44] <sands> ah, k.
[20:45] <tdonohue> I can leave it open, if we want. But, I will note that until #119 is accepted (or we find an alternative solution), the *-release zip/tarballs will have build errors (as they currently do for RC1 & RC2)
[20:46] <helix84> i'll reopen another topic if you don't mind. I'd like to get all the line endings fixed once and for all using gitattributes. tim had some concerns not to do it if there won't be testing after that, even if it's just whitespace change. so I think now's the perfect time - before the 2nd round of testathon. sounds good?
[20:48] <mhwood> Yes. Got to do it sometime if it's to be done.
[20:48] <helix84> this is what I'm talking about: https://github.com/DSpace/DSpace/pull/65
[20:48] <kompewter> [ EOL normalization with gitattributes by lyncodev · Pull Request #65 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/65
[20:48] <helix84> I just have to note that it _might_ break some pull requests that are still open
[20:49] <tdonohue> Yea, I think it likely will break *most* pull requests that are still open. As it likely will touch most files in GitHub (to update the line endings).
[20:49] <helix84> but there will always be open pull requests, now is supposed to be a low point for them
[20:49] <tdonohue> But, that being said, I'd be OK with doing it before RC3...(though I'd suggest to wait until we get in any other "green-lighted" pulls first)
[20:50] <helix84> tdonohue: my idea, exactly
[20:50] <sands> sounds like a reasonable time to me. fixing the pull requests should be fairly simple (i think)...
[20:50] <helix84> maybe they won't break - i haven't done it before :)
[20:50] <tdonohue> yea, fixing the broken pulls will be relatively easy..but we'd just need to get each person who created a pull to update it
[20:51] <tdonohue> helix84 -- looking at the number of files listed as being updated by Pull #65, I think some (if not all) will break at least in minor ways :)
[20:51] <tdonohue> but, again, I'm OK with that. We just should warn folks whose pull requests actually do end up breaking
[20:53] <tdonohue> So, it sounds like we're recommending Pull #119 and Pull #65 (though it'd need updating or just have a new pull created) for RC3. Anything else, or any objections?
[20:53] <mhwood> Ask for a "quiet period" with no new pulls while old ones are cleared, so damage is minimized? Not sure how long the moratorium would last -- would need to be quite short.
[20:53] <helix84> tdonohue: would we also fix indentation? there's a lot of mixed tabs and spaces in the codebase.
[20:54] <helix84> new pull requests should be fine
[20:54] <helix84> i mean new pull requests opened after the change
[20:54] <helix84> which should be done before tomorrow, since tomorrow is rc3
[20:54] <tdonohue> helix84: I'm hesitant to fix "indentation" issues until we come up with common indentation settings across all our IDEs. I think the problem is being caused by our IDEs, to be honest.
[20:55] <tdonohue> (I agree the indentation is annoying, but we likely need to figure out common IDE settings first, otherwise it will continue to happen)
[20:55] <mhwood> 1. Merge as many existing requests as possible. No new requests please. 2. Merge EOL fixup. 3. Open for more requests, fix any that remained and broke.
[20:55] <helix84> tdonohue: I thought there was an agreement on style. The code style wiki page says whatever the Eclipse reformatting plugin does is canonical.
[20:56] <mhwood> There's a specific packet of Eclipse indent rules for "DSpace style" as I recall.
[20:56] <helix84> https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-CodingConventions
[20:56] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-CodingConventions
[20:56] <tdonohue> helix84 -- the Eclipse reformatting plugin *was* canonical when we were all using Eclipse. Now that most folks seem to use IDEA & NetBeans, it's hard to run an Eclipse plugin :)
[20:57] <helix84> ok, so postpone until 4.0?
[20:57] <tdonohue> So, all I'm saying is that we likely need to update those formatting rules to tell folks *how* to configure that in their IDE of choice (Eclipse, NetBeans, IDEA)
[20:58] <mhwood> Got to have a massive whitespace reorg. or how would you know it's a .0 release? :-)
[20:59] <helix84> i hate to bring up whitespace as an issue, but it's distracting when you keep running into it
[20:59] * KevinVdV (~Zombie_Ke@d54C154B1.access.telenet.be) has joined #duraspace
[20:59] <helix84> another hero bug-slayer joined us! welcome!
[21:00] <tdonohue> Either way is fine by me... If folks want to do all the major formatting stuff (tab fixes & EOL) at once, we can do so. It's just gonna touch a lot of files & I'm convinced we'll always have some sort of tabbing issues (especially now that we can accept pull requests from anyone out there)
[21:00] <KevinVdV> Hi everybody
[21:00] <mhwood> I agree: various tools complain or do interesting things when you have mixed EOLs or runs of spaces followed by tabs followed by spaces....
[21:01] <mhwood> EOL fix should *stay* fixed, no? Should be done separately from general space fixing.
[21:01] <helix84> tim, you're running eclipse, right? O:-)
[21:01] <helix84> mhwood: right
[21:01] <tdonohue> Nope, I run Netbeans.
[21:02] <tdonohue> (and IIRC, most of the committers these days actually use IDEA)
[21:02] <helix84> lonely tabs looking for a handsome volunteer with Eclipse
[21:02] <mhwood> NB here.
[21:02] <helix84> vim here :(
[21:02] * KevinVdV is now known as ZombieKevinVdV
[21:02] <helix84> there goes another one...
[21:02] <hpottinger> I actually tried to use Eclipse with DSpace a while back, ran into trouble.
[21:02] * helix84 draws his sawed-off shotgun
[21:03] <tdonohue> DSpace + Eclipse = not fun :) I used to use it, but it became more and more a pain (mostly cause Eclipse + Maven = not fun)
[21:03] <helix84> Eclipse = 0
[21:03] <helix84> Maven = not fun
[21:03] <helix84> :)
[21:03] <hpottinger> right, I remember Maven and Eclipse cramping my style
[21:04] <mhwood> maven/eclipse plugin had intractable problems, then they addressed this by removing most features and inviting people to put them back in over new code. I moved to NB and never looked back.
[21:04] <tdonohue> So, I think we should fix the EOLs right away (and they will stay fixed, as it's a .gitattributes setting)
[21:04] <mhwood> +1
[21:05] <tdonohue> But, the matter of the fixing the tabulation may require some work, unless we find someone still running Eclipse + DSpace
[21:05] <hpottinger> When I reach for an IDE these days, it's usually IDEA, though I have to admit I'm mostly a Vim guy, still, and yay for IDE-agnostic EOL fixes
[21:05] <helix84> I'm running grep and sed, so I could take care of at least the worst violations...
[21:05] <sands> I haven't used Eclipse in a year or two now. I got tired of waiting… and waiting...
[21:05] <mhwood> Is there a DSpace Emacs mode? [ducks]
[21:06] * hpottinger hands mhwood his unexploded grenade, and runs...
[21:06] <helix84> mhwood: I think those long-bearded fools died our and were replaced by birds :)
[21:06] <tdonohue> helix84 -- what was your plan with grep/sed? Just replace all tabs with 4-spaces?
[21:06] <helix84> tdonohue: no, no. First detect mixed tabs and spaces
[21:07] <hpottinger> frankly, Oracle not releasing their DB for Mac any more kind of took the wind out of my sails as far as developing with an IDE goes...
[21:08] <sands> don't get me started on Oracle. I've spent the entirety of my day trying to get some Rails apps to connect to it (ones that used to work, on this computer) ugh.
[21:08] <mhwood> Must run. Thanks all!
[21:08] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:09] <sands> ditto. hpottinger, i'll see you tomorrow on #dspace.
[21:09] <tdonohue> Ok...so, it sounds like in any case the tabulation fixes are gonna take some work. So, likely not gonna happen for RC3 (and possibly not for 3.0 at all)
[21:09] * sands (~sandsfish@18.189.1.83) Quit (Quit: sands)
[21:10] <helix84> I always used MySQL or Postgres. Only recently I had to use Oracle with itd closed oci8 driver - what madness. Those who are used to it probably don't even realize it anymore.
[21:12] <helix84> I think I'll turn into a zombie now, too
[21:12] <ZombieKevinVdV> Hey guys, came in an hour late due to the hour change...... but I have a few pull request open if anybody is up for it ?
[21:13] <hpottinger> have a link for us, Mr. Zombie?
[21:13] <helix84> yeah, it's that time change that's killing me (bad pun intended)
[21:14] <ZombieKevinVdV> https://github.com/DSpace/DSpace/pull/118, https://github.com/DSpace/DSpace/pull/113, https://github.com/DSpace/DSpace/pull/111, https://github.com/DSpace/DSpace/pull/109
[21:14] <kompewter> [ [DS-851] When a "qualdrop_value" is set to "required", submit form always fails by KevinVdV · Pull Request #109 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/109
[21:14] <ZombieKevinVdV> I have been a busy Zombie :)
[21:15] <helix84> Kevin, I pulled what I could understand, but those remaining ones I'm not sure how to begin to test.
[21:15] * tdonohue is pressing button on #113 -- it's just an added comment to dspace.cfg. :)
[21:16] <tdonohue> #113 = merged
[21:16] <ZombieKevinVdV> Thx
[21:16] <ZombieKevinVdV> I will close Jira (& eat tdonohue's brain last)
[21:16] <tdonohue> sounds good (in both cases!)
[21:17] <helix84> mmm, candy!
[21:17] * hpottinger is simultaneously hungry and not hungry... odd...
[21:18] <helix84> it's normal when you're turning from an omnivore into a brainyvore
[21:18] <hpottinger> herbivore here
[21:20] <ZombieKevinVdV> Feel free to review & merge the other pull requests, or provide feedback if I did something wrong
[21:20] * tdonohue is gonna just press that tempting green button on #109 as well...the fix looks rather obvious. If Bamboo complains (doubtful) we can just undo
[21:21] <tdonohue> I'll leave #118 and #111 to someone else for now...they look reasonable enough to me, just don't have time to review them right now
[21:22] <ZombieKevinVdV> Allright, thx tdonohue !
[21:23] <tdonohue> BTW -- if anyone wants to push the big green button on #119, I won't mind (https://github.com/DSpace/DSpace/pull/119). Otherwise, I'll give it till tomorrow for any objections & press it myself before RC3 gets cut.
[21:26] * hpottinger considers pressing the button for #119...
[21:27] <hpottinger> see, I don't know if mdiggory's comment is a -1...
[21:28] <tdonohue> ok, leave it be then... I don't think it is, but I'll give mdiggory till tomorrow. Honestly though, I'm not sure of another way to easily resolve the build issues with the *-release packages at SourceForge
[21:36] * hpottinger wants it known that he will continue to encourage any committer to "press the button" on their own changes, if asked to do so by them... probably invoking the name of GrahamTriggs, and his refactor-a-thon, at some point...
[21:38] <tdonohue> yea. I agree, hpottinger. I tend to be wary to "press the button" on my own stuff unless (a) it's a rather obvious fix, (b) someone else has "ok'd" it, or (c) it's at least sat there long enough to ensure no one has any major objections
[21:38] <tdonohue> Though, even if (c) occurred later on, we obviously can "undo" any previously merged pull request
[21:39] <tdonohue> I added a comment to #119 letting everyone know I plan to merge it tomorrow. We'll see if anyone pipes up with final objections
[21:39] <hpottinger> right, some rather big changes have been made with very little review in the past, and the project has survived...
[21:40] <tdonohue> yep...the example of Graham's work is a good one. We all basically gave him "free reign" for a good while in SVN when he was digging into performance issues...he was committing at will :)
[21:41] <tdonohue> I think folks have been a bit more tentative in GitHub, but there is not need to be quite so tentative. If someone really disagrees with something that got merged, they'll let you know and ask for it to be unmerged (but most the time that doesn't happen, unless you broke something else on accident)
[21:41] <hpottinger> was the most riveting series of messages to ever come across the -changes mail list...
[21:42] <hpottinger> IMHO, of course, :-)
[21:43] <tdonohue> yea...I remember trying to follow along on the -changes list with what Graham was doing...but there were some days I just said "heck, it's Graham, he's not gonna break something huge, and if he does we'll fix it"
[21:44] <hpottinger> alright, I've gotta go, will be on #DSpace tomorrow, plan to start a dry run first thing, 9ish CDT
[21:44] <helix84> I had rather bad feelings from the change that brought in build.properties, because it caused at least 3 serious breakages... I guess I should have backed it out then.
[21:45] <tdonohue> ok, i'll be here (and make sure to press the button on #119 before then)
[21:45] <tdonohue> helix84 -- anything specifically still remaining?
[21:46] <helix84> no, not that i know of. remember that exponentially growing build directory?
[21:46] <hpottinger> yay! and I like the build.properties change, I like that we have a community-blessed way of managing dev -> staging -> production
[21:46] <hpottinger> wait, wait, I said I was going, gotta go, bye all!
[21:46] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:47] <tdonohue> yea. there were a *LOT* of issues caused by build.properties. I think they are mostly all squashed.... though, now I recall, I still may need to figure out a way to get build.properties to play better with IDEs (got pulled away from that for all the other POM stuff)
[21:47] <tdonohue> but, overall, I also think the build.properties seems like a nice direction....despite the pain points
[21:48] <helix84> I think I still fail to see the benefit, because you can define only _some_ changes there, but for others you still have to edit dspace.cfg...
[21:49] <helix84> It didn't seem to improve my workflow in any way, so didn't start using it
[21:50] <tdonohue> I think the benefit in my eyes it actually could help make the build/install process be less "scary" to novice users. You now just need to go edit some basic stuff in 'build.properties' rather than digging into the semi-scary dspace.cfg file to do a basic build & install. *AFTER* the install, you can worry about the endless array of options in dspace.cfg
[21:51] <tdonohue> but, it also has the dual benefit of helping developers manage their dev environment settings separate from dspace.cfg (admittedly though, I think there still may need to be a few small tweaks to help it work better with IDEs though)
[21:51] <helix84> so all you need to get DSpace up and running should be there?
[21:52] <tdonohue> helix84 -- yea, I believe it all is. The basic settings you need are all in build.properties. Everything else you should be able to worry about later on
[21:53] <tdonohue> (though I'll admit, I'm not sure the build.properties idea really was thinking about simplifying the install process....but, I think it does do that, almost by accident)
[21:53] <helix84> so if we decided to move everything else into database to be configurabe at runtime, those things would still remain in build.properties
[21:53] <helix84> (or just stripped dspace.cfg with those few options that are now in build.properties)
[21:53] <tdonohue> possibly so. Though admittedly, a few things in build.properties may also be able to be moved to the DB as well.
[21:54] <tdonohue> ack, look at the time. I need to head out of here, unfortunately. Will be around on IRC tomorrow though.
[21:54] <helix84> ok, I'll try to have the line endings ready before your day begins
[21:55] <tdonohue> sounds good. I still do want to get in #119 just before the EOLs if possible though...not sure how that will all play out. If needed, I guess I could quickly update #119.
[21:55] <tdonohue> bye
[21:55] <kompewter> bye
[21:56] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:56] * lyncode (~DSpace@bl23-34-65.dsl.telepac.pt) has joined #duraspace
[21:56] <helix84> hi joao
[21:56] <lyncode> hi!
[21:57] <helix84> everyone just left
[21:57] <helix84> mostly boring release stuff today :)
[21:57] <lyncode> hmm ok
[21:57] <lyncode> i have some feedback from SDUM
[21:57] <helix84> remember your your line endings fix?
[21:58] <helix84> yes?
[21:58] <lyncode> my pull was tested sucessfully
[21:58] <lyncode> https://github.com/DSpace/DSpace/pull/115
[21:58] <kompewter> [ XOAI Core Library (Version 2.2.9). Fixed incorrect virtual set count. Fi... by lyncodev · Pull Request #115 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/115
[21:58] <helix84> we were just talking today if we can close that jira issue :)
[21:59] <helix84> ehm, not that one...
[21:59] <helix84> I meant DS-1182
[21:59] <kompewter> [ https://jira.duraspace.org/browse/DS-1182 ] - [#DS-1182] Javamail: Getting Session object with getDefaultInstace - DuraSpace JIRA
[22:00] <helix84> but now it's great time to pull your #115
[22:00] <helix84> tomorrow is RC3, testathon 2nd round starts on Monday
[22:00] <lyncode> yes, i also think so
[22:01] <helix84> remember your your line endings fix?
[22:01] <lyncode> yes
[22:02] <helix84> would you like to do it before tomorrow? it was ACKed today.
[22:02] <helix84> but I've never done it before, so it would be better if you know what you're doing :)
[22:02] <ZombieKevinVdV> Needs to run
[22:03] <helix84> run, zombie, run :)
[22:03] <helix84> bye, kevin
[22:03] <lyncode> bye
[22:03] <kompewter> see ya
[22:03] <lyncode> yes helix, no problem
[22:03] <helix84> thanks
[22:04] <lyncode> now, who clicks the merge button of #115?
[22:05] <helix84> OK, I will :)
[22:06] <helix84> I'll update demo to RC3 on Sunday, assuming everything goes well
[22:07] <lyncode> ok
[22:08] <lyncode> on last thing
[22:08] <lyncode> one*
[22:08] <helix84> yes?
[22:08] <lyncode> https://jira.duraspace.org/browse/DS-1311
[22:09] <kompewter> [ [#DS-1311] XOAI validation issues - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1311
[22:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1311 ] - [#DS-1311] XOAI validation issues - DuraSpace JIRA
[22:09] <lyncode> what to do about this ticket?
[22:09] <helix84> I'm not sure. Do you think those XSDs exist somewhere?
[22:10] <lyncode> i've searched (not a lot, i admit) but i didn't found anything else
[22:11] <lyncode> maybe the community could help
[22:12] <helix84> and that tool Claudia found the validation errors with should have access to those schemas (at least locally), no?
[22:13] <lyncode> yes, in order to have a successful validation those schemas must be available
[22:14] <lyncode> locally or remotely
[22:14] <helix84> so I can write to openarchives.org and ask them to send me the XSDs
[22:15] <lyncode> yes, if they answer... that would help a lot
[22:15] <helix84> pmh@openarchives.org
[22:15] <helix84> do you want to write or should I?
[22:16] <lyncode> be my guest :)
[22:16] <lyncode> bamboo alarm sounded
[22:17] <helix84> ah, yes, there were a lot of pulls during DevMtg today
[22:18] <lyncode> how do you link jira issues to github pulls?
[22:19] <helix84> just URLs in comments :(
[22:19] <helix84> the GitHub plugin for Jira is not very sophisticated
[22:19] <helix84> it knows about commits, but not about pulls
[22:21] <lyncode> ok, nice
[22:22] <ZombieKevinVdV> Needs to run
[22:22] * ZombieKevinVdV (~Zombie_Ke@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...)
[22:22] <helix84> I'm going through the validation issues - so which XSDs are we hunting? RDF and?
[22:23] <lyncode> uh more or less 6 XSDs, need to list them
[22:23] <lyncode> look https://jira.duraspace.org/browse/DS-1326
[22:23] <kompewter> [ [#DS-1326] OAI 2.0 XSLT displaying incorrect results numbering & odd looking header - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1326
[22:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1326 ] - [#DS-1326] OAI 2.0 XSLT displaying incorrect results numbering & odd looking header - DuraSpace JIRA
[22:24] <lyncode> looks like i did something wrong
[22:25] <helix84> why? what did you want to do?
[22:25] <lyncode> link that jira issue to #115 pull
[22:26] <helix84> there was already the pull's URL in comments
[22:26] <helix84> and I notice the Git plugin is broken since last Jira upgrade
[22:26] <lyncode> ok ok
[22:27] <helix84> it's this one: https://studio.plugins.atlassian.com/wiki/display/JGIT/JIRA+Git+Plugin
[22:27] <kompewter> [ JIRA Git Plugin - JIRA Git Plugin - Confluence ] - https://studio.plugins.atlassian.com/wiki/display/JGIT/JIRA+Git+Plugin
[22:34] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) has joined #duraspace
[22:34] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) Quit (Client Quit)
[22:41] <helix84> I have the email ready but I'm lost in those XSDs, I don't know what's done and what's missing :/
[22:42] <lyncode> let me list them and send to you
[22:42] <lyncode> (tomorrow too)
[22:43] <helix84> sure, no problem
[22:46] <helix84> About those line endings, can you please have that ready before 18:00 GMT tomorrow? They will want to start releasing RC3 then. Thanks.
[23:11] <lyncode> ;)
[23:35] <helix84> thanks
[23:36] <helix84> good night!
[23:36] * 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.