Timestamps are in GMT/BST.
[5:10] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[7:36] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[7:54] * awoods (n=awoods@pool-71-178-169-240.washdc.fios.verizon.net) has joined #duraspace
[8:16] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[8:55] * bbranan (n=lc@9.159.121.70.cfl.res.rr.com) has joined #duraspace
[9:15] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[10:58] * awoods (n=awoods@pool-71-178-169-240.washdc.fios.verizon.net) Quit (Remote closed the connection)
[11:16] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit (Remote closed the connection)
[11:16] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:31] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[15:33] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:34] * bradmc (n=bradmc@dhcp-18-111-26-140.dyn.mit.edu) has joined #duraspace
[16:02] <bradmc> Hi all, we'll get started on a committers meeting in a few minutes. Topics of interest? (1.6 Updates, GSoC Updates )
[16:06] <bradmc> No other topics? I can seed a few more ...
[16:07] <bradmc> - Should we do something formally to address orphan Jira issues periodically?
[16:07] <bradmc> - How would we feel about yet another wiki move, from mediawiki to Confluence?
[16:09] <grahamtriggs> +1 for Confluence
[16:10] <mhwood> I don't know Confluence at all. TIme to learn, I suppose.
[16:10] <kshepherd> same for me
[16:10] <stuartlewis> Same here
[16:10] <kshepherd> but I'm +1 for the idea
[16:11] <bradmc> http://fedora-commons.org/confluence/ is a live one you could look at.
[16:11] <mhwood> *grumble*, I'd almost finished tidying up artifacts of the MoinMoin -> MediaWiki move. :-/
[16:11] <stuartlewis> What is the main difference?
[16:11] <bradmc> mhwood, yeah, that's the really painful part of considering this.
[16:12] <grahamtriggs> One is written in Java, has loads of plugins to do very useful things, good authorization mechanisms, would be excellent for maintaining documentation (and creating Docbook / PDFs from)
[16:12] <grahamtriggs> and the other is MediaWiki
[16:12] <kshepherd> heh
[16:12] <bradmc> Confluence is commercial, from Atlassian, has a wide selection of plugins, plays nice with the Jira and Crowd (single signon access across tools).
[16:13] <bradmc> Once you spend a few minutes in one, you feel lots of little positive differences. I encourage folks to take a look.
[16:14] <bradmc> Confluence also makes it easier to have subgroups, tight privilege control over sections, publish up from one domain to another, rename blocks of stuff ...
[16:15] <bradmc> The context is that it would be part of an overall DuraSpace strategy to go to one infrastructure supporting multiple projects.
[16:15] <grahamtriggs> Does Fedora Commons make use of the Gliffy plugin?
[16:16] <stuartlewis> Sounds a sensible move then.
[16:16] <bradmc> Dunno. cwilper or bbranan ?
[16:17] <grahamtriggs> Balsamiq Mockups is kind of fun too
[16:17] <bradmc> stuartlewis mhwood only as long as it doesn't create a huge pile of rework. mdiggory sez a test import went pretty well, but I think if we decide to move forward, we'll want to get more eyes checking on the result.
[16:17] <grahamtriggs> http://www.gliffy.com/confluencePlugin/
[16:17] <grahamtriggs> http://www.balsamiq.com/products/mockups
[16:17] <mhwood> OK, I'm registered at Fedora Commons, will try it out.
[16:17] <grahamtriggs> both are free to open source software
[16:17] <mdiggory> ??? not sure why this didn't "pop up" on my desktop
[16:18] <bradmc> Okay, I'll re-ask this question again next week to to check for dissenters, but I think we're on a road to investigate ...
[16:18] <grahamtriggs> And Scroll is the plugin that would help greatly with our documentation efforts: http://www.k15t.com/scroll/
[16:18] * bradmc notices grahamtriggs really hates the idea.
[16:18] <mdiggory> likewise... I successfully did an import of dspaces mediawiki into a local confluence instance
[16:20] <mdiggory> the standard wiki syntax ported ok, there is aconfiguration file that allows it to be tuned
[16:20] <cwilper> (catching up on discussion)
[16:20] <mdiggory> challenges were with categories and unconventional linking to files
[16:21] <mdiggory> some of the table layout style of the Main Page did not port, but I was able to adjust it
[16:21] <grahamtriggs> Are there any usage statistics for the Wiki?
[16:22] <cwilper> grahamtriggs: Gliffy, yes, go to a page and Add->Diagram
[16:22] <bradmc> Shall we move on to another topic? Topic proposals?
[16:22] <mdiggory> I think if we did do a conversion, maybe we should consider abandoning the "wiki.dspace.org" and redirect to the top level of a confluence instance, rather than trying to map confluence directly into the wiki.dspace.org domain
[16:23] <stuartlewis> Would be good to talk about JIRA issue list - try to get it in order for 1.6
[16:24] <bradmc> Okay, I had a different take on Jira issues; I'm confident in the ones for 1.6, I'm worried about the ones not associated with any release, many of which were relatively mechanically copied up from Tracker.
[16:26] <stuartlewis> Yep - thats what I was refering to - get rid of the old stale things, so that the tracker list for 1.6 is clean, and we can see what we're working towards.
[16:26] <mdiggory> isn't that what the voting process was supposed to alleviate? when do unpopular/dead jira tasks go away?
[16:26] <bradmc> I notice that on the fedora side, cwilper pretty much drives a conclusion on every issue they get. We don't have that practice. (And incidentally, if we find a community driven solution, we'll want to apply it in fedora-land too).
[16:26] <bradmc> mdiggory: exactly. If we had a policy, we could age some into a "wontfix" or other appropriate state.
[16:26] <mhwood> Old tasks go away when they are resolved.
[16:28] <mdiggory> Oh, the Poor developer, he passed away, but without resolution, his JIRA tickets lived on forever
[16:28] <bradmc> :) One could make an argument that marking every Tracker import issue with wontfix might drive us towards the correct state - if people reacted.
[16:29] <mdiggory> this is a good point
[16:30] <stuartlewis> That would be a good start.
[16:30] <mdiggory> sounds like we need a JIRA party at the next conference...Foundation buys a drink for every resolved ticket?
[16:31] <grahamtriggs> one significant issue with the Jira migration is that it doesn't seem to note who originally reported the issue
[16:31] <bradmc> On a related note, the Foundation is soliciting donations ...
[16:32] <mdiggory> So we the JIRA party needs sponsors then!
[16:32] <stuartlewis> Would be good to do it sooner rather than later - start as we mean to go on. Could we hold a special IRC meeting (tell everyone up front what we are doing and invite them along) and have a quick fire 1 minute per issue meeting?
[16:32] <bradmc> grahamtriggs: we can look into having that fixed by an intern -> for those cases that the reporter has created a jira account.
[16:32] <bradmc> stuartlewis: 1 minute per issue +1
[16:32] <mdiggory> how many issues?
[16:33] <stuartlewis> Oustanding = 85
[16:33] <grahamtriggs> Even if they haven't already got a Jira account, a comment could be added to the issue, and we could actively encourage the reporter to get an account
[16:33] <bradmc> All at once, or as a periodic IRC meeting; we'd need a few up front, but then on a monthly or quarterly cycle?
[16:33] <stuartlewis> maybe all at once to get our house in order, then monthly?
[16:33] <cwilper> When migrating from sf to jira, we had to do some custom jelly scripts to retain old info from sf. When there was no logical place in jira to put the data, it just went into a new comment, with a link back to the original tracker item.
[16:33] <mhwood> +1 periodic
[16:33] <bradmc> grahamtriggs: They should all be attributed back to the original Tracker, we could get the names in to.
[16:33] <grahamtriggs> ideally, we need each issue 'owned' before we start "won't fix"ing them, so that someone gets alerted to the fact that it's happened
[16:34] <bradmc> to = too.
[16:34] <stuartlewis> And when we agree to 'won't fix' we need to assin each to someone to write the explanation why we won't fix.
[16:35] <bradmc> "wontfix: Can't find the owner" <evil grin>
[16:35] <mdiggory> seems as though we would want to add those original reports as a cc?
[16:36] <bradmc> cc: +1
[16:36] <mdiggory> they can create accounts if they are interested in the ticket when they get notified its been labeled "wont fix"
[16:36] <bradmc> That can be accomplished using the existing comments referencing the SF tickets.
[16:36] * bbranan (n=lc@9.159.121.70.cfl.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[16:37] <mdiggory> should the original S.F. tickets go away?
[16:37] <cwilper> if you require login to submit a ticket, jira can auto-email the submitter (or assignee, or anyone who signs up to watch the issue) when state changes.
[16:37] <grahamtriggs> referencing Brad's comment, I'll agree that in this case imperfect action is definitely preferable to no action. But it's worth noting anything imperfect, in case anyone has a bright idea.
[16:38] <mdiggory> cwilper: right, but I think we are talkng about tickets that came from SF without an existing JIRA account
[16:38] <cwilper> ahh
[16:39] <bradmc> Wrapping up then: We have periodic "orphan jira issue reviews" in IRC. We time bound them for sanity. If we find an issue we want to 'wontfix' without an owner, we look up the original SF tracker entry and cc that address. For Jira issues that we review, we close out the original S.F. tickets. That sound about right?
[16:39] <mdiggory> I think Brad just said we have the original submitters email in the ticket description
[16:40] <bradmc> mdiggory, not the email, but the SF ticket.
[16:40] <mhwood> bradmc: sounds good to me.
[16:40] <stuartlewis> OK. When's the first JIRA party?
[16:40] <mdiggory> Ok. that'd probably take a minute per ticket just to do, a person could be delegated that role in the JIRA meeting
[16:41] <bradmc> Yes, I'd look to get a little admin support on that aspect. I think foundation can manage that.
[16:41] <mdiggory> GO Foundation!
[16:42] <bradmc> Next topic?
[16:42] <stuartlewis> 1.6?
[16:42] * bradmc gives stuart the gavel
[16:43] <stuartlewis> Batch editing is now in place in svn, via CLI or JSPUI. Kim has said he hopes to find time to look at the XMLUI.
[16:43] <stuartlewis> MIT are also contrbuting to this effort with a batch update tool.
[16:43] <stuartlewis> mhwood: How are things progressing with stats?
[16:44] <mhwood> Still hoping for some discussion of what the solution should look like.
[16:44] <mdiggory> 1.6 @mire Statistics work has been progressing and we could use some comments on UsageEvent and LoggerService / ReportingService API's that are coming in.
[16:44] <mdiggory> I've supplied a patch for Usage event in JIRA that needs comment
[16:44] <kshepherd> mdiggory: they're available now?
[16:45] <mdiggory> parts are available under /svn/repos/modules
[16:45] <mdiggory> dspace-solr, dspace-solr-stats are backend and client api
[16:45] <stuartlewis> Do we have a 'prefered solution' or 'prefered stats architecture' worked out yet for 1.6?
[16:46] <mdiggory> Still have alternative ideas around USageEvent and LoggingService API's we should discuss
[16:46] <grahamtriggs> stuartlewis: we have more than one ;)
[16:46] <mdiggory> grahamtriggs: is right and we are trying to be inclusive
[16:47] <mdiggory> "dspace-services" is a prototype of utilizing dspace 2.0 like serivces to access a LoggingService and ReportingService API
[16:47] <mdiggory> from within dspace User Interfaces
[16:47] <mdiggory> preparing to release some wiki notes on this stuff
[16:49] <mdiggory> I've reviewed Minho's hooks into dspace-api,xmlui,jspui around UsageEvent and think there are good points for adoption of those hooks though in somecases, those events may be questioned
[16:49] <stuartlewis> Sounds good - but would be good to be able to document at least one solution that can be almost seen as -out-the-box for people who want an easy life and installation.
[16:49] <mdiggory> some events are state changes rather than just access
[16:50] <stuartlewis> Do we want to bring the Minho guys in on this (are they already?) so that we can make sure their solution stays compatible?
[16:50] <mhwood> I recall that state change has its own event bus but may be lackig a few instrumentation points?
[16:50] <mdiggory> stuartlewis: I think this is an example of where multiple community solutions can drive the creation of the appropriate DSpace services/plugins
[16:51] <stuartlewis> +1, so I think we need to get the mino guys involved, so that we don't have a modular solution with one one working module. if they are interested that is.
[16:51] <mdiggory> I would follow along with such an activity
[16:52] <kshepherd> sounds good
[16:53] * stuartlewis apologises for his rubbish typing this morning
[16:53] <stuartlewis> So wherenext with stats?
[16:53] <stuartlewis> Is there anythign we can be helping out with, or getting other people involved with?
[16:54] <mdiggory> @mire will be working on some of its ReportingService implementation, the plan is to make a delivery point that is more ReportingService centric in the UI's (a portlet of sorts)
[16:55] <mdiggory> Need feedback on parts that will apply to dspace-api, dspace-xmlui and dspace-jspui etc
[16:55] <mdiggory> which are primarily "hooks"
[16:56] <stuartlewis> OK - keep us all in the loop then and we'll contribute where we can.
[16:56] <stuartlewis> Anyone know how embargoes are progressing?
[16:56] <mdiggory> need feedback and discussion around https://scm.dspace.org/svn/repo/modules/dspace-services/trunk/
[16:57] <mdiggory> Really, this is where there is a convergence between 2.0 activities and 1.6 activities, one of those possible "stepping stones" I alluded to previously
[16:59] <mdiggory> dspace-services is a torn down version of the DSpace 2.0 ServiceManager backed by the PluginManager with a configuration service and the two prototpye LoggingService and ReportingService api's
[17:01] <bradmc> We're at the end of our nominal hour, so I won't drive any new topics. However, as this channel is logged, there is no reason that interested parties can't go on as long as they like. I'll attempt a summary email in the next day or two, including last week's mtg.
[17:01] <mdiggory> Ok, there are some comments about 2.0 in relation to the community I'd like to bring to light
[17:01] <kshepherd> what was the final word on this JIRA meeting/rundown?
[17:02] <bradmc> I'm going to find a way to make at least an initial Jira issue rundown happen. I have a little legwork to do first.
[17:03] <mdiggory> Per 2.0 If you recently paying attention to the commit logs, you noticed there was a lot of reorganization going on
[17:03] <mdiggory> most of the 2.0 codebase has been folded into the shared "modules" project space
[17:03] <mdiggory> https://scm.dspace.org/svn/repo/modules/
[17:04] <mdiggory> The intention here is that this space will share implementation of both 1.x and 2.x projects
[17:04] <mdiggory> and where they converge, there will be but one project with separate branches
[17:05] <mdiggory> The recent statistics work is a "poster child" for this intitiative
[17:07] <mdiggory> You also notice a new project in this space:
[17:07] <mdiggory> https://scm.dspace.org/svn/repo/modules/storage-fedora/trunk/
[17:08] <mdiggory> we anticipate that Andrius' work on dspace/fedora storage will be going here
[17:08] <mdiggory> Andrius Blainskas is our GSoC student (krnl_ )
[17:19] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[17:19] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[17:19] <mhwood> It seems we're all wondering how to respond.
[17:19] <mdiggory_> I tend to have that effect lately
[17:22] <mhwood> I think it's because you understand what it all means and some of us are still working that out.
[17:23] * mdiggory_ levitates off floor and vanishes
[17:25] <mdiggory_> ok, maybe something a little lighter to play with...
[17:25] * mdiggory_ pokes hole through his firewall...
[17:25] <mdiggory_> http://76.176.188.83:8080/display/dspace/Main+Page
[17:25] <mdiggory_> for a very short term viewing
[17:26] <mdiggory_> results of a one pass import of the dspace wiki into confluence
[17:26] <mhwood> Gee, that looks familiar.
[17:27] <mhwood> Aside from a few "unable to render embedded object"s it looks good at first glance.
[17:27] <mdiggory_> some linking behavior in mediawiki doesn't translate so well
[17:28] <mdiggory_> whered you get htat
[17:28] <mhwood> http://76.176.188.83:8080/display/dspace/Statistical+Improvements+for+v1.6
[17:28] <mhwood> At the bottom, Leiden University.
[17:28] <mdiggory_> ah, yes
[17:29] * bradmc (n=bradmc@dhcp-18-111-26-140.dyn.mit.edu) Quit ()
[17:29] <mdiggory_> looks like resolution of the attechments didn't work that time
[17:29] <mdiggory_> no page attachments
[17:30] <mhwood> If/when we switch I'll probably put my wiki gnome hat back on and help tidy up brokennesses again.
[17:31] <mdiggory_> something to experiment more with...
[17:31] <mhwood> Thanks for the peek. I've stayed too late already, must go.
[17:31] <mdiggory_> well, unlike the last time, we could do it "right" this time
[17:32] <mdiggory_> which means the conversion would be approved as completed before the old one was taken out
[17:32] <mdiggory_> ok... leter
[17:33] <mhwood> 'bye all.
[17:33] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:42] <stuartlewis> mdiggory_: That looks pretty cool - a neat conversion.
[17:46] <mdiggory_> thx, I was able to do the extraction in just a couple hrs. I will spend a little time researching the configuration and see why the files did not import
[17:56] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[20:05] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) Quit (Read error: 104 (Connection reset by peer))
[20:50] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) has joined #duraspace
[22:14] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit ()
[22:47] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[22:50] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.