Timestamps are in GMT/BST.
[0:25] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[0:35] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[1:40] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[6:40] -adams.freenode.net- *** Looking up your hostname...
[6:40] -adams.freenode.net- *** Checking Ident
[6:40] -adams.freenode.net- *** Found your hostname
[6:40] -adams.freenode.net- *** No Ident response
[6:40] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:40] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:40] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:17] * PeterDie_ (~peterdiet@128.146.173.59) has joined #duraspace
[10:27] * PeterDietz (~peterdiet@128.146.173.59) Quit (*.net *.split)
[10:27] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) Quit (*.net *.split)
[12:08] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:48] * bradmc (~bradmc@static-76-161-241-125.dsl.cavtel.net) has joined #duraspace
[12:49] * bradmc (~bradmc@static-76-161-241-125.dsl.cavtel.net) Quit (Client Quit)
[12:59] * bradmc (~bradmc@static-76-161-241-125.dsl.cavtel.net) has joined #duraspace
[13:11] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:18] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[16:46] * bradmc (~bradmc@static-76-161-241-125.dsl.cavtel.net) Quit (Quit: bradmc)
[17:06] * bradmc (~bradmc@static-76-161-241-125.dsl.cavtel.net) has joined #duraspace
[19:03] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) has joined #duraspace
[19:04] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) has left #duraspace
[19:05] * bradmc (~bradmc@static-76-161-241-125.dsl.cavtel.net) Quit (Quit: bradmc)
[19:07] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[19:17] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has joined #duraspace
[19:45] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:49] <tdonohue> Hi all, reminder we have a DSpace Developers Meeting in about 10mins here: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-04
[19:49] <kompewter> [ DevMtg 2012-04-04 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-04
[19:50] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:56] <ablemann> woop
[19:57] * keithg (~keithg@2600:1002:b00d:3c66:5651:80cb:fab9:bde2) has joined #duraspace
[19:59] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:00] <tdonohue> Hi all, it's that time again (and I'm finally back). Here's the agenda for today's DSpace Devel meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-04
[20:00] <kompewter> [ DevMtg 2012-04-04 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-04-04
[20:00] <PeterDie_> Hi All
[20:00] <tdonohue> we'll kick things off, as normal, with some JIRA catchup: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-970+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-970 ] - [#DS-970] Item Edit View, Edit Collection View, Control Panel need Navigation Improved for extensibility and DSpace needs a "SiteMap" page. - DuraSpace JIRA
[20:00] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-970+ORDER+BY+key+ASC
[20:00] <tdonohue> starting with DS-970
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-970 ] - [#DS-970] Item Edit View, Edit Collection View, Control Panel need Navigation Improved for extensibility and DSpace needs a "SiteMap" page. - DuraSpace JIRA
[20:01] * PeterDie_ is now known as PeterDietz
[20:01] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) has joined #duraspace
[20:03] <tdonohue> I'm all in favor of the idea of Ds-970. But it sounds like several projects at once...we just need to find a volunteer (or two or three) to start digging in and figuring out a better way to implement these interfaces
[20:03] <mhwood> At first glance it seems sensible. Yes, there are at least two issues in there.
[20:04] <PeterDietz> no arguments against from here...
[20:04] <tdonohue> Definitely needs proposals on how to change, and/or some code examples. But, the concepts sound good
[20:05] <tdonohue> ok. so, we can just add a few comments to this ticket. Essentially, needs a volunteer to start investigating options & even perhaps beginning some development
[20:05] <tdonohue> So, we'll move along for now...
[20:05] <tdonohue> next up, DS-972
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-972 ] - [#DS-972] Mirage theme choice-support.js breaks on more results - DuraSpace JIRA
[20:06] <mhwood> Problem description is unclear to me.
[20:07] <tdonohue> hmm..not sure how this got overlooked. Has a patch and everything. Anyone interested in trying out this fix?
[20:08] <tdonohue> yea, I think the details are lacking on the problem... so we'd need someone to test this out. I'm assuming this has to do with the autocomplete functionality on fields in Mirage
[20:09] <tdonohue> I believe there's an option to "show more results", which he's claiming is broken. The autocomplete is driven by /Mirage/lib/js/choice-support.js (which in turn uses jQuery)
[20:10] * vtkeithg (~vtkeithg@2001:468:c80:a103:9c2e:f59c:efce:3767) has joined #duraspace
[20:10] <tdonohue> Any volunteers to try this out and see (1) if this really is broken, and (2) if so, whether the patch fixes it
[20:10] <hpottinger> steps to reproduce the problem would be helpful
[20:12] * keithg (~keithg@2600:1002:b00d:3c66:5651:80cb:fab9:bde2) Quit (Quit: Bye)
[20:12] * vtkeithg is now known as keithg
[20:13] <tdonohue> I think the steps required are to essentially just turn on Mirage, turn on authority control, and then type something into a submission UI textbox (e.g. subject box). After it displays some possible values, there should be a "more" option you can click on.
[20:13] <tdonohue> (but, this is just my guess)
[20:15] <tdonohue> Ok, I can try and take a look at this one. I think I know what he's talking about (but we'll see) . Assign Ds-972 to tdonohue
[20:15] <tdonohue> we can stop the JIRA review there for today.
[20:16] <tdonohue> next topic I had on the agenda was updates on the GitHub migration: https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub I've been a bit out-of-the-loop and was wondering where things currently stand.
[20:16] <kompewter> [ Migration to GitHub - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub
[20:16] <PeterDietz> hi tdonohue, glad your back
[20:17] <tdonohue> thanks :) glad to finally be back after 2 weeks
[20:17] <PeterDietz> I tried to cover this topic for the past few meetings. I've been meaning to send out a dspace-devel "Welcome to the era of GitHub" email for the past week
[20:17] <PeterDietz> So, to catch up. the DSpace/DSpace is good now.
[20:18] <mhwood> Small experiment: I fixed up the README in my fork and fired a pull request. Nobody commented, and after a few days mdiggory merged it.
[20:18] <PeterDietz> old DSpace/DSpace got renamed to DSpace/DSpace-SVN-Deprecated
[20:18] <PeterDietz> sorry for not reviewing that mhwood.. Our best laid plans still require humans to review
[20:19] <mhwood> Oh, and the POMs all had outdated SCM info. I think mdiggory fixed that too.
[20:19] <tdonohue> ok cool. So, it sounds like we've only really migrated the main codebase (which is fine -- it's what's most folks care about). Looks like we still have several others to do: dspace-services, dspace-pom, dspace-assembly-plugin, etc.
[20:20] <tdonohue> i.e. we are ready to start *developing* in GitHub. But, currently, it sounds like we are in a state were we really couldn't do a Maven *release* (which is fine again), as we are missing several key codebases required for a release
[20:22] <tdonohue> So, it sounds like to me: (1) we should draft up an announcement to let folks know that development has moved to GitHub (and make sure this gets on dspace-commit too). (2) we need to continue to migrate the other projects/codebases and likely even do a test Maven release at some point.
[20:23] <PeterDietz> yep
[20:24] <PeterDietz> I got somewhat distracted since I'm been trying to think about how i18n fits in. (i.e. collapsing the dspace-api-lang and dspace-xmlui-lang repos into DSpace/DSpace)
[20:24] <tdonohue> cool. I just wanted to make sure I understood where we were (I thought I did, as I read last few weeks meeting notes, but wanted verification)
[20:25] <tdonohue> yea, I think we need to wait on the i18n question a bit. Lots of discussion going on on dspace-tech (obviously), which in my opinion may affect how we want to move forward with translations in the future. (I'm planning to chime in on dspace-tech too -- just still catching up)
[20:26] <mhwood> Has anyone looked at the I18N proposal over in -devel?
[20:26] <tdonohue> so, I'd propose we migrate things to GitHub mostly as-is, and reorg things later as needed. That way we can get everything over (and avoid slowing down development on any one module) and then rethink things afterwards
[20:27] <mhwood> Yes, it would be neater to reorg and then migrate, but reorg should not slow down migrate unduly.
[20:27] <tdonohue> mhwood -- yea, I saw small thread on dspace-devel: http://sourceforge.net/mailarchive/message.php?msg_id=29028526
[20:27] <kompewter> [ SourceForge.net: DSpace: ] - http://sourceforge.net/mailarchive/message.php?msg_id=29028526
[20:27] <hpottinger> re-org after migrate is potentially more transparent
[20:28] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:28] <tdonohue> mhwood: But, to be honest, I wasn't sure exactly what the full proposal is -- other than: "what if we use transifex.net" (which sounds like an interesting idea, to be honest, but I'm not sure if it meets all concerns that have been posed?)
[20:30] <mhwood> That's the author's idea. We chatted a bit on IRC before his posting. I tried to generalize a bit. I don't mean to advocate for or against it yet, but I think it's worth some discussion.
[20:30] <mhwood> Trouble is, everyone has his favorite: transifex, Pootle....
[20:30] <tdonohue> yep, i agree. I think transifex.net should definitely be part of the discussion as a potential solution. Just have never used it before, so I don't know if it gets us 50% there, 90% there or 100% there
[20:31] <mdiggory> [20:19] <mhwood> Oh, and the POMs all had outdated SCM info. I think mdiggory fixed that too. <--- Yes, did this, but we still need to test releasing with git and the new settings.
[20:32] <mhwood> I think what's in it for DSpace is some management tools for translation, and potentially a larger group of translators (and languages).
[20:32] <tdonohue> I plan to start up some form of "How can we improve i18n" wiki page for us to better capture these concerns, ideas, and proposals in a single place. Discussion on lists is excellent, but we need to capture main points somewhere where it's easier to work from & create actionable items from.
[20:33] <mhwood> I have long thought that the translation process should be a bit more organized.
[20:33] <mdiggory> Yes, please transfer first, then reorg afterwards.
[20:33] <tdonohue> (I was hoping to get that page actually started *before* this meeting, but I didn't make it around to it today -- should have it up there tomorrow & will post back to the -tech thread)
[20:35] <tdonohue> Ok. Anything else on the GitHub front? Is anyone taking the lead on transferring those projects that still need transferring to GitHub? (e.g. dspace-services, dspace-pom, dspace-assembly-plugin, etc)
[20:35] <mdiggory> I think I can take the lead on DSpace Services
[20:35] <PeterDietz> I wasn't planning on touching those sub-projects
[20:35] <tdonohue> projects needing transfer to GitHub (that I am aware of) are listed here: https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub
[20:35] <kompewter> [ Migration to GitHub - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub
[20:35] <mdiggory> I'm still weighing dspace-pom
[20:36] <tdonohue> mdiggory -- thanks
[20:36] <tdonohue> "weighing"? how so?
[20:36] * mhwood is curious what dspace-assembly-plugin does that current maven-assembly-plugin does not. I should go read code....
[20:36] <mdiggory> after the various attempts to get buyin on the async release process. I think its somewhat clear that we do not have traction in that area
[20:37] <mdiggory> I"m weighing if consolidating dspace-pom into dspace-parent again would / wouldn't be beneficial
[20:37] <mdiggory> I would like to see opinions from the community.
[20:38] <tdonohue> mhwood -- dspace-assembly-plugin is basically just our settings to generate our WARs for release. It might be that it could be moved into the main DSpace/DSpace project eventually
[20:38] <mdiggory> mhwood: dspace assembly has our release and src-release assembly.xml in it.
[20:39] <mhwood> So it's not actually a plugin, but configuration for the plugin? Definitely must go read.
[20:39] <mdiggory> in theory, these could go in DSpace/DSpace/trunk/src/main/assembly
[20:39] <tdonohue> mdiggory -- so, to tease out dspace-pom stuff. If dspace-pom was combined into dspace-parent, then external modules could still use it as a "parent", but they would just have to wait until after a DSpace release. That seems reasonable
[20:40] <mdiggory> basically.
[20:40] <tdonohue> mhwood -- correct. It's configuration of a plugin, that was put in a separate "repository" so that it could be used by many modules. But, in truth, it's only used by dspace-parent POM right now.
[20:41] <mhwood> Yes, I see it now.
[20:42] <tdonohue> So, I'd be OK with looking at consolidating dspace-pom and dspace-assembly-plugin into DSpace/DSpace. I'd even be willing to help implement that (though I may not get to it until next week)
[20:42] <mdiggory> I think my original need there was that it somehow leaked into the subprojects when we were putting these directly into dspace-parent src
[20:45] <tdonohue> ok. Anything else on GitHub? I'd be glad to help chip in by looking more at dspace-pom and dspace-assembly-plugin
[20:45] <mdiggory> SWORD is int he process of now migrating to github as well.
[20:46] <tdonohue> PeterDietz -- did you start drafting up any sort of GitHub announcement? I'd be glad to help with that too, or just draft it up if you haven't gotten to it yet
[20:46] <mhwood> Is there some sort of standard for the path to assembly descriptors? I see src/main/resources/assemblies in dspace-assembly-plugin, dspace/src/assemble in the core, and I got the idea from somewhere in the Maven site that they go in src/main/assembly.
[20:46] <mdiggory> note, when I did the maven project consolidation branch... our org.purl.sword source now differs from the original sword 1.1 version
[20:47] <mdiggory> I was not able to drop these classes so they could be shared for the SWORD 1.1 release that went into maven central
[20:48] <tdonohue> mhwood -- you can setup your own location in the pom.xml. I'd recommend we look towards doing [dspace-src]/dspace/src/main/assembly/ (Or something like that). I'm not a fan of the [dspace-src]/src/ directory as it implies to me that you can find all the Source code there.
[20:48] <mdiggory> this was work that happened in the Packagers by you tdonohue (certainly beneficial but did alter things)
[20:49] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[20:49] <tdonohue> mdiggory: I don't understand. Cannot recall what the Packagers have to do with org.purl.sword
[20:50] <mhwood> GitHub miscellany: I've pushed a couple of branches up to my fork, on which I wasn't quite ready to ask for comment, but maybe it's a good time for someone to look at the testing-env branch and see at least the assembly stuff.
[20:50] <mdiggory> File vs InputStream.....
[20:50] <tdonohue> mdiggory: I probably just need to look at the SWORD v1 code again. It's been a while
[20:51] <tdonohue> ( I do recall that I changed the Packagers in terms of File v. InputStream though -- just don't recall how this changed SWORD code)
[20:52] <mdiggory> Git to the rescue....
[20:52] <mdiggory> https://github.com/DSpace/DSpace/blame/075a913755a709ad796d522c4c71f11f81d70623/dspace-sword/dspace-sword-api/src/main/java/org/purl/sword/server/DepositServlet.java
[20:52] <kompewter> [ DSpace/DSpace at master ยท GitHub ] - https://github.com/DSpace/DSpace/blame/075a913755a709ad796d522c4c71f11f81d70623/dspace-sword/dspace-sword-api/src/main/java/org/purl/sword/server/DepositServlet.java
[20:53] <mdiggory> ;-)
[20:53] <tdonohue> in any case, it sounds like GitHub stuff is moving along well & we have some next steps: (1) announcement, and (2) keep moving projects over. The only other step is to start to determine our GitHub best practices. I'm sure there may be some initial "bumpiness" in our future, but we'll figure it out
[20:53] <mdiggory> yes, this is a tangent.... the migration itself has gone very well
[20:54] <mhwood> It's working well for me, except that I'm still such a Git noob.
[20:55] <tdonohue> yea. I think the one thing I accidentally discovered is that it's good to create lots of branches in Git. I once did a "pull request" from my "master" and then continued to develop on "master".
[20:55] <mdiggory> Another tangent.... a caveat I discovered in the maven release process and github... it will push to the origin if your try to release without an opportunity for you to review the release in your local repo before pushing to origin...
[20:55] <tdonohue> The end result is that when the "pull request" was accepted, it included my *absolute* latest code on "master" (and not the code from when I initiated the "pull request")
[20:56] <tdonohue> (this came as an initial surprise to me -- but, it now makes sense)
[20:57] <mdiggory> origin/master or master?
[20:57] <tdonohue> in any case, when any of you discover something by "accident" (or otherwise) we should start to write these things down. They likely will be useful to everyone else, and may be the start of "best practices"
[20:58] <mdiggory> I will admit, I still struggle with fully understanding all the use cases for the distributed commands (pull, push, rebase)
[20:59] <tdonohue> mdiggory -- I was talking about the public copy of my "master" branch. As I committed more code there, I didn't realize that it was being included in that open "pull request" (as the pull request was pointing back at that "master" branch)
[20:59] <mhwood> Yeah, I would have thought that a pull request would refer to a commit, not a branch.
[20:59] <mdiggory> the pull request was to "pull" your master back to "origin/master"?
[21:00] <tdonohue> i.e. the lesson is that Git (and GitHub) almost wants you to create lots of branches. If I would have done my little work in a small branch, and then initiated the "pull request" from that branch, all would have been fine.
[21:01] <tdonohue> The pull request was to pull my forked "master" into "DSpace/dspace-replicate/master" actually. So, it was while I was playing around with GitHub development with the dspace-replicate module.
[21:01] <tdonohue> The whole idea here is that a "pull request" in GitHub points at a *branch* (like mhwood said). It does not point at a specific commit (or set of commits). So, if you update that branch, it will update your pull request
[21:02] <mdiggory> I think its that pull has two usecases that creates confusion "pull request" and "pull as 'fetch'"
[21:03] <tdonohue> I'm talking about a "pull request" (i.e. pressing that "Pull Request" button in GitHub's UI). The "Pull request" points at a branch. So, when the actual "pull" occurs, it will pull the latest version of that branch at all times
[21:03] <mhwood> The difference is that when you 'pull', you fetch and merge the state of the remote *now*, but when you request pull, the remote tree gets what your tree has *later*, when the 'pull' happens.
[21:04] <mdiggory> Yes, they are in opposite directions
[21:05] <mdiggory> seems I've not yet experienced "Pull Request"
[21:05] <tdonohue> yea, it's just something that we all need to be aware of. As it can potentially mean we'd accidentally pull in code into DSpace/DSpace (when someone "accepts" a pull request) that we didn't expect to.
[21:06] <tdonohue> mdiggory -- you actually were a part of one already (on the opposite end). mwhood submitted a "pull request" to DSpace/DSpace, which you then accepted and actually initiated the "pull" part of it.
[21:07] <mhwood> Luckily I hadn't done any more work on master since the request.
[21:07] <mdiggory> I did do that, and yes that can be dangerous because I did not fully understand what I was doing
[21:07] * tdonohue notices we are running over time. Not going to stop discussion here though
[21:08] <KevinVdV> *Needs to run*
[21:08] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :))
[21:08] <tdonohue> yep. exactly. It would have been "dangerous" had this happened: (1) mhwood submitted "pull request" of his "master" branch, (2) mhwood continued to add some new untested code on his "master" branch, (3) mdiggory than accepted the "pull request" and merged (pulled it).
[21:09] <tdonohue> the end result obviously would have been that we would have seen the new "untested code" also make it into DSpace/DSpace as part of #3
[21:09] <mhwood> Which is why I've been inventing new branches in my fork for the *other* stuff I've been up to.
[21:10] <mdiggory> So can we protect the pull request in some way so that those in our commiter group that do not fully know how to review the pull and decide on it do not accidentally just walk through it.
[21:10] <mhwood> But I hadn't really thought about the nature of pull requests, and it's just luck that something else didn't get into that merge.
[21:10] <hpottinger> so, bugfix branches are the best practice here?
[21:10] <tdonohue> yep. that's a good approach, mhwood. It may need to become part of our "GitHub best practices". We obviously want to avoid any "dangerous" or unexpected merges into DSpace/DSpace
[21:11] <mhwood> _Pro Git_ asserts that branches are so wonderful, you'll use them daily.
[21:11] <tdonohue> hpottinger: it may be the case. Fedora actually has a best practice that you create a new branch for each *Jira Ticket* you work on -- i.e. you'd have a branch called "Ds-1010" if you were working on that ticket
[21:11] <tdonohue> Fedora's best practices: https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[21:11] <kompewter> [ Git Guidelines and Best Practices - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[21:12] <richardrodgers> yes, from our backgrounds, we have to overcome the presumption that branching is expensive/messy (as it was in CVS/SVN)
[21:12] <mdiggory> So I have to run. But I've been doing branches in both my own fork and in DSpace/DSpace. My intention in doing them directly in DSpace/DSpace is to assure that everyone is aware of the maven-consolidation-branch and its intended results.
[21:12] <tdonohue> +1 richardrodgers
[21:14] <mdiggory> I think this will be the next important change to consider. Please do review https://jira.duraspace.org/browse/DS-1144
[21:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1144 ] - [#DS-1144] Maven Project Consolidation - DuraSpace JIRA
[21:14] <kompewter> [ [#DS-1144] Maven Project Consolidation - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1144
[21:14] <tdonohue> ok. Sorry we got a bit off-agenda today. But, I think the GitHub discussions are worthwhile. I'm not going to step into any other topics for today. But, I will hang around for a while if anyone has anything to bring up
[21:14] <richardrodgers> gotta run
[21:14] <tdonohue> (otherwise, you are also welcome to head out as you need to)
[21:14] <mhwood> I have to go too.
[21:14] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:14] <hpottinger> tdonohue, we've been trying to do that with SVN here, for major bug fixes... the jump in thinking is, as Richard points out, getting past the idea that we only branch for "hard stuff" because "branching is hard"
[21:14] <mdiggory> thanks, likewise, bye
[21:15] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[21:15] <tdonohue> hpottinger: yep. I agree. It's a new frame of mind. I've also been reading ProGit online (http://progit.org/book/) which does a good job of talking you through why branches are not "hard" in Git, and you should use them for everything (even small fixes)
[21:16] <tdonohue> that being said, I still haven't managed to get myself to branch *that* frequently either. It's a matter of changing my own habits as well
[21:16] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:21] <hpottinger> thanks for the book tip, tdonohue, I've got a request in for Pragmatic guide to Git, and sure enough, it's waiting for me at the circ desk...
[21:25] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[21:30] * hpottinger wanders off to pick up his book.
[21:40] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[21:46] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:52] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.