Timestamps are in GMT/BST.
[6:07] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[6:38] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[6:41] -card.freenode.net- *** Looking up your hostname...
[6:41] -card.freenode.net- *** Checking Ident
[6:41] -card.freenode.net- *** Found your hostname
[6:41] -card.freenode.net- *** No Ident response
[6:41] [frigg VERSION]
[6:41] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:41] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:41] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[8:42] * pvillega (~pvillega@86.47.50.67) has joined #duraspace
[12:09] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:15] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Ping timeout: 248 seconds)
[12:21] * Tonny_DK (~thl@130.226.36.117) Quit (Ping timeout: 245 seconds)
[12:28] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:35] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[13:03] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:19] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:32] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[13:56] * pvillega_ (~pvillega@62.77.170.185) has joined #duraspace
[13:59] * pvillega (~pvillega@86.47.50.67) Quit (Ping timeout: 245 seconds)
[14:14] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Read error: Operation timed out)
[14:32] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[15:55] * pvillega__ (~pvillega@86.47.50.67) has joined #duraspace
[15:58] * pvillega_ (~pvillega@62.77.170.185) Quit (Ping timeout: 276 seconds)
[16:18] * pvillega (~pvillega@86.47.50.67) has joined #duraspace
[16:22] * pvillega__ (~pvillega@86.47.50.67) Quit (Ping timeout: 276 seconds)
[16:39] * pvillega (~pvillega@86.47.50.67) Quit (Remote host closed the connection)
[19:02] * mary_bennett (868c9970@gateway/web/freenode/ip.134.140.153.112) has joined #duraspace
[19:08] * robint (52292565@gateway/web/freenode/ip.82.41.37.101) has joined #duraspace
[19:13] * mary_bennett_ (868c9970@gateway/web/freenode/ip.134.140.153.112) has joined #duraspace
[19:14] * mary_bennett_ (868c9970@gateway/web/freenode/ip.134.140.153.112) Quit (Client Quit)
[19:16] * mary_bennett (868c9970@gateway/web/freenode/ip.134.140.153.112) Quit (Quit: Page closed)
[19:16] * mary_bennett (868c9970@gateway/web/freenode/ip.134.140.153.112) has joined #duraspace
[19:22] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[19:27] * robint (52292565@gateway/web/freenode/ip.82.41.37.101) Quit (Ping timeout: 252 seconds)
[19:33] * pvillega (~pvillega@89.100.155.181) has joined #duraspace
[19:40] * kgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[19:53] * hardy_pottinger (80ce8605@gateway/web/freenode/ip.128.206.134.5) has joined #duraspace
[19:54] <tdonohue> Hi all -- DSpace Devel Mtg will be starting up here in about 5 min. Today we have a special topic meeting, see agenda: https://wiki.duraspace.org/pages/viewpage.action?pageId=22020598
[19:55] * JoseBlanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[20:00] * robint (52292565@gateway/web/freenode/ip.82.41.37.101) has joined #duraspace
[20:00] <tdonohue> Hi All, so today's DSpace Devel meeting is devoted to discussion of GSoC projects, and how best to start to merge some of them into our main codebase (Trunk) in preparation for DSpace 1.7. See agenda -- https://wiki.duraspace.org/pages/viewpage.action?pageId=22020598
[20:01] <tdonohue> In addition, last week we came up with several options to handle these student projects (and merging in code, etc) -- these are on this proposal page: https://wiki.duraspace.org/display/DSPACE/Managing+Release+and+Integration+Cycles
[20:02] <tdonohue> essentially, the big questions are how/when we'd like to begin these merges -- mdiggory proposed last week that we ask the students to perform the merges (as necessary) into our Trunk codebase.
[20:03] <tdonohue> mdiggory, is there more background/intro you'd like to add? (although I think most of us, though not all, were also here last week)
[20:03] <mdiggory> I suspect that we will want to be more specific concerning the projects... Some make sense to go into trunk, others still do not.
[20:04] <tdonohue> definitely-- so, which do we see as "trunk-ready"? Here's the full list for everyone: https://wiki.duraspace.org/display/DSPACE/Google+Summer+of+Code
[20:04] <mdiggory> I believe we should be looking at the testing and rest projects as primary candidates at this time
[20:05] <tdonohue> sounds good -- I know stuartlewis also recommended the Unit testing project, and the REST project seems logical as well to me
[20:07] <grahamtriggs> I have a number of concerns about the REST project - firstly, the proposal about DSpace/Fedora was about reducing redundancy. Committing to supporting [another] rest interface right now is very contrary to that goal.
[20:07] <mhwood> They also sound on the surface like projects that wouldn't have thousands of tentacles brushing other parts of the code. Good for anyone who is concerned about integrating them.
[20:08] <mdiggory> grahamtriggs: that rest interface does something very different than the fedora one
[20:08] <tdonohue> mhwood -- yes, I agree, they seem less intrusive overall, and will likely not conflict with each other too much
[20:09] <grahamtriggs> secondly, I've only briefly scanned the commits, but the code where it is getting stack traces and using it to determine if there is a loop seems rather scary, and is pointing to a flawed designed
[20:09] <mdiggory> grahamtriggs: we need that sort of feedback.
[20:09] <pvillega> (hi, sorry for the delay!)
[20:09] <snail> i would like to suggest that https://wiki.duraspace.org/display/DSPACE/GSOC10+-+Add+Unit+Testing+to+Dspace be prioritised for merging if possible, since it may catch collateral damage from the merging of other projects.
[20:10] <mdiggory> thats the point of threatening to commit it to trunk ;-)
[20:10] <tdonohue> grahamtriggs -- I also see the REST interfaces as being entirely different.... Even in the future, I think DSpace will likely need its own REST interface to handle some of the 'workflow' tasks, etc. which are not a part of Fedora (as you are well aware, DSpace and Fedora are quite different systems)
[20:10] <grahamtriggs> I do think the unit testing is looking a strong candidate for committing to trunk... although....
[20:12] <grahamtriggs> the point Stuart made about catching a bug in the code - whilst valid - that's a bug that could have been caught by static analysis, and we have a lot of other potential quick wins from static analysis without relying on unit tests that may in themselves be flawed
[20:12] <pvillega> if I may, before adding the project I would like it to be reviewed by the community, as some parts can be imporoved
[20:12] <grahamtriggs> (not saying that the unit tests are faulty, just recognising the equal potential to code a bug into the unit test as there is to write one in the code being tested)
[20:12] <snail> grahamtriggs: i take your point
[20:12] <tdonohue> hi pvillega
[20:13] <pvillega> hi everybody :)
[20:13] <tdonohue> grahamtriggs -- I also see your point.... and obviously pvillega is asking for more feedback on the code he's built
[20:13] <grahamtriggs> tdonohue: maybe - or maybe more workflow-y stuff gets pushed into Fedora to support Islandora / Hydra
[20:14] * bojans (~Bojmen@91.119.5.170) has joined #duraspace
[20:14] <bojans> join #dspace
[20:15] <tdonohue> grahamtriggs -- I'd highly doubt we'll see much of the 'workflow-y' stuff going down to the level of Fedora -- that doesn't seem to be a goal of theirs -- they are not trying to build an out-of-the-box IR system (with various pre-built workflows, etc). But, I take your point -- if there is that much duplication between the REST interfaces, then we don't need 2. However, at this point, there's almost no duplication between them
[20:16] <mdiggory> sorry, finishing up a call, I'm 100% here now
[20:16] <mdiggory> IMO, it does not hurt to have similar projects going in both spaces.
[20:17] <mdiggory> It identifies the overlapting areas.
[20:17] <tdonohue> i'd agree mdiggory -- I think it helps in the long run (to build a better REST interface in both cases)
[20:17] <mdiggory> Remember that Fedora Inside is not Fedora always inside
[20:18] <snail> mdiggory: care to expand on that last comment?
[20:18] <tdonohue> correct -- "Fedora Inside" is defined as "Fedora optionally Inside" (at least initially) -- the acceptance of it will help us to determine if that option is the default option or not
[20:18] <mhwood> More like "Fedora snaps onto the bottom, alongside X, Y, and Z?"
[20:19] <tdonohue> so, initially, the "Fedora Inside" idea is seen as one of the *options* when you would install DSpace -- there may still be other storage options available
[20:19] <mdiggory> snail: the point is that having fedora as a storage solution is an option, not a requirement
[20:19] <snail> mdiggory: oh yes. i understand now.
[20:21] <tdonohue> ok -- so, back to GSoC -- it sounds like there is more general "acceptance" of the Unit Test project (though some concerns are still noted, and pvillega would like more feedback). Do we want to make a decision on this project first?
[20:21] <mdiggory> the topic of discussion here is about our own SCM management and commit rights
[20:22] <tdonohue> mdiggory, but don't we need to keep that in context of GSoC, as it is ending soon?
[20:22] <pvillega> tdonohue - I think if people review the code, specially failing tests (like DCDate) the project should be ready to go. I have to add a sample of an integration test but that should be ready before the weekend.
[20:23] <mdiggory> Yes, but the question is really, can we accept alteration of our policies (or conversely voting in students to commit on trunk)
[20:24] <robint> mdiggory: But we could take this as a test case for more liberal commit rights.
[20:24] <tdonohue> yea, I was trying to tease out first which projects would be the "test case" (as robint says), so that we can then decide *how* we would want to alter our policies or vote
[20:25] <mdiggory> robint: quite true, actually I take what is happening here now as the first real case of discussing the addition of commiters publicly... which IMO, will lead to what your also wanting
[20:26] <mdiggory> pvillega is not a good posterchild for GSoC however, given his status within a company that is vested into DSpace
[20:27] <kshepherd> ?
[20:27] <snail> i thinking routinely adding GSoC stduents as commiters is probably a bad thing
[20:27] <mdiggory> snail: we have fine grained commit privileges for a reason
[20:28] <mdiggory> we can control exactly what code can be commited to and for how long
[20:28] <tdonohue> ok -- i think things are getting muddied here... there's no proposal to add GSoC students as full fledged "committers". Though they do have "commit" rights to a very specific area of our SVN (which is the "sandbox" area)
[20:29] <mdiggory> yes true a little muddied...
[20:30] <pvillega> mdiggory that would not be a problem, professional work and GSoC are different things. Anyway, I beleive I would not be the only one in that situation. But if it has to make somebody unconfortable, maybe Stuart can do the merging
[20:30] <tdonohue> what's at question here is the following: (1) Which projects (if any) do we work to get into Trunk for 1.7? (2) Assuming there are projects, do we vote to temporarily give the students full commit rights to Trunk (to be reverted after GSoC)? (3) Do any of our normal Committer policies need to be changed if we vote to do #2?
[20:31] <kshepherd> the alternative to trunk commit rights we discussed was to make a branch for all the GSoC developments that were to make it into trunk (eg. REST + Unit Testing), that can be tested and then merged back in later
[20:31] <mdiggory> pvillega: actuall, what I mean is the opposite, your more of a candidate to have stick around than a steriotypical gsoc student that is doing a summer project.
[20:31] <mhwood> Could the mentor "sponsor" (or not) his student's access to trunk? "Sponsor" meaning, "I think the code is good, I think the student knows his way around the SCM, and I'll help clean up if I was mistaken."
[20:31] <tdonohue> mhwood -- that's a nice idea, I like that
[20:31] <pvillega> mdiggory ok, I misunderstood you :)
[20:31] <pvillega> mhwood I think it makes sense
[20:32] <tdonohue> kshepherd: yes, that was another option -- we could let the students merge code into a Branch, and then move that Branch into Trunk once it is stable/ready
[20:32] <mdiggory> mhwood: I would expect that
[20:32] <mhwood> I like having multiple streams to compare, whenever big projects go in.
[20:32] <kshepherd> it might also be worth noting that trunk is very static these days..
[20:32] <kshepherd> so should make for easy merging
[20:32] * tdonohue thinks trunk may not be static much longer... :)
[20:33] * mdiggory hopes that trunk will not be static much longer.
[20:33] * tdonohue knows trunk will not be static much longer (I'm preparing code now)
[20:34] <tdonohue> so -- the downside of the separate branch is that it would need to be merged back to trunk quickly (while things are still relatively static, and before the flurry of activity around 1.7 gets going)
[20:35] <mdiggory> yes, where I would rather like to take projects that have good progress and get them in place to be the basis for that change
[20:35] <mdiggory> and testing is paramount for being able to verify the trunk even in a state of flux
[20:36] <mdiggory> testing will tell us when its broken, not break it
[20:36] <tdonohue> ok -- So, there seems to be a general consensus that the Testing project is good to get in (although pvillega wants more review from one or more committers)
[20:37] <tdonohue> Do we have anyone who will volunteer to take a closer look at the Testing project as it stands, and give us your thoughts (ideally in the next week)?
[20:37] <mhwood> I think so.
[20:37] * mdiggory would like to see that review happen on trunk
[20:37] <tdonohue> The alternative is to have that review on Trunk as mdiggory suggests :)
[20:37] <pvillega> yes. If possible, I would like: (a) review of the test for DCDate and (b) review (in general) of the tests/code/infrastructure built
[20:39] <tdonohue> So -- the DCDate code I know is being looked into for other issues -- I believe robint is looking at it (or was)?
[20:40] <robint> Yes. Kind of stalled but I will pick it up again. I'll look at the test as well.
[20:40] <mdiggory> pvillega: can you toss in some links/pointers to the unit tests
[20:40] <tdonohue> the implication there is that perhaps it would just be best to get that DCDate tests into Trunk, so that the others looking at DCDate changes can utilize it
[20:40] <tdonohue> (and fix it if necessary)
[20:40] <robint> I think it more likely that DCDate is broken than the test.
[20:41] <mdiggory> ;-) no doubt
[20:42] <pvillega> mdiggory on the tests, I created a project (dspace-test) where all unit and integration tests are stored. There is one base class (AbstractUnitTest) that creates the environment required for the tests. This includes a temporal filesystem and an in-memory database.
[20:42] <tdonohue> ok -- so, let's bring this to some sort of vote: All those in favor of having pvillega commit his "ready" Unit Testing code (with sponsorship from Stuart Lewis) to Trunk before the end of GSoC?
[20:42] <pvillega> There are 2 other classes (AbstractIntegrationTEsts and DSpaceObjectTest) that can be used to create specific tests by inheriting
[20:43] <mdiggory> Looking more for...
[20:43] <mhwood> +1
[20:43] <mdiggory> http://fisheye3.atlassian.com/committer/dspace/pvillega
[20:43] <grahamtriggs> well, really we have one major piece of untangling there to remove all the DC* code, and just work from the base metadata structures
[20:44] <mdiggory> http://fisheye3.atlassian.com/changelog/dspace/sandbox/gsoc/2010/testing
[20:44] <pvillega> oh ok :P
[20:44] <kshepherd> are we all still talking about the same thing?
[20:44] <kshepherd> if so, +1 to unit testing
[20:44] <mdiggory> http://fisheye3.atlassian.com/browse/dspace/sandbox/gsoc/2010/testing/dspace-test/src/test/java/org/dspace/content/DCDateTest.java?r=HEAD
[20:44] <kshepherd> if not, +0 for now
[20:45] <snail> +1 to unit testing
[20:45] <grahamtriggs> It's alright kshepherd - we weren't voting on whether you have to do the work
[20:45] <kshepherd> lol
[20:45] <grahamtriggs> we were just going to volunteer you regardless
[20:46] <mdiggory> http://fisheye3.atlassian.com/browse/dspace/sandbox/gsoc/2010/testing/dspace-test/src/test/java/org/dspace/AbstractUnitTest.java?r=HEAD
[20:46] <tdonohue> VOTE (+2 so far): All those in favor of having pvillega commit his "ready" Unit Testing code (with sponsorship from Stuart Lewis) to Trunk before the end of GSoC?
[20:46] <tdonohue> (kshepherd -- were you voting for that or not?)
[20:46] <mdiggory> +1
[20:46] <mhwood> Since there is a deadline for GSOC, I think it is okay to have a couple of tests that are not quite ready, if they are clearly marked so. Especially if the object of the test is in flux.
[20:46] <kshepherd> tdonohue: yep, that's my +1
[20:46] <mhwood> We want the tests, but we *need* the framework.
[20:46] <kshepherd> tdonohue: and i volunteer grahamtriggs for all related administrative duties
[20:47] <kgilbertson> +1 in favor of pvillega commiting to trunk
[20:47] <robint> tdonohue: +1 to unit testing
[20:47] <mdiggory> grahamtriggs as admin.... hear hear
[20:47] <tdonohue> ok -- vote is at +6 to add Unit Testing to Trunk
[20:48] <tdonohue> grahamtriggs, did you have a vote, or are you abstaining?
[20:48] <grahamtriggs> I'm +1 on unit testing
[20:48] <tdonohue> ok -- Final Vote is +7 -- Unit Testing will be added to Trunk
[20:49] <tdonohue> Did we want to touch back on REST (before meeting is over)? mdiggory, was the proposal to add this to Trunk or as a separate "module"?
[20:49] <kshepherd> we assume stuart will be happy with this ;)
[20:49] * kshepherd hasn't looked at the REST project at all yet, must get onto that :/
[20:49] <mdiggory> so, should we be careful about voting in IRC and not the email list?
[20:50] <kshepherd> mdiggory: which email list?
[20:50] <mdiggory> dspace-dev
[20:50] <pvillega> kshepherd he will hehe
[20:50] <tdonohue> mdiggory -- we notified everyone in advance of this meeting and I can always post a summary back to dspace-dev for comments/additional voting (But i see no reason to re-vote there)
[20:51] <kshepherd> mdiggory: guess it might depend how quickly a decision needs to be made? dspace-devel probably opens things up a bit better, but you'd probably have to give 7 days or so for voting
[20:51] <mdiggory> sounds good tdonohue
[20:51] <kshepherd> as long as everyone knows these weekly meetings happen and logs keep getting posted, at least it's transparent
[20:52] <mdiggory> Ok, we need to talk about REST next
[20:52] <mdiggory> and that possibly brings up more topics around modules revisioning and async releases
[20:53] * tdonohue notes the time -- we cannot dig too deep here if we want to make a decision today
[20:53] <mdiggory> Because I would view the addition of the REST project as going in the opposite direction we are talking about going with those.
[20:53] <mdiggory> IE trying to breakout applications into separate projects.
[20:53] <mdiggory> and async releases
[20:55] <tdonohue> mdiggory -- so what's the proposal for the REST interface -- would it be added to trunk? or to the "modules" area?
[20:55] <mdiggory> ok so tdonohue perhaps we ask ourselves that if we have a currently working sync versioning strategy. Do we push rest into that and treat it like the others until the appropriate path is visible to asyn releases
[20:55] <snail> i'll abstain from the REST discussion and vote, since I know too little about it (and don't have time to get up to speed)
[20:55] <pvillega> tdonohue - in fact I should get going. robint - contact me if you have any question regarding the dcdate tests ok?
[20:55] <robint> pvillega: will do. cheers
[20:56] <pvillega> cheers all, talk again soon :)
[20:56] * pvillega (~pvillega@89.100.155.181) Quit (Remote host closed the connection)
[20:57] <mdiggory> tdonohue: that is part of the issue, given a dependency on DSpace api and a continued sync releasing, if you want dspace-rest as part of the distribution, it has to go into trunk
[20:57] <grahamtriggs> Practically, I think it needs to be part of the sync release process to reach users - but, I'm not prepared to commit to supporting the rest interface at this stage
[20:57] <mhwood> Is it possible that some modular features will be more amenable to async. release than others?
[20:57] <kshepherd> i quite like the idea of async releases for modules, but i'm not sure how to gauge community uptake..
[20:58] <mdiggory> there are parts of the async process that still need to be worked out.
[20:58] <kshepherd> and we've been able to release language packs asynchronously for a while now (correct me if wrong) but it hasn't really taken off..
[20:58] <kshepherd> (that might just reflect a lack of work on language packs though ;))
[20:58] <mdiggory> At this time async release requires adding in maven build process if you want them in your disto
[20:59] <tdonohue> so -- if it helps, we can add 'async releases' / modules to agenda for next week (and/or do another special topic meeting in a few weeks devoted to it)
[20:59] <mdiggory> kshepherd: that a need more than a feature
[20:59] <mdiggory> most folks do not get that every time they rebuild reguardless of the distro they are using, new i18n modules are looked for
[21:00] <mdiggory> so 1.6.x.x release of i18n should be happening now, but we havn't the resources to keep the releases happening. (either CI or human)
[21:00] <kshepherd> true
[21:00] <mhwood> Aha, languages are one of the things which can be modular but which I think should release along with the core when possible. "DSpace 2.3 is released, but it won't work in French or Urdu." Yuck.
[21:01] <mdiggory> but the translation happens afterward mhwood
[21:01] <mhwood> Why?
[21:01] * tdonohue notes we're over time here -- no decision on REST for now
[21:01] <mdiggory> and I'm not at all for stalling a release for i18n completness.
[21:02] <mdiggory> talk about a scheduled release cycle buzz kill
[21:02] <tdonohue> mhwood -- translation happens after a release cause often the messages files are being changed during testathons/etc (and not all the translators can update right away)
[21:02] <mhwood> If we had a good way to highlight changes in the message catalog keys, so that translators can readily know what needs doing, then they can work right along with the rest.
[21:02] * JoseBlanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) Quit (Quit: Page closed)
[21:03] <mdiggory> mhwood: I am dealling with a similar issue right now
[21:04] <tdonohue> mdiggory, you never gave a proposal for REST to vote on -- is this something we should discuss either via email or next week?
[21:04] <kshepherd> yeah, claudia and i were trying to think of ways to manage collaboration around i18n for dspace a while back
[21:04] <kshepherd> but we didn't really get anywhere :(
[21:04] <mdiggory> kshepherd: I have but one response... database
[21:05] <kshepherd> mdiggory: sure.. it's more the interface that's the problem, not storage
[21:05] <mdiggory> tdonohue: given the time we need to push to next week I think
[21:06] * tdonohue if anyone needs to head out feel free -- we're well over time -- but, I'll stick around a bit
[21:06] <mdiggory> I think we should discuss it in the next 45 minute though in relation to the GSoC meeting time
[21:06] <robint> I would welcome any discussion on modularity etc on the mailing lists
[21:06] * kshepherd has a (probably silly) solr search question as well, if that's not too offtopic :)
[21:06] <tdonohue> mdiggory -- ok, I can hang around for a while to brainstorm on REST, etc.
[21:07] <mhwood> I will heave out one more thought and then I have to go: having a 1.7 Swahili language pack (for example) that is 95% ready at release is better than having none.
[21:08] <kshepherd> +1 for mhwood as Swahili i18n maintainer
[21:08] <tdonohue> wow, i didn't know mhwood knew Swahili
[21:08] <mhwood> He doesn't.
[21:09] <tdonohue> yea, but the key to the translations is actually finding the translator to maintain it :)
[21:11] <mhwood> Are there people who have committed to *maintaining* translations?
[21:11] <kshepherd> no
[21:11] <tdonohue> not really -- that's the bigger problem
[21:11] <kshepherd> it all gets dumped on Claudia
[21:11] <kshepherd> that is 99% of the problem
[21:12] <tdonohue> that's another reason why DSpace is often released with little or not translations -- initially it's just Claudia, and then other people translate as they upgrade and notice the issues
[21:12] <mhwood> Call for volunteers. Your name on the page of "special thanks to the following for keeping our translations up-to-date."
[21:13] <mhwood> Tools to help notice the issues is what maintainers will need.
[21:13] <kshepherd> yep.. i think this would be a grea meeting topic some time as well
[21:13] <kshepherd> great*
[21:13] <tdonohue> tools will probably help with volunteers (make it easier and it may not be such a big deal overall) -- but, tools need development (obviously), and that also takes a volunteer or two
[21:14] <mhwood> OK, will save my ranting for that meeting -- gotta go now anyway.
[21:14] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:15] <tdonohue> mdiggory -- did you say you wanted to brainstorm more on REST now? or just leave it all to next week (I can add to agenda, obviously)?
[21:15] <mdiggory> ok I'm back, needed to take 5
[21:15] <mdiggory> ok, my thoughts/concerns have more to do with how are modules installed into DSpace...
[21:16] <mdiggory> right now we have to utilize a build process to attain this.
[21:17] <tdonohue> ok -- so what are your thoughts then
[21:17] <mdiggory> One option to avoid worrying about if a modules is "endorsed" or not, is to focus on making that process easier
[21:17] <mdiggory> One example might be to create a number of maven archetypes that assist in the installation of new modules
[21:18] <mdiggory> This actually something that was started back around the time of the maven adoption
[21:18] <mdiggory> http://scm.dspace.org/svn/repo/tools/maven/
[21:19] <mdiggory> I sense that eventually this might allow for installing modules into runtime dspace instances
[21:20] <tdonohue> so, essentially installing modules via commandline, I assume?
[21:22] <mdiggory> By the point we get there... OSGi become more interesting
[21:23] <mdiggory> but for now, I'm talking about something more akin to maven pom alteration
[21:23] <mdiggory> for instance, installing dspace-rest as a module might look like:
[21:24] <mdiggory> mvn dspace:install-rest
[21:25] <mdiggory> run within the the dspace/modules directory
[21:25] <mdiggory> it would create a overlay project for "rest" add it to the modules/pom.xml
[21:26] <tdonohue> hmm...liking that general idea so far
[21:26] <mdiggory> the dspace:xxxxxxx namespace for installing would be the dspace means of "endorsing" an addon module
[21:27] <mdiggory> this would break the cycle we are encountering in trying to do releases that include modules maintained externally
[21:28] <kshepherd> sounds pretty good to me
[21:28] <mdiggory> it might even be the case that this be utilized during the assembly process so that module sources are then not part of the distribution, but downloaded separately based on the selection of choices
[21:28] <tdonohue> right --plus it lets us ship a release with less interfaces overall (or give you the option of "selecting" which ones you want, perhaps)
[21:29] <mdiggory> mvn dspace:assemble-core -Dfrom-source=true
[21:29] <mdiggory> mvn dspace:assemble -Dmodules=xmlui,oai,rest
[21:30] <tdonohue> I'm thinking of a day where you could run an 'easy installer': "dspace install" , and it asks "Which interfaces do you want?" and lets you select from a list of "endorsed" options (XMLUI, JSPUI, OAI, SWORD, LNI, REST, SOLR, etc)
[21:30] <tdonohue> (that easy installer obviously could just wrap the appropriate 'mvn' calls)
[21:31] <mdiggory> at this point we only use ant because we need to move a bunch of files around to custom locations. But a maven achetype plugin could provide similar capabilties
[21:32] <tdonohue> and i like that idea as well -- I hate that we still need both maven and ant
[21:33] <tdonohue> mdiggory -- so, do you have time to devote to this to try and prove it out a bit more? Or, is this something you are just throwing out the idea for and hoping someone else will take lead on?
[21:33] <mdiggory> there are many approaches possible with the tooling
[21:34] <mdiggory> I'm hoping for someone else to bite on it.
[21:34] <mdiggory> I did do initial prototyping some time ago, but the work never came to fruition
[21:35] <tdonohue> so, how can we promote this to others than? (Although I'm interested, I'm really devoted towards the AIP work in the nearterm to get that into 1.7)
[21:35] <mdiggory> http://maven.apache.org/guides/mini/guide-creating-archetypes.html
[21:35] <mdiggory> A wiki page and a announcement on the topic might help
[21:36] <tdonohue> can you write that up on wiki -- since you know this best, and understand what we could be doing with archetypes
[21:37] <mdiggory> Somewhere in my crazy day.... yes
[21:38] <tdonohue> i'd really appreciate it (doesn't have to be today -- but maybe soonish, in next week or so). I like this idea, and it'd be good to find someone who is interested in helping on it
[21:38] <mdiggory> theres always lots of examples of project initialization on teh web already
[21:38] <mdiggory> http://www.grails.org/Maven+Integration
[21:39] <mdiggory> http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-application-archetype.html
[21:39] <mdiggory> http://answers.oreilly.com/topic/258-how-to-create-a-new-maven-project-from-the-command-line/
[21:39] <robint> Got to run but I enjoyed this topic, very interesting. Cheers.
[21:40] <mdiggory> http://www.sonatype.com/books/mvnref-book/reference/archetypes.html
[21:40] * robint (52292565@gateway/web/freenode/ip.82.41.37.101) Quit (Quit: Page closed)
[21:40] <tdonohue> well -- hopefully that can get someone interested -- good links to include on the wiki page
[21:41] <mdiggory> ok... I'm moving this into the wiki...
[21:41] <tdonohue> good :)
[21:41] <mdiggory> we are still going roundabout on the other projects, but at this time, they are still looking to not be in the trunk afaict
[21:43] <tdonohue> right -- the other GSoC projects -- yea, I assumed as much -- they all seem like great wok, but we aren't quite ready for them yet (hopefully though they will be of great use in the future -- especially with the "Fedora Inside" project)
[21:48] * kgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: cupcake happy hour : /)
[21:50] <mdiggory> yes, bridging the divide between dspace2 and dspace1 is a rather challenging
[21:53] * hardy_pottinger (80ce8605@gateway/web/freenode/ip.128.206.134.5) has left #duraspace
[22:03] * bojans (~Bojmen@91.119.5.170) Quit (Remote host closed the connection)
[22:06] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:23] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[23:22] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.