Timestamps are in GMT/BST.
[2:43] * lyncodev (02de6f12@gateway/web/cgi-irc/kiwiirc.com/ip.2.222.111.18) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[4:39] * peterdietz (uid52203@gateway/web/irccloud.com/x-iuywlxlhzmdhotoq) Quit (Quit: Connection closed for inactivity)
[6:45] -asimov.freenode.net- *** Looking up your hostname...
[6:45] -asimov.freenode.net- *** Checking Ident
[6:45] -asimov.freenode.net- *** Found your hostname
[6:45] -asimov.freenode.net- *** No Ident response
[6:45] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:45] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:45] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:47] * kostasp (5e44f33c@gateway/web/freenode/ip.94.68.243.60) has joined #duraspace
[10:01] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[10:19] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[11:26] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[11:32] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[12:11] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[12:14] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Client Quit)
[12:15] * kostasp (5e44f33c@gateway/web/freenode/ip.94.68.243.60) Quit (Quit: Page closed)
[13:15] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:34] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[14:15] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[14:18] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[14:20] * Andy_____ (266cf8e2@gateway/web/freenode/ip.38.108.248.226) has joined #duraspace
[14:21] <Andy_____> hELLO
[14:21] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) has joined #duraspace
[14:28] * Andy_____ (266cf8e2@gateway/web/freenode/ip.38.108.248.226) Quit (Quit: Page closed)
[14:56] * kdweeks (~Adium@2001:468:c80:a103:3d2d:5fad:f56b:9625) has joined #duraspace
[15:54] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[17:06] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[17:29] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) has joined #duraspace
[17:31] * lyncodev (c24b26fa@gateway/web/cgi-irc/kiwiirc.com/ip.194.75.38.250) Quit (Client Quit)
[17:48] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:46] * peterdietz (uid52203@gateway/web/irccloud.com/x-doznzsvhfhbncmfp) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome! It's time for our weekly DSpace Developers Meeting. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-01-21
[20:01] <kompewter> [ DevMtg 2015-01-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-01-21
[20:02] <tdonohue> So, first off, obviously a huge congratulations to everyone on the release of DSpace 5.0! https://wiki.duraspace.org/display/DSDOC5x/Release+Notes
[20:02] <kompewter> [ Release Notes - DSpace 5.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC5x/Release+Notes
[20:02] <tdonohue> Thanks especially to our 5.0 Release Team.... peterdietz, mhwood, hpottinger, robint, pbecker, helix84 (I think that's all of you?)
[20:03] <hpottinger> Indeed, thanks, everyone, DSpace 5.0 is a huge release, I'm very much looking forward to upgrading to it.
[20:04] <mhwood> What worked well or not? We need a way to get impending features out in the open sooner, so we have time to resolve conflicts.
[20:05] <tdonohue> +1 to getting impending features sooner. Any ideas/brainstorms how best to do that?
[20:05] <mhwood> Earlier feature freeze. Much earlier.
[20:05] <hpottinger> Anything that refactors the database needs to go in really early :-)
[20:05] <tdonohue> I know that pbecker had made suggestions about possibly moving up the PR deadline to put more time between PR deadline & feature freeze
[20:05] <peterdietz> Ohh, is this a post-mortum? Having a plan of what we want IN, earlier.
[20:06] <mhwood> A plan. Now there's an idea.
[20:06] <hpottinger> :-)
[20:06] <tdonohue> yes, post-mortum on 5.0 now... what went well, or could be improved for next time?
[20:06] <peterdietz> Could also use some weighing on features from some friendly DCAT folks. i.e. Do you want Metadata 4 All. Do you want Author Profiles, ...
[20:07] <hpottinger> well... we can either move up the PR deadline, or go all-Agile
[20:07] <mhwood> There's a specific suggestion: feature freeze just before OR. Pro: we can say at OR what the major features will be. Con: can't do anything about features we hear of at OR until next year.
[20:07] <tdonohue> So, regarding a *plan*, I do agree. I also should add here that the new DSpace Steering Group wants to see an *actual* Roadmap (i.e. Plan) created for the use cases that DCAT has been giving input on
[20:07] <peterdietz> Yikes. Yeah, CRUD REST API was vaporware until OR, then I ran into CTU Czech group, who had been working on a CRUD enhancement
[20:07] <tdonohue> DCAT Use Cases: https://wiki.duraspace.org/display/DSPACE/Use+Cases
[20:07] <hpottinger> yeah, post-OR is an interesting time where we get to harness collaborations that occur there (like, oh, the ORCID integration)
[20:07] <kompewter> [ Use Cases - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Use+Cases
[20:08] <tdonohue> I think feature freeze needs to be *post-OR*... otherwise, I'd worry I'd never get anything into a release, as there's so much else to do prior to OR most years
[20:08] <mhwood> That does sound more useful than just being able to answer "so, what's coming in DSpace.next?"
[20:08] <peterdietz> So OR + 1 quarter to shut the door
[20:09] <hpottinger> which is pretty much what we have now, right?
[20:09] <mhwood> Yeah, that's around October.
[20:09] <mhwood> OR+1 month, no more. 2 weeks?
[20:09] <hpottinger> 2 weeks is too tight
[20:10] <hpottinger> with OR travel creating backlogs
[20:10] <mhwood> OK.
[20:10] <peterdietz> With some of the under-the-hood upgrade enhancements. Quicker upgrade iteration could be possible. i.e. git pull origin master && mvn && ant && service tomcat restart.... Technically feasible (due to flyway)
[20:11] <hpottinger> maybe mid-September PR deadline?
[20:11] <peterdietz> I didn't back to USA until 2 weeks after OR. (In Denmark)
[20:11] <tdonohue> before we jump to a schedule, let me backtrack a second
[20:11] <tdonohue> DSpace Steering Group wants to see DSpace features more "scheduled out" (as much as it possibly can be), so that users can better understand the direction of DSpace, and *hopefully* we can get collaboration on features that become higher priorities overall
[20:12] <mhwood> Sorry, didn't see that schedule was separate.
[20:12] <tdonohue> This relates to our schedule, because this may affect how we approach 6.0
[20:13] <mhwood> That sounds good. How?
[20:13] <tdonohue> DSpace Steering Group is currently looking into potentially *hiring* a part-time consultant person who can help us to "distill" the DCAT generated Use Cases into a high level "plan" of priorities...
[20:13] <hpottinger> this is sounding a lot like Agile to me...
[20:13] <mhwood> I already have one daily Scrum standup....
[20:14] <tdonohue> They *hope* to hire someone to help with this in the coming months...that person would work with Steering, DCAT & Committers to try to build out a Plan based on high priority use cases
[20:14] <peterdietz> Yeah, the brain trust would be helpful to identify the 10 juiciest next features. People can grab one of this to crank out. But, the way development time goes locally, is that we have to solve local problems, before I can volunteer to solve external projects.. Coordinating schedules / development effort, chews up some resources...
[20:14] <hpottinger> not necessarily "scrum" just story-oriented development
[20:15] <tdonohue> The *hope* is also that this actual *Plan* would be in a rough-draft state in time for OR15, so that we could start to gage how we can get enough buy in to implement it, and *how* to go about implementing it, etc
[20:15] <peterdietz> But, I would be happy to know that each year, the 10 highest demand things go tackled... So DSpace becomes an easier sell
[20:15] * srobbins (~Adium@mobile-130-126-255-111.near.illinois.edu) has joined #duraspace
[20:15] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:15] <hpottinger> peterdietz is right, though, before I volunteer for development I have to connect those projects to goals or issues that are important to my "local customers"
[20:16] <tdonohue> The reason I mention all this is that it *could* have an affect on how we go about implementing 6.0, and/or the 6.0 schedule.
[20:16] <tdonohue> But, it's worth mentioning so that you all are aware of the DSpace Steering Group discussions that are going on right now (this all was just decided recently)
[20:16] <peterdietz> We see a lot of debate in terms of which IR/archive is right for me: DSpace, Eprints, BePress, Dora's (Island, Fe, Hydra)
[20:17] <peterdietz> So, DSpace being the best product is helpful
[20:17] <peterdietz> FeDora = Iron Dora
[20:17] <tdonohue> In general, the DSpace Steering Group feels that DSpace's lack of a *plan* (longterm roadmap) does sometimes hinder it's acceptance, and also may cause us to lose users as they aren't sure what the direction of DSpace is in the next 3-5 years. So, they want to help correct that.
[20:18] <tdonohue> But, it also does mean that we also may be diving *headfirst* into some of the "elephants in the room" (cough cough two UIs cough cough)...to mix metaphors
[20:18] <mhwood> *sigh* Developers: what'cha want to do? Users: I dunno, what *you* wanna do? [repeat]
[20:19] <peterdietz> I see 2 UI's as an asset
[20:19] <mhwood> The answer to "2 UIs" these days seems to be "5 UIs". :-|
[20:20] <mhwood> Well, even if it's unpleasant, we ought to face some of these issues that keep hanging around.
[20:20] <tdonohue> I don't. But to be clear, I do see multiple UIs built on a *common backbone* as an asset *as long as they have their own, separate committer teams*. But, that is not what we currently have.
[20:20] <mhwood> Good point.
[20:20] <peterdietz> yeah, good point tdonohue
[20:21] <tdonohue> currently we have two UIs which are a mis-mash of stuff...using their own code/ideas, all under one set of committers (who are overwhelmed in supporting both simultaneously)
[20:21] <hpottinger> :-) well, in practice, we *don't*, not really
[20:22] <peterdietz> So. One stray thought. Wire up XMLUI to sit on top of REST API. REST gets beefed up to handle more neccessary services.. Followed by do the same with JSPUI...
[20:22] <mhwood> Pushing more logic out of the UIs back to the core should help, no matter how many teams we have.
[20:22] <tdonohue> so, in any case, I realize we have gone a bit away from "what'd we learn in 5.0?" onto "where do we go next?". I mostly wanted to make everyone aware of these Steering Group discussions that are popping up. So far, they are discussions, and not (yet) action / movement forward.
[20:22] * hpottinger would love to stop using XSLT as a template language
[20:23] * mhwood does not want to give up the aspect chain.
[20:23] <tdonohue> My stray thought: any UI that DSpace supports going forward should sit on top of REST API. (I'm hoping to draft up some ideas to this affect in the near future to get in front of all you for brainstorms)
[20:24] <mhwood> Consider the proposition that administrative pages may be a special case.
[20:25] <tdonohue> yep, there may be some special scenarios...hence "brainstorm" :)
[20:25] <hpottinger> further, any UI built on the REST-API, if it utilizes a framework, needs to utilize one that has a solid and large-ish community
[20:25] <mhwood> IOW not Cocoon 2.2. :-/
[20:25] <peterdietz> Then. When REST+NodeJS (some future UI) wants to add a missing feature of Dynamic Configs. Then the DSpaceAPI gets enhanced, then REST gets enhanced, then NodeJS gets enhanced. To then roll that out to XMLUI (on REST), you've already built your service layer, it should just involve altering XMLUI (on REST)
[20:25] <tdonohue> so, before we get too far off of 5.0, any other last thoughts on 5.0. We've identified that one issue is just *having more time to review / approve / enhance / merge* things
[20:25] <hpottinger> *cough* Cocoon *cough* *cough*
[20:26] <mhwood> Related to time is the size of some of the stuff that came in toward the end.
[20:26] <tdonohue> very true
[20:26] <hpottinger> big stuff goes in first
[20:26] <mhwood> I would like to see large changes sooner even if they are ugly at that point.
[20:27] <hpottinger> even if it makes the ride bumpy
[20:27] <mhwood> It only has to be believable that they can be spiffed up and tested in time.
[20:27] <peterdietz> Stuff kept rolling in, for better or for worse. Yeah, Metadata4All, we were skeptical, but mostly in favor of it. But it sat for some time, then we eventually merged it. It could have benefited from getting in sooner, if we knew we were going to go that direction
[20:27] <tdonohue> we did have some of that, IIRC with 5.0. Metadata for All got in fairly early didn't it, for example?
[20:28] <hpottinger> right: "big stuff in first" involves two parties doing things early
[20:28] <tdonohue> But, I do agree... big stuff getting in earlier is a big benefit to us all. We also know that we need to have more time between "PR deadline" and "feature freeze" (as 2 weeks was not enough)
[20:29] <hpottinger> and, as a carrot: if you get your PR in before OR, we will all be talking about *your code* at OR
[20:29] <mhwood> Put it this way: we would like to offer the next release as a test-bed and attract more helpers, if you would get your rough ideas into Github early.
[20:30] <mhwood> But then we need to be more decisive: is this for 6.0? 7.0? or not at all. Decide within (say) 2 weeks.
[20:30] * hpottinger pulls a rough idea out of the air as an example, like, say ORM?
[20:30] <tdonohue> with regards to 6.0, I'm a bit hesitant to lay out a schedule for it yet...as I'm still trying to feel out the direction of the Steering Group (around developing a longer term roadmap). I'm hoping that I'll have a better idea on this very soon.
[20:31] <mhwood> I was speaking of a hypothetical Big Feature.
[20:31] <tdonohue> FYI next Steering Group meeting is in two weeks
[20:31] <tdonohue> yep, I understand we're talking hypotheticals...just wanted to loop back to the 6.0 "freeze" discussions from earlier
[20:32] <mhwood> You brought us this rough code early. Thanks. Now we need to get you a decision early.
[20:32] <mhwood> OK
[20:32] <tdonohue> I *do* think we need to have earlier deadlines for 6.0...just hesitant to set them yet, until I get a sense of Steering Group's ideas on establishing a roadmap, and how that would effect our "normal" release schedule
[20:32] <hpottinger> so: maybe schedule more specific backlog reviews prior to the deadlines
[20:32] <peterdietz> Other projects that I contribute a minor fix to, I'm always pleased when they get a chance to review or merge it within a day. Not sure how they do it.. But somehow I've had that experience
[20:33] <mhwood> So then put discussion of scheduling on the agenda for 3 weeks hence?
[20:33] <tdonohue> hpottinger ++ Yea, I think specific backlog reviews or taking time from backlog to review features is a good idea as we near deadlines
[20:34] <hpottinger> we do that now, but it's really more of a "boy, there's a lot of things to talk about.... when? Oh, maybe backlog hour?"
[20:34] <peterdietz> Another post-mortum. I would like to see PR's that contain screenshots, and a full description... Especially if its something that is potentially pretty cool. The contributer's guide to selling your PR
[20:34] <tdonohue> mhwood: actually, we could discuss scheduling again on Feb 4 meeting (two weeks). The DSpace Steering Group meeting is earlier that day...so I should be able to say something more on Feb 4, if not earlier
[20:34] <mhwood> Even better.
[20:35] <hpottinger> OK, that works
[20:36] <tdonohue> prior to that, obviously it'd be good to already begin brainstorming ideas for 6.0 (or later). I do want to draft up some ideas on UIs going forward. I'd encourage others to draft up (or revisit) ideas you may have too
[20:36] <hpottinger> I think if we want to focus on specific packages of work and deliver on those particular features, we may need to change our focus from time-based releases to feature-based releases
[20:37] <mhwood> Features can be scheduled several releases out, if there is more to do than can be done in one cycle.
[20:37] <tdonohue> hpottinger: that could be. Or something that is a feature-based release but we still try to nail down a deadline... i.e. 6.0 will have [these features] and be out in Quarter #1 of 2016
[20:37] <mhwood> But we have to prioritize, which means some pet features get prioritized out of .next.
[20:37] <tdonohue> and mhwood ++ on scheduling things out
[20:38] <hpottinger> we have a process that prioritizes the release on a certain date, which does a good job of ensuring there's a release on a certain date
[20:38] <mhwood> Of course, anyone who wants feature X is welcome to take on some of the work, and there are a lot of experienced people to help you get started. That gets more features in sooner.
[20:39] <hpottinger> mixing in another focus (a set of features) may or may not fit into that schedule, however, if the goal is to improve communication on the specific feature timeline...
[20:40] <peterdietz> I'm thinking that a steering committee will have a lot of steering to do, but no resources to steer
[20:40] <mhwood> Well, if we're gonna talk Agile, it's a lot like making up a sprint. The available workers size tasks and decide how much work they can get done by next deadline.
[20:40] <tdonohue> peterdietz: Steering Group definitely realizes we lack "centralized" resources...but many on Steering have DSpace Developers (or even Committers) who work for them
[20:41] <tdonohue> peterdietz: So, it may be that we get things done in a more "collaborative" and less "centralized" fashion
[20:42] <tdonohue> Steering Group includes @mire, MIT, IUPUI, Texas Digital Libraries, Edinburgh, Minho, etc... http://dspace.org/steering-group So, they all have developers, mostly ;)
[20:42] <kompewter> [ DSpace Steering Group | DSpace ] - http://dspace.org/steering-group
[20:42] <tdonohue> In any case, looking at the time...it might be best to step back to DSpace 5 stuff again
[20:43] <peterdietz> okay, yeah, looks like they've got some horsepower in their own stables
[20:43] <tdonohue> Any other last thoughts on DSpace 5 stuff? Do we want to talk about 5.1 yet?
[20:44] <tdonohue> (Although 5.1 schedule seems highly dependent on bugs reported in coming days/weeks)
[20:44] <tdonohue> at the very least, I'd "guess" we may want to think about a 5.1 in the next month or two...sooner if we stumble on major issues
[20:44] <mhwood> I always hate to say "no" to working code, but we let it dribble in for too long. We should be firmer about deadlines.
[20:45] <tdonohue> yea, I do agree, we often have trouble saying "no" nearing deadlines
[20:46] <mhwood> We could make certain that there is a branch for version.next, and merge with it after release, so that late submissions have somewhere to go *today*.
[20:46] <tdonohue> I think I find myself sometimes being OK with "late, last minute additions" *as long as* they come with good verification tests (unit / integration tests)
[20:46] <mhwood> +1 automated testing
[20:47] <mhwood> It's amazing how much less fearsome changes are when you have a machine to look them over.
[20:47] <tdonohue> mhwood: exactly
[20:48] <mhwood> We probably need a written notion of what "good tests" looks like.
[20:48] <tdonohue> yes, though we also (as we know) need to likely clean up our unit / integration test framework some too...and then correct the notion of what good tests look like
[20:48] <mhwood> Yes.
[20:49] <hpottinger> and, erm, acceptance tests...
[20:49] <mhwood> We don't have any tests that drive the UIs, for example.
[20:49] <hpottinger> DS-2288
[20:49] <kompewter> [ https://jira.duraspace.org/browse/DS-2288 ] - [DS-2288] Acceptance test suite - DuraSpace JIRA
[20:49] <tdonohue> yes, that'd be nice
[20:50] <hpottinger> and DS-2397
[20:50] <kompewter> [ https://jira.duraspace.org/browse/DS-2397 ] - [DS-2397] Sort out Unit vs. Integration tests, and run them separately - DuraSpace JIRA
[20:50] <mhwood> You can't really "unit test" something that depends on a Servlet container, a web server....
[20:50] <hpottinger> mhwood is correct, that's a "functional" or "acceptance" test
[20:50] <tdonohue> both 2288 and 2397 sound like great ideas in my book
[20:51] <mhwood> Now we just have to do the work. Simple! :-)
[20:51] <hpottinger> http://blog.csanchez.org/2008/06/25/functional-testing-with-maven-carg/
[20:51] <kompewter> [ Functional testing with Maven, Cargo and Selenium | Carlos Sanchez's Weblog ] - http://blog.csanchez.org/2008/06/25/functional-testing-with-maven-carg/
[20:52] <tdonohue> It's really just a matter of yes, making them a priority. In many ways, the hardest part is *getting started* and then showing others some examples. After that, we can consider requiring or highly recommending them for PRs
[20:52] * tdonohue notes we are running a bit short on time here
[20:53] <mhwood> I recall thinking 5.1 had some hot-ish issues already, but that may be only the two we closed today.
[20:53] <hpottinger> so, reading the tea leaves, 6.0 may end up being the "great testing release"
[20:53] <tdonohue> If anyone does have a chance to dabble in 2288 or 2397, please feel free to get things rolling...
[20:54] <tdonohue> 5.1 does have a status page with some tickets already...but they were all moved from 5.0 to 5.1, I think: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.1+Status
[20:54] <kompewter> [ DSpace Release 5.1 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.1+Status
[20:54] <hpottinger> yes, DS-2415 and DS-2417 are both "committer-specific" issues, one of the pitfalls of working on the bleeding edge
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-2415 ] - [DS-2415] cannot add new metadata field to an existing item with Oracle back-end database - DuraSpace JIRA
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-2417 ] - [DS-2417] Metadata value table still contains foreign key reference to item_id - DuraSpace JIRA
[20:54] <tdonohue> well, except for 2415 and 2417 which seem to actually not be issues, unless you adopted unstable code from "master" branch
[20:54] <tdonohue> (prior to 5.0 stable)
[20:55] * hpottinger bristles at being called unstable, but it's probably true.
[20:55] <mhwood> Nice, we have seven issues already in code review.
[20:56] <tdonohue> (it highly depends on *when* you adopted code from "master"....there *was* some unstable code on master at times prior to release...even though we try not to do that)
[20:56] <mhwood> Thou shalt not break "master" unless it's really necessary.
[20:56] <tdonohue> So, looking at the 5.1 page, nothing is high enough priority to push a release ASAP (yet). But, we likely do have plenty for a 5.1 in the near future
[20:58] <tdonohue> before we run out of time today...I *did* want to also mention again that I plan to "rebuild" http://demo.dspace.org/ in the near future (on Ubuntu 14.04). If anyone has special requests, please let me know
[20:58] <kompewter> [ DSpace 5.0 Demonstration Repository ] - http://demo.dspace.org/
[20:58] <hpottinger> I think pbecker requested a reverse proxy to be in front of Tomcat
[20:59] <tdonohue> most of this rebuild will likely be "invisible"...I'll just swap the VMs out, once it's ready to go. But, I hope to fix a couple known issues on current demo server in the process
[20:59] <hpottinger> which means we could, in theory, set up Shibboleth on demo
[20:59] <tdonohue> yep, I plan to put Apache in front of Tomcat on demo, this time around....that's a much more "standard" setup
[20:59] <hpottinger> oh, can we give kompewter it's own little house?
[20:59] <tdonohue> (and I plan to get rid of running Jetty on demo, if possible)
[21:00] <tdonohue> "house"?
[21:00] * hpottinger slaps kompewter on the back, clank!
[21:00] <hpottinger> it's own VM, so it doesn't have to share a room with demo
[21:01] <tdonohue> no, likely not. It's much too "small" for it's own VM. I, personally, would rather it just sit on demo, so we can all reboot it easily as needed
[21:01] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:01] <tdonohue> (I just don't see any benefit to having it totally separate)
[21:01] <hpottinger> OK, I guess it's a nice "canary" letting us know if demo falls over
[21:02] <mhwood> Does it actually crash, or just go comatose? You could have something like monit watch it and restart it as needed.
[21:02] <tdonohue> It seems to actually "crash" sometimes...but I have never dug deeply into it, as kompewter is mostly peterdietz's baby
[21:02] <hpottinger> every once in a while, Kompewter dies, monit might be enough
[21:03] <peterdietz> And I snagged kompewter from the bot we used at Ohio State Univ Open Source Club
[21:03] <hpottinger> mhwood: if you set up monit for kompewter, best do it for demo, too :-)
[21:04] <tdonohue> so, we can always find ways to clean up kompewter more going forward. I think my highest priority is to just get demo upgraded & give it a good scrub (as it's quite messy these days)
[21:04] <mhwood> I'm still learning how to make monit and jsvc play nicely together.
[21:04] <mhwood> tdonohue++
[21:04] <mhwood> And, thank you!
[21:04] <tdonohue> (and we can always replace kompewter's insides at some point with a more stable bot software, if we find something else we like)
[21:05] <hpottinger> it's OK, kompewter, we still love you
[21:05] <tdonohue> kompewter will still live on, even if it's insides get replaced ;)
[21:06] <tdonohue> In any case...we're out of time here. I didn't have any other topics to bring up today, and I think we've had a lot of good brainstorms today (despite the smaller group). Thanks again though to everyone for the hard work on 5.0!
[21:07] <tdonohue> I'm going to close out today's meeting. I will be mostly around for the next few hours though, so I'm glad to discuss whatever pops up
[21:07] <mhwood> Thanks, everyone!
[21:14] * srobbins (~Adium@mobile-130-126-255-111.near.illinois.edu) Quit (Quit: Leaving.)
[21:41] * lyncodev (02de6f12@gateway/web/cgi-irc/kiwiirc.com/ip.2.222.111.18) has joined #duraspace
[22:07] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:25] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[22:50] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:57] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) has joined #duraspace
[23:01] * lyncodev (02de6f12@gateway/web/cgi-irc/kiwiirc.com/ip.2.222.111.18) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[23:29] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.