Timestamps are in GMT/BST.
[1:10] * jonathangee (~jonathang@blk-142-16-43.eastlink.ca) Quit (Quit: ZNC - http://znc.in)
[1:10] * jonathangee (~jonathang@blk-142-16-43.eastlink.ca) has joined #duraspace
[2:30] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[2:31] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) has joined #duraspace
[2:31] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) Quit (Changing host)
[2:31] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:33] -gibson.freenode.net- *** Looking up your hostname...
[6:33] -gibson.freenode.net- *** Checking Ident
[6:33] -gibson.freenode.net- *** Found your hostname
[6:34] -gibson.freenode.net- *** No Ident response
[6:34] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:34] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:34] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:54] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[7:12] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) has joined #duraspace
[7:12] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) Quit (Changing host)
[7:12] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[9:32] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[10:11] * eddies (~eddies@unaffiliated/eddies) Quit (Read error: Connection reset by peer)
[10:12] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) has joined #duraspace
[10:12] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) Quit (Changing host)
[10:12] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[13:17] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:07] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[18:02] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[18:59] * helix84 (~a@195.113.97.174) has joined #duraspace
[19:19] * tdonohue1 (~tdonohue@67.177.111.99) has joined #duraspace
[19:19] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Disconnected by services)
[19:19] * tdonohue1 is now known as tdonohue
[19:32] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:57] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all, it's DSpace DevMtg time. Here's today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-16
[20:00] <kompewter> [ DevMtg 2013-01-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-16
[20:01] <tdonohue> First off, just wanted to (re-)mention that we're now holding a "JIRA Backlog Hour" just before this meeting (starting around 19:00UTC) in #dspace. Anyone who wants to join us is welcome. The goal is obviously to work through our JIRA backlog a bit more rapidly
[20:03] <tdonohue> We'll be doing that "JIRA Backlog Hour" every Weds @ 19:00 UTC in #dspace... at least until we start to get that backlog under control. Folks are also more than welcome to help dig through some old tickets at other times too. Any help is appreciated
[20:03] <tdonohue> in any case...on to today's agenda.
[20:03] <hpottinger> I'll just say I was late to Backlog Hour today, but it was still fun, and there was very little swearing :-)
[20:04] <tdonohue> first off, I just wanted to put in a placeholder here for any 3.0 or 3.1 updates anyone may have. I know we still have some tickets/bug fixes being worked on by several folks... just wanting to check in and see if there are any updates to talk about
[20:04] <hpottinger> I've been adding comments to DS-1435 as I come up with anything that looks like a clue...
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1435 ] - [#DS-1435] DSpace 3.0 Oracle compatibility - DuraSpace JIRA
[20:06] <tdonohue> so, it sounds like that ticket is still being a pain. Do we really just need someone else to try 3.0 + Oracle? I'm wondering whether this is truly verified as a bug for everyone or not?
[20:07] <helix84> yes, there were complints about oracle not working with 3.0, i just don't remember if the issues are already correctly identified in Ds-1435 or not
[20:07] <hpottinger> I also blundered across the zip file containing the install files for Oracle 11.2 on Mac, if anyone wants them I can share them (Oracle no longer distributes this zip file)
[20:08] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:09] <KevinVdV> I'm always interested in the zip files to install oracle on Mac although I don't know if I can find the time to fix it ….
[20:09] <tdonohue> I guess I'm just trying to ask what help is needed here? Do we need more verification that this is a bug? Is it sufficiently verified already and we really need folks who know Oracle well?
[20:10] <helix84> it's surely verified that there are people who can't use 3.0 with oracle and had to go with postgres for now :)
[20:11] <hpottinger> I can verify that DSpace 3.0+ is not working for multiple Oracle back ends, just I'm concentrating on testing using my own Oracle instance
[20:12] <tdonohue> ok, thanks hpottinger. that's what I was wondering
[20:12] <tdonohue> I'm just puzzled myself cause it doesn't seem like *any* of this area of the code changed between 1.8 -> 3.0, and yet 1.8 works on Oracle and 3.0 does not work on Oracle.
[20:12] <helix84> hpottinger: would it be of any help to you to have people who are trying to tun 3.0 on oracle to contact you?]
[20:13] <hpottinger> yes, a roll call on DS-1435 would be great, don't have to contact me, can just comment on the ticket, even just a confirmation that an attempt has been made would be helpful
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-1435 ] - [#DS-1435] DSpace 3.0 Oracle compatibility - DuraSpace JIRA
[20:14] <tdonohue> +1 to commenting on the ticket itself. That way we can better track who is hitting this
[20:15] <tdonohue> Ok, so Ds-1435 is still outstanding & just needs some more help. Are there any other updates anyone has related to either 3.0 or 3.1?
[20:15] <mhwood> Any news on that GPL artifact that we need to replace? A CSV library or some such?
[20:15] <KevinVdV> No news on the CSV library, currently attempting to fix https://jira.duraspace.org/browse/DS-1449 but to no avail :(
[20:15] <kompewter> [ [#DS-1449] missing related items feature (xmlui) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1449
[20:15] <kompewter> [ https://jira.duraspace.org/browse/DS-1449 ] - [#DS-1449] missing related items feature (xmlui) - DuraSpace JIRA
[20:16] <hpottinger> sorry, I typo'd the version I'm using above, to cross my Ts, I'm using Oracle 10.2.0.4.0
[20:17] <tdonohue> sorry to hear about troubles on Ds-1449, KevinVdV. Is there any help you need?
[20:18] <KevinVdV> I believe I'm the solr expert …. & since we are handing all the correct parameters to solr ….. I'm afraid this is something I will have to find. Although if anybody else wants to take a look feel free
[20:19] <tdonohue> yea..you are more expert at Solr than I :) Just thought I'd ask though...not sure if anyone else here has some Solr chops they want to exercise
[20:20] <helix84> KevinVdV: is it possible that Andreas Discovery for JSPUI broke it? If it seems so, it may be helpful to ask him.
[20:20] <KevinVdV> I already looked at that, this is part of the problem but not everything is caused by this
[20:21] <tdonohue> So, it sounds like, in general, we still have a lot of fixes "in progress" for the upcoming 3.1 release. Which means obviously we'll just keeping working towards fixing them, and hold off on scheduling 3.1 for now.
[20:22] <tdonohue> (Oh, and for the record, that CSV library issue mentioned about is DS-1407. But, as KevinVdV mentioned, there's no updates on it yet)
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1407 ] - [#DS-1407] Refactor SOLR Statistics to use OpenCSV or Apache Commons CSV - DuraSpace JIRA
[20:22] <KevinVdV> Yes that is me also :D
[20:23] <KevinVdV> FYI: currently in the process of moving to the house I just bought hence I have very little time to fix these things …. should be fully operational again in a week or 2
[20:23] <tdonohue> Ok.. I had left a space on the agenda here to talk about GitHub Pull Requests & rebasing. I had just noticed a lot of confusion off & on in GitHub PR comments...so, I was wondering if we need to try and document this better?
[20:23] <mhwood> Please.
[20:24] <tdonohue> Although I also noticed helix84 & mhwood started discussing this in a Pull today: https://github.com/DSpace/DSpace/pull/164#issuecomment-12310599
[20:24] <kompewter> [ [DS-1085] EPerson last_active field is defined but never filled by mwoodiupui · Pull Request #164 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/164#issuecomment-12310599
[20:24] <tdonohue> I guess I should also state that : I am not a rebasing expert & have barely even played with it & also often gotten frustrated with it.
[20:25] <helix84> I'd be glad to explain what I know, but I'm not sure what needs documenting - we might do a problem->solution chapter, but we need to formulate the problems first.
[20:25] <tdonohue> So, I'm not sure I have any answers
[20:25] <tdonohue> well...I think part of what could use documenting is this:
[20:25] <tdonohue> 1. Someone submits a pull request...and it has one of those ugly "merge" commits that really shouldn't be there
[20:25] <mhwood> Problem from my POV: I know what I used to do with SVN to coordinate with others, but how does that procedure translate to git?
[20:25] <tdonohue> 2. How do you rebase it cleanly?
[20:26] <helix84> tdonohue: I just explained that in the last comment - create a new branch, rebase in it, publish it and make a pull request from it
[20:26] <mhwood> 3. How do you know you've addressed colliding commits from others without one of those ugly merge commits?
[20:27] <helix84> mhwood: that question is too generic
[20:27] <helix84> 3. that would be adressed by having your master branch up-to-date before rebasing
[20:28] <tdonohue> mhwood. For the record, the GitHub processes I use are the ones I documented here under "Developing from a Forked Repository" https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-SampleGitDevelopmentWorkflows
[20:28] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-SampleGitDevelopmentWorkflows
[20:28] <mhwood> Will read that.
[20:28] <tdonohue> Though, as mentioned, I didn't document anything around rebasing...As I'm still starting to understand it better
[20:29] <tdonohue> (I'm still a bit fuzzy on how to rebase stuff...sometimes I've gotten it to work fine...other times, something odd happens and I get frustrated with it)
[20:30] <helix84> tdonohue: remember that rebasing can go beyond just one command, just like merging (there's git-rebase --abort)
[20:31] <helix84> tdonohue: so you can have a repository with an unfinished rebase - that can complicate stuff a bit if you forget about it
[20:31] <tdonohue> helix84 -- yea, I know it can..still rebase just sometimes gets me confused and I end up in a detached head state or similar... So, I was just noting myself that it'd be nice to see some good examples of how & when to do rebases
[20:31] <helix84> also remember that branches are cheap, so if you need to experiment with rebasing, just create a new branch first
[20:31] <mhwood> See, using SVN, it was drilled into us to always 'svn update' before 'svn commit'. 'svn update' -> 'git pull'. But that adds a commit that people dislike. So I need a way to find out if I need to fix collisions before I push.
[20:32] <aschweer> I use something like this to show the current branch in my prompt -- it's really helpful: https://github.com/jimeh/git-aware-prompt
[20:32] <kompewter> [ jimeh/git-aware-prompt · GitHub ] - https://github.com/jimeh/git-aware-prompt
[20:32] <helix84> mhwood: now I see what you mean. I answered that in the last comment, though.
[20:32] <tdonohue> aschweer -- that seems like a simple, handy tool to be aware of :)
[20:33] <aschweer> it's super-useful in the middle of non-straightforward rebases... I use rebases more than I should
[20:33] <mhwood> Ah, there's more....
[20:33] <hpottinger> I also use this tool to keep me out of trouble: https://github.com/geelen/git-smart
[20:33] <kompewter> [ geelen/git-smart · GitHub ] - https://github.com/geelen/git-smart
[20:33] <aschweer> mhwood: git fetch follwed by a diff might help you
[20:34] <tdonohue> so, helix84...maybe it'd just be useful to try and turn that last comment (https://github.com/DSpace/DSpace/pull/164#issuecomment-12333664) into some rebasing hints on our "Development with Git" wiki page
[20:34] <kompewter> [ [DS-1085] EPerson last_active field is defined but never filled by mwoodiupui · Pull Request #164 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/164#issuecomment-12333664)
[20:34] <aschweer> +1 to documenting this elsewhere than in the irc logs...
[20:35] <tdonohue> in general, I'd like to try and encourage us ALL to share tips/hints/cool tools on that wiki page (or a subpage, if it's worth adding a separate page)
[20:35] <helix84> tdonohue: that one I can do, of course. But in general I'd try to avoid documenting generic stuff that you can find by just googling - there's plenty of documentation and howtos for git online.
[20:36] <tdonohue> helix84 -- yea, but it's still helpful to add in a few notes while we are getting familiar with stuff (and even link off to resources elsewhere). What I find on Google is not always clear :)
[20:36] <aschweer> helix84 that's exactly the problem: there is so much out there that it's not straightforward to figure out what applies. Plus there are different development models
[20:37] <aschweer> and I personally sure would like a chance to read up on the rules before being told off in a pull request
[20:37] <helix84> aschweer: +1 There's such thing as too much information for beginners.
[20:37] <mhwood> Problem is that it *is* generic. We need to all be doing things the same way.
[20:38] <aschweer> mhwood +1 (or at least in a compatible way)
[20:38] <tdonohue> +1 mhwood -- we need not do things *exactly* the same..but it's good to have some tips / best practices
[20:38] <helix84> well, we're dealing with things as they come. if we run into an unfamiliar situation like this one, we figure it out and document it.
[20:40] <KevinVdV> Need to run …. until next week !
[20:40] <tdonohue> yep, that makes sense. We've obviously hit the point where we need to document rebasing :)
[20:40] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: KevinVdV)
[20:41] <mhwood> tdonohue: a problem with your procedure is that I can only push up one project at a time, since they all go into master. I want to request pulls from topics.
[20:41] <helix84> tdonohue: all I'm saying is that rebasing is a huge topic. I'll document "don't merge master branch into feature branch - do a rebase instead"
[20:42] <tdonohue> helix84 -- yea, I think that's all I'm asking for. Not documenting every aspect of rebasing...just the one or two aspects we use most
[20:42] <helix84> mhwood: that's not a problem unless they conflict
[20:42] <tdonohue> mhwood : not sure I understand, though helix84 must as he answered
[20:42] <helix84> mhwood: i mean unless the two feature branches change the same thing in a different way
[20:42] <aschweer> helix84 the way I'm seeing this is, don't document too much about rebasing as such, rather document _how we expect contributors to use / not use it_
[20:43] <mhwood> It is if I have two pull requests from the same (master) branch. Each pulls both requests' commits.
[20:43] <tdonohue> aschweer +1
[20:43] <mhwood> aschweer +1
[20:44] <helix84> mhwood: (pull requests are _to_ the upstream/master branch) but yes, that's no problem unless the feature branches conflict
[20:44] <hpottinger> though, if you feel so moved, linking to additional reading about rebasing would be encouraged and appreciated
[20:44] <aschweer> mhwood: not sure I'm understanding you right -- the pull request comes from the feature branch, as in "I request you to pull this feature into master"
[20:45] <aschweer> so I guess what's missing on tdonohue's wiki page is "and here is where you make the pull request" ;)
[20:45] <tdonohue> mhwood : I'm not sure I understand completely either. Maybe we need to understand your normal processes better?
[20:45] <mhwood> Take a look at https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-SampleGitDevelopmentWorkflows. If I'm reading it right, I'm to merge my topic to *my* master and then request a pull from there.
[20:45] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-SampleGitDevelopmentWorkflows.
[20:45] <aschweer> mhwood: no, you request the pull request from the feature branch
[20:45] <aschweer> after step 6, pretty much
[20:46] <helix84> mhwood: no, that's wrong
[20:46] <tdonohue> Oh, the "Creating the Pull Request" part is further down that wiki page (and needs more filling out...it was mostly just a "stub"): https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-ContributingChanges/PatchestoDSpaceviaGitHub
[20:46] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-ContributingChanges/PatchestoDSpaceviaGitHub
[20:46] <helix84> mhwood: making a pullrequest from origin/master to upstream/master is discouraged
[20:46] <aschweer> tdonohue: yup I meant, at least at a quick glance I can't see whether you say _when_ to make the pull request
[20:46] <mhwood> helix84: yes, that's what I would have thought.
[20:47] <helix84> mhwood: about those parallel pull requests - i think you need to spend a little time looking at gitk-style graphs and a lot will be immediately clear
[20:47] <tdonohue> aschweer : yea, I may not. I created these docs as I was *first learning* Git/GitHub. Feel free to suggest or make updates :)
[20:47] <aschweer> I'm happy to write up my process for my most recent pull request if anyone is interested. I just don't know whether I did the right thing with it, especially with pull request to master vs pull request to 3.x branch
[20:48] <tdonohue> I'd like to see it myself, aschweer. I'm admittedly not sure whether my processes are as "clean" as they could be.
[20:48] <helix84> yes, step 7 is wrong, that is actually discouraged
[20:48] <aschweer> helix84 not necessarily -- I think origin in tdonohue's text is _his fork_
[20:49] <tdonohue> correct...those steps are using my own fork (tdonohue/DSpace).
[20:49] <helix84> aschweer: right, what i'm saying is that we discourage making pull requests from origin/master to upstream/master
[20:49] <mhwood> Look at what "developing from a forked repository" says. Work in a branch, push your branch, when finished merge to your master to share.
[20:49] <hpottinger> if anyone changes the wiki with updated best practices, please ping the mail lists, thanks! :-)
[20:50] <tdonohue> mhwood...Oh, I see the confusion here now...actually, I can see it can be misinterpreted that way..but it's not what I meant
[20:50] <tdonohue> I'm missing a clarification step here...
[20:50] <tdonohue> #6 -> Push your branch to GitHub
[20:50] <tdonohue> #7 -> If you want to generate a Pull Request for this code, generate it from the branch pushed in #6
[20:51] <tdonohue> #8 -> If you DON'T want to generate a Pull Request for this code, you can merge it back into your own Master (this was the OLD #7)
[20:51] <aschweer> tdonohue: yes, I think this would help a lot
[20:51] <mhwood> Yes, that's what I was getting at. If you issue concurrent pull requests from the same branch (for example, origin/master) then they get tangled up.
[20:51] <helix84> tdonohue: that's right. i think you mistakenly wrote master branch instead of origin repo
[20:52] <tdonohue> Ok...that's an easy fix. I didn't realize it could even be misunderstood that way
[20:52] <tdonohue> I can make an update like that to the wiki after this meeting
[20:52] <aschweer> mhwood: I think github actually won't let you make multiple pull requests with the same source/target. But making your pull request from the feature branch fixes that :)
[20:53] <helix84> aschweer: yes, that's the reason for making pull requests from feature branches and discouraging them from master
[20:53] * joaomelo (~DSpace@bl23-32-119.dsl.telepac.pt) has joined #duraspace
[20:53] <helix84> hi joao
[20:54] <mhwood> So, back to my actual question: how to identify colliding commits between my work and upstream without merging? The only way I've found so far is to always try to rebase.
[20:54] <helix84> mhwood: does this answer it? https://github.com/DSpace/DSpace/pull/164#issuecomment-12333664
[20:54] <kompewter> [ [DS-1085] EPerson last_active field is defined but never filled by mwoodiupui · Pull Request #164 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/164#issuecomment-12333664
[20:54] * joaomelo (~DSpace@bl23-32-119.dsl.telepac.pt) Quit (Client Quit)
[20:54] <mhwood> And we all know rebasing is evil, it says so everywhere...so I was looking for another way.
[20:55] <helix84> mhwood: that's not correct. only rebasing _published_ branches is evil.
[20:55] <helix84> mhwood: rebasing local branches is perfectly fine
[20:55] * joaomelo (~DSpace@bl23-32-119.dsl.telepac.pt) has joined #duraspace
[20:55] <mhwood> Forgot to insert ":-)"
[20:56] <tdonohue> Rebasing is essentially on "evil" if you are rebasing a branch someone else has forked & is developing off of. Rebasing *changes* the history in Git, which is why it is evil to change the history on a branch someone else is using
[20:56] <tdonohue> s/on/only/
[20:56] <kompewter> tdonohue meant to say: Rebasing is essentially only "evil" if you are rebasing a branch someone else has forked & is developing off of. Rebasing *changes* the history in Git, which is why it is evil to change the history on a branch someone else is using
[20:57] <helix84> mhwood: an alternative to rebasing is good old diff/patch. but essentially, rebasing is a convenience tool that helps you do multiple diffs/patches and even tracks the commit metadata for you.
[20:57] <tdonohue> (or at least, that's my understanding of the rebasing = evil point)
[20:57] <helix84> tdonohue++
[20:58] <aschweer> yet another way to make a clean pull request would be to create a fresh branch off upstream/master, then cherry-pick all relevant commits
[20:58] <mhwood> Merging or rebasing finds collisions and points them out to you. Diff just shows them somewhere if there are any.
[20:58] <helix84> right, forgot about that, that's actually what i do most of the time
[20:59] <mhwood> Anyway, thanks to all your comments, I think I have a way forward.
[21:00] <helix84> I guess I'll write a chapter "My feature branch went out of date. Now what?"
[21:00] <mhwood> That's the question!
[21:00] <tdonohue> helix84++ (that would be awesome)
[21:01] <hpottinger> (hey, if anyone is in a position to answer questions, we have someone looking for help in #dspace right now)
[21:01] <tdonohue> mhwood : thanks for continually asking tough questions about this...I think it's helpful in getting us all to actually get some best practices in place
[21:01] <aschweer> tdonohue +1 (and mhwood +1)
[21:02] <mhwood> Well, I hate doing things wrong, so I have to ask. :-/
[21:02] <tdonohue> :)
[21:02] <hpottinger> +1for the lot of ya, too :-) also, thanks aschweer for that bash prompt code
[21:02] <aschweer> sorry, gotta run. bye all!
[21:02] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:03] <tdonohue> Ok...noticing we're into "overtime" already. Spent most of the meeting on Git..but, I think it was time well spent. (I'll get my part of the docs updated to clarify)
[21:03] <helix84> did someone find the time to look at Joao's DAO code?
[21:04] <tdonohue> So, I'd like to close the meeting for today. We didn't get to talking about Joao's DAO work, but I'd encourage everyone to look at it more closely
[21:04] <tdonohue> I've glanced at it...but haven't spent much time yet
[21:04] <tdonohue> I think it's looking promising though
[21:05] <helix84> joao, I think it might help if you document what you'd like others to help with (the other 50%)
[21:05] <helix84> it might get someone else involved in the new code
[21:05] <tdonohue> +1 to that. It is still a bit unclear what parts are done & what you need help on. Letting us know what is not done can help to perhaps find some volunteers
[21:11] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has joined #duraspace
[21:11] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[21:13] <joaomelo> it's possible to define more code contribution rules?
[21:14] <helix84> what do you suggest?
[21:14] <tdonohue> joaomelo : the DSpace Committers are the ones that establish code contribution rules. We can vote to change/add/remove them at any time
[21:15] <joaomelo> for example, min unit testing code coverage
[21:15] <joaomelo> following some programming (good) practices
[21:16] <helix84> honestly, I don't know how to write testing code. I'd consider writing some if I knew how. And how to test UI code?
[21:18] <tdonohue> We've encouraged folks to do more unit testing code in the past...but, have yet to require it. Mostly cause we've run into several issues around getting Unit Testing to function properly for dspace-api and other modules. I know mhwood had done some work to clean it up for 3.0
[21:19] <mhwood> One problem (for which I continue to kick myself) is that some of our "unit test" code isn't proper unit tests. UI testing is 'way off in another part of testing-land, for example.
[21:19] <tdonohue> I think if we were going to start requiring it, we'd need to first do some legwork on helping people get fully up-to-speed on the recommendations (i.e. provide examples and documentation, etc)
[21:19] <helix84> tdonohue++
[21:19] * helix84 is going to lurking mode
[21:20] <mhwood> I often find that what I've written is more like integration testing.
[21:20] <tdonohue> (I know for a fact that some committers are more comfortable with unit tests than others...and some just aren't sure what the best practices are, but they'd be willing to write tests if they better understood it)
[21:22] <mhwood> I've been bitten hard by the Test-Driven Development bug, but need to develop more and better habits for test building.
[21:25] <helix84> mhwood: could you look at this test? I hit some race condition in it more than once, but cannot reproduce it reliably. https://jira.duraspace.org/browse/DS-1408
[21:25] <kompewter> [ [#DS-1408] WorkspaceItemTest fails (Timeout trying to lock table "EPERSON") - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1408
[21:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1408 ] - [#DS-1408] WorkspaceItemTest fails (Timeout trying to lock table "EPERSON") - DuraSpace JIRA
[21:29] <mhwood> It's not obvious to me.
[21:31] <joaomelo> need to go
[21:31] <joaomelo> bye
[21:31] <kompewter> see ya
[21:31] * joaomelo (~DSpace@bl23-32-119.dsl.telepac.pt) Quit (Quit: joaomelo)
[21:36] <mhwood> The database code is not a place I've spent enough time. But I wonder about creating a collection and a WorkspaceItem back-to-back without update() or committing the Context.
[21:37] <mhwood> In between, I mean.
[21:40] <tdonohue> mhwood. Just updated my GitHub workflow docs to clarify when you'd create a Pull Request (theres a new #7 step). Hopefully it makes a bit more sense now: https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-DevelopingfromaForkedRepository
[21:40] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-DevelopingfromaForkedRepository
[21:40] <mhwood> Thanks, will take a look.
[21:49] <mhwood> tdonohue that is much more clear. But it also combines two procedures: (a) you are developing for your own use only but may be willing to share, and (b) you are developing something you intend to contribute to upstream via a pull request. Might it be best to disentangle these into two separate procedures? Maybe even as two sub-pages.
[21:52] <tdonohue> yea...I started to realize that... it is a bit of a mixture of both. It's hard to disentangle them in some ways, as in my mind they are very parallel, and can even be done together: option (c) you are developing something you intend to contribute upstream but also want to merge immediately into your local code
[21:52] <tdonohue> i.e. it is possible to do steps #7 (send pull request), #8 (local merge), #9 (push local merge to your personal GitHub) all together...
[21:53] <mhwood> Hmmm, in that case you are contributing twice: once to your local variant and again to DSpace.
[21:53] <tdonohue> *kinda*. It's more like this...
[21:53] <tdonohue> 1) You find a bug in DSpace 3.0. You need a rapid fix for your production
[21:53] <tdonohue> 2) You create a fix & submit a pull request
[21:54] <tdonohue> 3) You cannot wait for that pull request to get merged, so you just merge it immediately into your own production code
[21:54] <tdonohue> so..it's is kinda like two contributions -- one to DSpace Central...and one to your own codebase
[21:55] <tdonohue> but, that sort of workflow is also possible in GitHub. The end result is not an either/or (either pull request, or local use)...it can be both.
[21:55] <tdonohue> not sure if that makes any sense or not
[21:57] <hpottinger> so... I'm wondering where I should park the installer for Oracle on OSX... I think our general counsel would not be happy with me if I posted them on one of our servers
[21:57] <mhwood> Probably the way I'd do it is: (2) create a fix and put it in production; (3) we like it, so submit a PR.
[21:58] <mhwood> hpottinger: are you *positive* that Oracle won't object? OS distro.s tend to make you go get your own copies of Oracle kits because Oracle won't let them redistribute.
[21:59] <hpottinger> mhwood, I'm actually pretty sure Oracle is exactly the sort of company that would object
[21:59] <hpottinger> unfortunately, they no longer distribute this file
[21:59] <tdonohue> mhwood : and you could do it your way as well...you'd just swap the order of steps... (1) create your bug-fix branch, (2) merge it into your local master & release to production, (3) submit a pull request from that bug-fix branch, (4) clean up bug-fix branch after pull request is accepted
[22:00] <tdonohue> hpottinger : stick it up on a Dropbox somewhere...don't public advertise it, but let folks know where it is who want it?
[22:01] <tdonohue> i.e. Oracle's not gonna find out if you aren't going around posting publicly, saying: hey all, take a look at what I have! :)
[22:01] <hpottinger> erm... I think I've already let the cat out of the bag here :-)
[22:02] <mhwood> I always worry: what if they *do* find out, because they're actively searching popular sites?
[22:02] * tdonohue is googling "Oracle hpottinger"
[22:03] <mhwood> This channel is logged....
[22:03] <hpottinger> attention lawyers: I was just kidding :-)
[22:03] <tdonohue> hey..what do you know, there's results from this channel :)
[22:04] <hpottinger> and, also, lawyers: please ask management to distribute this file, the fact that you don't is L.A.M.E.
[22:04] <mhwood> Oracle could have half a billion dollars' worth of traded-in Sun boxes scanning the Internet instead of taking up space in a warehouse.
[22:05] <tdonohue> the key word there is *could*
[22:05] * hpottinger head hurts...
[22:05] <mhwood> Yeah, if you want to grow your market share, go where the dev.s are, and a lot of them are on OSx
[22:06] <hpottinger> mhwood, I think they tried, and it was sooooo painful to get working, they decided to just pull the distribution and not have to deal with the negative social impact
[22:06] <tdonohue> even if they did, I doubt they are gonna go around googling hpottinger :) (Hi Oracle, how are you? We really think you are swell, but why'd you take down that OSX installer?)
[22:07] <hpottinger> however, this is mostly just me being paranoid
[22:07] <hpottinger> thinking the world revolves around me, that kind of thing
[22:08] <hpottinger> sorry to have interrupted an interesting conversation on testing, you may return to it
[22:08] <mhwood> Well actually I have to leave it, because I need to leave.
[22:08] <tdonohue> no problme
[22:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:10] <hpottinger> sent a plea for help to the dspace-developers list
[22:11] <tdonohue> hopefully you get some hits
[22:42] <helix84> hpottinger: you should have CCed dspace-tech, too
[22:46] <hpottinger> helix84: thanks, forwarded
[22:53] * tdonohue (~tdonohue@67.177.111.99) Quit (Read error: Connection reset by peer)
[22:54] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.