Timestamps are in GMT/BST.
[1:02] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[1:08] * stuartlewis_ (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[1:10] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Ping timeout: 276 seconds)
[1:10] * stuartlewis_ is now known as stuartlewis
[2:00] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[2:12] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[3:12] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[3:14] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 246 seconds)
[3:14] * stuartlewis_ is now known as stuartlewis
[3:37] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[3:39] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 276 seconds)
[3:39] * stuartlewis_ is now known as stuartlewis
[3:49] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[3:51] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 248 seconds)
[3:51] * stuartlewis_ is now known as stuartlewis
[4:23] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[4:25] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 258 seconds)
[4:25] * stuartlewis_ is now known as stuartlewis
[4:26] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Client Quit)
[6:36] -zelazny.freenode.net- *** Looking up your hostname...
[6:36] -zelazny.freenode.net- *** Checking Ident
[6:36] -zelazny.freenode.net- *** Found your hostname
[6:36] -zelazny.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:34] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[17:20] * tjohnson (~tjohnson@JohnsoTh-APiM24.library.oregonstate.edu) has joined #duraspace
[18:44] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Remote host closed the connection)
[19:53] * JRhoads (~jrhoads@160.10.15.22) has joined #duraspace
[19:54] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:55] * vibhaj (0e611ccc@gateway/web/freenode/ip.14.97.28.204) has joined #duraspace
[19:55] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:55] <tdonohue> Hi all -- in about 5 mins, our DSpace Developer Mtg will start here. Agenda, if you haven't seen it yet: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-11
[19:55] <kompewter> [ DevMtg 2011-05-11 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-11
[19:56] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:58] * cccharles (~chris@131.104.62.48) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. It's that time again, here's our DSpace Developers Mtg agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-11 we'll start with our normal JIRA quick review
[20:00] <kompewter> [ DevMtg 2011-05-11 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-11
[20:01] <tdonohue> Today, we kick off the JIRA review with DS-797. Here's the full list of issues remaining to review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-797+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-797 ] - [#DS-797] ant help says install_code target exists, but it doesn't - DuraSpace JIRA
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-797 ] - [#DS-797] ant help says install_code target exists, but it doesn't - DuraSpace JIRA
[20:01] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-797+ORDER+BY+key+ASC
[20:01] <tdonohue> let's try that again. We're starting with DS-797
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-797 ] - [#DS-797] ant help says install_code target exists, but it doesn't - DuraSpace JIRA
[20:02] * sandsfish (~sandsfish@dhcp-18-111-52-74.dyn.mit.edu) has joined #duraspace
[20:03] <tdonohue> Yep, ds-797 is a bug. Even on Trunk code, 'ant help' says there's such a thing as 'ant install_code' (when in fact, that target doesn't exist)
[20:03] <kompewter> [ https://jira.duraspace.org/browse/ds-797 ] - [#DS-797] ant help says install_code target exists, but it doesn't - DuraSpace JIRA
[20:03] <tdonohue> any thoughts on this? should we create 'ant install_code'? or fix the output of 'ant help'?
[20:04] <mdiggory> no, what would install code mean?
[20:04] <mdiggory> update installs code changes
[20:04] <sandsfish> deploy a code build without overwriting config?
[20:04] <mdiggory> I think this is old cruft leftover from the old build
[20:05] * mhwood (~mhwood@99.162.50.38) has joined #duraspace
[20:05] <tdonohue> I think, based on Ivan's request in Ds-797, he thought it should install Code without touching the DB again (not sure how much use that would get though)
[20:06] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[20:06] <tdonohue> So, is this a 'won't fix'? or Ask Ivan for more info?
[20:06] <mdiggory> tdonohue: any recommendation given your digging in this dirt with the installer?
[20:07] <mdiggory> I assume we want something like what sandsfish just pointed out
[20:07] <JRhoads> Has anyone requested an install without touching the DB?
[20:07] <tdonohue> yea, what sandsfish said would likely be useful.
[20:07] <mdiggory> albeit we generally overwrite everything with 'ant update -Doverwrite=true
[20:08] <mdiggory> vs not overwrite config directly with 'ant update -Doverwrite=false'
[20:08] <sandsfish> <echo message="install_code --> Install compiled code into ${dspace.dir}" />
[20:08] <mdiggory> ant doesn't compile anymore...
[20:09] <mdiggory> just copies
[20:09] <mdiggory> thus "update"
[20:09] <tdonohue> right, it says it's *installing* (pre-compiled) code to $(dspace.dir)"
[20:09] <sandsfish> yup, installs/copies. that's how it's documented in build.xml atm
[20:10] <tdonohue> Ok, I suggest we do the following: DS-797, ask Ivan for more info on usage, see if there's a better replacement for install_code, possibly suggest 'ant update'
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-797 ] - [#DS-797] ant help says install_code target exists, but it doesn't - DuraSpace JIRA
[20:10] <mdiggory> kinda misleading... what does it copy?
[20:10] <mdiggory> that was a retorical question
[20:10] <sandsfish> i personally haven't seen a use case where i needed this, so either more info or no fix is my vote.
[20:11] <tdonohue> I'm moving on..this is too much detail for one little issue :) move discussion to Ds-797
[20:11] <mdiggory> onward
[20:11] <tdonohue> Next up: DS-799
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-799 ] - [#DS-799] email sender fails to recognize BOM in the email template - DuraSpace JIRA
[20:12] <mdiggory> feeling a bit green... whats BOM?
[20:12] <tdonohue> not sure I fully understand this one, may need further investigation here
[20:12] <mdiggory> ah byte order mark
[20:12] <mhwood> Byte Order Marker. Only Microsoft uses them so far as I know. Has something to do with endian-ness.
[20:13] <tdonohue> any volunteer to investigate DS-799, to see if we can replicate this issue?
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-799 ] - [#DS-799] email sender fails to recognize BOM in the email template - DuraSpace JIRA
[20:13] <sandsfish> more info? maybe the build was done on a windoze machine and doesn't happen on other platforms.
[20:13] <mdiggory> --> insert Microsoft Bashing here <---
[20:13] <sandsfish> Microsoft/Skype
[20:13] <sandsfish> ;)
[20:14] <mdiggory> run for your lives
[20:14] <tdonohue> Ok. hearing no volunteers for now... Ds-799 Summary: Ask for more info about environment. Needs a volunteer to investigate & verify.
[20:14] <tdonohue> Next up: DS-800
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-800 ] - [#DS-800] Manage visibilty of metadata fields as field attribute rather than in dspace.cfg - DuraSpace JIRA
[20:15] <tdonohue> hmm.. this one (Ds-800) is marked as "Addressed By" DS-655, which robint is handling. But, it looks like robint didn't make it today
[20:15] <kompewter> [ https://jira.duraspace.org/browse/DS-655 ] - [#DS-655] MetadataExposure hides fields except for System Admins - this should extend to Community and Collection Admins - DuraSpace JIRA
[20:15] <mdiggory> visibility needs to be managed in the Model
[20:16] <mdiggory> not in configuration files... and to expand on this we need something like Metadata Bundles which would have ResourcePolicies attached
[20:16] <tdonohue> mdiggory -- yea, it looks like that is robint's recommendation down in the comments
[20:16] <mdiggory> So that we can have system, descriptive, administrative, bitstream metadata sections in a DSpace Item
[20:17] <mdiggory> and align completely with METS metadata sections and possibly align with Fedora Datastreams that are metadata centric
[20:17] <sandsfish> perhaps this is an architecture question that needs some further hashing out/design.
[20:17] <sandsfish> i can see the work taking on a few different shapes/sizes.
[20:17] <tdonohue> Maybe we should follow up with robint on this one?..I'd like to here how this overlaps with other linked issues, etc
[20:18] <mdiggory> tdonohue: yes I'm expanding on Robins suggestion....
[20:18] <tdonohue> ok. Ds-800 Summary: Followup with Robint. May need more discussion around necessary architecture changes and other related JIRA tickets. Needs volunteer
[20:19] <tdonohue> Next up: DS-802
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-802 ] - [#DS-802] Create a DSpace "Installer" which doesn't require users to build DSpace using Maven and Ant - DuraSpace JIRA
[20:19] <mdiggory> can we just post the dialog in the comments and wait for him to get back?
[20:19] <tdonohue> oh, wait, this is mine ;)
[20:19] <tdonohue> yep mdiggory -- we can post this dialog to comments of Ds-800.
[20:19] <mdiggory> did it
[20:20] <sandsfish> DS-802 - work proceeding on this already?
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-802 ] - [#DS-802] Create a DSpace "Installer" which doesn't require users to build DSpace using Maven and Ant - DuraSpace JIRA
[20:20] <mdiggory> I didn't realize the scale of the bloat until I did the standalone test
[20:21] <tdonohue> yes, Ds-802 is already begun, and is at: http://scm.dspace.org/svn/repo/sandbox/installer-prototype/ It's already "minimally working", but needs some more enhancements likely
[20:21] <kompewter> [ Revision 6368: /sandbox/installer-prototype ] - http://scm.dspace.org/svn/repo/sandbox/installer-prototype/
[20:21] <mdiggory> we have approx 30-40Mb per webapp lib directories
[20:22] <tdonohue> So, we can wait on the "official" Ds-802 review till it's in a more "ready" state, to be honest. But, in the meantime, comments/suggestions are welcome on dspace-devel or in the comments of the Ds-802 issue itself (please, feel free -- I'm looking for more ideas, etc)
[20:22] <mdiggory> which begs the question is it better to carry the Maven repo around as it would eliminate the duplication
[20:23] <tdonohue> mdiggory -- I already tried the option of "carrying around the Maven repo" in the installer. It won't work, unfortunately. See my comments here: https://wiki.duraspace.org/display/DSPACE/InstallerPrototype#InstallerPrototype-WhyembeddingMavenintoInstallerwon%27twork
[20:23] <kompewter> [ InstallerPrototype - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/InstallerPrototype#InstallerPrototype-WhyembeddingMavenintoInstallerwon%27twork
[20:24] <tdonohue> I'd suggest we leave Ds-802 to offline discussion though, I don't want to take up too much of this meeting's time. We have a rather full agenda here today. So, everyone OK with moving on to other topics?
[20:24] <JRhoads> Sure.
[20:24] <mdiggory> if the installer jar expands into a temporary directory?
[20:25] <mdiggory> think you should revisit it... at least from an assembly standpoint and the ongoing dialog about adding addons in etc...
[20:25] <mdiggory> but yes, offline
[20:25] <tdonohue> Ok, moving on then.
[20:26] <tdonohue> I'd like to revisit the idea of a 1.7.2. We've had more recent Oracle Threads on dspace-tech. Essentially, currently Oracle doesn't work with *either* 1.7.0 or 1.7.1. Should we release a 1.7.2, to ensure something in the 1.7.x series works with Oracle?
[20:27] <tdonohue> Here's the one outstanding Oracle bug: https://jira.duraspace.org/browse/DS-841
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-841 ] - [#DS-841] 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend) - DuraSpace JIRA
[20:27] <kompewter> [ [#DS-841] 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-841
[20:27] <tdonohue> what do others think?
[20:28] <scottatm> Do we have fixes for the issues?
[20:28] <sandsfish> do we have enough oracle test environment coverage to be confident in the stability of Oracle support?
[20:28] <tdonohue> I personally would *not* want a 1.7.2 to delay 1.8.0, so I think if we did release a 1.7.2 it should *ONLY* fix remaining Oracle issues
[20:28] <tdonohue> scottatm: Ds-841 has an attached patch, but I haven't reviewed it
[20:29] <hpottinger> I can confirm that the 'patch' I submitted for ds-841 is working, in an Oracle-backed environment
[20:29] <kompewter> [ https://jira.duraspace.org/browse/ds-841 ] - [#DS-841] 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend) - DuraSpace JIRA
[20:29] <tdonohue> sandsfish: no, we don't have a very large "oracle test environment coverage", but we have a few active Oracle users/developers, including hpottinger
[20:29] <hpottinger> we're about to put it into production
[20:29] <tdonohue> hpottinger, is that the last remaining Oracle issue you've seen in 1.7.1?
[20:29] <mdiggory> That suffices for me...
[20:30] <hpottinger> yes, we've not encountered anything else that needed fixing with 1.7.1, we're going into production using Peter's patch to DS-871 as well
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-871 ] - [#DS-871] XMLUI caches community / collection page which doesn't show a recently submitted item immediately - DuraSpace JIRA
[20:31] <tdonohue> Ok. So, do others then agree we should do a 1.7.2?
[20:32] <mhwood> Yes. We say we support Oracle. Can't leave it broken until fall.
[20:32] <scottatm> I think that makes sense, but I'd make sure the release notes say it only has a very limited number of fixes so that most people know they can skip it.
[20:32] <sandsfish> agreed with scottatm
[20:32] <tdonohue> scottatm -- I'd agree with that
[20:33] <PeterDietz> The release procedure is straight forward enough to perform it without being too much expense of time.
[20:33] <JRhoads> scottatm: +1
[20:33] <mdiggory> maybe we have a small initiative to collect more Oracle issue if anyone has them and release for OR11?
[20:33] <tdonohue> Anyone want to officially "cut" the release? It's a good "practice" of the release procedure, and as PeterDietz says, it should not be too difficult.
[20:33] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:34] <tdonohue> mdiggory -- we've already delayed this a while, to be honest. If we already have one Oracle institution (hpottinger) moving forward and saying this seems like the last Oracle issue, then I'm satisfied.
[20:34] <PeterDietz> I'd also like to schedule Ds-871 (xmlui caching of recent items) to 1.7.2.. Hopefully that doesn't conflate the idea of keeping it a low-key release
[20:35] <tdonohue> Ok. I'd be willing to compromise and say that 1.7.2 release is *just* Ds-841 and Ds-871. Nothing else gets in though, unless we hear of more Oracle issues in very near future.
[20:36] <mdiggory> wait wait , stop the presses ;-)
[20:36] <tdonohue> PeterDietz -- would you be interested in "cutting" the 1.7.2 release then and setting a date for it? :)
[20:36] <mdiggory> yes, that's a good ptach to get into release
[20:36] <PeterDietz> We should also get on with our plan to have the 1.8 beta's.. To get some of the +/- bold moves for 1.8 into the wild
[20:37] <stuartlewis> What about the issue that brings up the ugly stack traces in the dspace launcher?
[20:37] <tdonohue> stuartlewis -- is it fixed yet?
[20:37] <mdiggory> oh yea...
[20:37] <stuartlewis> Not sure - I think Kevin did?
[20:37] <KevinVdV> I have proposed a patch
[20:37] <mdiggory> its just changing the line in the start script
[20:37] <KevinVdV> It should work
[20:38] <KevinVdV> And the issue doesn't seem to occur in windows for the record
[20:38] <KevinVdV> (windows test == windows 7)
[20:38] <tdonohue> what's the JIRA issue number for that one? I cannot seem to find it
[20:38] <KevinVdV> https://jira.duraspace.org/browse/DS-875
[20:38] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:38] <kompewter> [ [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-875
[20:38] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:38] <JRhoads> Does the change work equally as well in windows?
[20:38] <hpottinger> sorry guys, I have to run, my 8yo will be grumpy if I don't pick him up from school :-)
[20:38] <tdonohue> thanks KevinVdV
[20:39] <KevinVdV> Np
[20:39] <PeterDietz> later hpottinger, thanks for the help
[20:39] <mdiggory> understand completely
[20:39] <tdonohue> no problem hpottinger. thanks for sticking around
[20:39] <mdiggory> So, it would reduce dspace-tech noise to get rid of the stacktrace
[20:40] <mdiggory> +1 on adding it
[20:40] <tdonohue> Has anyone else tested out KevinVdV's patch? (I trust KevinVdV, but it would be good to verify that DS-875 is fully fixed for a variety of OS's)
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:40] <PeterDietz> I'm of the mind that annoying bugs that (affect 1.7) and are fixed or have patches, that they get scheduled for 1.7.2
[20:40] <KevinVdV> Personally I would like to have some people test it in something other then windows 7
[20:40] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[20:41] <PeterDietz> For example, Ohio State still hasn't upgraded to 1.7.x solely because of xmlui recent item caching
[20:41] <tdonohue> PeterDietz -- I'm fine with that too, as long as we don't 'delay' 1.7.2 indefinitely to keep adding in new fixes ;) (I.e. I'd like to get 1.7.2 out in time for OR11 at the latest, preferrably even before then)
[20:42] <PeterDietz> I think I'm free the weekend before OR11. So how about May 27. (May 20 also works)
[20:42] <tdonohue> So, I think we should be 'strict' about what gets into 1.7.2 and what doesn't. If we can get some more of us to test out the Ds-875 patch, then I'd be fine with doing Ds-875, Ds-871 and Ds-841 all in 1.7.2
[20:42] <stuartlewis> I'll try out DS-875 today on my mac and our test servers, and can commit if all looks good (which I'm sure it will)
[20:42] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:43] <tdonohue> May 27 sounds fine to me. So, PeterDietz, you are going to 'cut' the release?
[20:44] <PeterDietz> yep. 1.7.2 is mine.
[20:44] <tdonohue> Sounds good. I'd definitely encourage you to be strict about 1.7.2, PeterDietz. Don't let us go sneaking in extra code if it doesn't need to be there ;)
[20:45] <tdonohue> Ok, so it's official: 1.7.2 will be May 27th release. Fix a few of the remaining annoying bugs in 1.7.1, and ensure full Oracle compatibility
[20:46] * PeterDietz says: Lobbyists interested in getting their pet projects into 1.7.2 should contact me offline. ;)
[20:46] <tdonohue> Ok. next topic: GSoC 2011. I just want to be sure all Mentors have been in touch with their students, etc. Students start programming on May 24
[20:47] <mdiggory> Ok... clocks ticking...
[20:47] <mdiggory> tdonohue: I thinkw e are suffering the same way as previous years.... we are not really seeing an open active dialog before the coding
[20:47] <tdonohue> Also, based on all the recent Git/Github discussions, I think it might be a good opportunity to "try out" github for some/all of the GSoC 2011 projects. I'll leave it up to the mentors, but it seems like a good opportunity
[20:48] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:48] <PeterDietz> Github is what we're leaning towards for WebMVC. Should be best for getting the student connected to the code.
[20:49] <tdonohue> mdiggory -- I guess that was what I was asking. Just cause we haven't "seen" a dialog in public doesn't mean that Mentors haven't started some sort of dialog with students. So, I was curious if the mentors here could fill us in on whether anything has started
[20:49] <mdiggory> I'm quite active on a number of the projects and I will say the dialog is lacking
[20:49] <PeterDietz> We've been in private/restricted communication Peter-Graham-Stuart-RobertFromSingapore. I suppose we should shift that to an open channel.
[20:49] * stuartlewis was working with our student (WebMVC) to get DSpace up and running last night - all going well now.
[20:49] <mdiggory> so if dialog is happening, its not transparent... TBH I guilty of this too
[20:50] * lllllllll (522921b0@gateway/web/freenode/ip.82.41.33.176) has joined #duraspace
[20:50] <tdonohue> PeterDietz: yea, that might be good to shift to a more "public" area soon-ish, if possible. Either dspace-devel or duraspace-gsoc
[20:50] <mdiggory> the challenge is that we will not get cross pollination if the dialog is not public
[20:51] <mdiggory> its for the students benefit... especially in the the WebMVC/REST area
[20:51] <tdonohue> right, hence the request to try and bring more discussions to 'duraspace-gsoc' or 'dspace-devel', to see if we can get more feedback to each of these projects, and see if there are cross-pollination opportunities or not
[20:51] <PeterDietz> I was somewhat wondering to myself how strong is the REST API's mechanism for determining which controller responds to which URL. And I was somewhat thinking that Spring WebMVC's annotations for URL's would be pretty excellent for a REST API.
[20:52] <sandsfish> duraspace-gsoc seems to make sense. there's already a decent amount of traffic on dspace-devel that it might get lost in.
[20:52] <grahamtriggs1> I should clarify PeterDietz's point - Robert dropped us an email asking if he there was anything he could be doing now, and we've replied with a courtesy email containing a couple of suggestions, whilst we discuss the GitHub issue.
[20:52] <tdonohue> +1 sandsfish. I'd probably recommend 'duraspace-gsoc' over dspace-devel (at least right now).
[20:53] <PeterDietz> ...and then I started thinking that I want to have Spring's MVC annotation. But someone would want REST API and/or WebMVC, and started to scratch my head...
[20:53] <mdiggory> PeterDietz: yes... Vibhaj, Bojan and I are dialoging about the possiblity of adopting Spring REST instead of EntityBroker
[20:53] <mdiggory> and that should be public as well... not the way it is now...
[20:54] <tdonohue> grahamtriggs1: what's the 'github issue'? just deciding whether you plan to use Github for the project code?
[20:55] <mdiggory> the tought hing about not using dspace-devel is that the exposure of the dialog is limit to those that joined that list... there might be someone who wasn't initially listening on dspace-devel and suddenly catches wind of a bit of work and has something valuable to add
[20:55] <mdiggory> they won't see that dialgo if its in duraspace-gsoc
[20:55] <grahamtriggs1> tdonohue: I think we're all pretty happy with the idea of using GitHub - I was just asking Peter about some of the practicalities given what he's already set up with the SVN sync, etc
[20:56] <mdiggory> likewise, your kind robbing the student of actually being int he middle of the community are you not?
[20:56] <tdonohue> mdiggory -- yea, but at the same time. dspace-devel is very "bogged down" these days. I'd hate to throw a student into that list immediately. Just like in past years we've always had a separate GsoC public list
[20:57] <mdiggory> yea and I realized it didn't really work then as well
[20:58] <mdiggory> I worry that the benefits of the community dialog are lost when trying to protect the student.... it may be premature to be trying to protect the student, isn't the dialog what DSpace developer community is about?
[20:58] <tdonohue> Ok. The other thing to point out is that obviously using 'duraspace-gsoc' is a way to also get Fedora or DuraCloud feedback. Admittedly, that may not be as important this year (as no projects have huge overlaps with other technologies), but it's another reason why we created 'duraspace-gsoc'
[20:58] <tdonohue> to be honest though, I'm fine with leaving it up to the Mentors to decide. I think the more important thing is to move discussions to being more public, whether that is dspace-devel or duraspace-gsoc
[20:59] <PeterDietz> grahamtriggs1: sorry for dropping the ball on responding about continuing sync of svn/github. I'd prefer to not sync github down to svn. Especially since you can svn co https://svn.github.com/DSpace/webmvc.git
[20:59] <PeterDietz> (sorry for directing towards tangent).. You can svn co a github project: https://github.com/blog/626-announcing-svn-support
[20:59] <kompewter> [ Announcing SVN Support - GitHub ] - https://github.com/blog/626-announcing-svn-support
[21:00] <mdiggory> maybe a happy medium is to post an email in the dspace-developer list to please join into the duraspace-gsoc list...
[21:00] <JRhoads> I'm gonna have to run (Lab closing). Good stuff today and great discussions on the dspace-devel list.
[21:00] <tdonohue> So, I'd recommend that all Mentors try and bring any discussions with Students to a move 'public' area. It's up to you if you feel the initial discussion should be put on dspace-devel or 'duraspace-gsoc'
[21:01] <tdonohue> mdiggory : that's actually already been done, several times during this GSoC process ;) But, I was planning to post another reminder to dspace-devel to join duraspace-gsoc for more info
[21:01] <PeterDietz> I guess we're always free to cross-post to dspace-devel, when something might be relevant to the wider group.
[21:01] <tdonohue> In any case, if you haven't already, please join 'duraspace-gsoc' list: http://groups.google.com/group/duraspace-gsoc/
[21:01] <kompewter> [ DuraSpace GSoC | Google Groups ] - http://groups.google.com/group/duraspace-gsoc/
[21:01] * JRhoads (~jrhoads@160.10.15.22) has left #duraspace
[21:02] <tdonohue> If you are a Mentor, you also should join the 'duraspace-gsoc-mentors' list (Private, administrative list): http://groups.google.com/group/duraspace-gsoc-mentors
[21:02] <tdonohue> +1 PeterDietz -- you are free to cross post as much as you see fit
[21:03] <sandsfish> gotta head out all. cheers!
[21:03] <mdiggory> PeterDietz: thats awesome... an anti- april fools joke
[21:03] * sandsfish (~sandsfish@dhcp-18-111-52-74.dyn.mit.edu) Quit (Quit: sandsfish)
[21:03] <grahamtriggs1> PeterDietz: I'm not bothered about syncing Git -> SVN. I'm more concerned about what might happen if we are developing on a Git project that is being synced FROM svn (as it currently is). And what if we decide to make occassional drops to svn whilst that is still the 'official' repository, etc.
[21:04] <tdonohue> That's everything we really have time for today. So, unless there are other questions/comments, I'd say we can close up the official meeting for today (but feel free to continue any discussions)
[21:04] * scottatm thinks we should just pick a day and switch to git. syncing the repositories seems like a recipe for disaster.
[21:05] <tdonohue> scottatm -- I think the problem is that we're still trying to get a majority in favor of that switch ;) So, I think PeterDietz's 'syncing' idea is just to try and give us tools to get more comfortable with github
[21:05] <mdiggory> scottatm: been in that disaster already
[21:05] <grahamtriggs1> scottatm: I tend to agree. Although I think a few more of us would like experience using Git before we can make that decision. Hence why GSoC projects are a good 'canary'
[21:05] * lllllllll (522921b0@gateway/web/freenode/ip.82.41.33.176) Quit (Quit: Page closed)
[21:05] <scottatm> Oh, yes. I'm not suggesting we should do that just now. I meant when we eventually decide to switch we should just flag day it.
[21:06] <mdiggory> PeterDietz: grahamtriggs can we get the students a decent starting point in git or at least a guideline of some sort
[21:06] <scottatm> Like we could say, 1.8.x will be the last release on SVN, 1.9 and above will be GIT?
[21:07] <mdiggory> for instance, put the rest project there as well and discuss how to fork for prototyping...
[21:07] <tdonohue> yea, I agree. I don't see "syncing" as a long term solution. At some point we either switch entirely or we decide entirely against it -- my point is that we need a majority and right now I'm not sure we have that (although it does seem we're getting closer to that)
[21:07] <PeterDietz> I'd prefer that once development begins for a project in github, that we cease svn commits. Perhaps even stopping the cron sync. Then then deleting the svn repo al-together
[21:08] <mdiggory> PeterDietz: the challenge is that the svn repo is there for legacy purposes... theres even one still at SF
[21:08] <scottatm> And the one at SF still has a stale code base there.
[21:08] <mdiggory> it better be
[21:09] <PeterDietz> I'd prefer to not keep that around.
[21:09] <tjohnson> mdiggory: what's wrong with importing the whole history via git-svn and nuking the old repo?
[21:09] <grahamtriggs1> PeterDietz: but I'm not clear on how these have been setup. For example: WebMVC is a separate Git repository from DSpace trunk? And there are separate crons for syncing each?
[21:09] <tdonohue> yea, we'd probably never *remove* the svn repo, to be honest (just like Fedora didn't remove theirs when they went to github). But we would make it entirely "read only".
[21:09] <mdiggory> tdonohue: right
[21:10] <PeterDietz> tjohnson: That's half of what's been done with the main dspace trunk. And for the module/webmvc. (No nukes yet, we're all nervous after what happened to Japan)
[21:10] <tdonohue> (but that is something we could still discuss -- just pointing out that Fedora actually decided against removing their old SVN, at least for now)
[21:10] <scottatm> The negative side of leaving the old repos around is that there's still lots of links around the web to them. Someone new to the project will stumble on one of those and think that no one has updated DSpace is a long time.
[21:10] * vibhaj (0e611ccc@gateway/web/freenode/ip.14.97.28.204) has left #duraspace
[21:11] * vibhaj (0e611ccc@gateway/web/freenode/ip.14.97.28.204) has joined #duraspace
[21:11] <PeterDietz> we could leave a README as the only file left once we've verified the conversion. Link to new repo
[21:11] <PeterDietz> I'm nervous about the person who types svn up though.
[21:13] <grahamtriggs1> We've already done CVS -> SVN, and SF -> OSL. Don't think anyone has been harmed so far.
[21:16] <PeterDietz> Things have died down. Last word on using github for webmvc?
[21:16] <mdiggory> TBH... if we switch to Git.... OSL may want to take down the scm server
[21:16] <mdiggory> there may not be much choice there
[21:17] <tdonohue> PeterDietz: I'd say feel free to use it, if all on the webmvc project are OK with it.
[21:18] <tdonohue> mdiggory -- yea, I think this is all something we'll figure out once we come to a decision around github. We can also always just "archive" an old, read-only copy of the DSpace SVN at https://svn.duraspace.org/ if we wanted to (or elsewhere, just in case we ever really needed it)
[21:18] <kompewter> [ svn.duraspace.org ] - https://svn.duraspace.org/
[21:19] <PeterDietz> I'd recommend having a few trials first. Moving one module isn't abandonment
[21:20] <mdiggory> I"m all for it... but it brings up the dialog Tim and I had about grouping modules into core, thirdparty, experimental, etc
[21:21] <tdonohue> dialog that mdiggory & I had is under "Time Permitting" on our Agenda -- we didn't get to it today though, as we ran over time with other discussions: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-11
[21:21] <kompewter> [ DevMtg 2011-05-11 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-11
[21:22] <PeterDietz> peace all. My weekend starts... right... now... later
[21:23] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has left #duraspace
[21:23] <mhwood> I should go too. 'bye all.
[21:23] * mhwood (~mhwood@99.162.50.38) has left #duraspace
[21:38] * vibhaj (0e611ccc@gateway/web/freenode/ip.14.97.28.204) has left #duraspace
[21:41] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[21:59] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:38] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[22:38] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[22:40] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 248 seconds)
[22:40] * stuartlewis_ is now known as stuartlewis
[22:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[22:48] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[23:00] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[23:20] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[23:22] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 260 seconds)
[23:22] * stuartlewis_ is now known as stuartlewis
[23:26] * stuartlewis_ (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[23:28] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
[23:28] * stuartlewis_ is now known as stuartlewis
[23:56] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.