Timestamps are in GMT/BST.
[0:29] * gsoc_ajhall (~darkmatte@acad54185.wireless.uic.edu) has joined #duraspace
[3:20] * gsoc_ajhall (~darkmatte@acad54185.wireless.uic.edu) Quit (Ping timeout: 246 seconds)
[4:30] * sbayliss (~IceChat7@188-222-88-173.zone13.bethere.co.uk) Quit (Ping timeout: 250 seconds)
[4:35] * guilhermekfe (~guilherme@189.73.205.136) Quit (Ping timeout: 240 seconds)
[5:24] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:52] * robertqin (~robertqin@nusnet-194-127.dynip.nus.edu.sg) has joined #duraspace
[6:52] <robertqin> hello there...
[6:52] <robertqin> I am a student from the National University of Singapore
[6:53] <robertqin> a year 3 information system students
[6:53] <robertqin> and I am very interested to take part in the JSPUI rewrite project under GSOC
[6:54] <robertqin> I am developed enterprise applications before
[6:54] <robertqin> and the main reason why I am interested in this project is because I have a habit of incorporating scriplet logic in my JSP pages
[6:54] <robertqin> and I am interested to find out more on how DSpace technologies can help me overcome that...
[6:55] <robertqin> I was wondering if anyone here could advice me on the specifics on the required DSpace components required
[6:56] -sendak.freenode.net- *** Looking up your hostname...
[6:56] -sendak.freenode.net- *** Checking Ident
[6:56] -sendak.freenode.net- *** Found your hostname
[6:56] -sendak.freenode.net- *** No Ident response
[6:56] [frigg VERSION]
[6:56] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:56] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:56] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:49] * robertqin (~robertqin@nusnet-194-127.dynip.nus.edu.sg) Quit ()
[12:14] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:19] * guilhermekfe (c889c59e@gateway/web/freenode/ip.200.137.197.158) has joined #duraspace
[13:05] * william_caiyun (da4f7067@gateway/web/freenode/ip.218.79.112.103) has joined #duraspace
[13:30] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[13:47] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[14:21] * william_caiyun (da4f7067@gateway/web/freenode/ip.218.79.112.103) Quit (Quit: Page closed)
[14:46] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[16:35] * guilhermekfe (c889c59e@gateway/web/freenode/ip.200.137.197.158) Quit (Quit: Page closed)
[16:50] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:03] * sandsfish (~sandsfish@18.111.28.210) has joined #duraspace
[19:04] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[19:10] * sandsfish (~sandsfish@18.111.28.210) Quit (Quit: sandsfish)
[19:11] * sandsfish (~sandsfish@18.111.28.210) has joined #duraspace
[19:12] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:36] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:41] <tdonohue> Reminder, DSpace Devel Mtg here at top of hour. Here's today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-30
[19:41] <kompewter> [ DevMtg 2011-03-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-30
[19:50] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:50] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) has joined #duraspace
[19:50] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all. DSpace Developer Mtg starting now. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-30
[20:00] <kompewter> [ DevMtg 2011-03-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-30
[20:00] <tdonohue> We'll kick things off with a JIRA "Quick Review" (~2min per issue), through this list of issues: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-756+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-756 ] - [#DS-756] Mirage theme, My Account context lists menu point submissions even if no unfinished submissions or workflow tasks are available - DuraSpace JIRA
[20:00] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-756+ORDER+BY+key+ASC
[20:00] <tdonohue> And, kompewter very nicely put in the first issue up for review, DS-756
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-756 ] - [#DS-756] Mirage theme, My Account context lists menu point submissions even if no unfinished submissions or workflow tasks are available - DuraSpace JIRA
[20:01] * richardrodgers (~richardro@18.111.4.50) has joined #duraspace
[20:01] <mdiggory> Think we should set that one to "won't fix"
[20:02] <tdonohue> thoughts on Ds-756? I'm not sure this is really a bug, based on Ben Bosman's comments
[20:02] <mdiggory> Or change it to feature request. invite feature for someone to develop,
[20:03] <mhwood> Agree. Maybe the "Submissions" link title is unclear? Dunno what else to use, though.
[20:04] <mhwood> Split into "My submissions" and "submit an item"?
[20:04] <mhwood> Or leave alone and check the documentation.
[20:05] <mdiggory> Yes, without the submissions view, you have to submit via the link in the collection view.
[20:05] <mdiggory> Submit to this collection is actually something that should be in the "Context" menu
[20:05] <tdonohue> unsure -- suggest marking "won't fix", but ask Claudia to open a separate feature request if she has suggestions on improved usability
[20:05] <mdiggory> not in the body of the page
[20:06] <tdonohue> (can also add a comment about mhwood's suggestion of splitting this up into two menu items)
[20:06] <mhwood> It sounds like the "won't fix"es have it.
[20:06] <mdiggory> its already partially split... could use some cleanup....
[20:07] <mdiggory> switch to feature request and leave out there for someone to enhance... its actually a good idea
[20:07] <tdonohue> moving on to next issue for now, DS-757
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-757 ] - [#DS-757] Mirage theme - managing of subscriptions - DuraSpace JIRA
[20:07] <PeterDietz> +1 idea
[20:08] <mhwood> Turn it into a feature request, as commented.
[20:08] <mdiggory> Here we are again... should be in the Context Menu of the collection
[20:08] <mdiggory> not in the page
[20:08] <richardrodgers> +1 feature request, as noted
[20:08] <tdonohue> +1 idea, should be feature request
[20:08] <mhwood> +1 idea
[20:09] <mdiggory> can we change the name so we are not saying "Mirage Theme" on all these?
[20:09] <PeterDietz> in the left hand column or not, there should be some way to subscribe to current "container" from current page
[20:09] <tdonohue> Ds-757 summary: +4 to idea, switch it to a feature request (we can also switch Ds-756 to feature request similarly)
[20:09] <mdiggory> +1
[20:09] <tdonohue> Next one: DS-759
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-759 ] - [#DS-759] Add the ability to copy to self of feedback - DuraSpace JIRA
[20:10] <mhwood> +1
[20:10] <tdonohue> +1 to idea, switch to a feature request again
[20:10] <sandsfish> +1, sounds reasonable.
[20:10] <richardrodgers> +1 feature request
[20:11] <PeterDietz> User clicks feedback, fills in body, hits submit. Then only the administrators get email, submitter is left in the dark until they get a follow-up response
[20:11] <PeterDietz> +1 idea
[20:11] <tdonohue> Ds-759 summary: +5, switch to feature request
[20:11] <tdonohue> Next up: DS-762
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-762 ] - [#DS-762] Add getter methods to objects, even if they have public fields - DuraSpace JIRA
[20:12] <sandsfish> Seems pretty easy and straightforward and harmless.
[20:12] <mdiggory> I actually have this int he domain model
[20:12] * JRhoads (~jrhoads@160.10.15.22) has joined #duraspace
[20:13] <mhwood> Yes.
[20:13] <richardrodgers> OK in principal - but I'd want to see concrete proposal. There are intentionally packaged scoped accesses....
[20:13] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/api/src/main/java/org/dspace/content/IMetadataField.java
[20:13] <tdonohue> ok, add comment relating back to domain model refactoring? (mdiggory, is there a JIRA issue for domain model stuff yet that we can relate it to?)
[20:13] <PeterDietz> This one would be followed up by remove usages of public fields? or wait until some overarching effort does that anyway?
[20:13] <mdiggory> jira.dspace.org
[20:13] <mdiggory> doh, wrong window
[20:13] <mhwood> Heh, it's not just me.
[20:14] <mdiggory> https://jira.duraspace.org/browse/DS-845
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
[20:14] <kompewter> [ [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-845
[20:14] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:14] <tdonohue> Ds-762 summary - should be related to Ds-845. Most seem ok with this 'in principal', but more specifics may be necessary
[20:15] <tdonohue> next up: DS-764
[20:15] <kompewter> [ https://jira.duraspace.org/browse/DS-764 ] - [#DS-764] OAI-PMH ListRecords false no result answer and missing resumptionToken - DuraSpace JIRA
[20:16] <richardrodgers> what is proper behavior per spec?
[20:16] <tdonohue> hmmm... sounds like a bug, but it'd be nice if someone could verify this (and compare to spec)
[20:16] * tdonohue isn't sure what "proper behavior" is here..anyone?
[20:17] <tdonohue> the patch itself seems relatively minimal & looks harmless at a glance..
[20:18] <tdonohue> any volunteer for Ds-764? Needs analysis & verification of proper response based on spec
[20:19] <tdonohue> Ds-764 Summary: Leave open, needs volunteer. Does patch follow 'proper behavior' per OAI-PMH spec? (Need someone to check and verify that)
[20:20] <kshepherd> morning all
[20:20] <tdonohue> we'll stop there for today...as we are at 20min
[20:20] <tdonohue> hi kshepherd
[20:20] <richardrodgers> hey
[20:20] <mhwood> Spec speaks of "deleted" records but not "unauthorized", which is what I thought "indisseminable" means....
[20:21] <tdonohue> next topic: first off, a congrats to us all on the 1.7.1 release! (thanks PeterDietz for sticking with it despite various Maven issues, etc)
[20:21] <kshepherd> yay
[20:21] <richardrodgers> yes congrats PeterDietz !
[20:21] <mhwood> [applause]
[20:21] <PeterDietz> The maven-monkey business for actually pulling off the whole releasing is not as scary as it looks, so I recommend all to not be afraid of it. (you may get bit a few times though)
[20:22] <sandsfish> thanks PeterDietz!
[20:22] <tdonohue> The Maven release issues we hit during 1.7.1 have all been resolved, and were not a fault of our "release procedure". Rather, they were the fault of accidental misconfiguration & typos in a few pom.xml files (whoops!)
[20:22] <JRhoads> Yes. Thank you PeterDietz
[20:22] <PeterDietz> ...also, I want to thank my agent, the directors, the creative team at duraspace, @mire, New Zealand folks for being awake, and .... (band starts playing to shoo me off-stage)
[20:23] <tdonohue> haha :)
[20:23] * kshepherd reaches out a shepherd's crook
[20:23] <PeterDietz> for next release coordinator robint I recommend upgrading your computer so you don't fall asleep doing all the release/perform steps
[20:24] <robint> PeterDietz: Noted :)
[20:24] <tdonohue> Ok, next bigger topic I wanted to bring up is our next release. I'd like to suggest moving right to 1.8.0 now (i.e. skip over 1.7.2), unless we hit upon a major issue in 1.7.1 (fingers crossed, hopefully we won't). Thoughts?
[20:24] <PeterDietz> but hopefully no silly bugs have crept into 1.7.1, I'm now excited to get people to upgrade, and hopefully get some traction behind things like curation tasks
[20:25] <mhwood> That's exactly what point releases are for, no?
[20:25] <tdonohue> correct. I guess the question is -- how long do we want to continue doing updates to *2* places in SVN (1.7.x branch & trunk), and when do we just switch to *trunk only* work...
[20:26] <richardrodgers> I'd like to see a minimal number of 1.7.1 installs before we breathe easy...
[20:26] <sandsfish> agreed.
[20:26] <sandsfish> but pending that, it sounds reasonable.
[20:27] <tdonohue> well -- there's two options as I see them...
[20:27] <tdonohue> (1) Keep working in 2 places in SVN until we feel we can "breathe easy"
[20:28] <PeterDietz> I wouldn't work on 1.7.x (for 1.7.2) unless we've found something solely worthy of a release. i.e. focus effort on making 1.8 awesome, something blows up, then 1.7.x gets attention
[20:28] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[20:28] <mhwood> PeterDietz++
[20:29] <PeterDietz> also you can say .addpoint PeterDietz
[20:29] <kshepherd> oops, Tim fell off
[20:30] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[20:30] <kshepherd> PeterDietz: that's not as cool though ;)
[20:30] <tdonohue> sorry all, I somehow got booted
[20:30] <kshepherd> and when i say cool i mean nerdy
[20:30] <PeterDietz> .addpoint kshepherd
[20:30] <kompewter> kshepherd: +1/-0, 1
[20:30] <mhwood> IOW if you find something in 1.7.x that is worth another release, fix it there and be sure it's okay in trunk; otherwise just work in trunk.
[20:31] <tdonohue> As I was saying, two options:
[20:31] <tdonohue> (1) Keep working in 2 places in SVN until we feel we can "breathe easy"
[20:31] <tdonohue> OR, 2) Only work out of Trunk, BUT make a promise to revisit 1.7.x branch *if and only if* there is a major bug that needs immediate release in a 1.7.2
[20:31] <kshepherd> yep i'm +1 on that :)
[20:32] <robint> +1 for option2
[20:32] <sandsfish> +1 for #2, for simplicity
[20:32] <kshepherd> (uh yeah i meant 2 too)
[20:32] <mhwood> +1 #2
[20:32] <richardrodgers> yea, I'm hoping that it won't be too long, so the tracking behind (2) should not be onerous
[20:33] <tdonohue> PeterDietz has said the same thing as I did, in my option #2 (just in a different way)
[20:33] <tdonohue> Ok, sounds like it's official then, Commits now move to Trunk. No more commits to 1.7.x branch, unless we discover something worthy of an immediate 1.7.2 release
[20:33] <PeterDietz> for 1.8 do we have ideas for what the milestones/betas will be? I imagine they'll have a load of changes from services / DAO?
[20:34] <tdonohue> (I'll also send a note about this decision to dspace-commit for others who didn't make this meeting)
[20:34] <tdonohue> The originally "suggested" 1.8 milestones are on the wiki here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes#DSpaceRelease1.8.0Notes-TimelineandProceeding
[20:34] <kompewter> [ DSpace Release 1.8.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes#DSpaceRelease1.8.0Notes-TimelineandProceeding
[20:35] <tdonohue> But, I've heard from several folks that there are concerns about the idea of "Beta" releases. Already, we've had people misunderstand what we originally meant by "beta"
[20:35] <tdonohue> For instance, I joined the DCAT meeting last month, and I had questions around whether we were having a feature freeze really early, so that we could ensure all features were in the first "beta"
[20:36] <robint> Yup, a colleague commented to me that "1.8 is being released in June"
[20:36] <mhwood> "We think this revision works. If you break it, tell us how."
[20:37] <tdonohue> So, I'm now also concerned about this "beta" release idea -- if you recall, initially we saw these as "early releases" which do not necessarily include all the changes or features in the final 1.8
[20:37] <richardrodgers> I was thinking of betas not as complete frozen releases, but feature previews
[20:37] <PeterDietz> instead of beta, how about alpha? (wondering if that changes peoples minds at all)
[20:37] <richardrodgers> intended to allow for longer community input
[20:37] <robint> The problem is that it would be labelled 1.8 alpha, or beta, or whatever
[20:37] <tdonohue> I should reword what I said: I *like* the idea of having some sort of "feature preview" mini-releases, but I don't think we should call them "beta" o
[20:37] <kshepherd> if we make feature freezes even earlier, won't that potentially result in *fewer* features? (alhtough it should mean that the features that do make it in a more stable/tested)
[20:38] <robint> Its the 1.8 bit that is misleaading
[20:38] <tdonohue> kshepherd -- wasn't suggesting doing an early feature freeze -- that was a misunderstanding from DCAT. They thought that a feature freeze would be *preceding* the first beta release
[20:38] <richardrodgers> I would decouple freezing from releasing - early on we can do latter without former
[20:39] <PeterDietz> no real need for feature freeze, other than we don't cut a release while the build is failing
[20:39] <kshepherd> robint: good thinking
[20:39] <kshepherd> theres probably a good term we can come up with that doesn't include version number
[20:40] <kshepherd> a 'codename' focused on the date or the features, not the final release tag
[20:40] <PeterDietz> dspace-11-05 (YY-MM)
[20:40] <tdonohue> aha, that's an idea. codenamed early releases :)
[20:41] <kshepherd> DSpace Dietz Alpha
[20:41] <JRhoads> Yeah. I think something that involves the date would be helpful.
[20:41] <mhwood> What's the difference between "DSpace 11-05" or "DSpace primal scream" and "DSpace 1.8.0 beta"?
[20:41] <PeterDietz> dspace-hamburger-hill H=8
[20:41] <tdonohue> or maybe just "1.8.0 early preview"?
[20:41] <kshepherd> mhwood: in terms of perception, i think robint was suggesting that the 1.8.0 makes people ignore the rest of the name and go "oh, 1.8.0 in [X date]"
[20:41] <richardrodgers> maybe just OR demo DSpace?
[20:41] <kshepherd> and i tend to agree
[20:42] <robint> kshepherd: yup
[20:42] <mhwood> Call it 1.7.9[0-9], like X.org does?
[20:42] <tdonohue> hmm... worried about numbering it with 1.7.x though, as it will likely (hopefully) have a few different features, etc
[20:43] <robint> If they are true tested releases with new features then they should be called 1.8, 1.9 etc
[20:43] <tdonohue> Maybe we do just do this by date -- "DSpace 11-05, an early preview of what is to come in 1.8"
[20:43] <JRhoads> Yeah. Il ike the idea of the minor version number as a bug fix.
[20:44] <mhwood> OK, /me doesn't get why numbers are so confusing, too long in this business.
[20:44] <tdonohue> yea, we've gone on too long here. let's table, and brainstorm on our own
[20:45] <tdonohue> next topic: GSoC 2011
[20:45] <tdonohue> Updates: we already have 4 applications in! (all for Dspace, so far)
[20:45] <richardrodgers> do tell
[20:46] <kshepherd> so.. the ideas i was brainstorming on the ideas page hasn't really had a lot of feedback or votes up/down from anyone
[20:46] <tdonohue> first, here's the project ideas here: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:46] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:46] <kshepherd> there are a few that probably don't deserve a full slot
[20:46] <tdonohue> as kshepherd notes, we really haven't voted on these yet
[20:46] <kshepherd> i've taken my name off a bunch
[20:46] <JRhoads> Have any emerged as favorites among the applicants?
[20:46] <stuartlewis> Agreed - we need to choose which projects are most important to us.
[20:47] <kshepherd> a lot of people are joining IRC/mailng list and expressing interest in teh JSPUI rewrite
[20:47] <stuartlewis> Favourite so far is jspui rewrite, but that probably isn't favourite amongst the community?
[20:47] <kshepherd> but i think that's just because it mentions a bunch of known, popular tech
[20:47] <tdonohue> but, the ones that already have a student application in on them are: 2 apps for "JSPUI rewrite", 1 app for "RTMP A/V Streaming", and 1 app for "Improve Submitter User experience"
[20:47] <kshepherd> stuartlewis: exactly, it's a favourite among students
[20:47] <kshepherd> but might not be best choice for a slot ;)
[20:48] <stuartlewis> Agreed - so do we need to trim our list down to the projects that we would be most keen to see developed?
[20:48] <kshepherd> i didn't realise DuraCloud already did RTMP streaming when i put that idea up, though i'm still kinda keen on it
[20:49] <tdonohue> kshepherd -- I think that DSpace should support RTMP streaming even *without* DuraCloud, to be honest. DuraCloud should just be one source
[20:49] <kshepherd> tdonohue: yeah for sure
[20:49] <richardrodgers> stuartlewis: in order to steer students to high-value projects?
[20:49] <stuartlewis> richardrodgers: Yes, exactly.
[20:49] <kshepherd> tdonohue: i was wondering if it could mean a sub-project for a specialised dspace player, without concentrating so much on the red5 backend
[20:49] <kshepherd> but both works
[20:50] <stuartlewis> If we don't steer them, we might be left i nthe situation of having good students with bad projects, and bad students with good projects, and it makes it hard to decide.
[20:50] <kshepherd> (one issue i've had in the red5 + generic player testing i've done myself is with authZ)
[20:50] <mhwood> How does HTML5 impact the streaming stuff?
[20:51] <tdonohue> +1 stuartlewis
[20:51] <kshepherd> so yeah i'd love to hear votes or comments on the ideas that are there
[20:51] <stuartlewis> Yes - should we rank them? And mark them as such, to help guide the students?
[20:51] <tdonohue> Do we want to do a quick run-down & vote on some of these (really quick +1 = I like it, 0 = not sure, -1 = against it)?
[20:51] <stuartlewis> tdonohue: +1
[20:52] <kshepherd> mhwood: i'd say it could impact hte players, but i'm not sure if browser support is quite there yet to replace flash? definitely worth considering
[20:52] <PeterDietz> stuartlewis: I don't think that tdonohue is a GSoC project
[20:52] <tdonohue> Ok, I'll post them in order here, please vote quickly on each, just your opinion of it's usefulness: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:52] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:52] <stuartlewis> I dunno - we could make 5 of him - that would be great?!
[20:53] <tdonohue> "Enhanced RESTful API" project
[20:53] <stuartlewis> +1
[20:53] <PeterDietz> REST +1
[20:53] <tdonohue> REST +1
[20:53] <sandsfish> REST +1
[20:53] <JRhoads> +1
[20:53] <mhwood> 0
[20:53] <richardrodgers> +1
[20:53] <robint> REST+1
[20:53] <tdonohue> Ok, looks like most approve of REST API. Next one...
[20:53] <tdonohue> JSPUI rewrite project
[20:53] <kshepherd> +1, with the caveat that if it doesn't happen this year, it should happen outside gsoc (3 years is enough!)
[20:53] <stuartlewis> 0
[20:53] <kshepherd> crap, my vote was for REST
[20:54] <kshepherd> JSPUI: 0
[20:54] <tdonohue> JSPUI: 0
[20:54] <mhwood> JSPUI: 0
[20:54] <JRhoads> JSPUI: 0
[20:54] <richardrodgers> JSPUI: 0
[20:54] <sandsfish> JSPUI: 0
[20:54] <robint> 0
[20:54] <PeterDietz> JSPUI: 0.001
[20:54] <tdonohue> Ok, looks like we are all not so interested in a new JSPUI (or we just don't care)
[20:54] <tdonohue> Next one..
[20:54] <tdonohue> "WebMVC (Freemarker) UI development" project
[20:54] <stuartlewis> + 0.5
[20:54] <mhwood> WebMVC: 0
[20:55] <PeterDietz> Freemarker +1
[20:55] <robint> +1 because I think Graham would welcome some help
[20:55] <tdonohue> I'd lean slightly towards +1 here, as I'd like to see new UIs
[20:55] <richardrodgers> WebMVC +1 (better son-of-JSPUI)
[20:55] <kshepherd> freemarker +1
[20:55] <JRhoads> WebVMC: +1 new UIs would be great
[20:55] <tdonohue> Ok, most seem in favor of WebMVC...next one
[20:55] <tdonohue> "Modular configuration" project
[20:56] <richardrodgers> 0 - not a student project, infrastructure
[20:56] <kshepherd> note that modular config also ivolves move to configurationservice
[20:56] <tdonohue> +1 to *idea*, but worried about "size of project" (plus, no mentor volunteer yet -- it would need tight control)
[20:57] <stuartlewis> 0: Ditto same reason as richardrodgers
[20:57] <tdonohue> actually, richardrodgers is probably right, this really is core infrastructure ;)
[20:57] <mhwood> Configuration: 0, size worries, good idea
[20:57] <robint> I think I agree with richardrodgers
[20:57] <kshepherd> ok
[20:57] <tdonohue> Ok, so we are all worred about "Modular config" as a student project
[20:57] <tdonohue> Next up..
[20:57] <JRhoads> 0, I reallylike the project but not fot GSOC
[20:57] <tdonohue> "MySQL support" project
[20:57] <stuartlewis> MySQL: 0, but might be taken care of in other re-wroking DSpacey 2 type stuff?
[20:57] <kshepherd> mysql: on it's own.. too small as a gsoc project
[20:58] <kshepherd> with DAO, could work?
[20:58] <PeterDietz> MySQL 0, DAO momentum +1
[20:58] <mhwood> mysql: 0, dependent on DAO work not yet available?
[20:58] <tdonohue> +0.5 (though as mdiggory notes in comments, has overlap with some of the Domain model stuff)
[20:58] * kshepherd feels as though he should abstain from most of these :P
[20:58] <richardrodgers> If done, should be part of larger abstraction, not one-off in current code
[20:59] <tdonohue> ok -- looks like there are also concerns about MySQL (though may be a way to create a project which helps with larger abstraction?)
[20:59] <sandsfish> DAO pursuant of a cleaner mysql sol
[20:59] <tdonohue> Next up:
[20:59] <tdonohue> "Pluggable bitstream storage" project
[20:59] * tdonohue thinks kshepherd should still vote on these, even if he suggested them :)
[21:00] <stuartlewis> +1, get rid of our SRB dependencies.
[21:00] <kshepherd> 0, no mentors, conflicts with duracloud probably
[21:00] <mhwood> richardrodgers already did this, yes?
[21:00] <PeterDietz> bitstream: moderately interested, wondering where it affects duracloud, s3 would be nice though possibly
[21:00] <richardrodgers> mhwood: yes, just needs integration
[21:00] <robint> Got to go unfortunately, cheers all.
[21:00] <tdonohue> richardrodgers, so this is done?
[21:01] <mdiggory> sorry guys I'm going to have to review this and answer questions afterwards. I've been pulled away from the meeting
[21:01] <kshepherd> ok then, -1 # already done but not committed
[21:01] <JRhoads> me too. Lab is closing.
[21:01] <PeterDietz> It would be interesting to get dspace installed into google app engine, which would require bitstream pluggable
[21:01] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) Quit (Quit: Page closed)
[21:01] <richardrodgers> essentially yes, and I'd agree with stuartlewis, it's a way ti shed the SRB dependencies
[21:01] <richardrodgers> ti->to
[21:02] <tdonohue> ok, then it sounds like "Pluggable storage" is already done / has dependencies
[21:02] <tdonohue> Next up: "Usage statistics reports" project
[21:02] <tdonohue> a big +1 from me. Love the idea of charts & better reports
[21:02] <PeterDietz> statistics graphics +1
[21:02] <kshepherd> stats +1
[21:02] <PeterDietz> I can assist moderately
[21:02] * JRhoads (~jrhoads@160.10.15.22) Quit (Quit: Leaving)
[21:02] <kshepherd> (and has 2 mentors :))
[21:02] <stuartlewis> +1
[21:03] <aschweer> I have some code for the aggregation stuff, not 100% done yet
[21:03] <aschweer> have been working on stats for the last weeks, so happy to help mentor this
[21:03] <mhwood> Sounds like a good student project.
[21:03] <tdonohue> So, looks like wide agreement that "usage statistics reports" is a good idea
[21:03] <tdonohue> next up: "RTMP A/V streaming integration" project
[21:03] <PeterDietz> here's my stab at dspace graphics: https://picasaweb.google.com/pdietz84/OSULibrariesDSpaceDesigns#5572201645324819106
[21:03] <kompewter> [ Picasa Web Albums - Peter Dietz - OSU Libraries... ] - https://picasaweb.google.com/pdietz84/OSULibrariesDSpaceDesigns#5572201645324819106
[21:04] <kshepherd> RMTP: +1, have had some good students enquire about this
[21:04] <stuartlewis> +1
[21:04] <tdonohue> RTMP: +1 from me (and DuraSpace). We would like to see DSpace be able to serve up A/V content from DuraCloud (which also supports RTMP)
[21:04] <kshepherd> (it's a topic that can get people interested/motivated too)
[21:04] <richardrodgers> RTMP +1
[21:05] <tdonohue> looks like wide agreement that "RTMP" is also a good project idea.
[21:05] <tdonohue> Next up: "New UI built over RESTful services" project
[21:05] <kshepherd> ok, so Bojans submitted this but has since indicated on dspace-tech that the API itself isn't finished/working
[21:05] <kshepherd> so -1 until we have a stable REST API
[21:06] <sandsfish> agreed
[21:06] <tdonohue> hmm...yea, that would be a problem, if it's dependency is not ready yet
[21:06] <richardrodgers> I'd second kshepherd, let's get RESTAPI going first
[21:06] <tdonohue> Ok, concerns then on "New UI over REST"
[21:06] <tdonohue> next up: "Accessibility" project
[21:06] <kshepherd> accessibility: +1, i really like this
[21:07] <tdonohue> +1 to better accessibility, good idea
[21:07] <sandsfish> +1, always sorely needed, never given enough attention.
[21:07] <mhwood> +1
[21:07] <kshepherd> and Bojan has contacts with an instituite in croatia that has a real need for it, would be a great pilot for it
[21:07] <tdonohue> (though we may need to better scope exactly *which* of the ideas would be implemented, there's a lot of good ideas here)
[21:07] <tdonohue> Ok, so general agreement that Accessibility is a good one..
[21:07] <richardrodgers> +1, hope we could attract students
[21:08] <tdonohue> Next up: "Scriptable Curation Tasks" project
[21:08] <stuartlewis> Curation tasks - good idea, but maybe not enough for a whole summer?
[21:08] <kshepherd> this might not be big enough for GSoC
[21:09] <tdonohue> depends on how many tasks you write, correct?
[21:09] <kshepherd> but is still cool :)
[21:09] <PeterDietz> maybe they can spend rest of summer making curation tasks?
[21:09] <richardrodgers> cool idea - we haven't done multilanguage on JVM in DSpace
[21:09] <aschweer> when I suggested this I meant more that the GSoC student would write the infrastructure, not necessarily tasks
[21:09] <mhwood> Doesn't it need a framework for running the tasks first?
[21:09] <aschweer> but I understand if people think it's not big enough for GSoC
[21:09] <tdonohue> I'd see this as two main things: (1) adding in the "framework" to actually allow someone to script Curation tasks, and the (2) write a few same tasks
[21:09] <tdonohue> (2) write a few *sample* tasks
[21:10] <aschweer> tdonohue: exactly
[21:10] <tdonohue> thoughts on this? still "too small"?
[21:10] <PeterDietz> it fits a nice niche of something that is likely to be completed and committed to core though
[21:11] <kshepherd> +1 # i like it, maybe not as high priority as others like REST, but i like it
[21:11] <tdonohue> Ok, I'll vote on it. I like the idea: +1 (agree with PeterDietz that I can see this as something that could be committed to core eventually)
[21:11] <sandsfish> :q
[21:11] <sandsfish> rats, vi commands in the chat
[21:11] <kshepherd> sandsfish: this isn't vi!
[21:11] <sandsfish> :)
[21:12] <tdonohue> sandsfish is trying to quit on us...
[21:12] <PeterDietz> .rmpoint sandsfish
[21:12] <kompewter> PeterDietz: I'm sorry, but I'm afraid I can't do that!
[21:12] <kshepherd> and he didn't even save changes!
[21:12] <PeterDietz> .rmpoint kompewter
[21:12] <kompewter> kompewter: +1/-2, -1
[21:12] <mhwood> There might be a good deal of work figuring out a nice set of supporting features to make scripting comfortable.
[21:12] <tdonohue> Ok. Some concerns about "Scriptable Curation Tasks" project. Many seem in favor, but some feel it might be "too small" a project
[21:12] <kshepherd> any other votes?
[21:12] <tdonohue> Last one: "Improve Submitter User Experience" project
[21:13] <mhwood> Another basket of popular ideas.
[21:13] * tdonohue notes that this one was suggested *by* a student, on our duraspace-gsoc listserv.
[21:13] <kshepherd> submission: 0, i prefer spending effort on sword, etc
[21:13] <sandsfish> 0
[21:13] <richardrodgers> a little vague....
[21:14] <PeterDietz> I do admit that DSpace submitter UI is not so friendly
[21:14] <kshepherd> so ditch it ;)
[21:14] <tdonohue> it's vague cause I just "threw" something up there...it needs more fleshing out, to be honest
[21:14] <PeterDietz> OSU is working on those things though
[21:14] <kshepherd> </sword bias>
[21:14] <PeterDietz> .rmpoint kshepherd
[21:14] <kompewter> kshepherd: +1/-1, 0
[21:14] <kshepherd> .rmbot kompewter
[21:15] <tdonohue> PeterDietz, is this stuff that OSU has already done then (and wanting to share with all)? or would a student project still be helpful in some areas?
[21:15] <richardrodgers> I gotta go - thanks all!
[21:15] <kshepherd> cheers richard
[21:15] * richardrodgers (~richardro@18.111.4.50) Quit (Quit: richardrodgers)
[21:15] <stuartlewis> One thing to think about with all this - how many sots are we (DSpace) likely to get, as part of the overall allocated slots for Duraspace? Assuming maybe 2 slots, which would be our very top projects we'd love to see?
[21:16] * tdonohue sorry to go over time here -- just really wanting to get through this GSoC conversation
[21:16] <PeterDietz> help can always be appreciated, first you gotta do lots of usability studies. We've done some here of random users/submitters
[21:16] <sandsfish> gotta run, later all!
[21:16] <sandsfish> :wq
[21:16] * sandsfish (~sandsfish@18.111.28.210) Quit (Quit: sandsfish)
[21:16] <kshepherd> sandsfish++
[21:16] <kshepherd> he saved us that time
[21:17] <mhwood> Didn't even know I was endangered.
[21:17] <PeterDietz> So, its a possible one to use help on, I would like more community buy in then me though perhaps
[21:17] <tdonohue> PeterDietz -- guess the question here is, being an "expert" in this area, would you want to be a mentor here? or, is it just not "ready" enough for this GSoC?
[21:18] <kshepherd> mhwood: as long as mhwood~ is still around, i guess we can always rescue you...
[21:18] * tdonohue thinks improved Submission UI is a good idea, just trying to figure out if we have someone interesteed in mentoring this sort of project, or if we just not worry about it for GSoC 2011
[21:18] * KevinVdV (~KevinVdV@94-227-61-160.access.telenet.be) Quit (Quit: KevinVdV)
[21:18] <PeterDietz> actually I could use help in submission, there are a bunch of things that need refactoring come to think of it
[21:19] <PeterDietz> I can mentor that one, with aschweer as a potential copilot
[21:19] <tdonohue> care to write up a better GSoC project description, when you get the chance?
[21:19] <aschweer> we've got plans to make major changes to submission later this year, not decided yet whether sword or within dspace
[21:20] <tdonohue> Oh, to answer stuartlewis's point from a while ago. We are requesting 7 project slots from Google. ~4 for DSpace (as we've had 4 projects most every year), and 3 to share between Fedora & DuraCloud. We may give some back though if we don't get enough students or mentors interested
[21:20] <stuartlewis> Do we have community consensus over what needs improving with submission?
[21:20] <PeterDietz> aschweer: I heard php easydeposit has security flaws that upload your materials to hackers in China, and that the sword has major performance problems, and that dspace ui is the way to go (eat that kshepherd)
[21:21] <aschweer> PeterDietz: I'll keep that in mind when I investigate which way to take ;)
[21:21] <kshepherd> you what
[21:21] <tdonohue> ok -- we're devolving into arguments. I wish sandsfish was here to save us
[21:21] <tdonohue> :)
[21:22] <kshepherd> i can't tell if this is a joke
[21:22] <mhwood> Sword performance problems: JIRA please.
[21:22] <kshepherd> and if i can't, maybe the random IR people/DCAT people rading this meeting log can't either
[21:22] * PeterDietz I'm just making that up, since we're locally not on sword. easydeposit is actually really awesome
[21:22] <tdonohue> I think we might as well close up for today. Sorry for the long meeting. Just wanted to get some general consensus on GSOC projects (and I think we got much closer). Ideas & mentors still welcome!!
[21:23] <mhwood> OK, must dash anyway. Thanks, all!
[21:23] * tdonohue says meeting is officially closed, but feel free to hang out and continue with discussions. I'll be here for a while
[21:23] <kshepherd> cheers all, i gotta run too
[21:23] <tdonohue> Oh, and if you know of any good students, try to get them into GSoC! :)
[21:23] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:24] <PeterDietz> for submission, did anything come of the work on type-based submission (from last year-ish)?
[21:26] <tdonohue> PeterDietz -- get in touch with richardrodgers. He's working on refactoring that 'type-based submission' stuff into his "Context Guided Ingest" work: https://wiki.duraspace.org/display/DSPACE/CGIProposal
[21:26] <kompewter> [ CGIProposal - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/CGIProposal
[21:29] <aschweer> on a related note: is there a good way to find out what submission improvements have been suggested and what the status on them is?
[21:30] <aschweer> I have a bunch of things that the users at 'my' 4 repositories are unhappy with wrt submission, but haven't had the time yet to sort through them properly and to decide how to go forward
[21:31] <PeterDietz> just to start picking apart things I don't like about UI...
[21:32] * ksclarke1 (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[21:33] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Quit: Leaving.)
[21:33] <PeterDietz> I don't like the file boxes when they show what you've uploaded, they seem to show less than is actually uploaded.
[21:34] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[21:34] <PeterDietz> Also the code that powers submission is seperate from the workflow code, which should be refactored and combined, since there is so much overlap
[22:04] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[22:09] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has left #duraspace
[22:11] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[22:26] * ksclarke1 (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Quit: Leaving.)
[22:30] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[23:21] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.