Timestamps are in GMT/BST.
[3:26] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[4:08] * eddies (~eddies@bb116-14-211-50.singnet.com.sg) has joined #duraspace
[4:08] * eddies (~eddies@bb116-14-211-50.singnet.com.sg) Quit (Changing host)
[4:08] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:35] -wolfe.freenode.net- *** Looking up your hostname...
[6:35] -wolfe.freenode.net- *** Checking Ident
[6:35] -wolfe.freenode.net- *** Found your hostname
[6:35] -wolfe.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:49] * lyncode (~DSpace@bl23-47-147.dsl.telepac.pt) Quit (Quit: lyncode)
[8:00] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[8:01] * eddies (~eddies@bb116-14-211-50.singnet.com.sg) has joined #duraspace
[8:01] * eddies (~eddies@bb116-14-211-50.singnet.com.sg) Quit (Changing host)
[8:01] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[8:24] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) has joined #duraspace
[11:27] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[11:39] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) Quit (Quit: lyncode)
[11:42] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[11:42] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[11:42] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:11] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:13] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) has joined #duraspace
[13:10] * vtkeithg (~vtkeithg@2001:468:c80:a103:709d:6937:a708:f964) has joined #duraspace
[13:26] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:27] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) Quit (Quit: lyncode)
[14:34] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has joined #duraspace
[15:09] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) has joined #duraspace
[16:52] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Ping timeout: 246 seconds)
[16:55] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[17:01] <tdonohue> Hi all, my "DSpace Office Hours" are starting now. https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours Ping me if there's anything you'd like to discuss today.
[17:21] * vtkeithg (~vtkeithg@2001:468:c80:a103:709d:6937:a708:f964) has left #duraspace
[17:35] <lyncode> Hi, does DSpace has any defined directory to store runtime generated files?
[17:41] <mhwood> No. Each subsystem that wants to generate files defines a new one under [DSpace]. So we have /exports, /handle-server, /log, /reports, /search, /solr, /upload.
[17:45] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[17:47] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[17:47] <lyncode> thanks
[18:34] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) Quit (Quit: lyncode)
[18:44] * blob (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[18:46] * blob (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Client Quit)
[18:47] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[19:01] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[19:18] * keithgilbertson (~Adium@cvl13.ece.vt.edu) has joined #duraspace
[19:22] * lyncode (~DSpace@bl23-47-147.dsl.telepac.pt) has joined #duraspace
[19:32] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:32] * helix84 (a@195.113.97.174) has joined #duraspace
[19:39] * lyncode (~DSpace@bl23-47-147.dsl.telepac.pt) Quit (Quit: lyncode)
[19:46] * KevinVdV (~kevin@d54C154B1.access.telenet.be) has joined #duraspace
[19:46] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[19:52] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:55] <tdonohue> Hi all, the DSpace Dev Mtg starts in ~5mins : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-27
[19:55] * hpottinger waves.
[19:56] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[19:56] <tdonohue> yea! kompewter decided to join us :)
[19:56] * PeterDietz (~peterdiet@128.146.173.59) has joined #duraspace
[19:58] <PeterDietz> I'm thinking my keep a remote ssh-session open to a server strategy to keep kompewter alive, isn't the best for uptime
[19:59] <tdonohue> PeterDietz -- I think I've offered this before, but we really could just move kompewter over to demo.dspace.org, if that makes things easier
[20:00] <helix84> PeterDietz: why keep ssh connected? what about using screen or tmux?
[20:00] * PeterDietz doesn't dive into these types of dark arts
[20:01] <tdonohue> Ok, looks like we got quite that group today! welcome all! https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-27
[20:01] <kompewter> [ DevMtg 2012-06-27 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-27
[20:01] * helix84 starts his voodoo chant
[20:01] <tdonohue> We'll start things off with JIRA reviews as normal https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1065+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1065 ] - [#DS-1065] Required "id" attribute for every node in controlled vocabularies - DuraSpace JIRA
[20:01] <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-1065+ORDER+BY+key+ASC
[20:01] <tdonohue> beginning with DS-1065
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1065 ] - [#DS-1065] Required "id" attribute for every node in controlled vocabularies - DuraSpace JIRA
[20:01] <mhwood> If it quacks like a daemon....
[20:03] <tdonohue> Ds-1065 sounds like a minor little bug, but I'm not familiar enough to say for certain. Anyone want to investigate?
[20:03] <mhwood> Ds-1065 obviously a bug.
[20:03] <mhwood> Sure, I'll take it.
[20:03] <tdonohue> Ok, Ds-1065 Summary: Assign mhwood. Thanks mark!
[20:03] <tdonohue> next up DS-1067
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1067 ] - [#DS-1067] Add ability to auto-merge old configs with new configs during 'ant update' - DuraSpace JIRA
[20:04] <helix84> ouch, more voodoo
[20:04] <tdonohue> Oh, this was an "experiment" by me. I got frustrated one day by how you have to always reconfig dspace. This isn't really "fully functional"
[20:04] <hpottinger> I like the idea, though
[20:04] <tdonohue> but, if it is of interest to others, I'd encourage someone to pick it up / take a look.
[20:05] <tdonohue> (I.e. this is likely not something I'm gonna get back to anytime soon)
[20:05] <helix84> i'd prefer having config options in the database instead of more maven magic :(
[20:05] <mdiggory> agree with helix84
[20:05] <tdonohue> yea..this is actually "ant magic". But, I agree. Moving configs to DB would resolve this in a better way
[20:05] <tdonohue> should we leave this open? Close it? (I won't take offense)
[20:06] <mhwood> OK, but that just moves the magic to code that grubs through the database.
[20:06] <tdonohue> DB "magic" code is much easier than "text file parsing" magic code (which is what some of Ds-1067 is)
[20:06] <mhwood> Yes, but the hard part is the magic.
[20:06] <helix84> mhwood: yes, but that allows you to actually write a UI for merging, to transfer and backup configs etc
[20:07] <hpottinger> I think it would be somewhat helpful to present this in a way to help the people who might make use of it the most: infrequent updaters; i.e. not a magic update, but a, "here, your new configs might look something like this..."
[20:08] <helix84> in the merging UI you could even have nice colored diffs, information notes, deprecation warnings, upgrade instructions... i could go on
[20:08] <mhwood> I like the idea.
[20:08] * lyncode (~DSpace@bl23-47-147.dsl.telepac.pt) has joined #duraspace
[20:09] <helix84> think of wordpress - you can configure everything from the UI. completely noob-proof
[20:09] <tdonohue> I also like the idea of doing this from UI / DB. But, we are kinda heading into conceptual areas here (which would be great for someone to start a wiki page / ticket on, if they have plans to work towards this)... Any "resolution" for this ticket?
[20:10] <mhwood> Actually, if the bulk of the config. is in the DB then we *have to* address that as part of the upgrade.
[20:11] <tdonohue> I'm gonna suggest we just close this Ds-1067 ticket, as it sounds like other approaches are favored (though we need to start thinking of ways to develop out these other approaches in the future).
[20:11] <mhwood> If config moves to DB then we should take the opportunity to *make it* more readily upgradeable.
[20:11] <helix84> OK, we don't have to solve the configuration problem right now. I'm -1 for this issue, sorry Tim.
[20:11] <hpottinger> I don't think there's any harm to add this optional target to the ant script, if we could revamp it to make it more of a suggestion than an auto-upgrade
[20:11] * tdonohue takes no offense. I already said we should just close it ;)
[20:12] <tdonohue> hpottinger -- it could be revamped to be an additional 'ant' option
[20:12] <helix84> hpottinger: I think the harm is when we add it, someone begins to use it and we'll have to maintain it, that's all.
[20:14] <mhwood> Sounds like people want to see this happen but in a different way. Is that a resolution?
[20:14] <hpottinger> helix84 has a good point, the patch is in Jira if anyone wants to play with it, I think the idea can wait for DB-based config
[20:15] <tdonohue> Ok, I'm going to close Ds-1067 for now & state that it's not going to be accepted out-of-the-box. If someone wants to "revitalize" this ticket or play with it more, feel free. We can always reopen it or create a new ticket if something better comes about
[20:17] <tdonohue> Ok. We'll end the "JIRA Review" for today.
[20:17] <tdonohue> Though we're gonna jump to the ticket briefly that robint asked us for feedback on : DS-1172
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-1172 ] - [#DS-1172] Add basic Spring based DAOs - DuraSpace JIRA
[20:17] <robint> Hi all
[20:17] <robint> I'm really just trying to push this along
[20:18] <mhwood> [All] Hi, robint.
[20:18] <robint> Let me say that I think the suggestions Mark made would be an improvement on what I posted
[20:18] <robint> I also think there are probably other better solutions
[20:19] <robint> But I am a little short on time and want to move on to actually moving the sql out of the model classses
[20:20] <robint> I believe the existing pull request would bet better than the current code and would allow us to move to something better in due course
[20:20] <tdonohue> https://github.com/DSpace/DSpace/pull/22/files (direct link to changes)
[20:20] <kompewter> [ Pull Request #22: [DS-1172] Add basic Spring plumbing for DAOs by robintaylor · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/22/files
[20:20] <mhwood> Nothing stuck out as obviously wrong and it seems a good step on the way to removing DBMS-specificity from the code.
[20:20] <robint> So unless anyone has the time to post an alternative I'm hoping we could merge this change
[20:21] <tdonohue> This looks OK to me. I think mdiggory had good points, but I also agree with you (robint) that we can refactor more later (and more easily) if we felt the need.
[20:22] <hpottinger> I think this is a really cool development, and I'm happy you've taken it on, robint
[20:22] <mhwood> Yes, bring this in now and we can build on it.
[20:23] <tdonohue> so, robint, would your plan be to take this on across the data model for 3.0? & this pull request is just meant to show a sample for Collections?
[20:23] <robint> yes
[20:23] <tdonohue> I'm +1
[20:23] <robint> Get as much of the sql out of the model classes as possible before 3.0
[20:24] <robint> If others would like to join in that would be great :)
[20:24] <hpottinger> +1 for me, and how can we help?
[20:24] <tdonohue> (One thing I wonder is if we need to "track this" a bit better -- wiki page maybe? So that others could chip in more easily and know which areas are "done" and which haven't been touch)
[20:24] <robint> Plus, if we have time we could review the plumbing once we have some DAOs
[20:24] <mdiggory> Hi sorry, doing two things at once
[20:25] <robint> tdonohue: yep, good idea
[20:25] <mdiggory> My original point to robint was that the Postgres and oracle code all contain 95% of the same code
[20:26] <mdiggory> the only real difference between Oracle and Postgres sql statements involves the use of null vs "" and maybe a couple other types
[20:26] <mhwood> LIMIT
[20:26] <lyncode> sorry, i was watching your conversation. DAO seems fine, to have an abstraction layer over the Database layer. But.. DAO is getting known as anti-pattern http://rrees.wordpress.com/2009/07/11/the-dao-anti-patterns/. Are you considering it?
[20:27] <mdiggory> the correct way this should have been handled would have been to burry all the differences in DatabaseStorageManager, then there would not be any "oracle vs postgres" code in any of the data model
[20:27] * robint_ (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:27] <robint_> Sorry, dodgy connection, did I miss anything ?
[20:28] <tdonohue> we're logged robint_ : http://irclogs.duraspace.org/index.php?date=2012-06-27 (You may have missed a few comments)
[20:28] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2012-06-27
[20:28] <mdiggory> DatabaseManager + Some of the code dealing with CRUD in the Data model "are" just one of many persistence strategies...
[20:29] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Ping timeout: 245 seconds)
[20:29] <robint_> I accept all the comments about alternative strategies and the shortcomings of what is currently posted
[20:30] <tdonohue> mdiggory: so what are you suggesting? do you have an alternative in mind that is "doable" for 3.0?
[20:30] <mdiggory> and what lyncode says about antipatterns can be taken into consideration... but that article points at a "Data Mapper" pattern that IMO, isn't much different than a DAO
[20:30] <robint_> But I don't want to get to August still considering alternative strategies
[20:30] <mdiggory> Neither to I, I'm not suggesting implementing any of those alternative persistence mechanisms at all
[20:31] <mdiggory> I'm just saying move the legacy code into one dao, not two
[20:31] <mdiggory> its actually less work
[20:32] <mdiggory> IE LegacyCollectionDAO, not PostgresCollectionDAO and OracleCollectionDAO
[20:32] <tdonohue> mdiggory -- I'd say "potentially" less work. You still may have to muck around with "if (oracle) [option#1] else [option#2]" stuff though
[20:32] <mdiggory> leave that up to later DAO coding in
[20:32] <robint_> But we have a pull request for one option currently on the table
[20:32] <mdiggory> future versions....
[20:33] <robint_> Are you offering to post an alternative ?
[20:33] <mdiggory> robint_: the PullRequest is only just for the Collection DAO correct, the rest of the model isn't yet ported....
[20:33] <robint_> correct
[20:34] <robint_> Ah ok
[20:34] <mdiggory> so theres still Site, Community, Item, Bundle, Bitstream, and numerous supporting objects to port still.
[20:34] <tdonohue> robint_ : I think mdiggory is stating that his "alternative" is nearly identical to the current pull request, except that he collapses PostgresCollectionDAO and OracleCollectionDAO into a single "LegacyCollectionDAO" (as the two classes are nearly identical anyways)
[20:34] <robint_> If you don't object we could accept the current pull request
[20:35] <robint_> tdonohue:understood
[20:35] <robint_> mdiggory: but code the rest as you suggest
[20:35] <robint_> and then refactor the Collection code to bring it in line
[20:36] <robint_> Just trying to avoid having to retest what is there and post another pull request
[20:36] <mdiggory> To clarify, what I am pushing back on is selecting the dao based on database vendor vs persistence mechanism
[20:37] <mdiggory> robint_: you realize the Pull Request is "live", if you alter your branch, the changes are expressed int he pull request?
[20:37] <mhwood> [tangent] It almost seems as though what one needs is a domain-specific language for manipulating the data model, a translator that recognizes it, and 1..N backends that produce nearly-optimal "code" for various persistence mechanisms.
[20:37] <mdiggory> you can rollback your changes, refactor, add new commits to your hearst content without having to redo the pull request
[20:37] <tdonohue> yea, Pull request code can be altered directly/easily. Robint, if you just commit new code to your "DS-1172" branch it will auto-appear in that pull #22
[20:37] <kompewter> [ https://jira.duraspace.org/browse/DS-1172 ] - [#DS-1172] Add basic Spring based DAOs - DuraSpace JIRA
[20:38] <robint_> Yes, I know its a trivial change, but we have to draw a line somewhere and commit
[20:38] <robint_> Bear in mind that this is the third pull request posted
[20:39] <mdiggory> well, I kinda did just draw the line int he sand... (sorry I say that in a most polite manner)
[20:39] <robint_> mdiggory: :)
[20:40] <mdiggory> robint_: this will probbily simplify some of the issues with selecting the appropriate DAO.
[20:41] <robint_> mdiggory: agreed
[20:41] <robint_> ok, I give in :)
[20:41] <mdiggory> this wierdness can get removed and the DOA provider selected exclusively via spring configuration...
[20:41] <mdiggory> https://github.com/robintaylor/DSpace/commit/3e504ad6548d36bfba10f11858741e63e4a05ae8#L5R39
[20:42] <robint_> I'll update the pull request. This has been useful. Thanks
[20:42] <mdiggory> the selection of the databse vendor can stay in the Configuration / DatabaseManager
[20:42] <mhwood> At the very least, we can remove some configuration stuff and just ask the driver what DBMS it's for.
[20:42] <tdonohue> It sounds like we have an agreement around a "Legacy[Object]DAO" then & the pull request will get updated (thanks robint!).. and that we likely should start up a Wiki page (or something) to track status & allow others to more easily help out.
[20:44] <tdonohue> Ok, we'll go ahead and move on to other topics then.... feel free to continue discussion on Ds-1172 and/or dspace-devel.
[20:44] <robint_> I'll bash on, apologies for hogging the meeting. Cheers
[20:44] <mdiggory> mhwood: I actually thought about some of that a bit and I concluded that take something like the null issue that is seeded throughout the code... db != "oracle" ? null : ""
[20:44] <mdiggory> thanks robint_, again, if you want me to aid in any manner just ping me
[20:45] <robint_> Will do, thanks
[20:45] <mdiggory> that above code should have been hidden in DatabaseManager.getNull()
[20:45] <mhwood> mdiggory++
[20:45] <tdonohue> Ok, next up. I wanted to mention that this is the *last* "official" DSpace Developer Meeting before OR12. I'll be out next week (July 4 is a US holiday), and OR12 is July 9-13. So, that means our next "official" meeting is Weds, July 18.
[20:45] <mdiggory> and some of the other nuances could have been hidden as well.
[20:46] <tdonohue> (If individuals want to meet "unofficially" either of the next few weeks, you are welcome to do so.. just no "official" meeting)
[20:47] <helix84> i'll be here
[20:47] <tdonohue> The OR12 Face-to-Face Meeting Agenda is mostly "finalized" (may be small tweaks, but nothing major): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:47] <kompewter> [ DevMtg 2012-07-09 - OR12 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:47] <hpottinger> if you *are* going to OR12, I invite you to fill out your Crowdvine profile: http://or2012.crowdvine.com/
[20:47] <kompewter> [ Open Repositories 2012 - Home (CrowdVine) ] - http://or2012.crowdvine.com/
[20:48] <tdonohue> There's also now a location posted on that meeting page (thanks robint for helping set things up for us)
[20:49] <tdonohue> One question I did have about the OR12 Meeting is if there's anyone who will be attending that'd be willing to help out Richard Rodgers by leading a discussion? Essentially all the Discussion topics for the Afternoon don't have a leader yet: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:49] <kompewter> [ DevMtg 2012-07-09 - OR12 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:50] <tdonohue> There's two main sessions needing a discussion leader: (1) "3.0 Planning" Session (which I assume one or more 3.0 Team Members could help with -- not sure who all will be there though), and (2) "Discussions of DSpace Developer Practices" session
[20:50] <tdonohue> if you would be willing to lead/co-lead or even just help out Richard, please get in touch with Richard & I
[20:51] <robint_> I'd happily help out, 3.0 might be a sensible choice in Sands absence
[20:52] <tdonohue> That'd be great robint_! Thanks. Yea, as far as I know Sands won't make it.
[20:52] <mdiggory> I can contribute some assistance in leadership if needed
[20:53] <tdonohue> mdiggory -- care to lead / co-lead discussion on the "DSpace Developer Practices" session. Essentially it's an open ended discussion of how we can improve developer workflows (JIRA/GitHub/etc). You don't even need to prepare anything
[20:53] <mdiggory> but will differ to robint_ if he's also interested (think we were typing at the same time)
[20:53] <tdonohue> that was supposed to be a question : "care to lead / co-lead discussion on the "DSpace Developer Practices" session?"
[20:53] <robint_> Happy either way
[20:54] <tdonohue> there's two sessions...so, you can each have one, if you want it ;)
[20:54] <tdonohue> For example: 3.0 -> Robint , Developer Practices -> mdiggory
[20:54] <mdiggory> I'll take the session at the Pair Tree House
[20:54] <robint_> lol
[20:54] <tdonohue> haha...
[20:55] <hpottinger> as discussion leader, I think you do have final say over the choice of venue... :-)
[20:55] <mdiggory> ba dum dum
[20:56] <hpottinger> +1 this: 3.0 -> Robint , Developer Practices -> mdiggory
[20:56] <mdiggory> robint_: your pretty active on the release team?
[20:56] <tdonohue> to be clear, neither of these sessions requires any preparation really (no slides necessary). You just need to kick off the discussion topic and perhaps pose questions / keep discussion flowing along.
[20:56] <tdonohue> robint_ is on the 3.0 release team :) so that's "active"
[20:56] <mdiggory> hpottinger: I think I'm ok with that
[20:57] <mdiggory> Ok... pencil me in for Developer Practices
[20:57] <tdonohue> Ok, I'll "pencil in" : 3.0 -> Robint , Developer Practices -> mdiggory If you change you minds on the day-of, or want to hand it over to Richard, I'm sure he won't mind.
[20:58] <robint_> Sounds good
[20:58] <tdonohue> Ok, we're running out of time here. But, I did just want to send out a notice about some "brainstorms" I've had about reworking our JIRA workflows
[20:58] <tdonohue> https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[20:58] <kompewter> [ JIRA Workflow Improvements - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[20:59] <tdonohue> This could really just be a topic in that "Developer Practices" session at OR12 (which mdiggory is penciled in for). It's just brainstorms, but I think it's worth discussing at some point
[20:59] <tdonohue> (though today we are a bit "out of time")
[20:59] <helix84> i agree that Open and In progress seem to be currently redundant
[21:00] <mdiggory> tdonohue I agree
[21:00] <helix84> i mean they're used interchangeably
[21:00] <mhwood> In Progress is to measure things we don't track.
[21:01] <helix84> mhwood: what does that mean?
[21:01] <tdonohue> Essentially the goal here is to better clarify *why* some JIRA issues are just "sitting around". That wiki page had my brainstorm of a new workflow. But, it could definitely use more eyes/feedback before we jump in and do anything different
[21:01] <robint_> Go to go. Cheers all.
[21:01] * robint_ (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:01] <helix84> question: can we define custom issue states in Jira or can we only choose from a pre-determined set?
[21:01] <mhwood> helix84: we don't typically estimate time-to-solution or track progress.
[21:02] <helix84> mhwood: so you're sayng In progress is used for something we don't do
[21:02] <tdonohue> I'll just add a link to this "JIRA Workflow" brainstorm into OR12 meeting agenda (in the "Developer Practices" session. If you all get to it, great. If not, we can talk about it after OR12 sometime.
[21:03] <tdonohue> helix84: It is possible to define completely custom states in JIRA.
[21:04] <mhwood> Does JIRA have a state "everyone is hoping that someone else feels more confident to tackle this one.
[21:04] <helix84> i suggest we KISS as much as possible
[21:04] <mdiggory> tend to agree with helix84 that Open and in progress are a little redundant
[21:04] <helix84> (that came out wrong)
[21:04] <mhwood> :-)
[21:04] <mdiggory> ba dum dum! ;-)
[21:04] <tdonohue> mhwood -- no, but we can "create one" if you know what it is called? Currently, in my brainstorm (on the wiki page), I'd probably lump that under "Needs Volunteer" status -- as no one has stepped forward to take it on
[21:06] * hpottinger would like it noted that all this talk of OR12 being imminent kind of freaks him out a bit...
[21:06] <helix84> tdonohue: i basically agree with your proposal
[21:06] <mdiggory> We need a state "unvoluntarily assigned to mhwood"
[21:06] <tdonohue> Ok, I'm gonna close out the "official meeting" now. But, feel free to stick around if you want (I'll be here for a while still). For those of you heading to OR12 in Edinburgh, have fun! (Again, next IRC mtg is Weds, July 18)
[21:06] <helix84> note: having "Needs volunteer" will help preparing for GSoC, theses on DSpace etc.
[21:06] <tdonohue> mdiggory -- I like that. I meant to include that "mhwood" status in the diagram but forgot about it ;)
[21:07] <mhwood> Hey, no plotting behind my back until I've left....
[21:07] <hpottinger> another proposed status: patch likely already exists :-)
[21:07] <tdonohue> helix84: yea, I think the "Needs Volunteer" and "Needs More Details" statuses will both help to better explain why a ticket is still "open" and what needs to happen next.
[21:08] <tdonohue> New extremely simplified Diagram: "Received" -> "Assigned to mhwood" -> "Closed"
[21:08] <mhwood> Seriously, I do think that the proposed states are sensible.
[21:08] <tdonohue> :)
[21:09] <mhwood> There *is* a way to automagically assign incoming issues, but we should all get a share.
[21:09] <mdiggory> needs "You gotta be kidding me!" stage that immediately deletes user who created task from JIRA
[21:10] <tdonohue> In any case, feedback is definitely welcome. If you have an idea for another status, feel free to add a comment to that page and/or create an alternative diagram.
[21:10] <mdiggory> even simpler... "Assigned to mhwood" -> "Closed"
[21:10] <hpottinger> all kidding aside, proposal looks fine as-is
[21:10] <mdiggory> because he requested automatic assignment just now
[21:11] <hpottinger> automatic assignment doesn't preclude manual assignment...
[21:11] * hpottinger welcomes our new mhwood overlord
[21:12] <helix84> suggested status: "Assignee needs to be poked with a cattle prod"
[21:12] <mhwood> Must go, have a fitting for the black cape....
[21:13] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:17] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:30] * lyncode (~DSpace@bl23-47-147.dsl.telepac.pt) Quit (Quit: lyncode)
[21:33] * KevinVdV (~kevin@d54C154B1.access.telenet.be) Quit (Quit: KevinVdV)
[21:42] * barmintor is now known as barmintor_afk
[21:52] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:57] * lyncode (~DSpace@bl23-47-147.dsl.telepac.pt) has joined #duraspace
[22:47] * helix84 (a@195.113.97.174) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.