Timestamps are in GMT/BST.
[6:47] -hubbard.freenode.net- *** Looking up your hostname...
[6:47] -hubbard.freenode.net- *** Checking Ident
[6:47] -hubbard.freenode.net- *** Found your hostname
[6:47] -hubbard.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:47] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:47] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:27] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:23] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[15:20] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:35] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[18:03] <cbeer> https://wiki.duraspace.org/display/REPONEXT/Fedora+4+Core+Functionality
[18:03] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/REPONEXT/Fedora+4+Core+Functionality
[18:03] <cbeer> Versioning.
[18:03] <cbeer> needs to be deeply tied to storage.
[18:04] <cbeer> has to be exposed down to storage, higher to API
[18:05] <cbeer> maybe should be a way to turn it off, expose lack of versioning service
[18:05] <cbeer> => core, or just outside, indeterminant.
[18:05] <cbeer> Messaging
[18:05] <cbeer> s/Messaging/Eventing/
[18:05] <kompewter> cbeer meant to say: Eventing
[18:06] <cbeer> => core
[18:06] <cbeer> Eventing => Event awareness?
[18:06] <cbeer> Auditability
[18:06] <cbeer> (what's it mean?)
[18:07] <cbeer> eddies: e.g. writing out premis events (tied to event awareness)
[18:10] <cbeer> => non-core, tied to storage.
[18:10] <cbeer> Object Model
[18:10] <cbeer> (discussion about what we mean by object model)
[18:11] <cbeer> what are we assigning identifiers
[18:12] <cbeer> barmintor: if things weren't as they were, we'd have a named subgraph, graph name as the 'PID'
[18:13] <cbeer> => core. for some definition of object model
[18:13] <cbeer> Assignment of Identifiers
[18:14] <cbeer> => core
[18:14] <cbeer> Relationship management
[18:14] <cbeer> => core
[18:14] <cbeer> Admin metadata
[18:14] <cbeer> => core, for some definition of admin metadata
[18:14] <cbeer> Validation
[18:14] <cbeer> internal vs graph consistency.
[18:15] <cbeer> s/Validation/Validation of internal consistency/
[18:15] <kompewter> cbeer meant to say: Validation of internal consistency
[18:15] <cbeer> => core
[18:17] <cbeer> Module management
[18:17] <cbeer> => core
[18:22] <cbeer> others?
[18:22] <cbeer> Identifier service
[18:22] <cbeer> cbeer: minimum, list objects in the repository
[18:23] <cbeer> => maybe.
[18:34] <cbeer> defined serialization
[18:34] <cbeer> (in context of storage only?)
[18:34] <cbeer> (in the context of export?)
[18:35] <cbeer> eddies: not foxml.
[18:35] <cbeer> barmintor: SIPs DIPs and AIPs
[18:45] <cbeer> ---
[18:45] <cbeer> External + Required
[18:45] <cbeer> Iterator Service
[18:45] <cbeer> yes, required. F4 selling point, etc.
[18:45] <cbeer> Auditability
[18:45] <cbeer> null auditing service is ok.
[18:46] <cbeer> logback auditing is ok
[18:49] <cbeer> AuthZ
[18:50] <cbeer> for the first iteration, can we assume authz is handled at a level higher?
[18:50] <cbeer> null authz?
[18:55] <cbeer> no. but as a subcomponent for object/resource service bindings
[19:02] <cbeer> (side conversation about need for F3 => F4 tool)
[19:02] <cbeer> Disaster Recovery Service
[19:02] <cbeer> (aka Rebuild)
[19:03] <cbeer> never worked for escidoc anyway.
[19:04] <cbeer> eddies: is it like format migration?
[19:06] * eddies (~eddies@38.127.143.193) has joined #duraspace
[19:06] * eddies (~eddies@38.127.143.193) Quit (Changing host)
[19:06] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[19:58] * helix84 (~a@89.203.176.28) has joined #duraspace
[19:59] <tdonohue> Hi all...(late) reminder that we have a DSpace Developers Mtg starting here in about a minute. https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-12
[19:59] <kompewter> [ DevMtg 2012-12-12 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-12
[20:01] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:01] <tdonohue> Ok, might as well get started with our DSpace Devel Mtg. A late agenda posted up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-12
[20:01] <kompewter> [ DevMtg 2012-12-12 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-12
[20:03] <tdonohue> I'm going to forgo the JIRA review again today...cause I have JIRA stuff I'd like to discuss in general on the agenda...and i want to make sure we get to it.
[20:03] <tdonohue> So, first up I wanted to make sure we had some time to talk about how the 3.0 release went, and if there's anything we'd like to try differently next time.
[20:04] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:04] <tdonohue> robint already started such a discussion over on dspace-release list...but, I wanted to get others opinions here today, to see what you all feel could be improved on in the release process in general
[20:05] <tdonohue> So, does anyone have brainstorms on things we may want to do different for the 4.0 release next year?
[20:05] <helix84> I hoped to get some feedback on my idea that developers should be responsible to find reviewers that I pitched in that discussion
[20:05] <mhwood> I think it would help to try to schedule landing of big pieces individually and set some expectations, so they are spread out.
[20:06] <mhwood> To find reviewers, we need to have some idea of who would be comfortable reviewing what aspects of DSpace. I'm not so good on user interface stuff, for example.
[20:06] <tdonohue> helix84 -- I have some general worries about making developers find reviewers...as I worry it could be more difficult for non-Committers to find reviewers than Committers.
[20:07] <helix84> mhwood: agreed, we should make a table on the wiki
[20:07] <tdonohue> So, in general, I agree with the reviewing concept that folks should be *encouraged* to locate someone to review their work...but, we may also need to provide suggestions/support for folks who need help finding a reviewer
[20:07] <mhwood> Maybe back up just a little: we need to have *someone* responsible for finding reviewers.
[20:08] <tdonohue> I'm not sure if that could/should be an activity of the Release Team? Help find reviewers for new work? (to be clear though, I don't think the RT should need to review all this stuff themselves...just help locate appropriate reviewers)
[20:09] <hpottinger> RT has a role finding reviewers if reviewers aren't self-selecting... however, it is my hope that we are self-selecting most of the time
[20:09] <mhwood> RT should not be responsible for *doing* review, but it makes sense that they are responsible for seeing that review gets started timely. First responsibility should be the contributor, but if he doesn't or can't find anyone then the RT could back him up.
[20:10] <tdonohue> +1 hpottinger...I'd also prefer that we try to self-select reviewers as much as we can. But, when a reviewer doesn't step forward, that's where the RT could help prompt us all to volunteer as a reviewer
[20:10] <helix84> tdonohue: well,it'snot like we wouldn't help them locate reviewers. but the truth is that we have unreviewed patches in Jira and the (I'm not sure if it's formal) rule seems to be that large unreviewed stuff doesn't go in. so I'm just formulating that fact and suggesting the next step.
[20:10] <tdonohue> +1 mhwood too..he just said the same thing I meant
[20:11] <helix84> remember that we are actively locating reviewers during our Jira reviews
[20:11] * jonathan_ (a06ffa6d@gateway/web/freenode/ip.160.111.250.109) has joined #duraspace
[20:11] <mhwood> I was unclear. Developer should try to find someone to review. First choice would be the person reporting, unless that is the developer.
[20:13] <helix84> i also agree on what was said about the roleof the RT
[20:13] <mhwood> "Large unreviewed patch doesn't go in" is good too. If you want your work to advance then you need to either line up reviewers or ask for help in doing so.
[20:14] <tdonohue> so, I think (unless I'm missing something) we are all essentially saying the same thing here....(1) developers should be encouraged to locate a reviewer themselves, if possible, (2) if a reviewer cannot be found or is not self-selected, that is where either the RT (during a release) or Committers in general can help to locate an appropriate reviewer. (And we all prefer that #1 happen as much as we can)
[20:14] <helix84> i think we have a consensus
[20:14] <tdonohue> yep, consensus.
[20:14] <mhwood> Me too.
[20:14] <helix84> plus, to help locate reviewers, we'll make a table of commiters x areas of competence
[20:15] <tdonohue> which means we should step back to mhwood's initial point (at beginning of meeting)...this one:
[20:15] <tdonohue> mhwood: I think it would help to try to schedule landing of big pieces individually and set some expectations, so they are spread out.
[20:15] <helix84> the thing is we mostly don;tknow what to expect this early in the cycle
[20:16] <helix84> then @mire comes and drops us ~3 large code bombs :)
[20:16] <tdonohue> right...we never know what to expect this early on.
[20:16] <tdonohue> I'll say, I agree with mhwood's idea here , in theory. However, I'm not sure yet at how good we are about setting & meeting early "deadlines"
[20:16] <helix84> my point being those code drops are mostly finished stuff and nosubstantial changes are expected
[20:17] <tdonohue> I'd personally love to see things get schedule more though
[20:17] <tdonohue> s/schedule/scheduled/
[20:17] <kompewter> tdonohue meant to say: I'd personally love to see things get scheduled more though
[20:17] <aschweer> we still need to make sure that large new features actually work for more than just the organisation that's contributing them
[20:17] <helix84> ok, what about this:
[20:17] <helix84> remember my 3.0 tasks page?
[20:17] <hpottinger> it would be nice to have preview pull requests, if the submitter really wanted community input on larger projects
[20:17] <helix84> let's start a 4.0 tasks tracking page right now
[20:18] <aschweer> hpottinger +1
[20:18] <helix84> so that we'll have status updates all in one place
[20:18] <tdonohue> I agree with hpottinger too -- sharing code earlier would be nice
[20:18] <helix84> and know what to expect
[20:19] <tdonohue> helix84 -- feel free to start up a 4.0 page. If even just to start capturing early ideas around what could be in it..or what our 4.0 wishlist is
[20:19] <helix84> then at some point _before_ what we called feature freeze, it would be the RT's discretion to accept any late features
[20:19] <hpottinger> though, it doesn't have to be an actual pull request, just a link to the branch would do, as long as the Git repo is public
[20:19] <mhwood> And then announce it. "4.0 planning/scheduliing page is open, please contribute."
[20:20] <helix84> hpottinger: exactly, anything, including proposals, discussions, status updates, jira issues, branches, pull requests
[20:21] <hpottinger> it's a bit like the whole "theme garden" idea, but for any section of code
[20:21] <helix84> theme garden and code zoo :)
[20:21] <helix84> not really, code lives in forks
[20:21] <tdonohue> The other (maybe crazy) related idea I have had bouncing around is to set *2 different "submission deadlines"* where folks *must* have something reviewable as a Pull Request. One is for Big Changes (and it's 2+ months before Feature Freeze), and the other is for smaller improvements (and it's 1 month before Feature Freeze).
[20:21] <helix84> thisis just a place to link to all of it
[20:23] <helix84> so let's have a "proposals freeze" and "code must be ready" deadlines
[20:23] <tdonohue> These "2 submission deadlines" would be strict...if you miss it, sorry. But, the code need not all be 100% finished..just needs to be in a reviewable state, where we can vote it in/out. But, I'm still not sure if this is the right direction
[20:24] <tdonohue> essentially, I'm trying to *force* people with significant changes (big new features) to get their code in front of us much sooner
[20:24] <mhwood> Forcing volunteers is difficult....
[20:24] <tdonohue> (even if that code they send us is still a bit buggy, and maybe not "feature-complete")
[20:25] <helix84> tdonohue: agreed, that's the goal. but i'm also not convinced yet that this willhelp towards that goal.
[20:25] <mhwood> Yes, if it's working well enough to show how it might look, we want to see it.
[20:26] <tdonohue> force may be too strong a word on my part, agreed. I'm just worried that if we tell people to give us their code / schedule their feature, those deadlines will just continually slip back.. we need some *earlier* deadline before feature freeze that is the "last chance"
[20:26] <helix84> the other related problem is that by giving us mostly finished code, the contributors are leaving us out of comenting on the design
[20:27] <helix84> which can bite them back if we're not satisfied with the design and they have to have fundamental changes
[20:27] <mhwood> That's why I keep saying "negotiate". The RT needs a commitment from the contributor, so that he goads *himself* to get it in.
[20:28] <mhwood> helix84++
[20:28] <helix84> ok, we spent almost 30 minutes, any conclusions?
[20:29] <hpottinger> +1 to involving the community on the design phase, let's make it easier, I think the earlier deadline does that a bit, by make the expectation clear
[20:29] <tdonohue> I agree with helix84 too, that we want to encourage the whole process to be more open.. I think @mire actually did this in 3.0 with some features...they were open about Advanced Embargo & even about Item Versioning, but the final code still came a bit late
[20:29] <mhwood> I guess the "2 deadlines" approach is to schedule the pile-up earlier so that the RT has time to work through it.
[20:30] <tdonohue> mhwood -- yea, exactly. I want the "pile-up" of last minute features to happen 2+ months before feature freeze, rather than *one week* before Feature freeze
[20:30] <helix84> about advanced embargoand versioning - IIRC, the feature specifications were actually available early
[20:31] <aschweer> helix84: development still happened entirely behind closed doors though
[20:31] <mhwood> We still have a ton of code arrive all at once but it's less problematic, because the code can wait on RT attention.
[20:31] <tdonohue> helix84 -- yea, that's what I was saying... features/specs were shared earler, but the code was not
[20:31] <helix84> but there was no code to play with, so I personally didn't understand the proposals wellenough to comment on them
[20:32] <helix84> so we should encourage development in public branches
[20:32] <tdonohue> So, I'm not sure we've come to any conclusions on this part...just some brainstorms here on possible solutions. Here's what I've heard
[20:32] <helix84> wait, i think that's what we were getting to the whole time
[20:32] <tdonohue> 1) We all agree it'd be best for all development to be more open in general
[20:33] <helix84> let's require from early on a public development branch
[20:33] <tdonohue> 2) We'd like it if we could work with contributors to schedule a time that their feature will be ready for review
[20:34] <tdonohue> 3) We may or may not want to mess around with different "final chance" deadlines...to perhaps get the "last minute pile-up of features" to happen earlier & give the RT/Committers time to work through it
[20:34] <tdonohue> I think that's the main points, unless I missed something
[20:35] <mhwood> Sounds right. I like the idea of combining negotiated scheduling with a hard "last chance" date (or two) that leave(s) sufficient lead time.
[20:35] <tdonohue> +1 mhwood -- yes, I think we could try both together
[20:36] <tdonohue> Ok...moving on now. I wanted to leave a slot here to talk about 3.1 timelines, but I'm not sure we're any closer this week to deciding on the 3.1 release. Any thoughts?
[20:36] <helix84> tdonohue: just that there are still many open issues for 3.1
[20:36] <tdonohue> (or I should say, I think we all agree a 3.1 will happen...we are no closer to deciding *when* it will happen)
[20:36] <helix84> right
[20:37] <mhwood> Curing the license conflict seems like the most significant issue. When that lands, I think it might be time to look around and see if there is any reason not to cut a release. (If other good stuff is expected within days, delay for it.)
[20:37] <tdonohue> +1 mhwood, I agree
[20:38] <tdonohue> (mhwood is talking about DS-1407...had to go look up the number myself)
[20:38] <kompewter> [ https://jira.duraspace.org/browse/DS-1407 ] - [#DS-1407] Refactor SOLR Statistics to use OpenCSV or Apache Commons CSV - DuraSpace JIRA
[20:39] <hpottinger> I haven't yet created a Jira for it, but I still can't get things running on Oracle
[20:39] <tdonohue> hmm..that's not good news. Well, a fix for Oracle would also warrant an immediate 3.1, I think
[20:40] <tdonohue> So, here's all our 3.1 issues, with the unassigned ones sorted to the top. Feel free to grab any that you have time too: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.1%22+AND+resolution+%3D+Unresolved+ORDER+BY+assignee+DESC%2C+priority+DESC
[20:40] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.1%22+AND+resolution+%3D+Unresolved+ORDER+BY+assignee+DESC%2C+priority+DESC
[20:40] <helix84> IIRC those oracle issues weren't causing any known problems, just removing warnings, right?
[20:41] <tdonohue> helix84 -- I think hpottinger is having different Oracle issues...namely that 3.0 isn't working on Oracle (throws errors)
[20:41] <hpottinger> helix84 the ones I fixed were warnings, I'm talking about not running at all with 3.0
[20:42] <helix84> oh, sorry, i didn't know about that
[20:42] <hpottinger> to complicate things, we're actually planning on moving our repository to PostgreSQL soon...
[20:42] <helix84> when did we/you find out?
[20:42] <mhwood> IIRC Graham Triggs does Oracle, but he seems very quiet lately. Other matters are consuming his time, I guess.
[20:42] <tdonohue> Ok. I think we'll move on for now from 3.1, as we obviously aren't ready for scheduling that yet. Just a sidenote that I encourage hpottinger to enter his Oracle Errors into JIRA :)
[20:42] <hpottinger> will do
[20:43] <tdonohue> graham is in a new job, he's no longer @ Open Repository (the company)...so, I'm not sure he's using Oracle as much these days
[20:43] <helix84> on a related note, i started marking some small bugs with the "papercut" label
[20:43] <helix84> these are meant to be simple fixes, like adding an exception handler
[20:44] <helix84> just to make finding them easier for a potential bug slayer
[20:44] <tdonohue> Ok, that basically transitions us into the next topic which is JIRA in general :)
[20:44] <hpottinger> I did reach out to the only other Oracle institution I know of, and they said they are contracting with @mire for support...
[20:44] <tdonohue> but, that sounds fine to me helix84. We just probably need to note somewhere what "papercut" means
[20:45] <helix84> ubuntu has defined it as a small bug thatcan be fixed by a competent developer in less than a day
[20:46] <tdonohue> So, with regards to JIRA...I'm hoping to actually make this "JIRA Workflow Improvements" (see diagram) happen in the near future, assuming there are no disagreements: https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[20:46] <kompewter> [ JIRA Workflow Improvements - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[20:46] <tdonohue> helix84 -- yea, see, I didn't know that, having never looked at Ubuntu's issue tracker. That's why I mentioned it'd be good to make others aware of this
[20:46] <helix84> i think we all agreedon that (perhapseven approved it with a vote?) before the release started, we only postponed it until after the release
[20:46] <mhwood> Essentially "open" splits into "needs more details" and "needs volunteer"?
[20:47] <tdonohue> mhwood -- yea, essentially "open" does split into those two categories -- unless it is "open + assigned to someone" in which case it becomes "in progress"
[20:48] <tdonohue> So, making this JIRA change happen will require a massive recategorization of all tickets marked "open" at this time...so, this may not all be able to happen easily in one day
[20:49] * hpottinger wonders if Jira makes a tool for refactoring classifications...
[20:49] <tdonohue> it does...JIRA has tools to let you move things around in bulk
[20:50] <tdonohue> the problem here though is that we need to eventually determine which "open" tickets belong under "needs volunteer" and which belong under "needs more details". That may not be as "automatic" of a change
[20:50] <mhwood> I was wondering more about whether Jira lets you remove an edge from the state machine, so that stuff in "open" can stay there until moved to one of the new states, but no more stuff can move from "received" to "open".
[20:50] <tdonohue> mhwood -- that may be possible. Good idea. I'll have to look into that
[20:51] <helix84> in the case of splitting "open" into "needs more details" and "needs volunteer" that can't be done automatically, a human must classify it
[20:51] <tdonohue> yep, exactly helix84.
[20:52] <tdonohue> So, I can look into our options further in the coming weeks/days. I do think this JIRA change is important to happen soon. I just may need help eventually doing the human-required activities
[20:52] <helix84> but "fixed" and "closed" could be merged automatically
[20:52] <helix84> i'll chip in, little by little
[20:53] <tdonohue> Oh, one last question with regards to JIRA Workflow stuff...in the comments of that Wiki page, Bram & mhwood mentioned a "Code Review Required" state. That's currently NOT in the diagram. Do we feel that should be added?
[20:53] <mhwood> Um, what state do we use for "developer thinks it's fixed, please test/review"?
[20:53] <tdonohue> mhwood just asked the same question as I ;)
[20:54] <helix84> the has-patch and has-pull-request labels
[20:54] <mhwood> So it just sits in "in progress" and we look for labels?
[20:55] <helix84> i guess. we can convert it to a state, i have no problem with that.
[20:55] <tdonohue> yea, I think there are two options. Stuff waiting for review either stays in "in progress" and we add a special label...or we move "in progress" stuff -> "code review required" if needed
[20:55] <helix84> currently you'd have to look for has either of those labels and is not fixed or closed :/
[20:56] <helix84> changing the labels into a state wouldmake that easier
[20:56] <tdonohue> However, we may be able to set it up so that the "code review required" state is Optional. I.e. from "in progress" you can either move directly to "Closed" or you can move to "Code Review Required" first.
[20:56] <helix84> tdonohue: sounds reasonable
[20:56] <hpottinger> state > labels, I agree
[20:56] <mhwood> tdonohue: yes
[20:57] <tdonohue> ok..sounds like a general consensus. I'll add that to the diagram, and I'll look into adding an optional "code review required" state
[20:57] <hpottinger> tdohonue +1
[20:57] <helix84> one more thing
[20:57] <helix84> i guess where would be just onestate, so we'd keep the labels to distinguish between a patch and pull request
[20:58] <helix84> IMHO distinguishing them doesn't justify 2 separate states
[20:58] <mhwood> I agree. The meaning of the state is "submitter or a reviewer should inspect this".
[20:59] <helix84> more like "code ready for review"
[20:59] <tdonohue> yea, I think "patch" and "pull request" can just be labels
[20:59] <tdonohue> "code ready for review" is fine by me
[21:00] <tdonohue> I think that's all the questions I had around the JIRA Workflow stuff (for now). Next steps are to start to figure out the best way to get this implemented...so, I'll just have to start that investigation & report back if I hit any major issues.
[21:00] <mhwood> It needs an edge returning to "in progress", in the case of not passing review.
[21:00] <helix84> tdonohue: so you'lllook into the automation tasks andi'll do some of the grunt work, right?
[21:00] <tdonohue> +1 mhwood agreed
[21:01] <tdonohue> helix84 -- yea, I'm going to look at how to first generate this workflow in JIRA, then automate what I can automate....finally I'll report back on what I'm gonna need human-help on (which is where I hope you and others can chip in)
[21:02] <helix84> i have one more jira thing to discuss
[21:02] <tdonohue> ok, go ahead
[21:03] <helix84> as new issues come in, i've been tagging them with either 3.1 or 4.0, even when they don't have an assignee. unless it's something like my pie in the sky ideas, which i leave without a target version.
[21:03] <helix84> i think that willforce us to look at them at some point in time and decide whether to push them back or find an assignee
[21:04] <helix84> which will be nice to have in addition to the regular jira review
[21:04] <mhwood> Good idea.
[21:04] <tdonohue> that makes sense. once we get these workflow changes in place... we can start immediately dumping new tickets into the "needs volunteer" or "needs more details" statuses too
[21:04] <tdonohue> I agree, it's a good idea
[21:05] <helix84> the only danger is we'll become a buldozer pushing heaps of issues to the next release every time :)
[21:05] <tdonohue> The last thing I had noted on the agenda (which I'm not sure we have much time for today -- we're already over time) is that we need to somehow find a way to cut down the JIRA Backlog
[21:05] <tdonohue> helix84 -- yea, that may happen, we'll have to see.
[21:06] <tdonohue> One thing I just realized as far as the JIRA Backlog goes though, is that I think these JIRA Workflow improvements may require us to tackle some of the backlog anyhow, and at least put them in the proper status
[21:06] <helix84> any suggestions on how todo that? :)
[21:07] <tdonohue> So, it may be that the JIRA Backlog may start to clear up more as we implement the JIRA Workflow improvements.....or, at least, that's my current hope
[21:08] <helix84> i was thinking along those lines that cleaning up the classification in jira will enable us to properly point to lists ofpossible tasks, that can be tackled e.g. in GSoC or as student's theses
[21:08] <aschweer> have an in-person or virtual bug squashing party of sorts (if in person, maybe just before/just after OR?)
[21:08] <tdonohue> +1 helix84
[21:09] <hpottinger> +1 party
[21:09] <tdonohue> aschweer - yea, that was my only other idea...holding a "JIRA Backlog Bash" (or something) and trying to dig in and at least clean up the JIRA backlog (if not squash/assign some old bugs). It could be in person, or just via IRC on a day
[21:09] <helix84> i've never been to a BSP (bug-squashingparty) but I have the impression that BSPs are mostly classification, not actuallya bug _fixing_ party
[21:10] <aschweer> my father went to http://wiki.debian.org/BSP/2012/11/de/Essen and it sounded like bugs did get fixed in the process
[21:10] <kompewter> [ BSP/2012/11/de/Essen - Debian Wiki ] - http://wiki.debian.org/BSP/2012/11/de/Essen
[21:10] <tdonohue> I'm betting it could be a little of both....small bugs could be squashed that day, but the more important thing would be to get through the backlog & categorize/assign things...so that there's no long a big menacing backlog over our heads
[21:11] <hpottinger> I'd drink to that
[21:11] <mhwood> Speaking of OR, if there will be a meeting before or after it would be good to get it scheduled so transport and lodging can be scheduled.
[21:11] <aschweer> hpottinger: um I'm not sure drinks+bugs mix so well...
[21:11] <aschweer> mhwood +1
[21:11] <tdonohue> I still think that process could be *either* in person (at OR or similar) or even via IRC -- make a day of it, if folks can spend a day (or part of a day) and join me to tackle to backlog
[21:12] <helix84> aschweer: never heard of wine flies? ;)
[21:13] <hpottinger> no, no, I think there's some confusion: drink *after* bugs are squashed, not during the squashing (because that would be gross)
[21:13] <tdonohue> mhwood -- good question around the meeting timeline at OR. I was waiting for an early OR schedule myself. I wasn't sure if Mon, July 8 was going to be "mostly workshops"...if so, we could have our mtg in parallel to those workshops
[21:13] <aschweer> I found last OR very stressful with so many things going on in parallel, but I guess it'd be hard for people to justify coming a day early / staying a day longer?
[21:14] <tdonohue> Since OR2013 is already scheduled for an *entire week* (Mon, July 8 - Fri, July 12), I wasn't sure I wanted to force folks to attend extra mtgs on either Sunday before or Saturday after
[21:15] <tdonohue> I know, personally, I have trouble making it a full week of conferencing (and still having some brain left)...so, I didn't want to make it even longer
[21:15] <mhwood> Well, the idea is to get people to start talking seriously about scheduling and find out what works.
[21:15] <hpottinger> scheduling concurrent with the workshops limits our opporutnities to participate (either by leading or attending)
[21:15] <aschweer> it's far easier for me to tack on a day to OR than to squeeze a whole day of DSpace things into my day work. plus there'd be fewer timezone issues at an in-person event
[21:16] <helix84> is anyone coming to OAI8? that'sa much shorter conference
[21:16] <tdonohue> Well, I can bring this up in DuraSpace -- I know a few folks are on the planning committee for OR2013 (not I though). I can ask to see if the plan is that the conference is going to actually last the full week or not...and when a DSpace mtg could happen
[21:16] <mhwood> What do we have that would warrant a face-to-face meeting in the first place?
[21:17] <helix84> mhwood: beer?
[21:17] <tdonohue> helix84 -- I'm not going to be at OAI8 (at least not as far as I'm aware yet....plans change sometimes though!)
[21:18] <tdonohue> Currently, face-to-face is just a good time to mingle & talk through upcoming roadmaps/plans/larger projects. There may not be anything yet to warrant it, but I bet there'd be plenty to talk about once we get around to OR2013 next July
[21:18] * hpottinger is still mulling over OR13... PEI is a pricey plane ride
[21:19] <mhwood> Cost has come way down since I looked a couple of months ago.
[21:19] <mhwood> Still pricey though.
[21:20] <aschweer> I'll not mention ticket costs from here...
[21:20] <tdonohue> (BTW -- I think the "official meeting" is likely over here...I'm not going to call any more topics. But, I will still be here for a while to chat about whatever)
[21:20] <tdonohue> yea, tickets are likely pricey *every year* for aschweer :)
[21:20] <helix84> i was just typing that :)
[21:20] <mhwood> True, I have little room for complaint.
[21:20] <aschweer> luckily I'm not paying for them out of my own pocket :)
[21:21] <hpottinger> aschweer: you guys need to host, problem solved
[21:21] <aschweer> haha
[21:21] <aschweer> then we could have OR in Middle Earth
[21:22] <hpottinger> +1 Middle Earth
[21:22] <helix84> i'll fit in unless i'll shave my feet
[21:22] <aschweer> it's getting a bit much actually...
[21:23] <tdonohue> I will ask around though to see if I can get a better handle on when we can have the DSpace face-to-face mtg @ OR2013. I agree though with much that has been said..the number of parallel mtgs/topics at OR2013 is getting crazy...that conference just seems to get larger & larger every year...which makes it harder & harder to fit in a face-to-face DSpace mtg.
[21:23] <aschweer> anyway, I need to run off. bye all!
[21:23] <aschweer> tdonohue +1
[21:23] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:24] * tdonohue sometimes longs for the early days of OR, when it was a 3 day conference, and you could easily add a day of meetings on before or after
[21:25] <helix84> i guess they've been adding them days for one year too many
[21:26] <mhwood> Maybe time to look around for something smaller which is still relevant and useful.
[21:26] <helix84> a dedicated dspace conference? :)
[21:26] <tdonohue> yea, if we were all/most at another smaller mtg, that'd be another option for a face-to-face
[21:26] <helix84> can't get more useful than that ...for us
[21:27] <tdonohue> there actually used to be a "DSpace User Group" conference every other year...we haven't had one in ~3-4 years though
[21:27] <tdonohue> it was called "DSUG" (DSpace User Group) for short
[21:27] <helix84> we had some preliminaryideas about one here in europe ths summer
[21:28] <helix84> since OR13 will be expensive
[21:28] <tdonohue> the last full DSUG conference (that I recall) was in Sweden in 2009. It was a 2? day conference, I believe.
[21:29] <tdonohue> helix84 -- yea that was the exact reason why we used to have DSUG meetings... to try and catch the folks who couldn't travel to OR
[21:30] <helix84> i'll head out now
[21:30] <helix84> see you
[21:31] <tdonohue> bye, have a good one
[21:31] <mhwood> 'bye.
[21:31] * helix84 (~a@89.203.176.28) Quit (Quit: helix84)
[21:37] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:45] * jonathan_ (a06ffa6d@gateway/web/freenode/ip.160.111.250.109) Quit (Ping timeout: 245 seconds)
[21:45] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[22:23] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:46] * tdonohue (~tdonohue@c-50-129-94-92.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.