Timestamps are in GMT/BST.
[0:31] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[0:48] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 110 (Connection timed out))
[3:32] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[3:50] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 110 (Connection timed out))
[6:05] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit ()
[8:05] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[8:22] * grahamtriggs (n=grahamtr@82.9.75.90) has joined #duraspace
[8:25] * grahamtriggs (n=grahamtr@82.9.75.90) Quit (Client Quit)
[8:26] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[8:42] * awoods (n=awoods@96.255.65.4) has joined #duraspace
[9:24] * awoods (n=awoods@96.255.65.4) Quit (Remote closed the connection)
[9:58] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[10:12] * awoods (n=awoods@pool-96-255-65-4.washdc.fios.verizon.net) has joined #duraspace
[10:33] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[10:38] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 60 (Operation timed out))
[10:45] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[11:01] * grahamtriggs (n=grahamtr@82.9.75.90) has joined #duraspace
[11:15] * bbranan (n=lc@9.159.121.70.cfl.res.rr.com) has joined #duraspace
[11:22] <cwilper> (moving jcr+fedora+duracloud discussion to irc)
[11:22] <awoods> In looking at the 'storage delegation layer' page:
[11:22] <awoods> http://fedora-commons.org/confluence/display/DSPACE/Storage+Delegation+Layer?focusedCommentId=7733379#comment-7733379
[11:22] <awoods> it seems worth discussing how we might leverage efforts
[11:23] <awoods> from my perspective... especially as we are trying to tackle duracloud/fedora/dspace plugins
[11:26] <cwilper> I know there was some thinking a while back to use JCR on the back end of dspace as a way to integrate with various stores.
[11:26] <awoods> what came of it?
[11:28] <cwilper> dunno. the "Content Repository Service API" was mentioned in Mark's comment on the above link.
[11:29] <awoods> were there discussions around this that fed into Akubra?
[11:32] <cwilper> I also heard from Mark at or09 that there's some thinking around using the DCMI Description Set Profile to help with defining constraints in a general way
[11:33] <cwilper> re:Akubra, not really...Akubra was never intended to take on anything more than blobs-with-uris
[11:33] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[11:34] <awoods> http://dublincore.org/architecturewiki/DescriptionSetProfile
[11:35] <cwilper> So far, the link from yesterday re:JCR is the closest attempt I've seen of getting a JCR interface for Fedora.
[11:35] <cwilper> I think having such a thing would be very welcome by a lot of folks
[11:36] <awoods> do you have that link?
[11:37] <cwilper> http://rit.mellon.org/projects/PloneJCR.pdf
[11:42] <cwilper> Also, link from Mark yesterday: http://weblogs.goshaky.com/weblogs/alexkli/entry/using_jackrabbit_spi_to_implement
[11:48] <awoods> I am looking at yesterdays log...
[11:48] <awoods> http://duraspace.org/irclogs/index.php?date=2009-06-30
[11:48] <awoods> it seems incomplete
[11:48] <awoods> or at least I am not seeing the links
[11:48] <cwilper> yes, logging didn't start till later yesterday
[11:49] <cwilper> i have the info in my buffer tho..hmmm...
[11:51] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 110 (Connection timed out))
[11:59] <cwilper> ok, previous text from yesterday is there now, check link again
[12:00] <mhwood> Was the DSpace committers' meeting to be in #duraspace or #dspace today?
[12:00] <grahamtriggs> It's meant to be here
[12:01] <grahamtriggs> we might want to periodically poke #dspace to get them over here
[12:01] <mhwood> Thanks.
[12:02] <mhwood> Okay, topic nominations for today?
[12:04] <mdiggory> hello
[12:05] <mhwood> Hello. Topics for today?
[12:06] <mdiggory> GSoC Mentors Evaluations are Next week
[12:06] <mdiggory> will announce to dspace-gsoc list
[12:08] <mdiggory> seems we are operating with a smaller group today
[12:09] <mdiggory> perhaps focus on topics that are relevant to us
[12:09] <mhwood> Do we usually discuss irrelevant topics? :-)
[12:10] <mdiggory> mhwood: there was a thread yesterday on some of the statistics work going on. I can give some status on the @mire side as we get ready to publish modules into the svn repo
[12:10] <mhwood> OK, that sounds like a topic. Anything else?
[12:12] <mdiggory> apparently not
[12:13] <mdiggory> Other topics of interest, since we have cwilper and bbranan we can chat about DSpace 2.0 / JCR etc
[12:13] <mhwood> tdonohue asks over on #dspace: "Is there a CGI:IRC interface to #duraspace anywhere? that's the only way I can get on IRC at work (all normal IRC ports are blocked)"
[12:14] <mdiggory> boggling...
[12:14] <mdiggory> cwilper: you still have that link I sent you... think its in your wiki now
[12:16] <mhwood> Yes, there was a question about JCR and related things just before you joined.
[12:17] <mdiggory> I see it
[12:17] <mdiggory> http://www.mibbit.com/
[12:18] * testing (i=52094b5a@gateway/web/freenode/x-b6b7477dc1562037) has joined #duraspace
[12:18] * testing (i=52094b5a@gateway/web/freenode/x-b6b7477dc1562037) Quit (Client Quit)
[12:18] <awoods> our experience yesterday was what mibbit was no longer working with freenode.net
[12:18] <cwilper> heard mibbit had probs with freenode, but this worked for ppl: http://webchat.freenode.net/
[12:19] * tdonohue_ (i=80ae241d@gateway/web/freenode/x-23884c684ed368c4) has joined #duraspace
[12:19] <mhwood> Apparently webchat does work.
[12:19] <grahamtriggs> cwilper: Freenode blocks Mibbit - but it tells you to use webchat.freenode.net
[12:19] <tdonohue_> yep, i got in via webchat.freenode.net just now
[12:20] <mhwood> OK, topics so far are "statistics" and "DSpace2/JCR".
[12:20] <mdiggory> ahh ok... good to note
[12:23] <mdiggory> tdonohue_: maybe you can comment ont he delegate admin stuff
[12:23] <tdonohue_> sure...I can do that...
[12:24] <tdonohue_> essentially, after problems with my NetBeans (it wasn't finding/committing all my code changes), I finally got DS-228 patch committed in preparation for 1.6
[12:24] <mdiggory> maybe a converstation about this channel in this channel
[12:24] <tdonohue_> it adds the ability to assign Community Administration privileges, and also adds the ability to move items (in XMLUI) between collections
[12:24] <mdiggory> I.E. #duraspace polisies
[12:25] <mdiggory> policies
[12:25] <tdonohue_> yes? it would be good to inform me of policies if they are different than #dspace
[12:26] <mdiggory> 1.) Everytime you say "commit" you have to drink
[12:27] <grahamtriggs> no wonder everyone in #dspace is sober
[12:27] <mdiggory> 2.) 100% Logged, 100% of the time
[12:28] <mdiggory> tdonohue_: Delegated Admins, how far along is it in terms of testing?
[12:29] <tdonohue_> Delegated Admins needs testing..it's in DSpace Trunk right now, but I'd appreciate any testing anyone can provide.....also, Andrea Bollini is leading the port to JSPU (currently it's only fully functional on XMLUI)
[12:30] <mhwood> Documented?
[12:30] <tdonohue_> Documentation is currently just here: http://jira.dspace.org/jira/browse/DS-228 That's still a to-do.
[12:30] <mdiggory> Is this where we call Jeff in?
[12:31] <tdonohue_> It's also worth reviewing the decisions made as to what Community Admins, Collection Admins can and cannot do....Currently this is *not* configurable, though that would be a nice addition, if somehow has the time to implement
[12:32] <mdiggory> mhwood: we talked about having some documentation templates a little last week. Maybe Jeff might be interested in pushing something like that into that task
[12:33] <tdonohue_> mdiggory and mhwood .... i'd definitely be wiling to work with jeff on trying out his documentation templates for this Delegated Admins patch
[12:33] <mhwood> Yes. If Jeff does it all, it's going to be a big job. The more we can help developers to provide good stuff to begin with, the better.
[12:34] <mhwood> Hmmm, I only recall the idea of templates for cataloging add-ons. But we do need some guidelines for usage documentation too.
[12:34] <mdiggory> mhwood: I'm avoiding the technological topic here... but maybe working in the wiki first would allow for rapid generation. Link to wiki page in JIRA issue
[12:35] <mdiggory> move wiki content to docbook once it is in relatively good shape
[12:36] <mhwood> That's the way I often think of using wikis: mine the good stuff for other, more settled documentation.
[12:37] <grahamtriggs> https://plugins.atlassian.com/plugin/details/7019
[12:37] <mhwood> Any more discussion of "delegate admin"?
[12:37] <tdonohue_> mhwood: I don't have any other details to mention, unless there are questions from others
[12:38] <mdiggory> configuring the delegation of delete and withdraw privileges
[12:39] <tdonohue_> mdiggory: Yes, that'd be a nice addition...if someone has time to take the lead on it, I'd encourage it....my time for most of the rest of the summer is unfortunately few and far between (so it may be a long while till I'd get to it)
[12:39] <mdiggory> we commented that it should be configurable, not hardcoded, which actions could be delegated. I'm hoping maybe we can determine if that is tractable
[12:40] <tdonohue_> it's definitely doable...I just haven't had the time to implement, and the patch needed to be committed so that others (Andrea, etc.) could build off of it more easily
[12:41] <mdiggory> I assume much of the changes rely on hardcoded logic that was in the legacy Collection object and delegation is replicating that hardcoded logic into Community.
[12:41] <mdiggory> +1 on working iteratively
[12:42] <tdonohue_> not entirely, to be honest, some of it was based on local policy decisions made at Illinois (since we've been running this patch for over a year now)...these are the privileges we wanted to give to Community/Collection Admins
[12:42] <mhwood> Yes, a nice implementation will be a sizable job.
[12:44] <mdiggory> Ok, so, theres a possible iteration of work there to consider, we should get moving we have about 15 official minutes left
[12:44] <mhwood> If we want this meeting to run an hour, we have about 16 minutes left.
[12:45] <mhwood> Was there more discussion of #duraspace policies?
[12:45] <mdiggory> not really IMO
[12:45] <mdiggory> want to finish up a breif chat on statistics
[12:45] <mdiggory> Statistics, I want us to start working on identifying common change points in dspace-api and dspace-xxx-api/webapp for supporting
[12:45] <mdiggory> for supportiing statistics logging.
[12:46] <mhwood> I think we have them for content views, unless I missed something. Other events?
[12:46] <mdiggory> for instance, Minho logs update events as Usage Events, workflow stage changes etc
[12:47] <mdiggory> the existing Event API doesn't currently log until the Item is Archived
[12:48] <tdonohue_> mhwood: "content views" = file downloads? Or does "content views" = a "hit" on the item splash page?
[12:48] <mdiggory> UsageEvent was originally conceived to be just view/downlaod events
[12:48] <mhwood> UsageEvent is essentially the instrumentation points from the Rochester stat. code, made pluggable.
[12:49] <mdiggory> Right now I'm "revisioning" UsageEvent a little bit in the work I'm doing, there are some issues with it
[12:49] <mdiggory> 1.) can't attach more than one "provider"
[12:49] <mdiggory> 2.) we can make this look more like the 2.0 Services and it will be cleaner
[12:50] <mdiggory> i.e. StatisticsLoggerService with an interface fireEvent(UsageEvent event)
[12:50] <mhwood> Yes, after I pushed it out I began to think of uses for a chain of event sinks.
[12:51] <mdiggory> and have event just be an interface
[12:51] <mdiggory> no sorry, I mean a simple been
[12:51] <mhwood> "bean"?
[12:52] <mdiggory> yes, not bein or been, but bean
[12:52] <mdiggory> This does bring us to a topic that started to arise in the dspace-architecture list.
[12:53] <mdiggory> We can take some of the dspace 2.0 services api and create a wrapper around the legacy plugin manager that emulates what is going on in 2.0 but against the dspace.cfg/PluginManager
[12:54] <mdiggory> I've already prototyped it in creating the above service
[12:54] <mdiggory> but not trying to drill down into details, just bringing up topic and suggesting we organize another meeting around it
[12:55] <mhwood> Sounds okay to me.
[12:55] <mdiggory> this leads us to another topic... dspace-architecture
[12:56] <mhwood> I subscribed but am not caught up -- fast and furious discussion of things the architects already understood. Must find more hours in the day for reading.
[12:57] <mdiggory> there was considerable chatter last week about migrating dspace 2.0 discussion to the dspace-devel list instead of having it located in a separate list, currently theres about 50 members
[12:57] <mdiggory> and there are currently about 390 members in dspace-devel
[12:57] <grahamtriggs> mhwood: I'm in the opposite situation - completely up to date in -architecture, but not caught up in the other lists
[12:58] <mdiggory> and for reference there are 1100 members in tech
[12:58] <mhwood> A brief intro on "how to think about this stuff" would be really helpful if discussion is moved into -devel.
[12:59] <mhwood> Not to squash this topic, but we have 1 minute and haven't talked about DS2/JCR issues.
[12:59] <mdiggory> I'm not wholly convinced it will be beneficial to consolidate the lists yet
[13:00] <mdiggory> we can table that topic
[13:00] <mdiggory> for further discussion afterwar
[13:00] <mdiggory> d
[13:01] <grahamtriggs> mdiggory: agreed - I don't accept the suggestion that '-architecture' is some kind of back-channel. Anyone that wants to read it/participate is free to sign up.
[13:01] <grahamtriggs> short term move, I propose that joining -architecture is advocated on the -devel list
[13:02] <mdiggory> my concern is that making it so folks have to identify the category of the topic in their subject heading in one central list will result in a mess because folks won't always do it
[13:02] <mhwood> Either way there is need for some way that others can readily come up to speed on the organization and conceptual layout of 2.0.
[13:02] <mdiggory> and they will make up their own [topic]
[13:03] <mdiggory> mhwood: Yes, but its not a listserv
[13:03] <mdiggory> its not a listserv thats going tohappen in
[13:04] <mdiggory> we need more tutorials, documentation and examples for testing
[13:04] <mhwood> If you find people writing Subject: [topic] a lot, you really have multiple lists.
[13:04] <mdiggory> or, we need an effort to consolidate those activities.
[13:05] <tdonohue_> i think they should remain separate lists, until the 2.0 work has tutorials, documentation, etc...otherwise it will be way to confusing for folks on -devel
[13:05] <mhwood> I need to actually fire up the copy I checked out and start tripping over things in the dark corners.
[13:05] <tdonohue_> until the documentation for 2.0 is there, interested folks can just follow -architecture for the latest work
[13:06] <grahamtriggs> mhwood: there aren't any dark corners - just gaping holes where the corners are meant to be
[13:06] <mhwood> Yes, the barriers to entry need to be low enough or some will just tune out.
[13:06] <mdiggory> I think the proposition of consolidating the lists is to get more folks involved. So the real question is how do we get more folks involved as the foundation funded project effort is ending
[13:06] <mdiggory> note: foundation funded project ending != to developers stopping work
[13:07] <grahamtriggs> step 1: encourage people to join -architecture
[13:07] <grahamtriggs> step 2: repeat step 1 until we can think of a step 2
[13:07] <tdonohue_> i think you get more folks involved by building documentation/tutorials on how to begin to "play with" the 2.0 work.....and some more advertising of the main "features" helps too
[13:08] <mdiggory> tdonohue_: grahamtriggs I agree
[13:08] <tdonohue_> that advertising can happen on -devel, and then bring up this discussion of merging the lists....I think in the longer term they should be merged...just not yet
[13:08] <mhwood> Keeping them separate with an open invitation sounds good. That way you get those curious enough to work it out, and don't overwhelm those who aren't yet ready.
[13:08] <mhwood> Separate for now, joined later when it's easier to get started.
[13:09] <tdonohue_> mhwood: exactly
[13:09] <mdiggory> this is the feedback we need to make a decision (or argument) on, thanks
[13:10] <mdiggory> ok, I need to finish up and tackle other activities this morning.
[13:10] <grahamtriggs> in the longer term, they will either merge naturally, or there will be a clear need (in the community) for having separate 1.x and 2.x discussion strands
[13:10] <mdiggory> so I propose we adjourn this meeting
[13:10] <mhwood> Thanks, everybody.
[13:10] <tdonohue_> yep...thanks! later, everyone
[13:10] <mdiggory> grahamtriggs: yes
[13:11] <mdiggory> cheers, thanks everyone who showed up :-)
[13:13] * tdonohue_ (i=80ae241d@gateway/web/freenode/x-23884c684ed368c4) has left #duraspace
[13:31] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit ()
[14:14] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[16:32] * grahamtriggs (n=grahamtr@82.9.75.90) Quit ()
[17:00] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:03] <mdiggory> graham pointed out Scroll for generating docs off a wiki... looks like they have a community license model same as confluence... nice
[17:03] <mdiggory> We offer free community licenses to community license holder of Confluence. Contact sales@k15t.com to obtain your free Scroll community license.
[17:03] <mdiggory> http://www.k15t.com/scroll
[17:08] <mdiggory> cwilper: awoods bbranan what are your thoughts on confluence sharing?
[17:08] <mdiggory> hmm, docBook to confluence round tripping http://sourceforge.net/projects/dita2wiki/
[17:11] <cwilper> seems like a good idea to me...brad has also pointed out this would be good
[17:13] <cwilper> i think it requires us to think about how to deal with user management (ldap) a bit
[17:14] <mdiggory> are you using ldap to manage confluence accounts?
[17:14] <cwilper> besides the fun technical bits of getting a shared ldap+confluence setup, let's say we had a shared install...
[17:15] <cwilper> yes, via crowd (gives a decent web interface to openldap, plus provides a singlesignon plugin for other atlassian products)
[17:16] <mdiggory> So my fedora confluence login works on the fedora JIRA as well then... nice
[17:17] <cwilper> yeah, as much as possible, that's very nice to have. plus it email addresses in ldap for notifications across both.
[17:17] <mdiggory> shared install would possibly be either each project as separate space and top level a duraspace?
[17:19] <cwilper> right now there are quite a few spaces in the fc confluence. like a dedicated space for "official" fedora 3.x docs, but then looser spaces for scribbling design thoughts, and various other things.
[17:20] <mdiggory> so it might not be so clean as that
[17:20] <cwilper> so there's the potential of multiple spaces per project, yeah
[17:21] <cwilper> confluence lets you have many, many spaces...there's no hierarchy on them though, it's just a flat list.
[17:23] <cwilper> having a project-neutral space would be nice too...
[17:26] <cwilper> btw, which link? i missed to context of this: <mdiggory> cwilper: you still have that link I sent you... think its in your wiki now
[17:26] <mdiggory> the one that was used to configure the web based IRC client
[17:28] <cwilper> ahh, ok. well it looks like freenode's is working ok for people.
[17:34] <cwilper> seems like having confluence at duraspace.org/confluence or somesuch makes sense.
[17:35] <cwilper> the same sort of thing could potentially be done w/jira.
[17:36] <cwilper> it occurred to me with jira that some of the configuration would be "fun" to try to merge. for example, custom issue types are a global (instance-wide) thing.
[17:51] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) Quit (Read error: 104 (Connection reset by peer))
[17:52] <mdiggory> we should consult with Atlassian to see if duraspace can run multiple instances of confluence and jira at no cost.
[17:55] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) has joined #duraspace
[18:06] <cwilper> i suspect it's possible...but multiple instances would be more work to manage. seems like we should see how feasible a shared instance would really be.
[18:09] * bbranan (n=lc@9.159.121.70.cfl.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[18:21] * cwilper is talking to Douglas Butler of Atlassian
[18:27] <cwilper> Ok, Douglas said having multiple instances would be no problem from a licensing perspective.
[18:59] <mdiggory> thats good to know
[20:30] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Read error: 110 (Connection timed out))
[22:07] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[22:12] * awoods (n=awoods@pool-96-255-65-4.washdc.fios.verizon.net) Quit (Read error: 113 (No route to host))
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.