#duraspace IRC Log

Index

IRC Log for 2018-02-14

Timestamps are in GMT/BST.

[6:36] -hitchcock.freenode.net- *** Looking up your hostname...
[6:36] -hitchcock.freenode.net- *** Checking Ident
[6:36] -hitchcock.freenode.net- *** No Ident response
[6:36] -hitchcock.freenode.net- *** Couldn't look up your hostname
[6:36] * DuraLogBot (~PircBot@54.243.59.36) has joined #duraspace
[6:36] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:36] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:43] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:15] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[17:36] * dyelar (~dyelar@dyelar.mrb.ku.edu) Quit (Quit: Leaving.)
[19:32] <DSpaceSlackBot> <tdonohue> <here>: Reminder that our DSpace DevMtg is in about 30 mins (20UTC) here. Our rough agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-02-14.
[20:00] <DSpaceSlackBot> <tdonohue> <here>: It's DevMtg time! Agenda is listed above. Let's do a quick roll call to see who's here (either in Slack or IRC).
[20:00] <DSpaceSlackBot> <mwood> Hi
[20:00] <DSpaceSlackBot> <hpottinger> here
[20:00] <DSpaceSlackBot> <kshepherd> :spock-hand:
[20:01] <DSpaceSlackBot> Action: hpottinger faints
[20:01] <DSpaceSlackBot> <tdonohue> Looks like we've got a decent quorum.. nice ;)
[20:01] <DSpaceSlackBot> <hpottinger> I'm jamming to the Code4Lib live stream hold music
[20:01] <DSpaceSlackBot> <terrywbrady> hello
[20:02] <DSpaceSlackBot> <tdonohue> As you may notice, the agenda is a little light / similar to last few weeks... but, I'll quickly touch on the updates
[20:03] <DSpaceSlackBot> <tdonohue> On the DSpace 7 side, I don't have any significant updates to share. Next meeting is tomorrow (15UTC). Latest status of the effort is on our DSpace 7 status spreadsheet: https://docs.google.com/spreadsheets/d/18brPF7cZy_UKyj97Ta44UJg5Z8OwJGi7PLoPJVz-g3g/edit#gid=0
[20:03] <kompewter> [ DSpace 7 Development Planning - Google Sheets ] - https://docs.google.com/spreadsheets/d/18brPF7cZy_UKyj97Ta44UJg5Z8OwJGi7PLoPJVz-g3g/edit#gid=0
[20:03] <DSpaceSlackBot> <tdonohue> (Just realized I should link that spreadsheet off the agenda...which I'll do for next week)
[20:04] <DSpaceSlackBot> <tdonohue> We have two other important meetings coming up.. DSpace Entities Mtg on Feb 23 at 15UTC, and our first ever Developer Show & Tell Mtg on Feb 27 at 16UTC
[20:04] <DSpaceSlackBot> <tdonohue> links to more info on each are on the agenda
[20:05] <DSpaceSlackBot> <tdonohue> I also don't have any significant updates on DSpace 6.3 release efforts. Still looking for volunteers to help lead/organize. Get in touch if this is of interest to you
[20:06] <DSpaceSlackBot> <tdonohue> So, that's really it for topics #1 and #2 on the agenda (and the reminders).... unless others want to share updates or questions or comments on either DSpace 7 or 6.3, etc?
[20:06] <DSpaceSlackBot> <tdonohue> Not hearing any...so, we'll move along to the "meat" of today's agenda, the new Java Code Style: https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266
[20:06] <kompewter> [ Code Style Guide (WIP) - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266
[20:07] <DSpaceSlackBot> <tdonohue> As you've likely seen, I've got two PRs in progress... the actual code style itself (and corresponding Checkstyle configs): https://github.com/DSpace/DSpace/pull/1895
[20:07] <kompewter> [ New Code Style rules for DSpace "master" branch by tdonohue · Pull Request #1895 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1895
[20:07] <DSpaceSlackBot> <tdonohue> That PR #1895 is ready to merge, unless there are final comments/questions
[20:08] <DSpaceSlackBot> <tdonohue> And then, there's the *massive* (literally) PR to cleanup the codebase: https://github.com/DSpace/DSpace/pull/1952
[20:08] <kompewter> [ [WIP] Align Java code with new Code Style by tdonohue · Pull Request #1952 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1952
[20:08] <DSpaceSlackBot> <tdonohue> And 1952 is still WIP, but it's very close....all the modules are corrected. Just need to correct the "dspace-parent" directories and turn "on" checkstyle by default
[20:08] <DSpaceSlackBot> <mwood> Aw, it's only *a hundred thousand lines*.
[20:09] <DSpaceSlackBot> <kshepherd> hehe
[20:09] <DSpaceSlackBot> <kshepherd> it looks good to me
[20:09] <DSpaceSlackBot> <tdonohue> :$ um, yes. Hence the need for a code style. Obviously we aren't good at code consistency ;)
[20:09] <DSpaceSlackBot> <mwood> Point.
[20:09] <DSpaceSlackBot> <hpottinger> Duralogbot, do not quote Tim
[20:09] <DSpaceSlackBot> <terrywbrady> thank you for doing this. It will be an improvement moving forward
[20:10] <DSpaceSlackBot> <tdonohue> I will say this effort has taken longer than expected. Some modules were pretty easy to cleanup... Others (:cough: dspace-api :cough:) took literally hours
[20:11] <DSpaceSlackBot> <hpottinger> it's funny to think of -API as a module...
[20:11] <DSpaceSlackBot> <tdonohue> But, I'd like to know from you all if you have concerns/questions/comments.... My goal is to get this massive 1952 completed today/tomorrow, and hopefully merged before end of week. BUT, I'd want your approval, and want to know if anyone has any concerns/questions
[20:12] <DSpaceSlackBot> <mwood> I've built the result and it succeeds without complaint. I looked over one of the modules and didn't see anything actually *wrong*. There are things that'll take some getting used to, a few that I'll never get used to, and some things that I like. I guess that makes it a good compromise, if others feel the same way.
[20:12] <DSpaceSlackBot> <tdonohue> (And I'll also be asking the same of the DSpace 7 team in tomorrow's meeting ... as I want their approval too obviously before touching most files on `master`)
[20:13] <DSpaceSlackBot> <tdonohue> I have also updated the Wiki docs to give more details of "good" and "bad" code per the new CodeStyle rules: https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266#CodeStyleGuide(WIP)-DSpaceJavaStyleGuide(Adopted2018,forDSpace7.xandabove)
[20:13] <kompewter> [ Code Style Guide (WIP) - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266#CodeStyleGuide(WIP)-DSpaceJavaStyleGuide(Adopted2018,forDSpace7.xandabove)
[20:14] <DSpaceSlackBot> <tdonohue> @mwood: yes, I have the same feeling...there are things to "get used to". But, I think that's where IDE configuration will also come in....luckily major IDEs can integrate our Checkstyle config, and warn you if you go wrong
[20:16] <DSpaceSlackBot> <mwood> A bit of advice gleaned from a similar effort: if we're going to be aligning broken lines like that, we need to keep identifiers reasonably short. Otherwise we'll have places where the code will have to be rewritten slightly to make it fit all the rules. (Another project here has one identifier that is 60 characters long! It will only ever be seen on a line by itself...)
[20:16] <DSpaceSlackBot> <hpottinger> so... the two code style PRs are for master... we're not backporting/applying this to 6x, correct?
[20:17] <DSpaceSlackBot> <tdonohue> @hpottinger: correct. This code style *starts* with DSpace 7. It will not be backported
[20:17] <DSpaceSlackBot> Action: hpottinger looks relieved...
[20:17] <DSpaceSlackBot> <kshepherd> could this make cherrypicking commits for some modules that don't change (much?) in 7 like oai-pmh, sword etc, difficult?
[20:18] <DSpaceSlackBot> <kshepherd> or weird?
[20:18] <DSpaceSlackBot> <kshepherd> (ie. i have a SWORD fix for 7, will it need extra work to merge nicely into 6 now?)
[20:18] <DSpaceSlackBot> <tdonohue> That does mean of course that *forward-porting* PRs built for DSpace 6 will be slightly more painful... likely cherrypicking won't work in 90% of the cases. You'll need to create a separate PR for 7 that uses the code style
[20:18] <DSpaceSlackBot> <mwood> Weird: yes. Difficult: probably not.
[20:18] <DSpaceSlackBot> <kshepherd> ok, gotcha
[20:19] <DSpaceSlackBot> <hpottinger> the price of progress
[20:19] <DSpaceSlackBot> <tdonohue> This code style PR touches quite literally 90% (or more) of all our code. Even most of the POMs are touched. So, yes, cherrypicking likely won't work between DSpace 5/6 and DSpace 7.
[20:20] <DSpaceSlackBot> <hpottinger> I think that's fine, 7 is kinda a different universe already
[20:20] <DSpaceSlackBot> <tdonohue> And even if the cherrypick is successful, CheckStyle might still fail the build... if the cherrypicked code doesn't obey the new rules ;)
[20:20] <DSpaceSlackBot> <kshepherd> yeh that's why i was just thinking of those unchanged modules, OAI, SWORD, etc.
[20:20] <DSpaceSlackBot> <kshepherd> but not exactly a big deal
[20:21] <DSpaceSlackBot> <tdonohue> Yes, it's the price of progress here. We'll just need to be aware the cherrypicking won't be trustworthy between old releases and DSpace 7. That said, the code itself (in most situations) won't be hard to adapt
[20:22] <DSpaceSlackBot> <tdonohue> The other major thing to note is that currently open PRs on `master` may also be affected (in that they will now have conflicts that need to be resolved by a rebase). But, I don't see any way around that one either
[20:23] <DSpaceSlackBot> <tdonohue> But again, the price of a major effort here
[20:23] <DSpaceSlackBot> <tdonohue> and not the first time we've affected open PRs
[20:23] <DSpaceSlackBot> <kshepherd> yep, and that'll only get worse the longer we leave it!
[20:24] <DSpaceSlackBot> <kshepherd> i guess that means we shouldn't be merging anything to master until after this is merged too, or we can end up making new conflicts/work
[20:24] <DSpaceSlackBot> <hpottinger> oh, yeah, code freeze
[20:24] <DSpaceSlackBot> <tdonohue> So, as this is a big deal...and it does affect a lot, I do want to make sure folks are OK with this. I'd appreciate it if you either (a) give me a :+1: (you approve), (b) ask more questions, or (c) give me a sign you have concerns still needing to be addressed
[20:25] <DSpaceSlackBot> <tdonohue> @kshepherd Yes, that's why I'm trying to finish this immediately *this week*. Hoping to avoid much more mergers into `master`. Not calling for a complete "code freeze", but would appreciate it if ping me before any mergers
[20:26] <DSpaceSlackBot> <mwood> Order with which I'm mostly happy is better than disorder.
[20:26] <DSpaceSlackBot> <tdonohue> And I'll talk to the DSpace 7 team about this tomorrow too....as they are doing most of the (larger) work on `master` these days
[20:28] <DSpaceSlackBot> <tdonohue> And if you want to get a "jump" on correcting any PRs you own (or plan to create), we do already have notes on how to support CheckStyle in IntelliJ / Eclipse / Netbeans here: https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266#CodeStyleGuide(WIP)-IDESupport
[20:28] <kompewter> [ Code Style Guide (WIP) - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266#CodeStyleGuide(WIP)-IDESupport
[20:28] <DSpaceSlackBot> <tdonohue> So, you can already start playing with configuring your IDE properly, and uploading the checkstyle.xml config file from https://github.com/DSpace/DSpace/pull/1895
[20:28] <kompewter> [ New Code Style rules for DSpace "master" branch by tdonohue · Pull Request #1895 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1895
[20:28] <DSpaceSlackBot> <mwood> I'm looking forward to seeing all the mustard-yellow underlines disappear from NetBeans.
[20:29] <DSpaceSlackBot> <tdonohue> @mwood: oh, in IntelliJ the codestyle issues are highlighted in RED ;) I'm looking forward to those going away too
[20:31] <DSpaceSlackBot> <tdonohue> My plan / next steps are as follows: 1. Finish up the massive PR 2. Ping folks to quickly review/merge 3. Finalize Code Style wiki page (take off the WIP stuff) 4. Notify all developers (dspace-devel) that new rules are in place on `master`.
[20:31] <DSpaceSlackBot> <tdonohue> All of that, hopefully before end of day on Friday.... assuming all goes smoothly ;)
[20:31] <DSpaceSlackBot> <tdonohue> Any last questions / comments / things I've missed?
[20:32] <DSpaceSlackBot> <kshepherd> good luck!
[20:32] <DSpaceSlackBot> <mwood> I'm ready to approve, after the presentation tomorrow.
[20:32] <DSpaceSlackBot> <tdonohue> Thanks ;) Oh, and yes, this all needs to be OK'd by DSpace 7 team... but they've also been wanting this for some time, so I expect that'll go smoothly tomorrow
[20:34] <DSpaceSlackBot> <tdonohue> So, that was the major topic on our agenda for today. I still have the same three tickets/PRs listed under topic #4 as last week. These are just "quick fixes" that look nearly ready to go / need more eyes.
[20:34] <DSpaceSlackBot> <tdonohue> (But obviously wait on anything to `master` till next week)
[20:34] <DSpaceSlackBot> <tdonohue> Are there any topics / tickets that you all would like to discuss? (We have 25mins remaining here)
[20:35] <DSpaceSlackBot> <terrywbrady> We have a plan for the first Developer Show and Tell meeting.
[20:35] <DSpaceSlackBot> <mwood> I'm looking for someone who can exercise dspace-rest (the old one) on master to see if I broke anything in DS-3836.
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-3836 ] - [DS-3836] dspace-rest old dependencies break command line - DuraSpace JIRA
[20:36] <DSpaceSlackBot> <tdonohue> RE: 3836, I pinged @terrywbrady on the PR: https://github.com/DSpace/DSpace/pull/1955 Hoping maybe he can exercise some of his existing tools/scripts
[20:36] <kompewter> [ [DS-3836] dspace-rest old dependencies break command line by mwoodiupui · Pull Request #1955 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1955
[20:37] <DSpaceSlackBot> <tdonohue> And thanks @terrywbrady again for all the planning / coordination you've done for that first Developer Show & Tell Mtg!
[20:37] <DSpaceSlackBot> <terrywbrady> Sure, I will be glad to test DS-3836
[20:37] <kompewter> [ https://jira.duraspace.org/browse/DS-3836 ] - [DS-3836] dspace-rest old dependencies break command line - DuraSpace JIRA
[20:37] <DSpaceSlackBot> <mwood> Thanks!
[20:38] <DSpaceSlackBot> <kshepherd> look forward to watching the recording of the show & tell
[20:40] <DSpaceSlackBot> <tdonohue> Oh, and I just remembered I meant to report back on this 20UTC meeting time. If you recall, I expressed concern (more like frustration) a few weeks back about whether to keep this meeting timeslot. I've rethought that since then...I'm gonna wait to do anything until after we see how the show & tell meeting plays out. I'm hoping maybe that'll "re-energize" developers to pop their heads up, and maybe find m
[20:40] <DSpaceSlackBot> more convenient
[20:40] <DSpaceSlackBot> <terrywbrady> I have volunteered to lead a webinar on customizing DSpace 6 in April. I would really like to run the demo on a cloud instance of DSpace rather than using my test environment. I hope the Show and Tell meeting will give me some insights on how to do this. In the meantime, I am trying again to get DSpace to run on Codenvy. Unfortunately, I do not have enough expertise in Docker to get it working.
[20:41] <DSpaceSlackBot> <terrywbrady> If a DSpace developer who understands Docker would be open to working with me for 3-4 hours on this, I think we could offer a great solution to the community.
[20:41] <DSpaceSlackBot> <tdonohue> @terrywbrady: There's also vagrant-dspace to consider. I still find it pretty useful (when I need it)
[20:42] <DSpaceSlackBot> <tdonohue> @hpottinger is the "Docker guy" (or at least I hear him talking about it the most)
[20:42] <DSpaceSlackBot> <hpottinger> Hey, @terrywbrady I can pitch in with that, though I certainly don't "understand" Docker
[20:42] <DSpaceSlackBot> <terrywbrady> @hpottinger tried to help me get it running a year ago, and we hit a wall so I have been discouraged by that option.
[20:43] <DSpaceSlackBot> <hpottinger> Docker is not particularly great on anything but Linux is one problem
[20:44] <DSpaceSlackBot> <tdonohue> Yes, Docker is a bit frustrating on Windows (or at least I've found it to be so)...which is why I'm using vagrant-dspace (which, at least for me, is slightly less frustrating on Windows, most of the time)
[20:44] <DSpaceSlackBot> <tdonohue> But, to each their own ;)
[20:44] <DSpaceSlackBot> <hpottinger> Now... Docker on Linux... is like a sports car
[20:45] <DSpaceSlackBot> <tdonohue> I can believe that, @hpottinger. I want Docker to work, I do
[20:45] <DSpaceSlackBot> <terrywbrady> Thanks @hpottinger. Do you use Docker regularly?
[20:45] <DSpaceSlackBot> <hpottinger> I used it a few weeks back when I was doing lots of compiling and theme work
[20:45] <DSpaceSlackBot> <terrywbrady> Today I have been trying to build a docker image on my home Mac and then import it into Codenvy. terrywbrady/dspace is the image.
[20:46] <DSpaceSlackBot> <terrywbrady> I cannot get postgres properly set up to allow a user to connect to psql.
[20:46] <DSpaceSlackBot> <hpottinger> Ah, OK, let's talk. One thing you need to keep in mind, containers are not the same thing as VMs
[20:48] <DSpaceSlackBot> <tdonohue> If you figure anything interesting out, please do document it ;) Even just in the README of https://github.com/DSpace-Labs/dspace-dev-docker
[20:48] <kompewter> [ GitHub - DSpace-Labs/dspace-dev-docker: DSpace instant development environment using Docker ] - https://github.com/DSpace-Labs/dspace-dev-docker
[20:49] <DSpaceSlackBot> <hpottinger> So, that ^^^ does build a single container with all the bits, but the "proper" Docker ways would be to pull in the images that are already close to what you need (like the Postgres image, and the Tomcat image) and then tie them together
[20:50] <DSpaceSlackBot> <kshepherd> @tdonohue is your AWS topic about straight VM provisioning? do you do anything with docker swarms using the Elastic Container Service?
[20:51] <DSpaceSlackBot> <kshepherd> i've messed around with that at a wee bit but i've probably thrown away all my working/prototypes by now
[20:51] <DSpaceSlackBot> <hpottinger> DSpace swarm!
[20:51] <DSpaceSlackBot> <tdonohue> I'm literally just gonna talk puppet-dspace: https://github.com/DSpace/puppet-dspace and puppet-dspace-demo (how the demo site is setup): https://github.com/DSpace-Labs/puppet-dspace-demo
[20:51] <kompewter> [ GitHub - DSpace/puppet-dspace: A basic Puppet module to install DSpace (and common prerequisites). ] - https://github.com/DSpace/puppet-dspace
[20:51] <kompewter> [ GitHub - DSpace-Labs/puppet-dspace-demo: Puppet / Cloud-Init scripts to auto-setup demo.dspace.org server ] - https://github.com/DSpace-Labs/puppet-dspace-demo
[20:51] <DSpaceSlackBot> <kshepherd> ah, cool
[20:51] <DSpaceSlackBot> <tdonohue> It probably shouldn't be hyped as "AWS tools"... it's more about setting a basic DSpace up in AWS
[20:52] <DSpaceSlackBot> <tdonohue> It's nothing fancy...just a very basic cloud deployment like the demo.dspace.org site
[20:52] <DSpaceSlackBot> <tdonohue> I'll update the description on that Wiki page to make that clearer
[20:52] <DSpaceSlackBot> <terrywbrady> I am so bewildered by all these options that exist.... yet I do not know how to make any of them work.
[20:53] <DSpaceSlackBot> <mwood> Heh, I'm still trying to figure out *why* to make any of them work.
[20:55] <DSpaceSlackBot> <tdonohue> Timecheck: we are nearly out of time. I don't have any other agenda items...but, just want to be sure no one else has topics to (quickly) share
[20:56] <DSpaceSlackBot> <terrywbrady> @mwood, here is my reason. I want to demonstrate to a new developer how to customize a bare instance of DSpace and I want to do it without needing to wipe out my existing test environment.
[20:58] <DSpaceSlackBot> <mwood> I just install DSpace into a different directory and whip up a context to point to it. I made a couple of tiny scripts to write local.cfg and a context according to my local conventions.
[20:58] <DSpaceSlackBot> <hpottinger> here's my "why": I spent several months trying to help a CS student set up IntelliJ IDEA to do DSpace. He never ever got past that state.
[20:59] <DSpaceSlackBot> <hpottinger> I *never* want to waste time like that again.
[21:00] <DSpaceSlackBot> <terrywbrady> I think we underestimate what a barrier there is to getting started with the platform.
[21:00] <DSpaceSlackBot> <mwood> Probably. It's still set up very much oriented toward the developer who already knows the code.
[21:01] <DSpaceSlackBot> <tdonohue> I definitely agree, @terrywbrady. I hope maybe the Dev Show & Tell will inspire folks to help improve our "getting started" docs (for various IDEs, etc) and also tell us what is missing so we can start to decrease that barrier
[21:01] <DSpaceSlackBot> <hpottinger> There are many non-developers who are pretty technically savvy. That's the entire premise of XSLT, right? But we need to simplify the right of passage, so people can help.
[21:02] <DSpaceSlackBot> <terrywbrady> I hope I did not hijack the conversation today!
[21:02] <DSpaceSlackBot> <tdonohue> Well, we are at the top of the hour. I'll still be around a bit, but, I'm planning to hack away at that massive PR some more in the background
[21:02] <DSpaceSlackBot> <tdonohue> @terrywbrady: no worries. We had a light agenda
[21:03] <DSpaceSlackBot> <tdonohue> So, feel free to continue discussion as you see fit. I'm gonna head into lurking mode now though ;)
[21:03] <DSpaceSlackBot> <kshepherd> i better go earn some money
[21:03] <DSpaceSlackBot> <kshepherd> bye all
[21:04] <DSpaceSlackBot> <mwood> (0) You need a JDK. Tell your package manager to install it.(1) You need one of these DBMSs. Tell your package manager to install it. (2) You need Tomcat or something like it. Tell your package manager to install it. (4) You need Git. See above. (5) You need DSpace. Use Git to get it.
[21:05] <DSpaceSlackBot> <mwood> (6) You need Maven. Ask your package manager.
[21:06] <DSpaceSlackBot> <hpottinger> 2 and 6 can lead to doom
[21:07] <DSpaceSlackBot> <hpottinger> and 7 You need Ant
[21:07] <DSpaceSlackBot> <mwood> Really? Those were the simple bits.
[21:07] <DSpaceSlackBot> <mwood> Ah, yes, Ant. Ask your package manager.
[21:07] <DSpaceSlackBot> <hpottinger> if you depend on your package manager for Tomcat, Maven, or Ant you can end up with a mess
[21:07] <DSpaceSlackBot> <mwood> Somebody needs a new package manager.
[21:08] <DSpaceSlackBot> <terrywbrady> Here are some other pre-requisites: You need a server. You need that server connected to the internet. You need your audience to be able to access that server.
[21:08] <DSpaceSlackBot> <hpottinger> RHEL is appealing to large IT orgs
[21:08] <DSpaceSlackBot> <hpottinger> RHEL's approved packages are notoriously stale
[21:08] <DSpaceSlackBot> <mwood> Oh, that. Yes.
[21:09] <DSpaceSlackBot> <hpottinger> Homebrew isn't much of an improvement, from time to timme
[21:11] <DSpaceSlackBot> <mwood> Hardware and network access are irreducible requirements for any service. And they're provisioned differently in each shop.
[21:12] <DSpaceSlackBot> <terrywbrady> The cloud has simplified that issue for lots of software platforms. I wish we had that for DSpace.
[21:16] <DSpaceSlackBot> <hpottinger> see... Vagrant-DSpace flattens all this out to > here, just install Vagrant and Virtualbox, then run `vagrant up`
[21:24] <DSpaceSlackBot> <terrywbrady> Unfortunately, when you and I tried to get vagrant dspace to run on my desktop, we were unable to get it to work. That has led me to explore other options... options that I understood to be simpler than managing VM's within Virtual Box. I am quite invested in DSpace, and I find the provisioning of development resources to be complicated. What is the experience like for new developers?
[21:25] <DSpaceSlackBot> <terrywbrady> For my regular work, I have the benefit of a great set of DEV/TEST servers that are populated with relevant content for our repository instance. When I want to do something ad-hoc that is unrelated to our repository instance, I encounter this challenge.
[21:26] <DSpaceSlackBot> <mwood> Now, VirtualBox is something I can deal with. I have a virtual CentOS box to run Oracle, and a virtual Windows 10 box for the three times a year I need Windows.
[21:27] <DSpaceSlackBot> <tdonohue> FWIW, the thinking behind `vagrant-dspace` was exactly trying to simplify the issue...make it easier to get DSpace installed to demo, do basic development on, etc. But, I fully admit that it may not have fully met that need... I too find that when it "work" it just works (and I don't have to think about it). But, when it doesn't (e.g. some versions of Vagrant have difficulties with other versions of Virtua
[21:27] <DSpaceSlackBot> what is going wrong
[21:28] <DSpaceSlackBot> <tdonohue> For my purposes, I still use vagrant-dspace (when I do development) cause I've found it easier for my environment...but, I don't believe in a single solution. We definitely need multiple ways to "get started" so folks can find something easiest for them
[21:29] <DSpaceSlackBot> <tdonohue> So, I'd love to see / find ways to enhance tools to spin up DSpace in the cloud / docker / AWS / etc. We have bits and pieces of each, but nothing super simple yet
[21:32] <DSpaceSlackBot> <terrywbrady> I know that I am whining a bit, but it is for a purpose. We are updating the code base in DSpace 7 to be developer friendly. I think we should be thinking about this for testing/deployment as well. I am not convinced that we should tell other developers to try to replicate what has historically worked for Terry/ Tim/Hardy/Mark/Kim. Unfortunately, I do not have the expertise to recommend the approach
[21:33] <DSpaceSlackBot> <mwood> I agree that DSpace could do with some attention to production installation.
[21:35] <DSpaceSlackBot> <tdonohue> @terrywbrady: I agree with those statements completely. I just don't have an answer to that question yet. I think developers tend to come with preferences already...they might prefer an IDE over another, they might prefer Docker to Vagrant, or AWS to both. I think my feeling is we need to find ways to help folks in through different paths...so sharing what we know is good, and hopefully we learn more about
[21:36] <DSpaceSlackBot> <tdonohue> But, I agree completely that the path / tools of one person are not always the best path / tools of others. I have my own preferences and biases (e.g. heck I use Windows 10! I actually find it easier than Mac or Linux for my main environment...but I also do deal heavily in Linux VMs)
[21:39] <DSpaceSlackBot> <mwood> So: everyone needs to know *what* is needed to run DSpace. Some need help to determine *how* to get those things; others don't.
[21:40] <DSpaceSlackBot> <tdonohue> Yes, and some could really use a simple: Press a button or two (or type a line or two) and "hey there's DSpace!". That was the hope of vagrant-dspace, but it hasn't panned out, and it likely could be made even easier with AWS or Cloud tools
[21:42] <DSpaceSlackBot> <tdonohue> As one simple example of this concept... part of the Hydra-in-a-box project was creating a set of AWS CloudFormation scripts to "launch the stack" in AWS: https://github.com/hybox/aws There's *literally* a button on that GitHub repo to launch the stack... I don't recommend pressing it though, as the full stack is a bit large / pricey.
[21:42] <kompewter> [ GitHub - hybox/aws: AWS CloudFormation templates for the Hydra-in-a-Box application stack ] - https://github.com/hybox/aws
[21:43] <DSpaceSlackBot> <tdonohue> But, one could imagine a set of AWS CloudFormation templates to launch a simple DSpace for demo / development. That thing doesn't exist yet, but no reason it couldn't
[21:52] <DSpaceSlackBot> <mwood> One could, and there's no reason it shouldn't exist or be used by those who want it. But when I have used a thing like that, sooner or later it breaks, and I don't know what's inside, and the quickest way (for me) to learn what's inside is to wipe it clean and install all the pieces myself. So, myself, I tend to avoid in-a-box.
[21:53] <DSpaceSlackBot> <mwood> They used to deliver new servers to me with Netware already installed. I always wiped the box first thing and installed Netware again, my way, and then when something went wrong I usually knew why. Eventually they learned to just drop off the sealed maker's box.
[21:54] <DSpaceSlackBot> <mwood> Others have different methods.
[21:55] <DSpaceSlackBot> <tdonohue> yep, nothing's perfect. There's no "single solution" and anything we do build would need maintenance
[21:57] <DSpaceSlackBot> <mwood> So I think we need to start with "here's what you'll need to make it run. If that tells you all you need to know, skip a bit; otherwise, here are links to pages which show several ways that people have organized this setup work."
[21:59] <DSpaceSlackBot> <mwood> If we can characterize *why* someone chose method B over method C, that might be as helpful as explaining methods B and C (which we would still do).
[22:02] <DSpaceSlackBot> <mwood> We can throw a rug over some of the complexity, but it's still there. It's just a question of when you want to face it: now, or later.
[22:02] <DSpaceSlackBot> <mwood> There are good reasons for each choice.
[22:04] <DSpaceSlackBot> <mwood> Aaaand, I have to go.
[22:09] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:50] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.