Timestamps are in GMT/BST.
[6:36] -card.freenode.net- *** Looking up your hostname...
[6:36] -card.freenode.net- *** Checking Ident
[6:36] -card.freenode.net- *** Found your hostname
[6:36] -card.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:19] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[12:02] * ablemann (~alexleman@147.226.128.170) has joined #duraspace
[13:27] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[14:56] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[16:28] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Read error: Connection reset by peer)
[16:42] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[17:38] * snail (~yeatesst@130.195.179.88) Quit (Ping timeout: 260 seconds)
[17:52] * snail (~yeatesst@130.195.179.88) has joined #duraspace
[19:49] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) has joined #duraspace
[19:49] <KevinVdV> Hi everybody
[19:51] <tdonohue> Hi all, reminder that our weekly DSpace Devel meeting starts at the top of the hour. https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-31
[19:51] <kompewter> [ DevMtg 2011-08-31 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-31
[19:55] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:56] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:58] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[20:00] <tdonohue> Hi all, time for our weekly DSpace Developers mtg. https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-31
[20:00] <kompewter> [ DevMtg 2011-08-31 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-31
[20:00] <tdonohue> I thought we'd start off with a JIRA review, as we haven't done that in a few weeks...plus, we might stumble across some bug reports we may still want to include in 1.8
[20:01] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:01] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-882+ORDER+BY+key+ASC
[20:01] <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-882+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-882 ] - [#DS-882] Homepage warning message when using Snapshot versions - DuraSpace JIRA
[20:01] <tdonohue> we'll start with DS-882
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-882 ] - [#DS-882] Homepage warning message when using Snapshot versions - DuraSpace JIRA
[20:02] <tdonohue> thoughts on this idea?
[20:03] <mhwood> Better to first find out why so many sites running on SNAPSHOTs?
[20:04] <robint> Yep, it would be interesting to know if it was deliberate
[20:04] <scottatm> Is there a patch with this bug report? If so, let's add it. Otherwise let it wait until 1.8.1
[20:04] <scottatm> It's nice, but not very important.
[20:05] <aschweer> maybe we can make it clearer on sourceforge what should be used for production? (not sure it's possible there)
[20:05] <aschweer> assuming that Bram means the release candidates
[20:05] <tdonohue> we can ask bram what exactly he's seeing (currently on SourceForge we do have separate folders for "Stable Versions" and "Release Candidates")
[20:06] <tdonohue> I also agree this would likely be post-1.8.0. (most of these issues we review today may be that same way, unless we run across something that really should be in 1.8.0)
[20:07] <tdonohue> Ds-882 summary: Followup with Bram -- what is he seeing exactly? This might be a nice idea, but would be post-1.8.0.
[20:07] <tdonohue> next DS-883
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-883 ] - [#DS-883] Artifact preview thumbnail in browse screens does not display primary bitstream - DuraSpace JIRA
[20:08] <scottatm> What is the desired effect?
[20:09] <tdonohue> I think this is a misunderstanding of what the "primary bitstream" is used for. It's only used for HTML content. I think this issue is implying it should also be used to determine which thumbnail is displayed (if there are multiple image files attached to an Item)?
[20:09] <tdonohue> or, at least, that's what I think it's saying (I could be reading it wrong though)
[20:09] <robint> Thats my reading of it
[20:10] <aschweer> tdonohue: that's how I read it too
[20:10] <tdonohue> so, do we mark this as "not a bug"? Or is this a new feature (to wait until after 1.8.0)?
[20:10] <aschweer> I would actually probably expect the same behaviour as the reporter
[20:10] <KevinVdV> Well t.b.h. I don't know how the browse thumbnails work but there is now an option to reorder files so this could solve his issue
[20:10] <robint> Could we make clearer the meaning of "primary bitstream" ?
[20:11] <aschweer> robint: I could imagine, if an item has many images, that people want to control which thumbnail shows up in the browse
[20:12] <aschweer> which may not be addressed by making it the primary bitstream anyway
[20:12] <tdonohue> I'd think I'd lean towards reclassifying this as a "new feature request" for post-1.8.0. I think aschweer is right that there's a new feature in here -- whether or not the 'primary bitstream' is the way to do this may need investigation
[20:12] <robint> aschweer: Fair point. Does anyone know how media-filter decides which image to thumbnail ?
[20:13] <scottatm> media filters creates thumbnails for all bitstreams that it can.
[20:13] <scottatm> It dosn't just pick one for an item, an item may have several thumbnails.
[20:13] <aschweer> the browse index then apparently pick one, not sure based on what
[20:14] <tdonohue> anyone want to "claim" Ds-883 and investigate it after 1.8.0?
[20:15] <tdonohue> I'll take that as a no. Ds-883 summary: we can just schedule this for post-1.8.0 then & change into a feature request, and hope to find someone to investigate further
[20:16] <tdonohue> one last one for today: DS-885
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-885 ] - [#DS-885] links within CC license_text are broken - DuraSpace JIRA
[20:16] <robint> Worth recording on it that KeveVdV's bitstream order change may fix it
[20:16] <tdonohue> Anyone have any idea if this is fixed by the new CC license stuff? (Just curious)
[20:16] <robint> 883 that is
[20:17] <robint> tdonohue: No idea, but I could take this one and have a look whilst testing the CC stuff
[20:17] <tdonohue> thanks, it'd be worth investigating (it'd be nice if we could just mark it fixed now)
[20:18] <tdonohue> Ds-885 summary: robint will look into while testing new CC stuff
[20:18] <tdonohue> ok. we'll stop there for today & move on to 1.8.0 updates, etc
[20:19] <tdonohue> Anyone have updates to share? Bugs they've noticed that need immediate help/review? Anything else related to 1.8.0?
[20:19] <robint> I have acouple of things
[20:19] <robint> The Sword2 module was added but as some have noticed there are some issues with some libraries
[20:20] <robint> Richard Jones is now back from holiday and has promised to fix things
[20:20] <robint> hopefully before Testathon
[20:21] <robint> CC Rewrite code has been committed (big thanks to Wendy Bossons)
[20:21] <robint> It has some rough edges
[20:21] <robint> plus one change that I would value others opinions on
[20:22] <robint> A new template has been added to structural.xsl, called cc-license
[20:22] <scottatm> I understand that it has been turned off by default in the input-forms.xml. I think we should change that and turn it on by default, and only turn it off if we find some problems with it during the test-a-thon.
[20:22] <tdonohue> robint, do you have the issue # handy for that new CC license stuff? trying to track it down again?
[20:23] <tdonohue> nevermind, I found it DS-964
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-964 ] - [#DS-964] Implement Creative Commons Web Service API with the Submission Process - DuraSpace JIRA
[20:24] <robint> So, is that a sensible thing to do
[20:24] <robint> adding the new template I mean
[20:24] <robint> If it is will this give existing sites a problem with the upgrade ?
[20:25] <robint> If they have been good and added their own local them on top of the existing stuff then it shouldn't be a problem
[20:26] <tdonohue> correct. if they've been good about it, it shouldn't be a problem.
[20:26] <robint> But if they have directly customised structural.xsl then they will need to integrate the changes
[20:27] <robint> Is this an issue, or not worth worrying about ?
[20:27] <tdonohue> one thing I'd like to know is whether it would matter if someone is *not* using CC licensing. In other words, would they still need to have this new 'cc-license' template, or would it just be skipped over
[20:28] <tdonohue> (i.e. we should test that if you *disable* CC Licensing, then the theme doesn't need that template to work)
[20:28] <robint> Ok, I'll test that. Thanks
[20:28] <tdonohue> But, I'm ok with requiring that new template, if you want to use the new CC licensing. I'm sure we'll need to add new templates throughout the years
[20:29] <robint> Then thats all my updates
[20:29] <tdonohue> to go back to what scottatm said. I worry about leaving CC license "on" by default, as I'm not certain how many institutions actually use the Create Commons licensing feature (but if most everyone here thinks otherwise, then I'm fine with being overruled)
[20:30] <tdonohue> but, to be clear, we *will* enable it on demo.dspace.org during Testathon. The demo.dspace.org site is setup such that *every possible feature* is enabled.
[20:31] <scottatm> oh, I was under the impression that if not enabled that dspace would use the old CC method. yeah, I don't think that we should turn CC on by default... but if on by default it should use the new method.
[20:31] <scottatm> That's probably me just causing confusion, sorry.
[20:32] <robint> jspui still uses old methos, xmlui uses the new
[20:32] <robint> method
[20:32] <tdonohue> ok, thanks for clarifying robint.
[20:33] <tdonohue> Anyone else have updates they want to share, or bugs they've either discovered, or saw in JIRA that we should look at?
[20:33] <robint> The only other big'ish piece of work ongoing that I know of is Richard's Curation enhancements
[20:33] <tdonohue> richard committed those today, I believe
[20:34] <robint> Lets go to the pub :)
[20:34] <tdonohue> Actually, the other thing to follow up on is the whole Tombstone stuff. No one has yet to create a default Tombstone for XMLUI. I'm assuming we are going to "leave out" the withdrawal reason stuff, as it seems to have been controversial: DS-969
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-969 ] - [#DS-969] Add ability to monitor & clear Cocoon's Cache from XMLUI Control Panel - DuraSpace JIRA
[20:35] <tdonohue> ug, DS-996
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-996 ] - [#DS-996] Add optional reason text to tombstone page - DuraSpace JIRA
[20:35] <tdonohue> it's the latter one, not the former (obviously)
[20:36] <tdonohue> So, the question is: Are we leaving this feature for post-1.8.0? I'd still like to include just a default XMLUI Tombstone in 1.8.0 (as that's just a bug fix, as it doesn't even have one yet).
[20:36] <aschweer> I think it'd be useful to have a default XMLUI tombstone
[20:37] <robint> +1
[20:37] <hpottinger> +1
[20:38] <tdonohue> ok. I'll talk to richardrodgers about this. I think he already has code that would give us a default XMLUI tombstone....we just need to pull it out and commit it. We'll leave the extra feature (a custom withdrawal message) for post 1.8.0.
[20:39] <hpottinger> just a note for the record, which I think I've covered in the tickets themselves, but I'm punting on DS-994, and I've made two new bug tickets DS-1006 and DS-1007, so I'm focusing on those two instead of Ds-994, should I close 994?
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1006 ] - [#DS-1006] authorizations via SpecialGroups methods are not properly created if an existing ePerson is found - DuraSpace JIRA
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1007 ] - [#DS-1007] AuthenticationManager.canSelfRegister is problematic with stacked authentication modules - DuraSpace JIRA
[20:40] <tdonohue> hpottinger, if Ds-994 is no longer of any use and/or obsolete, then definitely close it. It may be worth linking the other two issues back to Ds-994 though (just to keep that "history")
[20:40] <robint> hpottinger: If 994 is still valid but you don't think it will make 1.8 then you could reschedule for post-1.8
[20:41] <scottatm> I'm also working (today actualy) on an overhaul of the shibboleth authenticator....
[20:41] <tdonohue> yea, like robint says -- if it's still valid, then don't close it :) We only close/resolve issues that are either fixed, obsolete or no longer valid for whatever reason.
[20:41] <scottatm> To support lazy auth, netid based identity, and additional metadat.
[20:42] <robint> scottatm: Is this intended for 1.8 ?
[20:42] <scottatm> no, post 1.8
[20:43] <robint> Good stuff, thanks
[20:43] <mhwood> Interesting...I've been cooking up a CAS authn plugin (using the Shib plugin for ideas). (Probably not generally useful: IU hacked CAS and won't interoperate with JASIG CAS.)
[20:44] <scottatm> mhwood, we can chat sometime if you'd like.
[20:44] <mhwood> Thanks!
[20:45] <tdonohue> 1.8 general update: We could really use some volunteers to help with Documentation, as well as anyone interested in quickly searching JIRA to see if there are any "quick fix" bugs there (i.e. bugs with patches already built that would be easy to add to 1.8).
[20:45] <tdonohue> more info on both is in the Yellow note on our meeting minutes: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-31
[20:45] <kompewter> [ DevMtg 2011-08-31 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-31
[20:45] <KevinVdV> I do have one annoying bug for which I created a patch (https://jira.duraspace.org/browse/DS-897), this should be fixed in DSpace 1.8.0
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-897 ] - [#DS-897] Selecting "This Collection" in the sidebar search box produces a Page Not Found - DuraSpace JIRA
[20:46] <scottatm> I would also like to commit DS-1010 to 1.8
[20:46] <kompewter> [ https://jira.duraspace.org/browse/DS-1010 ] - [#DS-1010] Item count (collection strengths) do not update on the community-collection list. - DuraSpace JIRA
[20:46] <scottatm> https://jira.duraspace.org/browse/DS-1010
[20:46] <kompewter> [ https://jira.duraspace.org/browse/DS-1010 ] - [#DS-1010] Item count (collection strengths) do not update on the community-collection list. - DuraSpace JIRA
[20:46] <kompewter> [ [#DS-1010] Item count (collection strengths) do not update on the community-collection list. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1010
[20:46] <tdonohue> could we get a volunteer for Ds-897? Might be nice to quickly get in before Testathon.
[20:47] <aschweer> KevinVdV: I should be able to test Ds-897 today
[20:47] <KevinVdV> Thanks aschweer
[20:47] <tdonohue> thanks aschweer,
[20:47] <aschweer> actually, Ds-1010 too, we've had problems with that in my repos
[20:48] <robint> +1 for 1010
[20:48] <tdonohue> scottam -- looks like Ds-1010 already has a lot of support (based on the comments on that issue). So, sounds like it should definitely get in 1.8
[20:49] <scottatm> great.
[20:50] <tdonohue> If anyone really would like to write Documentation, please get in touch. We could use more eyes/help on updating Install Docs, Upgrade Docs & Configuration Docs. Volunteer now, before I have to twist some arms -- it seems like none of us likes to do Docs :)
[20:50] <KevinVdV> I plan to write some docs on the services in the near future
[20:50] <robint> I'll start looking at the docs tomorrow
[20:50] * hpottinger raises his hand
[20:51] <tdonohue> Also, if you have committed any new feature to 1.8.0, you are obviously expected to write up some Documentation for us. So, Robint & I will be in touch if we notice your docs are lacking :)
[20:51] <robint> Thanks hpottinger: , I may ask for help as I go along
[20:51] <tdonohue> hpottinger -- cool, if there's a particular area you'd like to work on, let us know.
[20:52] <hpottinger> just point me at something
[20:52] <robint> will do
[20:53] <hpottinger> but I'll do my best to ensure the upgrade docs are current
[20:54] <tdonohue> Oh, Testathon is obviously now a week delayed (but you all likely already saw that announcement) & will start on Sept 12. The official testathon announcements should go out later this week.
[20:55] <tdonohue> ok. I think that's all I have to mention. So, we can adjourn to the "virtual pub" (to bad it's not a real pub) unless anyone else has any last topics
[20:56] <tdonohue> Sounds like it's "meeting adjourned"! I think 1.8.0 is looking great so far -- lots of new last minute features, but it's definitely been worthwhile to have extended the "freeze" a bit :)
[20:57] <robint> Time to sneak away. Cheers.
[20:58] <aschweer> time to go to work for me :) see you all
[20:58] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:58] * hpottinger bolts for the door as well, bye folks!
[20:58] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[20:59] <mhwood> I also must go.
[20:59] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[21:01] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:03] <KevinVdV> Also need to go, cya later all
[21:03] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) Quit (Quit: KevinVdV)
[21:52] * barmintor (barmintor@specdl11.cul.columbia.edu) Quit ()
[22:01] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:50] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[23:36] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.