Timestamps are in GMT/BST.
[2:14] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[2:37] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) Quit (Remote host closed the connection)
[3:50] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[4:24] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 264 seconds)
[4:31] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[5:58] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) Quit (Remote host closed the connection)
[6:36] -rothfuss.freenode.net- *** Looking up your hostname...
[6:36] -rothfuss.freenode.net- *** Checking Ident
[6:36] -rothfuss.freenode.net- *** Found your hostname
[6:36] -rothfuss.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
[10:31] * fasseg (~ruckus@HSI-KBW-091-089-154-204.hsi2.kabel-badenwuerttemberg.de) has joined #duraspace
[12:54] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:53] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[15:19] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[16:01] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[16:05] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[18:37] * fasseg (~ruckus@HSI-KBW-091-089-154-204.hsi2.kabel-badenwuerttemberg.de) Quit (Ping timeout: 264 seconds)
[19:14] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-12-11
[20:00] <kompewter> [ DevMtg 2013-12-11 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-12-11
[20:01] <tdonohue> So, as normal, the primary topic is 4.0.
[20:01] <tdonohue> I'm essentially going to open up the floor here... I think 4.0 seems like we are getting close...last week I recall a tentative release date of Dec 12 or 13. But, I'm not sure if we have anything still outstanding?
[20:02] <mhwood> I promised pbecker that I'd bring up his DS-1836
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-1836 ] - [DS-1836] doi_seq in update-sequences.sql missing - DuraSpace JIRA
[20:05] <tdonohue> has there been any decisions on 1836?
[20:07] <mhwood> He and I discussed it earlier, as he can't be here to do so now. In the end we agreed that setting to max(doi_id) seems best.
[20:09] <mhwood> That's what every other sequence gets, except for handle_seq
[20:09] <tdonohue> yea, it sounds like it might be hard to do some "tricks" similar to how we deal with "handle_seq"...unless there is a way to do a regexp and extract out the doi_seq
[20:09] <tdonohue> Here's the handle_seq tricks...for reference: https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/update-sequences.sql#L90
[20:09] <kompewter> [ DSpace/dspace/etc/postgres/update-sequences.sql at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/update-sequences.sql#L90
[20:10] <mhwood> The "namespace separator" could be almost anything. It would be hard to predict.
[20:11] <tdonohue> ok, yea, wasn't sure if there was a limit there...for example, if the "namespace separator" is never a *number* (integer), than you might be able to still do a regexp to pull out the last number. But, if it can be anything (including integers) than that's problematic
[20:13] <mhwood> We eventually agreed that people who monkey with the tables should know how, or expect pain. DSpace itself should be well behaved here.
[20:13] <mhwood> I have some separate qualms about people manually allocating DOIs, which he will address in the documentation.
[20:14] <tdonohue> ok. that's fine. We just may want to have a comment then in the 'update_sequences.sql' that explains the limitations of "max(doi_id)", or links to documentation if there will be more details in documentation
[20:15] <tdonohue> beyond that, I think the suggestion to use max(doi_id) is "good enough". Just may need some explanatory documentation & warnings
[20:15] <mhwood> One interesting thing is that doi_id has no default but gets set anyway. There is magic in DatabaseManager (in two places!) to hunt down a likely looking sequence and use it.
[20:15] <mhwood> I haven't had time to determine whether this magic is adequately documented.
[20:15] <tdonohue> huh, I didn't know that
[20:16] * lap_ (~chatzilla@host54-210-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[20:16] <mhwood> Neither did we.
[20:16] <mhwood> It was puzzling. The code works as is, but we didn't know why.
[20:16] <mhwood> Anyway, is there agreement on fixing update_sequences? How urgent is this? Should we delay 4.0 for it?
[20:17] <mhwood> A larger question: is there *anything* on the table for which we should delay 4.0?
[20:18] <mhwood> I've never had to use update_sequences, so I'm inclined to document it as a known problem in 4.0 and try to get a 4.1 out soon.
[20:18] <tdonohue> it seems like 1836 is a one-line change to update-sequences.sql. It might be nice to have it in 4.0, but it likely doesn't need to wait on it.
[20:19] <mhwood> But if there is something else that cannot wait, this could go in too.
[20:19] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:19] <tdonohue> update_sequences is rarely used unless you are doing something like *restoring content from a backup* (in which case, especially with restores from AIPs, update-sequences.sql is sometimes a lifesaver)
[20:21] <tdonohue> ack, crud. That reminds me...we might need to document whether DOIs work with AIPs....I'm guessing they may not
[20:22] <tdonohue> (again, that's not a showstopper for 4.0. Just needs to be documented.)
[20:22] <mhwood> Um. The DataCite API provider has that database table to be re-sync.ed. The EZID provider depends on EZID for coining DOIs and should only be touching metadata, which ought to be restored properly.
[20:24] <tdonohue> ok, yea, as long as all that needs to be restored is *metadata*, then likely AIPs still will work with DOIs. I just wasn't sure if restoring metadata is enough...or if we need another "crosswalk" for the new 'doi' table
[20:25] <mhwood> I think that rows in the Doi table will need to be regenerated when restoring. Only the automatic generation of DOIs would be affected, I think.
[20:26] <mhwood> That is: subsequent generation of new DOIs.
[20:26] <tdonohue> in any case, this isn't a showstopper...so, we can figure out some of the details later on
[20:26] <mhwood> Possibly a loop that retries with increasing doi_id values until a non-collision is generated. That could take care of several potential problems.
[20:27] <tdonohue> mhwood: yea, that might be nice
[20:27] * PeterDie_ (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) has joined #duraspace
[20:27] <mhwood> Oh, collision here means look in the metadata to see if there *should* be a Doi row.
[20:28] <tdonohue> In any case, this feels like something we can set aside for now. We probably should concentrate on anything high-priority, and anything left as "todo" on the list of tasks: https://wiki.duraspace.org/display/DSPACE/DSpace+4.0+Tasks
[20:28] <mhwood> So, is there agreement that the proposal in 1836 is sufficient for now, and that we don't want to delay 4.0 for it?
[20:28] <kompewter> [ DSpace 4.0 Tasks - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+4.0+Tasks
[20:31] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 252 seconds)
[20:31] <hpottinger> big things left are documentation, release notes
[20:31] <mhwood> May I suggest that updating dependencies should happen at the *start* of a development cycle. There's not much time now.
[20:31] <hpottinger> good point, mhwood
[20:31] <tdonohue> 1836 probably doesn't require delaying 4.0. But, I'm not sure myself about whether the resolution is sufficient -- I'll add a comment to the ticket though.
[20:32] <mhwood> Do I recall correctly that we reviewed the prerequisites' versions?
[20:33] <hpottinger> I believe that recollection is correct, but I can't back it up with a link
[20:34] <tdonohue> yes, we reviewed prereqs in a meeting
[20:35] <hpottinger> that list of possible dependency updates was made a while ago
[20:37] <hpottinger> though the org.dspace lines jump out at me
[20:39] * PeterDie_ (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[20:39] * PeterDietz (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) has joined #duraspace
[20:44] <mhwood> Hmmm, the release notes credit me for the remote handle server work, but I haven't done anything yet except comment. (I see I promised some Maven rework for 4.1. Making a task for that now.)
[20:45] <tdonohue> it looks like the official "Release Notes" page has a list of Contributors as "TODO": https://wiki.duraspace.org/display/DSDOC4x/Release+Notes (scroll down to past the big table)
[20:45] <kompewter> [ Release Notes - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Release+Notes
[20:46] <hpottinger> oh, I remember these icons
[20:49] <tdonohue> Hmm...wondering if we need some more notes at the top of the Upgrade Docs. We don't note anywhere the renaming of the "update-discovery-index" script to "index-discovery" and other such things..
[20:50] <tdonohue> we also probably need a note to say that the JSPUI has undergone a massive redesign (which is a great thing, but it could mean that if you use JSPUI, it would affect many of your local customizations)
[20:52] <tdonohue> We often have these sort of important notes at the top of the Upgrade Docs for major releases...e.g. https://wiki.duraspace.org/display/DSDOC4x/Upgrading+From+1.7.x+to+1.8.x and https://wiki.duraspace.org/display/DSDOC4x/Upgrading+From+1.8.x+to+3.x
[20:52] <kompewter> [ Upgrading From 1.7.x to 1.8.x - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Upgrading+From+1.7.x+to+1.8.x
[20:52] <kompewter> [ Upgrading From 1.8.x to 3.x - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/Upgrading+From+1.8.x+to+3.x
[20:52] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:54] <tdonohue> So..there are some minor Doc updates still needed, it looks like. Do we have folks willing to help chip in here? Especially need to get rid of that "TODO" in the "Release Notes" page in Official Docs.
[20:54] <mhwood> I plan to work on docs tomorrow.
[20:55] <hpottinger> I will show up in IRC with my red pen at hand, ready to work, tomorrow.
[20:55] <tdonohue> We also need to nail down the date. I'm going to be unavailable on Friday (Dec 13) -- on vacation. So, if we are releasing on that day, I won't be around to do the needed www.dspace.org updates. I could see if Val or someone else is able to take that on then, though
[20:56] <tdonohue> Finally, we need to draft up the actual 4.0 Release Announcement (which is likely mostly just the list of exciting features, cribbed from the Release Notes page)
[20:57] <mhwood> BTW those active checkboxes on the tasks page were a nice idea.
[20:57] <hpottinger> I stole that nice idea from helix84 :-)
[20:58] <mhwood> I can do the announcement, unless someone else wants it. I've been announcing the RCs and so far nobody has thrown anything.
[20:59] <tdonohue> sounds fine, mhwood. I think your announcements have been good. Here's what the 3.0 announcement looked like. Feel free to steal the general structure or any language: http://dspace.2283337.n4.nabble.com/DSpace-3-0-Released-td4660105.html
[20:59] <kompewter> [ DSpace - Tech - DSpace 3.0 Released! ] - http://dspace.2283337.n4.nabble.com/DSpace-3-0-Released-td4660105.html
[20:59] <mhwood> OK, I have that logged. Thanks!
[20:59] <mhwood> I will work on this early tomorrow and send the draft around.
[21:00] <tdonohue> sounds good.
[21:01] <tdonohue> So, is the anticipated plan to release on Friday the 13th? [cue sinister laugh]. If so, I need to find someone to do the dspace.org updates. If not, I can do dspace.org updates on either Thurs or Mon
[21:02] <mhwood> Thursday seems tight, with documentation still to review & extend.
[21:02] <tdonohue> so that leaves either Fri 13th or Mon 16th
[21:03] <tdonohue> If you are planning to "cut" the release on Friday, I'm guessing it won't be ready to fully *announce* then (as it may not have propagated)
[21:03] <mhwood> Currently scheduled for Friday (just updated the timeline!) but could push to Monday.
[21:03] <tdonohue> that may mean we "cut" the release Friday, and announce on Monday
[21:04] <hpottinger> Friday the 13th sounds good, mhwood, are you doing the honors?
[21:04] <tdonohue> (And if the announcement is held until Monday, then I can do the needed dspace.org updates just before the official announcement goes out)
[21:04] <mhwood> I'm thinking that cutting a release needs to be started early in the day. Not past noon, certainly.
[21:04] <mhwood> Isn't there a rule of thumb about never releasing on a Friday? Maybe there should be.
[21:05] <tdonohue> mhwood: OK, it's really up to you. I'm just trying to determine if I need to get someone else to update dspace.org...or not. I'm 100% offline on Friday, so I'm not gonna be around to help, unfortunately. But, I'm around Thurs & Mon.
[21:05] <mhwood> Since coordination is needed, maybe we do need to wait.
[21:05] <hpottinger> I wouldn't announce a release on a Friday
[21:06] <mhwood> So, just quietly create it and say nothing until Monday?
[21:06] <tdonohue> mhwood: yea, that's fine. We've done that in the past...in fact, we may have done that for 3.0...I think 3.0 was released on a Fri and announced on a Mon
[21:06] <hpottinger> it certainly won't be quiet around here :-)
[21:06] <mhwood> Let's do that then. Create release on Friday, announce Monday.
[21:07] <mhwood> Objections?
[21:07] <tdonohue> sounds good.
[21:07] <hpottinger> none
[21:07] <hpottinger> spectators welcome, bring soundtrack suggestions
[21:08] <tdonohue> Just one other note...it'd be good if you can ping me before you plan to send out the announcement on Monday, mhwood. I just want to be sure to get dspace.org fully updated *before* that email goes out :)
[21:08] <mhwood> It's on my calendar now.
[21:08] <mhwood> Yes, will do.
[21:08] <tdonohue> thanks
[21:09] <mhwood> Noted.
[21:09] <tdonohue> So, it sounds like several of us will be around tomorrow to chip in as needed (let me know if you need help with any docs, etc, I'll be around). Then we cut the release on Friday, and announce on Monday.
[21:09] <tdonohue> Anything else we need to talk through today?
[21:10] <mhwood> Nothing comes to mind.
[21:11] <tdonohue> same here. I cannot think of anything else.
[21:12] <tdonohue> So, we might as well close up this meeting then. I'll be around for a while, so feel free to ping me as needed
[21:12] <tdonohue> And: 4.0 YAY! :)
[21:12] <mhwood> Likewise, I'll be around until about 2200 UTC.
[21:13] <tdonohue> Thanks again for all the hard work, Release Team (mhwood, hpottinger & bollini). We really are in the home stretch, and it's exciting!
[21:15] <mhwood> You are all welcome.
[21:16] <mhwood> Looking forward to finishing off 4.0 so I can give more attention to 4.1 and 5.0 coding. :-)
[21:21] <hpottinger> lol, googling for GPG vagrant plugin leads me right back to DS-1663
[21:21] <kompewter> [ https://jira.duraspace.org/browse/DS-1663 ] - [DS-1663] Add GPG code signing key import functionality to Vagrant-DSpace - DuraSpace JIRA
[21:35] * PeterDietz (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[21:38] <hpottinger> I wish there were a way to programatically add a profile to .m2/settings.xml
[21:46] * lap_ (~chatzilla@host54-210-dynamic.16-87-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310])
[21:47] <mhwood> ??? It's XML. xsltproc addprofile.xsl ~/.m2/settings.xml
[21:48] <hpottinger> I have a pathological fear of XML :-\
[21:49] <mhwood> Many do. I just think it's wordier than COBOL. Oh, and the processing model for XSL-T has never yet felt natural.
[21:50] <hpottinger> I'm much more comfortable assuming that it's perfectly fine to just overwrite the existing settings.xml file with a Vagrant provisioner
[21:50] <mhwood> Ah, well, that's a special case, since that is probably the way you got your settings.xml in the first place.
[21:51] <hpottinger> well, it actually came from Ubuntu's apt-get package
[21:52] <hpottinger> whoops, it's not there anyway, woohoo blank slate!
[22:01] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:06] * PeterDietz (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) has joined #duraspace
[22:09] * PeterDietz (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) Quit (Read error: Connection reset by peer)
[22:10] * PeterDietz (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) has joined #duraspace
[22:12] * PeterDietz (~peterdiet@dhcp-164-107-232-31.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[22:12] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[22:34] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[22:47] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 264 seconds)
[23:12] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.