Timestamps are in GMT/BST.
[6:34] -leguin.freenode.net- *** Looking up your hostname...
[6:34] -leguin.freenode.net- *** Checking Ident
[6:34] -leguin.freenode.net- *** Found your hostname
[6:34] -leguin.freenode.net- *** No Ident response
[6:34] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:34] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:34] * Set by cwilper!ad579d86@gateway/web/freenode/ip.22.214.171.124 on Fri Oct 22 01:19:41 UTC 2010
[13:53] * fasseg (~ruckus@HSI-KBW-091-089-022-149.hsi2.kabelbw.de) has joined #duraspace
[14:09] * tdonohue (~firstname.lastname@example.org) has joined #duraspace
[18:31] * mhwood (~mhwood@2602:306:382a:8b89:6a05:caff:fe00:f66d) has joined #duraspace
[19:22] * helix84 (~email@example.com) has joined #duraspace
[20:00] <tdonohue> Hello DSpace Developers. It's time for our weekly Devel Mtg. Today's agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-02-05
[20:02] <tdonohue> Looks like a low attendance today, but hopefully others will at least be reading the logs (or perhaps even join up shortly)
[20:02] <tdonohue> First off, I wanted to be sure to remind us all that OR2014 proposals are *due* next Monday (Feb 10). This includes proposals for the main conference, workshops, and also DSpace User Group sessions.
[20:03] <tdonohue> more info at: http://or2014.helsinki.fi/?p=392
[20:04] <tdonohue> Next up, I wanted to be sure to touch back on our 4.1 status.
[20:04] <tdonohue> Looks like as of today we still have ~13 tickets which are unresolved yet marked "fix for 4.1": https://jira.duraspace.org/browse/DS/fixforversion/11568
[20:06] <tdonohue> So, that would imply the status is "we're still working on 4.1" and it's not quite ready. But, I wasn't sure if there were any tickets that needed more immediate eyes today
[20:06] <mhwood> I have one (DS-1531) waiting on comment, but I may just go ahead and pull it.
[20:07] <tdonohue> mhwood: yea, regarding DS-1531, it sounds like you verified that it was code that is not being used? (based on the last comment)
[20:07] <mhwood> I see six others in "code review needed" status.
[20:07] <helix84> DS-1898 is obvious, but it won't go to master, only to 4.x
[20:07] <helix84> I mean it has a PR
[20:08] <mhwood> Yes, Hardy asked Kevin VdV about the code in 1531 and he said it was leftovers.
[20:09] <helix84> I *don't* think we can tackle DS-1781 for 4.1 unless someone really deeply looks into this
[20:09] * kompewter (~firstname.lastname@example.org) has joined #duraspace
[20:09] * tdonohue just woke up kompewter
[20:09] * helix84 is going to kick kompewter
[20:09] <helix84> oh, thanks
[20:09] <tdonohue> DS-1531 sounds like it's "verified enough" then. So, seems good to merge
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1531 ] - [DS-1531] bug in current DSpace (3.1) with log importing - DuraSpace JIRA
[20:10] <mhwood> Will do.
[20:10] <helix84> Then there's the question of DS-1821 - merge or reschedule?
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-1821 ] - [DS-1821] Internationalize the bitstream access icon alt text - DuraSpace JIRA
[20:10] <tdonohue> DS-1898 seems reasonable (at a glance)
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-1898 ] - [DS-1898] OAI not always closing contexts - DuraSpace JIRA
[20:11] <tdonohue> sorry, still catching up with the tickets mentioned above
[20:11] <tdonohue> DS-1781 sounds like a possible "reschedule it" (as helix84 suggests)
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1781 ] - [DS-1781] LDAP never uses the specified email_field - DuraSpace JIRA
[20:13] <mhwood> 1898 looks right to me too.
[20:14] <helix84> just reminding you not to push the button on 1898, it needs to be cherry-picked instead
[20:14] <tdonohue> DS-1821 is the one I'm not sure about. Do we want to be adding new I18N keys in bug-fix releases? Although it's a sort of "bug fix" it would require translators to update their translations (or else they'd get errors in the UI).
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1821 ] - [DS-1821] Internationalize the bitstream access icon alt text - DuraSpace JIRA
[20:14] <helix84> tdonohue: I don't think it's much of an issue. We have only one or two translations updated for 4.x
[20:14] <mhwood> Errors consistof untranslated message key.
[20:14] <tdonohue> i.e. accepting changes like 1821 into a 4.1 would mean that 4.0 translations are not 100% compatible with 4.1
[20:16] <helix84> yep, there's mine and there's pt_BR updated for 4.x
[20:16] <tdonohue> yep, I see two...Czech & pt_BR. So, I guess that shouldn't be too big of a deal
[20:17] <helix84> anyway, I would appreciate if someone would just test it once (I think I tested it with an older branch)
[20:19] <mhwood> *sigh* I need to learn how to exercise this I18N stuff.
[20:20] <tdonohue> Might be helpful to know how/where to test it. Is it the hover-over/alt text for access restricted bitstreams? (Just not entirely sure which icon this is)
[20:20] <helix84> I really hope we can confirm the fix of DS-1536 for 3.x. But it's been confirmed for 4.x.
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1536 ] - [DS-1536] having a DOT in handle prefix causes identifier.uri to be cut off when being created. - DuraSpace JIRA
[20:20] <helix84> thanks, mhwood. it's the hover text over the restricted bistream icon.
[20:21] <helix84> DS-1860 now has a PR
[20:21] <kompewter> [ https://jira.duraspace.org/browse/DS-1860 ] - [DS-1860] Community-list doesn't show all collections - DuraSpace JIRA
[20:22] <tdonohue> 1536 - yes, we should minimally fix it for 4.x. I do think this is also worth porting to 3.x. It's unclear to me whether this really isn't working in 3.x, or if there were other issues at play?
[20:22] <helix84> And I believe if we bug Andrea a bit, he can provide a PR for DS-1899
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1899 ] - [DS-1899] Spellchecking is not enabled by default on the whole site - DuraSpace JIRA
[20:23] <helix84> It definitely is worth porting to 3.x. It only surfaces for those who use a handle prefix with a dot (e.g. 132456.1/123)
[20:27] <tdonohue> So, regarding 1536, this sounds like it should be in 4.1. It's been verified for 4.0. It should be backported to 3.x too, though it's uncertain whether it fixes *all* the issues in 3.x (based on Hilton's comments)
[20:28] <tdonohue> So, in my opinion, 1536 sounds like it's mergeable into master/4.x/3.x. But 3.x may need more testing to see if other related errors exist there (that have been resolved somehow in 4.x)
[20:29] <mhwood> It looks like Hilton Gibson will have some 3.x test results soon?
[20:29] <helix84> I also have a SQL command that will find and fix the damage caused by 1536, pending verification from Hilton.
[20:29] <helix84> mhwood: yes, he said so
[20:30] <tdonohue> Regarding that SQL command. That would *NEED* to be advertised in 4.1 release notes / upgrade notes.
[20:31] <helix84> also 3.3 release notes
[20:31] <mhwood> So 1536 can go into 4.1 now and 3.3 whenever. 3.3 isn't really a thing yet, is it?
[20:31] <tdonohue> right, and 3.3 release notes/upgrade notes
[20:32] <tdonohue> 1536 would warrant a 3.3 in my opinion. We need not release 3.3 at the same time as 4.1, but we probably should at least follow 4.1 with a 3.3 shortly thereafter
[20:32] <tdonohue> 1536 is a major issue which blocks anyone using dots in their handles from upgrading to either 3.x or 4.x. We've left them behind on 1.8.x and below
[20:33] <helix84> mhwood: well there are pending fixes in the 3.x branch and I volunteered to do the docs stuff, so it's really a matter of running the mvn stuff
[20:33] <mhwood> I agree that it's important.
[20:34] <mhwood> Anyway, waiting on 3.x confirmation should not hold up inclusion in 4.1.
[20:34] <tdonohue> in terms of release priorities here though, 4.1 has highest priority. 3.3 is important as well, but not as important as 4.1
[20:35] <tdonohue> correct, we should merge this for 4.x and 3.x immediately. We can release 4.1 with it...and then potentially wait on verification for 3.x. It *sounds* like Hilton thinks it should work in 3.x now...but we should verify
[20:37] <tdonohue> so, 1536 just needs a volunteer to merge it...then we need verification from Hilton that everything is also OK on 3.x
[20:38] <mhwood> I can push a button, and it looks like this is so small that porting to 3.x should be simple.
[20:38] <tdonohue> it'd need to be merged into master, 4.x and 3.x. (three places total)
[20:39] <mhwood> Will do. Making note.
[20:39] <tdonohue> sounds good
[20:42] <tdonohue> Ok, so, where were we here...
[20:43] <mhwood> 1821, 1898, 1821, 1860, 1899.
[20:43] <helix84> DS-1834 has a PR from Kevin that needs verification
[20:43] <kompewter> [ https://jira.duraspace.org/browse/DS-1834 ] - [DS-1834] Collection content source harvesting test does not check sets properly - DuraSpace JIRA
[20:44] <tdonohue> hmm...another major issue (not mentioned yet): DS-1823
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1823 ] - [DS-1823] Move dspace.url to build.properties as an independent variable (default value in dspace.cfg can cause issues) - DuraSpace JIRA
[20:45] <helix84> I still think that's a change for a major release
[20:45] <mhwood> I think I agree.
[20:46] <mhwood> And someone started discussion of an alternative approach.
[20:46] <helix84> and I like it
[20:46] <tdonohue> Not sure I agree..it's causing issues because people are overlooking this "dspace.url" in dspace.cfg and it ends up improperly set to "/xmlui"
[20:46] <tdonohue> not sure I agree it's "for a major release"
[20:47] <tdonohue> but, the alternative approach is good by me
[20:47] <helix84> tdonohue: but that has been an issue for many releases now
[20:47] <helix84> such a surprise change in config would cause some confusion
[20:47] <helix84> in a minor release
[20:48] <tdonohue> helix84: yes, it has, which means it also likely needs backporting. Currently, this issue affects things like Google Scholar/Google coverage (as Sitemaps will work but will create invalid URLs, etc)
[20:49] <tdonohue> I guess at a minimum we could create clearer documentation around this possible misconfiguration. But, the reality here is that it's a major issue if you aren't aware that you need to go manually tweak the "dspace.url" setting in the final dspace.cfg
[20:50] <helix84> if this were a minor config change... but it's one of the few most important config variables
[20:53] <mhwood> Clearer documentation now, something else later. Sounds good enough?
[20:53] <tdonohue> I can understand both sides here.... it is a big change. At a bare minimum we really need to change all of our Installation/Upgrade docs to warn folks of this misconfiguration. Not sure if you've noticed, but this comes up time & time again on our lists too
[20:55] <helix84> I only know, as a user, I wouldn't like this as a surprise change in a minor release. I usually do read release notes, but I think I'm the minority in that :)
[20:56] <tdonohue> I guess docs is OK for now, but we need to update both 3.x and 4.x docs. We may want to create a docs ticket for that, and we REALLY need to be sure to fix this once and for all in 5.x
[20:57] <mhwood> Too bad that the stock setting doesn't break *obviously*.
[20:58] <tdonohue> nope, unfortunately a lot of stuff fails, and it all fails silently...eventually you tend to notice something odd (this manifests itself in many different ways on the lists as many different errors....try searching dspace-tech for "dspace.url" and you'll see a lot of different issues that are caused by this)
[20:59] <tdonohue> E.g.: http://dspace.2283337.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=3276944&query=dspace.url&days=365&sort=date
[20:59] <kompewter> [ DSpace - Search for 'dspace.url' ] - http://dspace.2283337.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=3276944&query=dspace.url&days=365&sort=date
[20:59] <helix84> tdonohue: the most frequent problems with dspace.url is that people leave a port or an IP there
[21:00] <helix84> sorry, I'll have to go now
[21:00] <tdonohue> In any case, I guess I can just create a Documentation ticket for 4.1...and we can leave it at that.
[21:01] <helix84> I planned to tackle one of the tickets for 4.1 that weren't mentioned, don't remember off-hand which one
[21:01] <tdonohue> Another possible consideration for 4.1, DS-1596
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1596 ] - [DS-1596] Page not found look and feel - DuraSpace JIRA
[21:01] <mhwood> OK, thanks tdonohue. Thanks and goodbye for now, helix84.
[21:02] <mhwood> 1596 would be nice to have. It's not *critical* for 4.1.
[21:03] <tdonohue> not critical no...but it's definitely a longstanding issue worth resolving. I hadn't scheduled it for 4.1 yet myself, cause I wasn't sure if others wanted this in 4.1 or not.
[21:05] <tdonohue> We are so few today :) Not sure how to make much more headway on 4.1 without more heads/volunteers here
[21:05] <mhwood> True.
[21:06] <tdonohue> I was also wanting to talk about Google Summer of Code. To see if we had interest in it this year. But, again, we are too few to really dig into it much.
[21:06] <mhwood> The US Midwest got clobbered with snow, so many may still be digging. We got sent home at 1400 yesterday and won't open unti 1700 today. (I'm at home.)
[21:06] <tdonohue> So, I'm not sure if there's really much more to discuss today...as it sounds like it's now just you and I, mhwood
[21:07] <mhwood> Yes, I think so.
[21:07] <mhwood> It's past time. Should we close the meeting?
[21:07] <tdonohue> Yep, we may as well. Hopefully we have more luck "organizing the troops" next week or via email! :)
[21:08] <mhwood> OK, I'll go see to pulling 1536 (three times).
[21:09] <mhwood> I'll keep IRC open in case something comes up.
[21:10] <tdonohue> Just for the record (for anyone reading this later on). If you are interested in having DuraSpace apply for Google Summer of Code projects, we need to generate some more ideas here: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas DuraSpace will not apply for GSoC unless we get sufficient project ideas & mentor volunteers.
[21:10] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[22:11] * mhwood (~mhwood@2602:306:382a:8b89:6a05:caff:fe00:f66d) Quit (Quit: Leaving.)
[22:52] * tdonohue (~email@example.com) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.