Timestamps are in GMT/BST.
[0:39] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[0:39] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[0:39] * mdiggory_ is now known as mdiggory
[1:57] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) Quit (Quit: Leaving.)
[1:57] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[2:05] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[4:06] -hubbard.freenode.net- *** Looking up your hostname...
[4:06] -hubbard.freenode.net- *** Checking Ident
[4:06] -hubbard.freenode.net- *** Found your hostname
[4:06] -hubbard.freenode.net- *** No Ident response
[4:06] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:16] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[4:16] * Tonny_DK (~thl@130.226.36.117) Quit (Remote host closed the connection)
[4:17] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[4:59] * grahamtriggs (~trig01@80.169.130.178) has joined #duraspace
[6:43] * pvillega (~pvillega@62.77.170.185) Quit (Ping timeout: 240 seconds)
[6:43] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[8:10] * Tonny_DK (~thl@130.226.36.117) Quit (Ping timeout: 240 seconds)
[8:22] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:25] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[9:06] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:22] * Dan_Davis (~43f22e74@gateway/web/freenode/x-uxvatpjfvjdrcnoc) Quit (Quit: Page closed)
[9:27] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[9:43] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[10:03] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[10:12] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) has joined #duraspace
[10:42] * pvillega_ (~pvillega@62.77.170.185) has joined #duraspace
[10:46] * pvillega (~pvillega@62.77.170.185) Quit (Ping timeout: 252 seconds)
[12:21] * grahamtriggs (~trig01@80.169.130.178) has left #duraspace
[12:33] * pvillega_ (~pvillega@62.77.170.185) Quit (Ping timeout: 240 seconds)
[12:33] * pvillega_ (~pvillega@86.47.50.67) has joined #duraspace
[12:36] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[12:42] * pvillega_ (~pvillega@86.47.50.67) Quit (Remote host closed the connection)
[13:23] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[15:45] * Keithg (~Keith@207.138.47.158) has joined #duraspace
[15:49] * carynn (~cneiswen@c726.staff.lib.uci.edu) has joined #duraspace
[15:50] * bojans (~Bojmen@vpn1-71.tu-graz.ac.at) has joined #duraspace
[15:52] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:53] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:54] <tdonohue> DSpace Developers Mtg will be starting at the top of the hour. Here's today's agenda (feel free to send items to add if you have any): http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-05-19
[15:56] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[16:00] <PeterDietz> tdonohue, if one is here at this meeting, do they need to fill out the doodle, or would all using doodle make it easier to calculate?
[16:01] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[16:01] <tdonohue> PeterDietz: I was hoping to just use doodle to vote once we get to the Special Topics Mtg discussion -- but, either way is fine...it's possilbe we'd want to choose a different topic altogether -- those are just my suggestions
[16:01] <tdonohue> ok...we'll get started now... Agenda here: http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-05-19
[16:01] <tdonohue> Send me a msg if you have items to add, and I'll tack them on the end
[16:02] <tdonohue> First up is 1.6.1 Updates from kshepherd -- he emailed these too me as he won't be here in person today. So, I'll paste in his updates now:
[16:02] <tdonohue> 1. 1.6.1 is online at demo.dspace.org, people are testing, would love more!
[16:02] <tdonohue> 2. The documentation issues are just staying open until the day before release (or so) in case there are last minute changes
[16:03] <tdonohue> 3. The other "fix for 1.6.1" open issues were committed on the weekend and will be resolved after a bit more testing
[16:03] <tdonohue> 4. It looks like we're still all on track for 21st May GMT
[16:03] <tdonohue> 5. Big thanks to everyone who contributed code, raised issues, helped with testing and review, updated documentation!
[16:03] <tdonohue> 6. It wasn't huge in terms of numbers, but it's a good stable release of 1.6 and I feel that sticking to our plan re: release timing worked out well. Good turnaround -- only 44 days between the announcement and the code freeze.
[16:03] <richardrodgers> big thanks to kshepherd in absentia!
[16:04] <tdonohue> that's it from kshepherd! I agree, a huge kudos to kshepherd for all his hard work!
[16:04] <mhwood> Yaaay!
[16:04] <tdonohue> Any thoughts, questions, comments on 1.6.1 or what kshepherd mentioned above?
[16:05] <richardrodgers> how are we managing publicity?
[16:06] <tdonohue> I fully anticipate that publicity/announcements likely won't go out until Monday. As the release will happen Friday, and it takes a while for the central maven repo to pick up the new release.
[16:06] <tdonohue> But, the announcements will go out in all the normal ways: website, email, blog, twitter, etc. I'll work with Kim to draft it up before Mon
[16:06] <richardrodgers> cool thanks tdonohue
[16:08] <tdonohue> If everyone could take a few minutes to do some testing on http://demo.dspace.org (or on your local installs) it'd be beneficial to us all!
[16:09] <tdonohue> Ok -- next topic I had on the agenda was talking about Robin's Jira Workflow suggestions (though I just noticed robin isn't here)
[16:09] <tdonohue> these went across in an email to dspace-devel: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg03340.html
[16:10] <tdonohue> Are there any comments on the idea to add a "Received" step *before* "Open", to try and better track which issues have been reviewed and which haven't?
[16:11] <mhwood> So how does an issue move to Open?
[16:11] <tdonohue> Once someone reviews the issue and decides that it actually *is* an issue, then he/she moves it to Open
[16:12] <tdonohue> (this idea actually came from the Fedora Community -- this is how they manage their Jira issues)
[16:12] <mhwood> What sort of issue would not be an issue?
[16:12] <PeterDietz> "please help me, my dspace no work"
[16:12] <tdonohue> one that is, e.g. not really a bug or not reproduceable, etc
[16:12] <PeterDietz> ...something that should go to dspace-tech
[16:13] <tdonohue> yep...exactly -- we've actually had quite a few of those sorts of issues pop into Jira recently -- I've been trying to be diligent and close them immediately, but cannot always get to them
[16:15] <tdonohue> As we've all likely noticed, Jira issues are piling up as we never get around to reviewing them most weeks -- the hope here is that we can start to do these reviews asynchronously, and only bring back the ones that need "more eyes" to these meetings
[16:15] <PeterDietz> would we assume someone will eventually grab each "received" issue, or do we need to say the RC is on-call, and up to them to find someone to review it?
[16:15] <mhwood> Unless there is a designated triage agent who doesn't actually (usually) work on code, I expect that issues will move directly from Received to either Closed or In-Progress.
[16:17] <tdonohue> I'll admit, I don't have the "answers" here -- I'm mostly just pointing out that our current Jira Workflow is causing a lot of issues to "appear" stagnant. If we have some sort of confirmation to the submitter that someone has reviewed it, that could be helpful. But, I'm also looking for other ideas/suggestions
[16:18] <tdonohue> as to who would be "on call" -- I was hoping that individual committers could volunteer to review issues occasionally -- or we could somehow rotate this duty around
[16:18] <mhwood> What about a periodic email listing issues that have aged without ever changing state? (Assuming JIRA can do that.)
[16:18] <tdonohue> mhwood: it's a nice idea, but I haven't seen a way to do that in Jira (though if anyone knows of one, please speak up!)
[16:20] <tdonohue> Jira only seems able to send emails when the state/status of an issue changes, or an issue is updated/commented on (at least from what I've seen)
[16:20] <mdiggory> I'm sure you can customize the reporting in JIRA, I've just not done it before
[16:20] <mhwood> There could even just be a team of non-developers who scan the list manually every two weeks and hold our feet to the fire.
[16:20] <mdiggory> I like the idea of a "stagnation" report
[16:21] <PeterDietz> I'm thinking to have the (RC, or assistant RC), go through each received, and make sure it atleast has a component listed, then component leaders can make sure their components are all reviewed
[16:21] <mdiggory> make team of non-developers = one computer
[16:22] <mhwood> PeterDietz: so you do want a kind of Issue Editor.
[16:24] <tdonohue> I think the "issue editor" idea could be good, if we can rotate that around -- I'd hate for that to fall to the RC, as then it is his/her job for potentially *months* (depending on how far off the release is)
[16:26] <tdonohue> my point is, I feel we (the committers or trusted developers) should be keeping a closer eye on these issues as they come in, and somehow sharing the duties of the "quick review" of whether an issue is acceptable or should just be closed immediately. Then we can somehow mark those that really need broader review in these meetings
[16:27] <PeterDietz> Being issue editor for 7 months would be no good. I'm +1 on a stale issue reporter that finds old issues that don't move. I looked through a bunch of issues that say, too tight to fit into 1.6.0, push for later release, and since they didn't get tagged 1.6.1, I don't think anyone looked at them again.
[16:27] <tdonohue> ok...well, we can look into a stale issue reporter -- just not sure how easy it is -- it is a good idea though
[16:27] <mhwood> Sounds reasonable. I think it does need someone (or a rota of someones) tasked with touching every unreviewed issue and moving it to another state. I fear that review en passant won't happen often enough.
[16:29] <tdonohue> Ok -- in essence of time, we'll table this for now. I'll bring back the "stale issue reporter" idea, and we can look into that. Other brainstorms are welcome -- send to robin or myself, please.
[16:29] <PeterDietz> who knows, anyone hitting browse issues, that sees a group of received (needs a quick look at), could be easy enough that with 20+ people going to jira each week, that they will be easy to spot and triage
[16:30] <tdonohue> Next Topic: Next Special Topics Mtg -- I posted 5 possible topics (recent "hot" topics) on agenda: http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-05-19
[16:31] <tdonohue> Any thoughts on what you all feel is *most pressing* (or is there a topic I missed)?
[16:31] <tdonohue> You can also vote for one or more in this Doodle Poll: http://www.doodle.com/q9ewqpcf49x5z7c8
[16:32] <mhwood> DSpace Services seems to be infrastructure for a couple of the others.
[16:33] <tdonohue> true -- yea, I'll admit, I didn't order these -- I lean towards discussion of either DSpace Services (if mdiggory can lead) or even DSpace UI myself (only bring that up as I've had recent questions about UI-parity offline)
[16:34] * snail (~stuart@130.195.179.88) has joined #duraspace
[16:34] <tdonohue> we also could try and discuss multiple, if we wanted to split a meeting into two parts
[16:35] <richardrodgers> tdonohue: are you thinking extra meetings, or a 'theme' to this weekly?
[16:36] <tdonohue> a *themed* meeting is what I'm looking at -- a meeting devoted towards more detailed discussion on one or more topics
[16:36] <mhwood> IIRC the idea was that every so often the weekly meeting has a theme.
[16:37] <tdonohue> yes, exactly -- we first did this in early April and haven't done it since: http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-04-07+-+DSpace+RoadMap
[16:38] <tdonohue> so, I was hoping that others would have suggestions on what they'd like to discuss -- the goal of any of these themed meetings is to try and come closer to a general consensus or a roadmap/direction on that topic
[16:39] <richardrodgers> I guess it would also be good to set up some rough ideas on a wiki page in advance...
[16:39] <tdonohue> It's already there: http://wiki.dspace.org/confluence/display/DSPACE/Special+Topics
[16:39] <tdonohue> (maybe I didn't advertise that enough -- I've pulled most of these ideas from this page)
[16:40] <richardrodgers> yes, but these are questions, I meant more postitions
[16:40] <mdiggory> Just getting back to the computer....
[16:40] <richardrodgers> e.g. pros & cons of UI parity
[16:40] <PeterDietz> I vote all of them, but I see it tends to revolve around what does services give us for free
[16:41] <mdiggory> I don't think that I have time today to go into a discussion of dspace-services.
[16:41] <mdiggory> though I think its an important subject.
[16:41] <tdonohue> oh, right. correct. I misunderstood richardrodgers. It would be nice to have someone or someones write up some proposals or pros/cons
[16:41] <richardrodgers> mdiggory: this isn't today's topic, but the 'next' one
[16:41] <mdiggory> great ok... yes, in that case I wouldn't mind talking about it
[16:42] <tdonohue> mdiggory -- ok, any particular week? (next week, in two weeks, etc.)
[16:43] <PeterDietz> mdiggory, are you going to be talking about services at OR10 ?
[16:43] <mdiggory> next week, but I would also say to place it into context with the discussion about stuffing config stuff into the database, it might seem more practical
[16:43] <mdiggory> I'm doing a presentation on discovery
[16:44] <mdiggory> which is currently a "service"
[16:44] <tdonohue> Ok. mdiggory, that sounds reasonable.
[16:45] <tdonohue> So, we'll have a Special Topics meeting on DSpace Services (with context of Runtime Reconfiguration) led by mdiggory next week (May 26th). That sounds like a plan to me.
[16:46] <mdiggory> good to go, I have to go back to lurking mode now, sorry.
[16:46] <tdonohue> ok mdiggory -- i'll send you an email about this after the mtg
[16:47] <tdonohue> ok -- enough time for a quick Jira review?
[16:47] <mhwood> Go.
[16:47] <tdonohue> Here's the list, we'll start with DS-517: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-10w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[16:48] <tdonohue> DS-517: Versions missing in dspace/pom.xml http://jira.dspace.org/jira/browse/DS-517
[16:49] <PeterDietz> Aren't versions usually in [dspace-source]/pom.xml not [dspace-source]/dspace/pom.xml
[16:49] <tdonohue> carynn has this been fixed yet? I though I remember seeing a similar issue (or I'm imagining things)?
[16:49] <tdonohue> PeterDietz +1 - yea, I think you are right
[16:49] <mhwood> Yeah, everything should inherit from the parent via DependencyManagement.
[16:50] <carynn> yep, the patch resolves the issue
[16:51] <carynn> if i remember correctly, this particular pom.xml was the only one with the missing versions (sorry, it was a while ago...)
[16:51] <tdonohue> ok, I think this needs more review -- I've never seen it happen -- any volunteer to test (anyone have 1.5.2 locally)
[16:51] <mhwood> *Most* POMs in an inheritance structure should be missing versions. The versions should flow down from the top of the structure.
[16:52] <PeterDietz> I still have 1.5.2 running on production until june, so I can test. Though mvn package, hasn't buggered me about this
[16:52] <tdonohue> yep -- agreed -- the versions should only be in [dspace-src]/pom.xml (the root pom.xml) and not the others
[16:52] <carynn> yah, it didn't bug me either until i went to use eclipse...
[16:53] <tdonohue> ok -- DS-517 assign to PeterDietz for verification -- if not reproduceable, feel free to close
[16:53] <mdiggory> Eclipse is buggy enough as it is, the versions are left off to let the plugin increment on their own as the Maven community releases them.
[16:53] <tdonohue> DS-519: ItemExport doesn't/can't create mapfile http://jira.dspace.org/jira/browse/DS-519
[16:53] <mdiggory> Maven builds on other IDEs don't exhibit this behavior. m2eclipse tends to be a bleeding edge version of Maven
[16:54] <tdonohue> DS-519 seems to be a misunderstanding of what ItemExport and ItemImport are meant to do?
[16:54] <mhwood> DS-519 sounds like a local issue to me. I've had no trouble getting mapfiles with 1.5.whatever.
[16:55] <tdonohue> mhwood: no, I think he's expecting a mapfile from ItemExport (which doesn't generate them at all), rather than from ItemImport
[16:55] <richardrodgers> If I understand the need, ItemUpdate should work...
[16:55] <mhwood> Export. Yes. Sorry.
[16:55] <tdonohue> richardrodgers -- would you be willing to respond?
[16:55] <richardrodgers> OK, will do
[16:56] <tdonohue> ok -- assign DS-519 to richardrodgers for followup -- suggest to use ItemUpdate
[16:56] <tdonohue> DS-520: Allow for bulk/mass authorization/policy changes on items/bitstreams http://jira.dspace.org/jira/browse/DS-520
[16:57] <tdonohue> oh -- this was an improvement/new feature to ease dealing with Policies across multiple bitstreams -- so, it'd need a volunteer to work on before we could do anything
[16:59] <tdonohue> we'll leave DS-520 open for now -- volunteers welcome if you are interested in working on making this easier to manage
[16:59] <tdonohue> skipping DS-521 -- kshepherd is working on it
[16:59] <tdonohue> PeterDietz: anything to review on DS-522? http://jira.dspace.org/jira/browse/DS-522
[17:00] <PeterDietz> I have local improvements I could add to the patch, I do have two questions though
[17:00] <PeterDietz> 1) Currently its expecting someone to awk, their existing apache logs so that its in a nicer format, should these tools be self contained?
[17:01] <PeterDietz> 2) Do you think having ability to get solr logs from apache logs useful enough to commit into dspace?
[17:01] <PeterDietz> its locally useful since we have gaps in dspace.log, but I'm not sure thats a common problem
[17:01] <tdonohue> my view on #1 is that "awk" is not cross-OS -- so, we should preferably figure out a way to make this self contained and cross-OS
[17:02] <tdonohue> #2 -- I'd say, yea, it sounds useful to me. There's plenty of sites that use Tomcat behind Apache and often apache captures more useful stats info
[17:03] <PeterDietz> it would be nice if i had a fancy chart comparing my dspace.log data vs apachelog data, but sorry, no fancy chart comparing total stats
[17:03] <PeterDietz> ok, so should this be targeted 1.7, since that accepts new features?
[17:04] <PeterDietz> or will a 1.6.2 do new features
[17:04] <richardrodgers> depends on how buggy 1.6.1 proves to be
[17:04] <tdonohue> I'd say 1.7.0 -- the subminor (1.6.x) releases should just be bug-fix only (in my opinion)
[17:04] <PeterDietz> and... its already targeted for 1.7
[17:04] <tdonohue> yep.
[17:06] <tdonohue> ok...we're over time here. So, we'll stop there for now. Next week will be a Special Topic Meeting on DSpace Services (and I'll work with mdiggory to get some preparation material -- i.e. "homework")
[17:06] <mdiggory> thanks tim, that would be helpful
[17:07] <tdonohue> ok -- so, have a good rest of the week. Please help with some more 1.6.1 testing if you have time!
[17:07] <tdonohue> (meeting closed)
[17:07] <mhwood> I've begun scribbling some more Javadoc (overview, package stuff so far) for Services, probably just to show how much I've misunderstood.
[17:07] <richardrodgers> thanks all, bye
[17:07] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[17:09] * carynn (~cneiswen@c726.staff.lib.uci.edu) has left #duraspace
[17:11] * Keithg (~Keith@207.138.47.158) Quit (Quit: Leaving)
[17:12] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:13] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[17:14] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[17:17] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (Ping timeout: 240 seconds)
[17:17] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[17:22] * bojans (~Bojmen@vpn1-71.tu-graz.ac.at) Quit (Remote host closed the connection)
[17:47] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has left #duraspace
[18:04] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[21:26] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.