Timestamps are in GMT/BST.
[0:34] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[0:34] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Client Quit)
[0:46] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[1:04] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Read error: Connection reset by peer)
[1:04] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[1:05] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Client Quit)
[1:29] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[2:01] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[2:02] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Client Quit)
[2:51] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[6:35] -hitchcock.freenode.net- *** Looking up your hostname...
[6:35] -hitchcock.freenode.net- *** Checking Ident
[6:35] -hitchcock.freenode.net- *** Found your hostname
[6:35] -hitchcock.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:56] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Ping timeout: 276 seconds)
[10:36] * eddies_ (~eddies@unaffiliated/eddies) has joined #duraspace
[10:36] * eddies_ (~eddies@unaffiliated/eddies) Quit (Client Quit)
[10:36] * eddies (~eddies@245.17.113.78.rev.sfr.net) has joined #duraspace
[10:36] * eddies (~eddies@245.17.113.78.rev.sfr.net) Quit (Changing host)
[10:36] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:59] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:09] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[14:54] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:58] * grahamtriggs (~trig01@62.189.56.2) Quit (Ping timeout: 240 seconds)
[18:17] * vibhaj (7376e151@gateway/web/freenode/ip.115.118.225.81) has joined #duraspace
[18:50] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:04] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:29] * cccharles (~chris@131.104.62.48) has joined #duraspace
[19:33] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) has joined #duraspace
[19:47] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:48] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[19:48] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:48] <tdonohue> Hi all, reminder that at the top of the hour is our DSpace Developers Mtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-18
[19:48] <kompewter> [ DevMtg 2011-05-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-18
[19:51] <robint> If anyone cant wait could they tell me if they object to https://jira.duraspace.org/browse/DS-852 ?
[19:51] <kompewter> [ https://jira.duraspace.org/browse/DS-852 ] - [#DS-852] Split the Creative Commons and Licence steps into two seperate steps. - DuraSpace JIRA
[19:51] <kompewter> [ [#DS-852] Split the Creative Commons and Licence steps into two seperate steps. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-852
[19:53] * vibhaj (7376e151@gateway/web/freenode/ip.115.118.225.81) has left #duraspace
[19:53] * vibhaj (7376e151@gateway/web/freenode/ip.115.118.225.81) has joined #duraspace
[19:53] <tdonohue> robint -- I approve of the idea of Ds-852, haven't had a chance to look at the code though. Assuming it's well tested & working, I wouldn't have any objections
[19:54] <mdiggory> +1 ideal as well
[19:55] <robint> thanks both. Didn't have to change any code, just seperated it.
[19:55] <mdiggory> +! on no code change ;-)
[19:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[19:55] <tdonohue> cool, in that case, i'd approve :)
[19:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:56] <mdiggory> what gets committed if no code changed?
[19:56] <mdiggory> that was a joke...
[19:56] <mdiggory> chirp chrip chrip
[19:56] <KevinVdV> ....
[19:56] <robint> :)
[19:59] <mdiggory> might check with MIT... Think they were rewriting CC portion of step, verify theres no duplication/conflict
[19:59] <robint> mdiggory: I checked with Wendy and Richard, cheers
[20:00] <KevinVdV> There is also an issue with the creative commons & the embargo feature: https://jira.duraspace.org/browse/DS-873
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-873 ] - [#DS-873] Creative commons license bundle on embargoed item will cause internal system errors on item pages - DuraSpace JIRA
[20:00] <kompewter> [ [#DS-873] Creative commons license bundle on embargoed item will cause internal system errors on item pages - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-873
[20:00] <tdonohue> Ok, about time to start the "official" meeting. Welcome. We'll kick things off with a JIRA quick review.
[20:01] <tdonohue> Here's the list of issues we are starting from today, beginning with Ds-803: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-803+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-803 ] - [#DS-803] 'dspace harvest -g' (ping) 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-803+ORDER+BY+key+ASC
[20:01] <mdiggory> can we backup to the one KevinVdV just posted first?
[20:01] <KevinVdV> https://jira.duraspace.org/browse/DS-873
[20:01] <kompewter> [ [#DS-873] Creative commons license bundle on embargoed item will cause internal system errors on item pages - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-873
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-873 ] - [#DS-873] Creative commons license bundle on embargoed item will cause internal system errors on item pages - DuraSpace JIRA
[20:01] <robint> KevinVdV: I'll check there are no conflicts with 873, cheers
[20:01] <tdonohue> mdiggory -- I thought KevinVdV's post was "informational" for robint?
[20:02] <KevinVdV> That also but don't know if it conflicts
[20:02] <KevinVdV> I think it is just a pretty serieus issy
[20:02] <KevinVdV> issue
[20:02] <mdiggory> just wanted to make sure it wasn't missed in the onslaught, thats all...
[20:03] <mdiggory> it relates to all the JIRA noise I posted this morning... but ok to leave that for later...
[20:03] <tdonohue> ok. fine. We can step back for a moment then. We'll start with DS-873 and then go back to my list afterwards
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-873 ] - [#DS-873] Creative commons license bundle on embargoed item will cause internal system errors on item pages - DuraSpace JIRA
[20:03] <mdiggory> I will add this to the related issues on the task I just created....
[20:04] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:04] <mdiggory> Ds-908
[20:04] <grahamtriggs> isn't it a bit odd to have Creative Commons on an embargoed item?
[20:04] <tdonohue> Ds-873 looks like a rather simple fix to me, and seems to make sense
[20:05] <KevinVdV> Strange though it may be it occurs
[20:05] <tdonohue> grahamtriggs -- perhaps a bit odd, but we probably shouldn't assume it's "impossible" :)
[20:06] <robint> This one may conflict with the MIT work, worth checking with Wendy Bossons
[20:06] <mdiggory> This reflects the need for a more all encompassing view on how resource policies are managed in embargo, moving items and or movement of items into Archive from Workflow, etc
[20:06] <tdonohue> Ok. Sounds like we need (a) a volunteer, (b) talk to MIT, and (c) link back to robint's Ds-852 work
[20:07] <grahamtriggs> well, depending on the embargo reason, it might be feasible. and if you have multiple files, some may be CC, whilst one is embargoed / restricted
[20:07] <grahamtriggs> but generally, it is at odds to say something is both restricted access,, and freely (re-)usable
[20:08] <mdiggory> DS-908 would resolve issues allowing embargo at multiple levels (Item or Bitstream) and more than likely be customizable.
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-908 ] - [#DS-908] Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace - DuraSpace JIRA
[20:08] <tdonohue> Notes we're doing "quick" reviews here -- probably should wrap this issue discussion up. Any volunteers to tackle this or investigate issues further?
[20:08] <mdiggory> a.) no matter how much we say "Embargo is Item level" right now, the Policies are set at the Bitstream Level.
[20:09] <mdiggory> so, having differing policies on licenses etc is feasable
[20:10] <tdonohue> Ds-873 summary: Seems relatively minor. Needs a volunteer. Also should be run past MIT folks. Link up with Ds-852 work as well?
[20:10] <mdiggory> anyhow... leaving it tdonohue to decide... I'm not trying to shanghi the JIRA review and suggest this is probibly a topic for a special meeting
[20:11] <mdiggory> patch is small, I push it
[20:11] <tdonohue> mdiggory -- yea, not enough time to discuss this in a "quick review" -- this part of our meeting is about quick decisions and assigning volunteers, not about larger discussions (i.e. we need special topic mtg for your topic)
[20:11] <tdonohue> moving on for now...next up
[20:11] <tdonohue> DS-803
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-803 ] - [#DS-803] 'dspace harvest -g' (ping) doesn't - DuraSpace JIRA
[20:12] <grahamtriggs> I'm happy to push embargo issues to a special topic - I was just flagging up that there are probably bigger issues to think about than have been covered so far
[20:12] <mdiggory> grahamtriggs: "bring it" in my JIRA ticket.
[20:13] <tdonohue> any comments on Ds-803, or volunteers to implement 'ping', since it doesn't seem to exist?
[20:13] <mdiggory> seems someone needs to create a patch first?
[20:13] <tdonohue> yep..hence my request for "volunteers to implement" ;)
[20:14] <grahamtriggs> is it documented?
[20:15] <tdonohue> not sure, but it sounds like the option exists, from what mhwood says, but it doesn't work
[20:16] <tdonohue> Ok. we'll just move on for now. Ds-803 Summary: Needs more information, e.g. is it documented? Needs a volunteer to implement.
[20:16] <tdonohue> Next up: DS-804
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-804 ] - [#DS-804] Spelling errors in Russian language pack/ - DuraSpace JIRA
[20:17] <tdonohue> oh, err. looks like a Claudia item (and she's already started conversation in the comments)
[20:17] <mdiggory> perhaps see if she will complete the commit?
[20:17] <tdonohue> Ds-804 Summary: Assign to Claudia? Waiting on response to Claudia's last comment
[20:18] * mdiggory ponders that one could actually commit such a change from the github UI itself without needing local svn checkout and commit knowledge...)
[20:18] <tdonohue> mdiggory -- it looks like it's "in limbo" Claudia's last comment is requesting fixes to the patch
[20:18] <grahamtriggs> looks like DS-803 just needs to call harvester.verifyOAIharvester if the options passed are valid.
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-803 ] - [#DS-803] 'dspace harvest -g' (ping) doesn't - DuraSpace JIRA
[20:19] <tdonohue> thanks grahamtriggs! Would you be willling to add a comment to Ds-803 around that?
[20:19] <mdiggory> k... maybe "PING" Ivan in the comments again
[20:19] <tdonohue> Moving on to next one: DS-805
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-805 ] - [#DS-805] QDC schema registry needs to be brought into conformity with the current DCMI standards - DuraSpace JIRA
[20:20] <robint> Couldn't disagree but its not a 5 minute job
[20:20] <tdonohue> this is a larger issue, obviously. Metadata schemas is in our "Topics in Waiting" list for Special Topics meeting
[20:21] <tdonohue> It could also be something we could bring up for some discussion at our OR11 Dev Mtg, if others are interested
[20:21] <tdonohue> (as the topic of Metadata support may also be of great interest to folks from DCAT, some of whom will be at the OR11 Dev Mtg)
[20:21] <mhwood> harking back to CC license + embargo: license means it *will be* freely usable once the embargo is lifted. Embargo is a temporary overlay on rights.
[20:22] <robint> tdonohue +1
[20:22] <mdiggory> tdonohue: I agree.. Of strong interest to me was well
[20:23] <mdiggory> looking forward to any dialog
[20:23] <tdonohue> Ok. we'll stop there. Seems like agreement that Ds-805 (and idea of ongoing Metadata support) be "tabled" for some initial discussions at OR11 Dev Mtg along with DCAT and others. May also warrant a future Special Topic Mtg after OR11, we'll see
[20:23] <mdiggory> yep
[20:24] <tdonohue> Ok. moving on to other topics on agenda. Next up is 1.7.2 Updates
[20:24] <PeterDietz> Hi
[20:24] <PeterDietz> I was on the fence about one of the caching issues making it in
[20:24] <mdiggory> mhwood: could be that instead of alter embargo ResourcePolices... maybe the UI's should check for permissions prior to attempting to show?
[20:25] <PeterDietz> I ended up deciding that if 1.7 didn't break it, then 1.7.x+1 doesn't need to fix it. 1.8 should
[20:25] <mhwood> Maybe. Sorry, I just got back from moving servers. Must look more deeply into this. Meanwhile, conversation moved on. Just wanted to capture a thought.
[20:25] <mdiggory> why does the UI need to access the License? To try to embed licensing detail (a http link embeeded in bitstream)
[20:25] <PeterDietz> Its weird logic, and I'm typically of the mind, that if we can fix things now, then we should, to encourage adoption of latest release
[20:26] <mdiggory> seems goofy
[20:26] <tdonohue> yep. Plus, another point on 1.7.2 is that we likely want to keep it "small" and avoid anything that we are not certain about (so as to avoid needing a 1.7.3)
[20:26] <robint> PeterDietz: Agreed. Leave until 1.8
[20:27] <mdiggory> sorry that last comment was about cc licesnse and embargo
[20:27] <mdiggory> not 1.7.2
[20:28] <tdonohue> So, it looks like 1.7.2 will fix, Ds-841 (has a code fix, uncommitted yet), Ds-871 (already committed), and hopefully Ds-875 (seems to not have a "valid" fix yet?)
[20:28] <tdonohue> https://jira.duraspace.org/browse/DS/fixforversion/10464
[20:28] <kompewter> [ DSpace: 1.7.2 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/10464
[20:28] <mdiggory> I rather think that yes we want it small, but if the behavior is greatly improved by getting what is a small patch into place, it might be a wise exception
[20:28] <PeterDietz> hopefully we can have all of our fixes to have nice clean patches in the attachments. So that X-University who wants to have a patch, can just patch their system with their important fix. Sounds like several years old advice, but its still a usable route for affects-me bugfixes
[20:29] <hpottinger> for my little addition to this, I can confirm that the revised patch for DS-898 is working smashingly on our repository
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-898 ] - [#DS-898] Caching error in browse, search and discovery results - DuraSpace JIRA
[20:31] <PeterDietz> Ds-898 came in 2 parts. A fix to trunk, that caused NPE, followed by an additional fix
[20:31] <PeterDietz> r6369 and r6379
[20:31] <tdonohue> Any updates or comments on DS-875 proposed fix, which seems to be the one issue already scheduled for 1.7.2 that doesn't have 'wide agreement' (or at least stuartlewis, who isn't here, had some comments)
[20:31] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:31] * mdiggory enjoys the use of the word "smashingly"
[20:32] <PeterDietz> smashingly kind of sounds like the bug fix caused more problems. ... unless it was said by Austin Powers, then it made your repository even more groovy
[20:32] <KevinVdV> I just commented on DS-875 before this meeting
[20:32] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:33] <KevinVdV> T.b.h. the thing is I don't know what the "best" way to fix it is...
[20:33] <tdonohue> yea, thanks KevinVdV. I was also curious to see others opinions on this. Do we remove 'CLASSPATH' altogether (like current patch does) or see if we can find another way around it.
[20:33] * mdiggory rofl'ing
[20:34] <tdonohue> any other ideas on Ds-875 from anyone?
[20:35] <mdiggory> I was trying to comment... basically, I think if your going to pass in a CLASSPATH... the problems that it causes are upto you to manage
[20:35] <PeterDietz> could we remove the e.printStacktrace ?
[20:35] <mdiggory> I think we should protect the command with at least a warning
[20:35] <KevinVdV> We could but that will not fix the issue
[20:36] <mdiggory> and use if conditionals to configure the commandline to have CLASPATH only if it is set
[20:36] <mdiggory> conditional example provided needs work... theres a better way in bash
[20:36] * hpottinger has to run, sorry folks
[20:37] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[20:37] <tdonohue> mdiggory -- so, something similar to what stuartlewis suggested then?
[20:37] <KevinVdV> But I think it should also be clear IF it crashes the user should be aware of this
[20:37] <mhwood> But we may not have bash.
[20:37] <KevinVdV> Perhaps a cleaner error could be thrown...
[20:38] <mdiggory> But more explict, check for CLASSSPATH present in environment, set it only if it is present, right now what it dumps onto the executable is not correct with CLASSPATH is not set
[20:38] <mdiggory> its a bash script
[20:38] <tdonohue> KevinVdV - yea, I can see a cleaner error perhaps. But, I do like the idea of keeping the CLASSPATH in there, if it is set.
[20:39] <mhwood> mwood@mhw ~/servers/johncock/build/dspace/dspace-1.7.0/dspace/bin $ head dspace
[20:39] <mhwood> #!/bin/sh
[20:39] <KevinVdV> I agree with you on the fact that the CLASSPATH should stay in (if explicitly set)
[20:40] <mhwood> Agreed, do not want to lose CLASSPATH if we can deal with odd values.
[20:40] <tdonohue> Ok. it sounds like we have several of us in agreement that "preserving the inclusion of CLASSPATH" is a good thing. So, sounds like we need a few of us to revisit Ds-875 then, and see if we can throw better errors if they should occur.
[20:41] <mdiggory> A warning clarifying that if your CLASSPATH is "dirty" you may break DSpace would be good to toss in there
[20:41] <mdiggory> and like KevinVdV suggested, maybe a light/quick review of that path might help...
[20:41] <tdonohue> yea, a cleaner warning or error would be best -- either one
[20:42] <mdiggory> likewise, I would still research use of classworlds in this case as a possible means to let a third party open source tool dedictated to managing classpaths on commandline execution of java deal with such problems instead of us
[20:43] <mdiggory> because then one solution would apply to both *nix and Windblows
[20:43] <KevinVdV> Using a third party tool might also work if it does a propper job
[20:43] <tdonohue> Ok. any volunteers to continue work on this? Obviously need to prioritize Ds-875 if we want to "make the deadline" for 1.7.2
[20:43] <KevinVdV> Well I can create a patch for a clean error pretty swiftly
[20:44] <mdiggory> I think thats best for 1.7.2
[20:44] <tdonohue> KevinVdV -- that'd be great. If we can combine that with an updated patch that preserves the CLASSPATH, that seems like a good solution for 1.7.2
[20:44] <mdiggory> save the classworlds overhaul for 1.8
[20:44] <tdonohue> +1 mdiggory
[20:44] <KevinVdV> I will indeed save the classworlds until 1.8
[20:45] <KevinVdV> I can also attempt to look into the "optional" CLASSPATH
[20:45] <tdonohue> Ok. any other 1.7.2 topics? (noticing we're running shorter on time, and it might be good to talk briefly about GSoC today)
[20:45] <mdiggory> I think we need to dedicate a meeting to it
[20:46] <mdiggory> but I know that timezones make it impossible to get everyone in one room
[20:46] <tdonohue> "it" -- using that term always confuses me in IRC, you talking about GSoC?
[20:46] <PeterDietz> 1.7.2 will have Oracle bug fixes, the bug we just discussed about services classpath, and xmlui caching of recent items list (caused by 1.7 reshuffle of aspects artifactBrowser)
[20:46] <mdiggory> it = GSoC rampup
[20:47] <tdonohue> Ok. let's move on to GSoC rampup then now... since at many of the mentors are here currently
[20:47] <mdiggory> I mean it would be good to have meetings where we have an agenda of some sort
[20:48] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) Quit (Ping timeout: 252 seconds)
[20:49] <tdonohue> mdiggory -- can you clarify. You want just one meeting on 'rampup', or are you talking about multiple check-in meetings on GSoC (which I actually thought we'd do mini-checkins during this Dev Mtg each week)
[20:49] <PeterDietz> as far as GSoC goes, webmvc has still kept discussion private. I'll fork the thread to the gsoc list
[20:50] <mdiggory> Originally, meetings would be held where students and mentors delivered status and entertained feedback from thos interested.... I'm suggesting scheduling would help in this area
[20:50] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) has joined #duraspace
[20:50] <mdiggory> Projects need to get into the WIKI (pointing finger at self too) into the great pages you created
[20:50] <mdiggory> Adjustments to proposed solutions....
[20:51] <mdiggory> requirements...
[20:51] <mdiggory> engagement with students....
[20:51] <mdiggory> setup of accoutns and verifying access...
[20:51] <tdonohue> So, how about similar to last year, we do 10-15 mins of "GSoC Updates" as part of our weekly Dev Meeting. We could also encourage every project to give more detailed updates at 21UTC or 19UTC (either just before or just after our normal Dev mtg)
[20:52] <mdiggory> true tru
[20:52] <tdonohue> would everyone agree to that sort of meeting structure? Other mentors have thoughts on this?
[20:54] <PeterDietz> I'm free for the after dspace meeting
[20:54] <tdonohue> Or alternatively, how would the other mentors out there prefer to manage GSoC this year? I'm looking at grahamtriggs, PeterDietz, scottatm, mdiggory (and all those others not in attendance)
[20:54] <tdonohue> sounds good PeterDietz
[20:54] * 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:55] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[20:55] <tdonohue> (As mdiggory noted above) All mentors should also work with their students to start to populate their Project's Wiki page, linked off here: https://wiki.duraspace.org/display/GSOC/GSoC+2011+Projects
[20:55] <kompewter> [ GSoC 2011 Projects - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/GSoC+2011+Projects
[20:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:56] <PeterDietz> The webmvc project still needs to get the ball rolling. i.e. choosing svn or github. making sure the students got an editor, can install dspace, understands the technology. And also we need to sort out exactly what the scope of the project it
[20:56] <mdiggory> sending reminder to Duraspace GSoC list now to get into the WIKI
[20:57] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[20:57] <mdiggory> PeterDietz: thats an issue across the board...
[20:58] <tdonohue> Any others have thoughts about a weekly all-GSoC meeting either just before or just after our Dev Mtg? I noticed stuartlewis just joined as well. So far, it sounds like PeterDietz prefers an "after Dev Mtg" all-GSoC meeting
[20:58] <mdiggory> PeterDietz how can we shepard getting this setup sooner.
[20:58] <stuartlewis> after++
[20:58] <grahamtriggs> PeterDietz: we're still looking for a little clarification on the GitHub setup - in particular with the svn syncing. I'm ready to just agree to do stuff on GitHub, but I don't want to start committing code there only for an attempted svn->github sync to screw things up
[20:58] <mdiggory> lets say... choose Git and have an expert organize forks for us?
[20:58] <mdiggory> after ++
[20:59] <tdonohue> Ok, the "afters" have it. We'll have an all-GSoC meeting weekly on Weds at approx 21:00 UTC (or right after this normal mtg) and encourage everyone who can to stick around to provide feedback, etc
[21:00] <PeterDietz> I'll arrange any project in github that is wanted to be organized there. However, the syncing between git <--> svn works, but you eventually would want to choose one or the other. So that you know which repository is canonical
[21:01] <tdonohue> I'd say for GSoC, if it simplifies things, we could consider Github as "canonical". Later on (after GSoC ends) we could always move it to SVN if we really wanted to, or just keep it in Github
[21:02] <stuartlewis> But for now presumably syncs will be turned off?
[21:03] <tdonohue> hmm... well, actually, I was more thinking that the primary sync svn -> git that PeterDietz does could be "on". But, that each GSoC project would just do their own code in Github and not worry about syncing it back to SVN (or does that not work for each project?)
[21:03] <robint> Got to run unfortunately. Cheers all.
[21:04] <mhwood> Yes, I need to go too. 'bye!
[21:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:04] <stuartlewis> Yep - sounds sensible (I was thinking about the other way round, thinking we didn't want git->svn)
[21:04] <PeterDietz> yep, my recommendation is what tdonohue just said. maintain the current dspace-trunk sync so that we've got that big project "mirrored". Then have modules that want to leap (i.e. webmvc), to do all development in github, no more svn commits
[21:05] <tdonohue> +1 - PeterDietz may have said it better than I did :)
[21:05] <grahamtriggs> tdonohue: I'm concerned about that - what if someone inadvertantly committed something to svn, and then it's trying to sync out of date stuff to github?
[21:05] <mdiggory> PeterDietz: what if project infove changes to dspace directly?
[21:06] <mdiggory> infove = involve
[21:06] <tdonohue> mdiggory -- wouldn't you just "fork" it? (similar to how you'd branch it or create a new 'prototype' in SVN)?
[21:07] <mdiggory> Will forking and being in git make getting those changes into dspace at the end more difficult?
[21:07] <mdiggory> meaning back to the dspace svn repository
[21:07] <PeterDietz> once a project becomes abandoned on svn, then we should take it down / board it up, and leave a note to go check out github/your-project-name
[21:08] <tdonohue> grahamtriggs -- but, shouldn't that hopefully be mostly avoided if you are managing your WebMVC code entirely in GitHub (i.e. everyone moves development from SVN to Git for that project, to avoid sync problems)? I admit, I don't know for sure, just thinking outloud
[21:09] <PeterDietz> since we've got one foot in both camps. Then you'll have to make your dspace/trunk commits in svn (since we're just using github/dspace repo as a mirror)
[21:09] <grahamtriggs> tdonohue: I realise nobody would be doing it normally - but what if someone else doesn't realise? What if a command forces the tree to think there are changes, and sync across old code?
[21:10] <tdonohue> mdiggory: yea, it could. But if there's a one-way sync from SVN to Git, then hopefully your "fork" would pick up most of those changes in SVN little by little. In which case, maybe you could more easily merge back to SVN if necessary.
[21:11] <tdonohue> grahamtriggs - i don't know to be honest. I'm not a Git expert yet, admittedly. Just offering some ideas for how you could start to "test out" Git/Github as part of GSoC, in the hopes that we can make the switch entirely some day in the future
[21:12] <PeterDietz> @mdiggory, the github repo + forked by someone who sends in pull request that gets merged into main github repo, will squash all changes to say that whoever performs the sync (peterdietz) made the commit, and he made it just now. As opposed to attributing it to whoever did it in git / 2 weeks ago
[21:13] <PeterDietz> my last statement means that if you tried to sync github stuff down to svn, you'll lose author attribution of changes. No big loss, but I'm hoping we don't sync from github down to svn
[21:14] <tdonohue> All in all here, I'd really leave it up to the Mentors of each project. Although it seems like a good opportunity to try out Github for GSoC, I'll admit there may be some "pain points", so there's no requirement to do so
[21:14] <PeterDietz> @grahamtriggs: If we don't want stuff going into svn/modules/webmvc, then we ought to disable the sync task, and possibly delete the svn/module/webmvc
[21:14] <mdiggory> PeterDietz: I view those author attributions as very important...
[21:14] <grahamtriggs> So, I'm still not clear about how GitHub and the svn sync has been setup. So, simple question - if we move WebMVC development to GitHub, can we disable syncing for just WebMVC, and leave it in place for everything else?
[21:15] <mdiggory> I'm rather for get your project off the svn modules / sandbox space entirely and into git if you want to use git...
[21:16] <mdiggory> seems the safest and if its the case that git sucks and the whole experiment is a failure... put the code in the svn again...
[21:16] <tdonohue> grahamtriggs -- pretty sure the answer is "yes", but PeterDietz can verify. Sync processes are separate for 'dspace-trunk' and 'webmvc' (for example)
[21:16] <mdiggory> this may help with our classifying modules...
[21:17] <mdiggory> experimental in git.... supported mirrored off svn?
[21:18] <mdiggory> then whole "modules" directory becomes dedicated to supported modules....
[21:18] <mdiggory> I'm even willing to sort through all my work there to attain this...
[21:18] * tdonohue notes we are way over time here, but we should continue to hash out this Github discussion for GSoC next week, as needed. (But others are free to head out if you need to)
[21:19] <PeterDietz> (sorry, ran out for office pizza party)
[21:19] <tdonohue> mdiggory -- could be worth trying out. The big question though still becomes how to 'transition' an "experimental module" (in Git) to a "supported module" (in SVN /modules). it could be worth thinking about though
[21:20] <PeterDietz> sync per module / project is completely seperate cron job.
[21:20] <tdonohue> thanks PeterDietz -- that's what I thought :)
[21:20] <mdiggory> Are you volunteering to support those corns Peter?
[21:20] <PeterDietz> so even though in svn, its one really big repo, with many subfolders. They get converted into seperate git repositories (according to whatever breakdown we want)
[21:20] <PeterDietz> corn?
[21:20] <mdiggory> sorry "crons"
[21:21] <tdonohue> I too was wondering why mdiggory was talking about corn ;)
[21:21] <PeterDietz> I'm volunteering to migrate any projects to/fro svn and github
[21:21] <mdiggory> what happens to trunk/tag/branches in the git world?
[21:21] <PeterDietz> I can run the cron too, but I'm thinking of those as temporary
[21:22] <PeterDietz> so.. git svn clone http://path-to-svn/dspace/trunk looks around for standard layout of tags and branches folders
[21:23] <PeterDietz> it says that each directory in branches become a branch in git. and I'm not sure if it bothers with the tags. You might have to re-tag things.
[21:23] * vibhaj (7376e151@gateway/web/freenode/ip.115.118.225.81) Quit (Ping timeout: 252 seconds)
[21:23] <tdonohue> So, does everyone feel "ready" for GSoC to begin next week? Anything else pressing to discuss, please bring it up (either now or in coming days over duraspace-gsoc email)
[21:23] <PeterDietz> then you've got one big git repo with a bunch of branches/tags. And you can see them all in action at github: https://github.com/DSpace/DSpace
[21:23] <kompewter> [ DSpace/DSpace - GitHub ] - https://github.com/DSpace/DSpace
[21:24] * tdonohue is not trying to stop this Github discussion -- just want to make sure we stay "on topic" with things related to GSoC, as GSoC starts on May 24, next week
[21:24] * PeterDietz prefers to continue other important discussion. github seems like distraction from actually dialogging with students
[21:25] <grahamtriggs> PeterDietz (/ stuartlewis ): there's not been any commits to WebMVC - can we simply agree now to use GitHub, and stop the syncing cron?
[21:25] <mdiggory> I tend to think getting this ironed out is important...
[21:25] * vibhaj (0e61cfa0@gateway/web/freenode/ip.14.97.207.160) has joined #duraspace
[21:26] <mdiggory> the majority of the work I anticipate happening in module projects.
[21:26] <tdonohue> mdiggory -- ironing out how Github handles tags/branches, though important, doesn't seem as necessary to decide for GSoC. But, ironing out whether or not you are using GitHub is important for GSoC :)
[21:26] <mdiggory> moving a modules project to github and having it blow away all your tags would suck
[21:26] <stuartlewis> Yep - so for webmvc, github with (for now) no syncs, sounds sensible.
[21:27] <mdiggory> likewise, for other projects as well... we will need a Git primer for all mentors and students however...
[21:27] <PeterDietz> grahamtriggs: sure, webmvc will now use github solely. I'll stop the syncing (can be revived later I suppose). In meantime, no svn commits (for the foreseeable future).
[21:27] <grahamtriggs> PeterDietz: done
[21:28] <tdonohue> Git Primer (built by Fedora folks): https://wiki.duraspace.org/display/FCREPO/Working+with+Git
[21:28] <kompewter> [ Working with Git - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Working+with+Git
[21:28] <grahamtriggs> PeterDietz: can you ping me / stuartlewis when the syncing has been stopped?
[21:28] <tdonohue> (Note -- some of that primer is obviously Fedora specific -- but, there's lots of "how tos" for Git in there as well)
[21:28] <mdiggory> most excellent
[21:29] <mdiggory> we need an announcement to duraspace-gsoc list about all this...
[21:30] <tdonohue> I can send an announcement today/tomorrow to duraspace-gsoc about Using GitHub for DSpace GSoC + All-DSpace-GSoC meeting schedule (anything else I need to add to that?)
[21:32] <mdiggory> no that sounds good...
[21:33] <grahamtriggs> errmm... Peter, Stuart and I are happy to make this decision for WebMVC - but shouldn't this be a per-project decision for the mentors and students involved?
[21:33] <mdiggory> so.. the second question that is Git related.... when using maven-release-plugin.... how will it treat Git? forking/tagging?
[21:33] <tdonohue> Ok, anything else GSoC related? Does everyone feel "ready" enough to get started next week (obviously first few weeks may still need time to figure out exact scope for some projects)?
[21:34] <tdonohue> grahamtriggs -- oh, sorry, I misstated that. "Using Github for DSpace GSoC" part actually is *recommended*, but not required :)
[21:34] <scottatm> Sorry, comming a bit late :)
[21:34] <mdiggory> well, in this current chatroom... thats sorta me in three other cases...and scottatm in one... I'll clarify it with the other students...
[21:34] <tdonohue> so, grahamtriggs, you are correct, Github is a per-project decision for the mentors & students involved
[21:36] <mdiggory> gosh, lets just use the email in the duraspace-gsoc list to elicit viewpoint/feedback
[21:37] <PeterDietz> I've got an idea for what we've gotta do for webmvc project. Share the workflow with the student, and give them a few primer tasks to get started
[21:37] <tdonohue> yep. I'm fine with bringing stuff to duraspace-gsoc email. Anything else to decide now? or should we "close up" this extended meeting and move discussion to duraspace-gsoc?
[21:38] <mdiggory> PeterDietz: can we make that dialog in the duraspace-gsoc list so that others can ride on your coat-tails..
[21:39] <tdonohue> hearing nothing, I'm going to assume we are done here. Please bring final preparation comments & discussions to duraspace-gsoc. I'll also send a brief summary of this discussion to that list today/tomorrow to bring others in the loop
[21:40] <mdiggory> groovy man!
[21:40] <PeterDietz> yep, I'll post in the gsoc list/group.. cheers all.
[21:40] <tdonohue> cheers! have a good one
[21:41] <PeterDietz> grahamtriggs / stuartlewis: I've commented out the webmvc svn --> github sync task, thus svn is not being synced.
[21:41] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) Quit (Quit: Page closed)
[21:41] <stuartlewis> PeterDietz: Excellent, thanks
[21:41] <PeterDietz> mdiggory: If you have any modules projects that you want converted to github project, then let me know and I can perform the conversion
[21:41] <grahamtriggs> btw - IntelliJ 10.5 is out
[21:41] <PeterDietz> I think the process to do it is documented somewhere
[21:43] <mdiggory> thanks PeterDietz I'll get you a list...
[21:43] <PeterDietz> by documented, i mean that the process for converting is in a dspace-devel email: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg05813.html
[21:43] <kompewter> [ Re: [Dspace-devel] [Dspace-commit] DSpace Development Practices [was: Co ] - http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg05813.html
[21:48] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[21:49] <grahamtriggs> IntelliJ tip for GitHub - if you want to use the GitHub version control option, you need to go to GitHub and 'watch' the public repositories first
[21:51] * vibhaj (0e61cfa0@gateway/web/freenode/ip.14.97.207.160) has left #duraspace
[21:51] <grahamtriggs> except it won't clone the watched repository, as Intellij doesn't support https. So you have to fork it. :(
[21:54] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[21:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:56] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[21:56] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Client Quit)
[21:57] <mdiggory> grahamtriggs: that sucks
[22:23] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has left #duraspace
[22:28] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[22:42] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[23:42] * Disconnected.
[23:42] -barjavel.freenode.net- *** Looking up your hostname...
[23:42] -barjavel.freenode.net- *** Checking Ident
[23:42] -barjavel.freenode.net- *** Found your hostname
[23:42] -barjavel.freenode.net- *** No Ident response
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.