Timestamps are in GMT/BST.
[6:28] -hitchcock.freenode.net- *** Looking up your hostname...
[6:28] -hitchcock.freenode.net- *** Checking Ident
[6:28] -hitchcock.freenode.net- *** Found your hostname
[6:28] -hitchcock.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:06] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:15] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:36] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[14:39] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:48] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[17:28] * vtkeithg (~vtkeithg@2001:468:c80:a103:41e7:ca94:54ec:46d6) has joined #duraspace
[17:41] * hpottinger is now known as Guest40433
[18:36] * Guest40433 (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[18:36] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:00] * sands (~sandsfish@18.189.87.190) has joined #duraspace
[19:30] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:47] <tdonohue> Hi all, reminder we have a DSpace Developers Meeting starting at the top of the hour : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-11
[19:51] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome to our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-11
[20:01] * tdonohue notices it looks like kompewter is absent today... not sure if PeterDie_ is around or not. But, we can do without it for now
[20:01] <tdonohue> First up, we'll do some JIRA reviews: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-976+ORDER+BY+key+ASC
[20:01] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:01] <tdonohue> beginning with DS-976 (just in time, kompewter!)
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-976 ] - [#DS-976] Simple Asynchronous Add-on Facility for DSpace - DuraSpace JIRA
[20:02] <tdonohue> oh, this is one of those large "placeholders". Not sure where this stands right now, but probably would require a larger meeting to discuss
[20:02] <sands> Richard is away from the meeting today. I can mention it to him for status.
[20:03] <tdonohue> ok, thanks sands. Yea, would be good to know if this is still an idea he is trying to pursue or not
[20:03] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:03] <tdonohue> ok, we'll move along to the next one for now. DS-977
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-977 ] - [#DS-977] Problem in new user registration Dspace 1.7.2 - DuraSpace JIRA
[20:04] <tdonohue> looks like this one should have been posted to dspace-tech. Sounds like a config/setup error, and not a bug
[20:04] * PeterDie_ is now known as PeterDietz
[20:04] <mhwood> Looks like a configuration problem.
[20:05] <tdonohue> I have a "template" that I can paste into this issue to close it & recommend that more info/questions be posted to dspace-tech
[20:05] <tdonohue> assign Ds-977 to tdonohue for closing
[20:05] <tdonohue> next up, DS-981
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-981 ] - [#DS-981] Created a DSpace API module to contain api changes - DuraSpace JIRA
[20:06] <tdonohue> oh, I remember this one....about creating a new [dspace]/modules/api/ folder for API overlays.
[20:08] <KevinVdV> It appears my patch is a bit out of date
[20:08] <tdonohue> anyone have thoughts/opinions on this idea? does this seem useful to others?
[20:08] <sands> seems like a reasonable and non-disruptive change.
[20:08] <PeterDietz> ohh, I haven't seen this.. When I was following the module overlay method, this would have been very useful to be in there.
[20:09] * ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) has joined #duraspace
[20:09] <hpottinger> I think having a clear place to override API stuff would be great, and +1 PeterDeitz
[20:09] <KevinVdV> Well the thought behind it is that it would be nice general place to place all dspace-api code changes
[20:09] <PeterDietz> (I've since switched to not following module overlays), but I would be supportive of this
[20:09] <mdiggory> hello, Kevin just kicked me to wake me back up.
[20:10] <mhwood> 0, I don't use overlays but the proposal seems sensible.
[20:10] <tdonohue> The only (very slight) concern I have is that technically this doesn't "overlay" the full dspace-api (in that I don't think it lets you overlay the dspace-api.jar in [dspace]/lib/ used for command-line). But, I still like the idea of putting API changes in one place so that they are inherited by all webapps
[20:11] <mdiggory> correct, it is a place to put customized addon code.
[20:11] <tdonohue> so, that's more of an "advertising" concern. We just need to be very clear about where code/files placed in [dspace]/modules/api/ ends up.
[20:12] <aschweer> tdonohue: that would cause problems with custom embargo lifters and the like, wouldn't it? definitely something to advertise then
[20:13] <tdonohue> one last question: should it then be called something besides "api"? Is the name [dspace]/modules/api/ OK, or should it be named something else? (I'm on the fence here)
[20:13] <mdiggory> I think the general point here that is of concern is... when you create custom addons that are just for your local use, you either need to create this kind of project to share them across the webapps, or dump your code into dspace-api
[20:14] <mhwood> [dspace]/modules/global ?
[20:14] <mdiggory> the objective of the api project is to make it so that implementers don't need to edit poms to get simple java code into lib and webapps.
[20:14] <PeterDietz> I would say changes that I make to dspace-api, are generally overall improvements that we ought to contribute back upstream, so hopefully they don't dangle as modifications for too long
[20:15] <tdonohue> mdiggory -- totally agree with the reasons behind this. I think it's a good addition. I'm just questioning whether the name "api" would make people assume they are also updating "dspace-api.jar" in [dspace]/lib/
[20:15] <mdiggory> is it a better practice to package your own changes and classify them accordingly modules/addon1 modules/addon2.... or promote putting all in one modules.
[20:15] <sands> would calling it dspace-api be a more descriptive name?
[20:16] <sands> it seems worth including to me, as one doesn't have to use it if their practice doesn't agree with it. it's a minor addition for some extensibility it sounds like some will use.
[20:16] <mdiggory> PeterDietz: yes in that case I'm in agreement with putting them there, but for the average non-developer, having a spot like this is good to save them pain.
[20:16] <mdiggory> I want to caution, it is not an overlay of dspace-api.jar, it is a separate jar
[20:16] <mdiggory> called api.jar
[20:17] <tdonohue> I think my main point here is that we just need to be clear that code/files placed in [dspace]/modules/api/ does not end up in the same place as code in [dspace-src]/dspace-api/ So, we should avoid that misconception if possible.
[20:17] <mdiggory> you cannot overlay jars.
[20:17] <tdonohue> mdiggory -- exactly. that's why I worry the name "api" is too close to "dspace-api"
[20:17] <PeterDietz> note: your overlay jar has to be alphabetically before what it overrides
[20:17] <KevinVdV> What do you propose as a name then tdonohue ?
[20:17] <mhwood> local-api ?
[20:17] <sands> api doesn't rub me the wrong way. it seems relatively consistent with other module naming schemes.
[20:18] <mhwood> aaa-local-api ?
[20:18] <mdiggory> the choice of "api" is also because of a benefit in classpath ordering, you can copy and override dspace-api, jspui-api, xmlui-api classes in that manner
[20:18] <tdonohue> ugh, I forgot about that whole alphabetic stuff.
[20:18] <hpottinger> mhwood: aaa-local-dspace-api
[20:19] <tdonohue> maybe "api" is the best we can do afterall. We can just be clear about what it is and is not doing
[20:19] <PeterDietz> if our core stuff is all in dspace-api, then it logically makes sense for the module overlay to be api
[20:19] <mdiggory> PeterDietz: its not an overlay :-P
[20:19] <tdonohue> PeterDietz -- the point there though is that what you said isn't fully "true". [dspace]/module/api is NOT an overlay of dspace-api
[20:20] <PeterDietz> .rmpoint mdiggory
[20:20] <kompewter> PeterDietz: I'm sorry, but I'm afraid I can't do that!
[20:20] <tdonohue> instead, [dspace]/module/api/ is just a new "empty" module, which lets you create your own custom API code that will be shared across all Webapps (but won't end up in [dspace]/lib/)
[20:20] * helix84 (a@195.113.97.174) has joined #duraspace
[20:20] <mdiggory> "Sorry Dave, I can't do that."
[20:21] <aschweer> "all-webapps"?
[20:21] <tdonohue> so, as mdiggory says, it's not a "true" overlay. It's something different
[20:21] <KevinVdV> Second tdonohue it SHOULD end up in dspace/lib
[20:21] <aschweer> KevinVdV +1
[20:21] <KevinVdV> Because else your command line would use different code as your webapp
[20:21] <tdonohue> but, it doesn't end up in [dspace]/lib/ right now (in these patches)? Or did I misunderstand?
[20:22] <aschweer> KevinVdV ... which would get interesting if xmlui finds your curation tasks but the command line doesn't
[20:22] <mdiggory> theres one more benefit to to the jar module, if it is a dependency of all webapps and dspace/lib, you can just add new dependencies for all projects in it as a single edit
[20:23] <mdiggory> dspace-additions
[20:23] <tdonohue> ok. so, maybe I'm wrong here. Does this "api.jar" end up in [dspace]/lib as well as all Webapps? If so, then this all seems fine to me and I'll just shut up now ;)
[20:24] <mdiggory> comes before dspace-api
[20:24] <KevinVdV> It WILL end up in the [dspace]/lib
[20:24] <mdiggory> then just call it dspace/modules/additions for directory name
[20:25] <tdonohue> ok. that wasn't clear to me. I withdraw my complaint then. I'm fine if this is called "api"....we'll just be clear that it's creating a new "api.jar" that is separate from the default "dspace-api.jar"
[20:25] <sands> +1
[20:25] <tdonohue> so, I'm +1 this addition as well
[20:26] <tdonohue> (just needs some corresponding documentation, obviously)
[20:26] <KevinVdV> Allrighty I'll prepare a new patch & contribute in the near future
[20:26] <mhwood> We need to note somewhere that everything that comes with DSpace must begin with "dspace-" (or, at least, something that sorts after "additions").
[20:26] <mdiggory> tdonohue: the name or the contribution? mdiggory: dspace-additions
[20:26] <tdonohue> mdiggory, I'm +1 the contribution.
[20:26] <PeterDietz> instead of a "patch", how about a pull request?
[20:27] <PeterDietz> you can add a link to the jira ticket
[20:27] <tdonohue> to me, the name "api" is OK. But, I'm not against changing to "dspace-additions" (just don't feel strongly one way or the other, to be honest)
[20:27] <KevinVdV> I'll see what I can cook up (still learning github)
[20:28] <mdiggory> I fear "api" is starting to feel like "core" thats why I'm avoiding it.
[20:29] <mhwood> But it's not part of DSpace; it's part of your local ScholarWorks or IDEALS or whatever.
[20:29] <tdonohue> mdiggory & mhwood : both are good points
[20:29] <mhwood> The part that comes with DSpace is just the hole you dorp it into.
[20:29] <sands> not to beat this to death, but for the name, you could technically be overriding (not overlaying now) a class in any module with this, right? not just dspace-api?
[20:30] <tdonohue> "addon-api" (ugh), "api-local"
[20:30] <tdonohue> correct sands. You could be overlaying *any* module (as long as this one is named in such a way that it's alphabetically first)
[20:30] <tdonohue> so, it's not just for overriding 'dspace-api'
[20:31] <KevinVdV> sands: well I wouldn't recommond overriding anything outside of the dspace-api since it doesn't have any xmlui depencendencies for example
[20:31] <KevinVdV> You COULD add dependencies for xmlui stuff but then these would end up in your [dspace]/lib directory which isn't good
[20:31] <sands> ok, well, i'd be fine with additions then, since it's more accurate, less misleading, maybe more telling.
[20:31] <sands> KevinVdV: understood
[20:32] <mdiggory> sands: yes
[20:33] <mdiggory> not only any class in any module.... any class that comes after "addons" on the classpath, even system classes
[20:33] <tdonohue> We're probably getting to the point of "thinking about this too much". If anyone comes up with an amazing idea, add it to DS-981. The name "additions" or "addons" is OK with me for now.
[20:33] <kompewter> [ https://jira.duraspace.org/browse/DS-981 ] - [#DS-981] Created a DSpace API module to contain api changes - DuraSpace JIRA
[20:33] <mdiggory> this is a dark art, we need to be careful about suggesting we fully support doing it (even though we do it ourselves)
[20:33] <mhwood> Yup, and you *could* carve a turkey with a chainsaw. It might even work. But you shouldn't.
[20:34] <mdiggory> thats after I cooked it with a blow torch?
[20:34] * mhwood worries about all this dark classpath magic.
[20:34] <hpottinger> "God as my witness, I thought turkeys could fly..."
[20:35] <tdonohue> should we just move along? bring further discussion/ideas/brainstorms over to Ds-981 comments or to dspace-devel as necessary?
[20:35] <mdiggory> ROTFL
[20:36] <sands> tdonohue: sounds good
[20:37] <KevinVdV> *adds discussion in the jira task*
[20:37] <tdonohue> Moving along to next topic. Just a few FYIs for folks. First up, the OR12 Face-to-face DSpace Developers Meeting will be on Monday, July 9. So, keep that in mind for any of your travel plans
[20:37] <tdonohue> (if anyone would like to lead that face-to-face meeting, get in touch)
[20:38] <tdonohue> next up...I sent this to dspace-commit, but the feedback from Google about GSoC is up at: https://wiki.duraspace.org/display/GSOC/GSoC+2012+Rejection+Notes Essentially the response was "good application, but we wanted to give new orgs a chance this year"
[20:38] <kompewter> [ GSoC 2012 Rejection Notes - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/GSoC+2012+Rejection+Notes
[20:38] <tdonohue> So, there's not much we could have done "better" in the application we are told. Just bad luck
[20:39] <tdonohue> that's it for the FYIs. I'll pause for a brief moment if anyone has quick comments/questions
[20:40] <PeterDietz> In other news, I've been cranking away at Elastic Search Statistics.. see some screenshots at: https://plus.google.com/115522466408243604820/posts
[20:40] <kompewter> [ Peter Dietz - Google+ ] - https://plus.google.com/115522466408243604820/posts
[20:40] <tdonohue> Next topic: We are now officially on GitHub (save for a few minor "modules"). So, *no more commits can be made to SVN* (it's now read-only).
[20:40] * hpottinger cheers for GitHub and Elastic Search eye candy
[20:41] <tdonohue> I'm starting to write up some ideas for "best practices" (or at least resources) at: https://wiki.duraspace.org/display/DSPACE/Development+with+Git I could really use some help here, and we may want to dig into this further in a meeting
[20:41] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git
[20:41] <tdonohue> the more I look into Git/GitHub development practices, it seems like there are a lot of them -- lots of folks do their collaborative development in different ways. We likely will find our own way as well
[20:41] <PeterDietz> I'm glad Alan Orth's email came in on dspace-tech, about how do i migrate all my code history between versions
[20:42] <mdiggory> is elastic search syntax similar to solr?
[20:42] <PeterDietz> not really, I'll dig up some examples
[20:42] <tdonohue> PeterDietz -- yea, that was a good question, and worth documenting best practices around. We need to let folks know how we recommend they "upgrade" from 1.7.x to 1.8.x (or similar) via GitHub
[20:44] <mdiggory> So I attended the DCAT meeting on Tuesday to discuss our project with UMICH, members are reviewing the described requirements... If committer folks could take a look over the following and comment, we'd be grateful too [ https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support ]
[20:44] <kompewter> [ Advanced Embargo Support - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support
[20:44] <tdonohue> essentially, I'd like for us to be documenting the answers to these questions (as they come up , or as we realize them ourselves, which ever comes first). Just worried that currently we're all a bit "in the deep end" and we need to start writing things down in order to come to a common agreement about how we want to take advantage of Git/GitHub
[20:45] <mdiggory> aschweer has already done a great job adding in their implementation details.
[20:45] <aschweer> thanks mdiggory -- I need to update that a bit after discussion with "my" librarians
[20:46] <tdonohue> thanks mdiggory. yea, definitely worth us looking at. Oh, and can we get this added to the 3.0 page, assuming this is planned for 3.0. The 3.0 page is looking very sparse: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
[20:46] <kompewter> [ DSpace Release 3.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
[20:47] <tdonohue> Speaking of which, the next topic on the agenda is 3.0 and trying to get planning/ideas for that moving forward more. If you have a feature/idea you want (or hope) to add to 3.0, put it up at: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
[20:47] <mdiggory> added it
[20:47] <kompewter> [ DSpace Release 3.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
[20:48] <tdonohue> Also : We still need a 3.0 Release Team Leader! Anyone interested? (I'll just keep on pestering) You can also ping me offline :)
[20:49] <sands> tdonohue, perhaps a write-up of the release team leader role would make people more likely to raise their hand? #notvoluteering
[20:50] <sands> just a thought.
[20:50] <PeterDietz> perhaps pay for Release leaders trip to Scotland?
[20:50] <tdonohue> sands: yea, the issue here is that it's an entirely new role (obviously). I have some guesses as to the role (essentially just keeping the Release Team organized). But, it's likely going to be "shaped" a bit as we move forward
[20:51] <tdonohue> PeterDietz just offered to pay your way to Scotland! ;)
[20:51] <sands> PeterDietz: did i say i wasn't volunteering?...
[20:51] <mhwood> Maybe this is something that the RT works out for itself?
[20:52] <tdonohue> mhwood -- it could be. that may be the 'default approach'. Have the Release Team almost "self-organize", and divvy things up as they see fit.
[20:55] <tdonohue> The only other topic I had for today was a question about the "Virtual Summit" and when we'd next like to hold one (or if we just want to "table" that decision until we feel we need another Virtual Summit)?
[20:55] <tdonohue> My initial thoughts were to make that *at least* a yearly event (usually in Jan/Feb, after we're all back from holiday).
[20:56] <tdonohue> But, I'm also wondering if there'd be interest in making it two times a year (e.g. Jan & May/June/July) or 3 times (Jan, May, Sept)? Though, I don't want them to be too frequent as to become "less useful"
[20:57] <sands> tdonohue: twice a year doesn't sound like too much.
[20:57] <mhwood> 1-2 / yr.
[20:57] <hpottinger> following summer break, or is that too close to release?
[20:58] * hpottinger realizes that's hemisphere-centric
[20:58] <tdonohue> so, if we did twice a year, it is worth thinking about how this differs from the OR12 Dev Mtg? Should a second "Virtual Summit" be held after OR, to allow us to touch base about things that came up there (or new ideas)?
[20:59] <aschweer> (sorry all, I need to go to work)
[20:59] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:00] <KevinVdV> Needs to run need sleep
[21:00] <KevinVdV> Until next week
[21:00] <tdonohue> Or, are we really talking about: 1 virtual summit (early in year), and 1 face-to-face summit (at OR12). Though, you could argue that the OR meeting is sometimes a bit of a larger / broader meeting as it often involves non-developers as well
[21:00] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC)
[21:00] <sands> after the release would be a good time to discuss features of the next release before they're hardened.
[21:02] * PeterDietz (sorry been distracted by impromtu meeting by office)
[21:03] <tdonohue> sounds like it's gone mostly quiet. :) Maybe this is just "something to think about more".
[21:04] <tdonohue> sands -- I actually viewed the Jan/Feb Virtual Summit as sort of "after the release" in Nov. So, I agree with that idea -- it's good to come together after a release to start to brainstorm the next one
[21:04] <sands> makes sense
[21:05] <tdonohue> (that's the main reason why I think we should *always* at least have a yearly summit in Jan or Feb each year, since we've been tending to do our major releases late in the year)
[21:05] <hpottinger> a post-OR virtual summit would be a good chance for everyone who didn't make it to OR to share information with those who did
[21:05] <PeterDietz> ^ and to get some summary / conclusion about the direction to be going
[21:06] <sands> how 'bout a yearly shouting match just before the release? ;P
[21:06] <tdonohue> hpottinger: that's a good thought. I also wonder if a post-OR summit lets us "keep the momentum going". I tend to feel "energized" by OR, but sometimes that momentum doesn't continue for long after getting home :)
[21:06] <tdonohue> PeterDietz : good point too
[21:07] <mdiggory> virtual meetings are good... maybe some integration milestones might be good too.
[21:07] <tdonohue> "integration milestones" like "deadlines"?
[21:08] <mdiggory> hmmm.. more like checkpoints
[21:08] <PeterDietz> get a series of changes into something stable
[21:08] * tdonohue notes we have been running in "overtime". If you have to head out, feel free (no worries). I'm gonna hang around for a while though to continue this thread
[21:08] <mdiggory> IE, we might do a integration build prior to OR for testing etc
[21:09] <tdonohue> mdiggory -- sounds like an idea for the Release Team! (I actually do like the idea of more "checkpoints". Just a matter of scheduling them)
[21:10] <sands> i like the idea(l) of checkpoints/milestones too. we should talk about it when we start organizing around this release. (goes to email the team)
[21:10] <mdiggory> shucks... we should have chatted quick about the maven consolidation today.. see if we could get that finalized...
[21:10] <mhwood> So, no more CI watching the trunk? (Oops, I mean DSpace/DSpace/master or something like that.)
[21:10] <tdonohue> mdiggory -- I do recall with 1.8, we tried to get a 1.8 "beta" released before OR11, but then when we got close, we realized there was hardly any new code on Trunk to even warrant a "beta" release.
[21:11] <tdonohue> so, part of it is just getting some code into GitHub master in a timely fashion
[21:11] <tdonohue> mhwood -- Bamboo is now setup to watch GitHub. So, we do have CI still, it's just now looking at GitHub
[21:11] <sands> heading out all. catch you on the flip-side
[21:11] <mdiggory> yes, there needs to be some motivation there, surely.
[21:11] * sands (~sandsfish@18.189.87.190) Quit (Quit: sands)
[21:12] <mhwood> How would it work to just ask specific people to commit working versions of specific stuff they're doing by a date they choose, as long as it's not release-1wk.
[21:12] <mhwood> So we have an integration build every time a commit lands.
[21:13] <hpottinger> tdonohue: re: bamboo, since that's just the main project, and not an individual fork of dspace, we all need to be thinking of running our own CI instances, for our own forks, I've been looking into it, but not seriously, if anyone beats me to it, please write up what you're doing?
[21:14] <mhwood> Maybe what we do for a milestone is to focus on getting the integration build stable before resuming unfinished work.
[21:14] <tdonohue> mdiggory -- yea. I've yet to figure out what motivates us besides a strict deadline (we all procrastinate, self included). ideas are definitely welcome.
[21:14] <tdonohue> Maybe adding some more enhanced CI stuff (like auto-build & deploy to demo.dspace.org) would help? (to show off your cool stuff)
[21:14] <mdiggory> but integration needs to = build --> test --> deploy --> http test or the like...
[21:14] <mhwood> hpottinger: I have Jenkins watching mine.
[21:14] <mdiggory> not just = build --> test
[21:15] <mhwood> mdiggory: I see.
[21:15] <tdonohue> we can work towards a build -> test -> deploy -> http test model. I'm completely open to it. We just need to set it up in Bamboo, etc.
[21:16] <hpottinger> I've been meaning to build some acceptance tests at some point...
[21:17] <tdonohue> hpottinger: yea, I'm not entirely sure of the best route for CI + all our various GitHub forks. Technically, we could point Bamboo at all of them (for committers forks only), but I'm not sure if that's the right route.
[21:17] <mdiggory> could it be linked to demo? or has mhwood's test reworking reached a point we can run dspace on a java db?
[21:17] <tdonohue> mdiggory -- we could link it to demo.dspace.org if we choose to. demo.dspace.org is ours and ours alone. So, we can do whatever we want with it (though we still should keep a demo of the most recent release up there, obviously)
[21:19] <mhwood> Rats, I have to go, will check the log later.
[21:19] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:19] <helix84> hello guys, don't let me disturb the conversation, I was wondering if someone could help me with this issue I'm stuck on: http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg16732.html
[21:19] <kompewter> [ [Dspace-tech] custom authentication plugin ] - http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg16732.html
[21:23] <tdonohue> helix84: It looks like it's complaining that the XMLUI cannot see that MyAuth class. Does that same updated "dspace-api-1.8.2.jar" also exist in your /dspace/webapps/xmlui/WEB-INF/lib/ folder? And, you might want to clear the Cocoon & Tomcat caches to make sure they aren't doing something odd.
[21:24] <helix84> tdonohue: thanks, will check and try
[21:25] <helix84> tdonohue: i think it's the likely cause because i actually overwrote the whole xmlui webapp folder to keep my customizations...
[21:26] <hpottinger> tdonohue: I've been meaning to look at running our own CI server for a while, and have a box that would be just perfect for it, but my situation might not match all committers, so if Bamboo could be tweaked to watch all committer forks of DSpace/DSpace, that would (I think) be ideal
[21:28] <tdonohue> hpottinger: I'll ask others in DuraSpace about using Bamboo to watch committer forks. I think it likely shouldn't be a big deal to configure it to watch all our various forks though -- it just would take some time to setup (though I might be able to just give each committer rights to set it up for themselves)
[21:30] <helix84> tdonohue: spot on! thanks for catching my stupid mistake
[21:30] <tdonohue> no problem, helix84. I only thought of that because I've made the same mistake myself many times before
[21:32] * ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) Quit (Quit: Page closed)
[21:50] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:58] <hpottinger> here's a fun diversion someone sent to me today: https://github.com/icefox/git-achievements#readme
[21:58] <kompewter> [ icefox/git-achievements ยท GitHub ] - https://github.com/icefox/git-achievements#readme
[22:08] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[23:21] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has left #duraspace
[23:31] * helix84 (a@195.113.97.174) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.