Timestamps are in GMT/BST.
[0:13] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[3:00] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[3:27] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) Quit (Remote host closed the connection)
[3:33] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[5:07] * PeterDietz (~peterdiet@162-231-20-234.lightspeed.clmboh.sbcglobal.net) Quit (Remote host closed the connection)
[6:34] -holmes.freenode.net- *** Looking up your hostname...
[6:34] -holmes.freenode.net- *** Checking Ident
[6:34] -holmes.freenode.net- *** Found your hostname
[6:34] -holmes.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:42] * fasseg (~ruckus@HSI-KBW-091-089-154-204.hsi2.kabel-badenwuerttemberg.de) has joined #duraspace
[11:42] * fasseg (~ruckus@HSI-KBW-091-089-154-204.hsi2.kabel-badenwuerttemberg.de) has left #duraspace
[13:08] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:06] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[15:01] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[16:55] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 240 seconds)
[17:01] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[17:02] <hpottinger> true story, I totally missed all day yesterday that mhwood had released 4.0, didn't see the announcements in my inbox until I went home and caught up on my e-mail, had my head down all day, it would seem
[17:08] * PeterDietz (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) has joined #duraspace
[17:21] * PeterDietz (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[19:03] * PeterDietz (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) has joined #duraspace
[19:19] * PeterDie_ (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) has joined #duraspace
[19:20] * PeterDietz (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) Quit (Read error: Connection reset by peer)
[19:31] * PeterDie_ (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) Quit (Ping timeout: 250 seconds)
[19:33] * PeterDietz (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) has joined #duraspace
[19:47] * PeterDietz (~peterdiet@dhcp-164-107-102-174.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[20:00] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-12-18
[20:00] <kompewter> [ DevMtg 2013-12-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-12-18
[20:01] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:01] <tdonohue> Today, I don't have much on the agenda. But first and foremost I do want to congratulate us all on the DSpace 4.0 release! A huge thanks to our 4.0 RT of mhwood, hpottinger & bollini for all their hard work (especially the last few weeks)
[20:02] <tdonohue> I thought the Release Team, lead by mhwood, did a fantastic job. The 4.0 release seemed to go off quite smoothly
[20:04] <hpottinger> It's a pretty impressive release
[20:04] <helix84> good job, RT!
[20:04] <mhwood> We had lots of good contributions on which to draw.
[20:04] <tdonohue> 4.0 also seems to have been well received so far. Though I'm sure we'll get more feedback in the coming weeks/months as folks start upgrading, etc.
[20:05] <tdonohue> I think 4.0 may have been one of the largest releases yet (both in terms of features/commits and in terms of contributors). It beat out 3.0, which itself was a big release
[20:06] <mhwood> 1.4 -> 1.5 was a huge internal reorganization, but may not have had so many visible changes.
[20:07] <helix84> and just a few months ago during the summer it seems there's very little contributions for 4.0. almost everything came in towards the end onf the cycle.
[20:07] <tdonohue> Much of today's meeting I've really set aside to do a "4.0 release wrap-up". Is there anything we want to chat about regarding the release process itself (whether 4.0 specific or not)? Improvements we can make to the release process or release schedule? Issues that may have been encountered that we should try to avoid next time around?
[20:07] <mhwood> Yes, again. I wanted to spread that out but did not bug people enough.
[20:07] <tdonohue> helix84: that's very true. I recall in the summer wondering what 4.0 was going to look like :)
[20:07] <hpottinger> and we survived :-)
[20:08] <helix84> I only regret all the bugs we pushed back for 4.1 :)
[20:08] <mhwood> The main challenge still seems to be starting early enough. Getting things documented was occasionally difficult.
[20:09] <hpottinger> re: bug fixes, there's a release branch, get cracking ;-)
[20:09] <helix84> do you think it would help if we declared that we're not accepting PRs without documentation?
[20:09] <tdonohue> re: bug fixes. yea, it's hard to fit in *everything*. There's always something that slips to x.1 or the next x.0. The key is to ensure that we don't let bigger issues slip (which I think we did a good job of with 4.0)
[20:09] <mhwood> A step for Starting a New Release: review bugs early and start begging for volunteers.
[20:10] <hpottinger> starting a new release: review dependencies that have updates and just update their versions in the pom
[20:11] <hpottinger> (after testing, of course... ahem)
[20:11] <mhwood> In general: we have a nice document on how to complete a release, but we should also have one on how to begin.
[20:11] <tdonohue> Documentation is always an issue. I wish I knew a good way to "fix" that problem. We could make a rule that PRs must come with (at least minimal) docs before they will be merged. It might be worth a try
[20:11] <hpottinger> mhwood++
[20:12] <hpottinger> back when the docs were in the source code that would have been pretty easy to manage
[20:12] <tdonohue> mhwood++ I'd honestly welcome the creation of a "Starting a New Release" page or similar, alongside our "Release Procedure"
[20:12] <mhwood> I will see what I can come up with for Starting a New Release.
[20:13] <mhwood> Noted.
[20:13] <hpottinger> Can we make wiki pages in our own personal space and then copy them (or point to them in a PR)?
[20:13] <tdonohue> I'd also be glad to try and contribute to the "Starting a New Release", though I suspect the RT might be the best resource -- as your minds may be able to more easily list some of the "stumbling blocks" that should be tackled early
[20:14] <tdonohue> hpottinger: yes, it is possible to create wiki pages in your personal space. Several folks already do that for "in progress" docs, and then they move/copy them to the final location
[20:14] <hpottinger> so, it sounds like we could make that a requirement of acceptance of a PR?
[20:15] <tdonohue> I suspect we probably should vote (amongst the committers) whether "we require (at least minimal) documentation for the acceptance of a PR". It needs to be an "accepted policy" amongst us all, for it to work.
[20:16] <mhwood> That sounds right.
[20:17] <tdonohue> And then we need to define what constitutes "minimal documentation" :) (obvious answer may be -- new configs need explanation/docs. New features need usage details, configs, how to enable/disable)
[20:18] <mhwood> A personal page would be an option, if your work is fairly self-contained and large enough to warrant a page. Some really ought to just be threaded into an existing page. But we do need a better way to encourage that we get something along with the code.
[20:19] <mhwood> Maybe minimal documentation is "complete" but it's okay to just dash off something complete and ask for help to put it into shippable condition.
[20:19] <helix84> A page in the DSPACE namespace should be preferable to a page in the personal namespace - because other early testers could help out there, whereas in a personal space only that one user can write.
[20:20] <helix84> But that's just a detail - the important thing is to encourage early docs, no matter what form.
[20:20] <tdonohue> Ok, well, I can email dspace-commit to begin this policy discussion (and brainstorm what we really require). We can then work towards an official vote/approval as needed
[20:22] <mhwood> How can we help the person who has a great idea and great code but no idea how to document it? There are many such. Others could write or improve documentation, but the tech writer needs access to the coder's thoughts.
[20:23] <helix84> chmod o+r mhwood
[20:23] <helix84> that person asking for help would be a good start
[20:24] <mhwood> I'd be willing to be named on a list of people who can help with tech writing, as long as there are others in the list. :-)
[20:24] <tdonohue> mhwood: yea, I think that gets to the point of what constitutes "minimal docs". In my mind, "minimal" may not necessarily be "complete"...but it's enough docs that someone else could run the feature, and help you enhance/tweak the docs.
[20:24] <helix84> me, too
[20:25] <tdonohue> I'm also always willing to help with docs, my time permitting. (sometimes these days my time is lacking though)
[20:26] <helix84> I explored something with ES stats - when I was testing them before the release, I just wrote down everything that I didn't understand and that could be improved into ES docs comments on the wiki. I think that's a great start - a perspective of a new user. I only pity I didn't transform those notes into an improved documentation.
[20:26] <hpottinger> add me to the list
[20:27] <mhwood> Maybe I can find a place to write this up among the Contribution Guidelines. I will see.
[20:27] <tdonohue> So, it sounds like we have two main ToDo's here so far: (1) Create a "Starting a New Release" page with stuff to get done early (mhwood will start, others to enhance), and (2) Begin discussion on -commit around requiring some docs before we can merge a PR (tdonohue will start discussion, others to take part)
[20:28] <mhwood> I'll see what I can do generally to talk about documentation in the Contribution Guidelines, without stating a policy. Policy to follow.
[20:28] <tdonohue> Are there any other threads I missed, or other things we should make sure to talk through today (while the 4.0 release is fresh in everyone's minds)?
[20:28] <tdonohue> sounds good, mhwood
[20:29] <helix84> A random thought - I think best features turn out to be those that have another early adopter before the release. For example, Keiji tested a lot of CINECA stuff, gave feedback and both sides improved the code.
[20:30] <mhwood> Maybe there is a way for the RT to promote "incoming features" and help to find those early testers.
[20:31] <tdonohue> helix84: I agree. That's why the first step of "Code Approval Process" in our "Code Contribution Guidelines" says..."Share Early. Share Often!". But, I've yet to figure out a way to get everyone to do that & encourage that early collaboration
[20:31] <tdonohue> https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-OverviewofCodeApprovalProcess%E2%80%93HowtogetyourCodeintoDSpace!
[20:31] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-OverviewofCodeApprovalProcess%E2%80%93HowtogetyourCodeintoDSpace!
[20:32] <tdonohue> if there are ideas though, anything is worth a try :)
[20:33] * bollini (~bollini@host175-103-dynamic.21-87-r.retail.telecomitalia.it) has joined #duraspace
[20:34] <helix84> The hard part seems to be convincing people developing new stuff to talk about it early. If there's not much we can do on that end, how about starting from the other end ans saying hey, I'm available to test new stuff. What have you all got?
[20:35] <mhwood> Scheduled update mailings on the developing release? With a list of features and improvements?
[20:35] <mhwood> Ulterior motive: get people to want their stuff to be in that list.
[20:36] <helix84> mhwood: that is something I seriously considered doing after the 3.0 release. Only problem is there was nothing to report on. Early in the cycle was dead calm. Then after the summer, a storm came.
[20:36] <hpottinger> how about this: OR time comes, we show off what we have
[20:36] <mhwood> "New features:
[20:36] <mhwood> o Apparently 5.0 will have no new features."
[20:36] <tdonohue> helix84++ It seems to always work that way...dead calm before the storm.
[20:37] <helix84> tdonohue: I keep thinking if there's a way we can turn that into our advantage. I have nothing yet :)
[20:37] <bollini> It is also true that OpenRepository is a major driver
[20:37] <hpottinger> I had a list of features to hunt down after OR (dev meeting and presentations)
[20:38] <tdonohue> OR time could be an opportunity (in the Developer mtg) to get folks to show what they may have. We also could encourage Committers especially to share their very-early-work privately on -commmit (if they just want more eyes, but don't want it public yet). Not sure if that'd work though
[20:38] <hpottinger> bollini can attest i was quite a nag about his web service lookup code
[20:38] <tdonohue> that was -commit, not -commmit ;)
[20:39] <mhwood> As with many management issues, it seems that what is needed is someone to wander around bothering people regularly.
[20:39] <tdonohue> mhwood++
[20:39] * hpottinger volunteers to wander around, who has the airplane?
[20:40] <helix84> turns out we need management... that was unexpected...
[20:40] <tdonohue> Maybe we program a script that starts sending weekly emails to -commit (beginning in the summer) just saying: "Hi there, I notice that our next release has very few new features. Care to tell us what you are working on?"
[20:41] <hpottinger> part of the problem is, and I saw plenty of this at OR but have encountered it elsewhere, there's this notion we all have that the "code is not good enough" it's "not ready"
[20:41] <mhwood> True. It helps to recognize that "not ready to ship" is not the same as "not ready to show to *anyone*".
[20:42] <hpottinger> https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-0.ShareEarly,ShareOften!
[20:42] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-0.ShareEarly,ShareOften!
[20:43] <mhwood> These days I try to push projects up to Github from the start, but I haven't done much to call attention to them.
[20:43] <tdonohue> yea, that's why I was wondering if getting folks talking privately on "dspace-commit" can kickstart some of this.... (just brainstorming)...maybe committers would be more willing to share "not ready to ship" code privately much earlier in the process? Ideally, it'd be better if they just share publicly, but not all are willing to do so.
[20:44] <tdonohue> i.e. start a weekly/monthly discussion thread on "dspace-commit": "What are you working on lately?"
[20:44] <bollini> I think that there are also another devious issue here... if I have a new feature that want to share and if I share it very early probably it will stale for too long before that we will start to seriously thing about merge it
[20:44] <mhwood> We could try that. It might work, and if it doesn't then we can try something else.
[20:44] <hpottinger> here's a thing to do: everyone, star/follow all your fellow committers
[20:45] <helix84> an example occurred to me of someone who did it right and it didn't help
[20:45] <mhwood> bollini has a point. Code doesn't get attention from others, possibly because no one feels qualified to review it.
[20:46] <hpottinger> if you follow us on github, then, if any of us pushes something interesting, we *ask them about it*
[20:46] <tdonohue> very true, bollini & mhwood.
[20:46] <helix84> Pascal-Nicolas announced his work on DOI support very early in the 3.0 cycle. Later, he had code out and needed advice how to solve some open issues and didn't get any response. Only later mhwood helped him wrap it up.
[20:46] <hpottinger> which reminds me, sands put up something I meant to ask him about
[20:47] <mhwood> Yes, I should have responded more quickly.
[20:47] <tdonohue> hpottinger: that is a "dead simple" thing to try. Though it assumes I'm paying attention to my GitHub "news feed" (which I really should do, but I don't always do so). Still I should follow everyone anyhow
[20:47] <bollini> yes, I think that the key is make some guarantee... as we have done for the PR deadline... if you submit it in time we will review it for sure
[20:48] <mhwood> Is there a way to turn the news feed into emails? Those make noise to attract my attention. I have not yet the habit of looking at little "you have notices" icons up in the corner.
[20:48] <helix84> mhwood: We're glad that you were able to help out, regardless. The question here is can we do something better next time it happens? Perhaps a list of issies where help/review/testing is wanted?
[20:48] <hpottinger> I use an app on my iPad called Hojoki (http://hojoki.com/) to keep up with GitHub news feeds, JIRA, and Trac
[20:48] <tdonohue> mhwood: GitHub "news feeds" has an RSS feed...which you might be able to turn into an email.
[20:49] <bollini> we should try to collect idea about new features and improvements and reserve a IRC meeting to the exposed idea, 1 IRC for month
[20:49] <mhwood> We could at least reserve a slice of the meeting time, if there is not enough for an entire meeting.
[20:50] <bollini> yes, we can manage several idea in a single meeting
[20:51] <bollini> but the point is we need to guarantee that you will have a scheduled opportunity to get feedback and maybe a vote
[20:51] <mhwood> bollini: I agree. This kind of thing should be regularly scheduled.
[20:52] <tdonohue> one issue with IRC is that I've noticed we have 2-3 factions in our Committers group: (1) those that are nearly always in IRC meetings, (2) those that pop in occasionally when they can, (3) those that are almost never in IRC meetings.
[20:52] <tdonohue> The problem is something that "those that are almost never in IRC meetings" sometimes are still folks who push big changes at us (e.g. Richard Jones great work on SWORDv2)
[20:53] <tdonohue> s/something/sometimes/
[20:53] <kompewter> tdonohue meant to say: The problem is sometimes that "those that are almost never in IRC meetings" sometimes are still folks who push big changes at us (e.g. Richard Jones great work on SWORDv2)
[20:54] <tdonohue> I do agree though that having something regularly scheduled is a good idea. It can be in our IRC meetings. But, we may also need to catch folks in other ways (email, or whatever else)
[20:54] <mhwood> Well, again, let's try it and see if it works.
[20:55] <tdonohue> yep, agreed. Just noting that we may want to try several options at once here
[20:55] <hpottinger> completely on a tangent here, but if *anyone* has code they are tinkering with to wire up a streaming server with DSpace, or working pseudo-streaming code that doesn't freak out Acrobat, I'm really interested in working with you to polish that up
[20:56] <bollini> ok, can we try to concretize this proposal? the 3rd IRC meeting of any month will be (at least partially) reserved to talk about the idea that are presented in the devel and commit list
[20:57] <hpottinger> +1 bollini
[20:58] <mhwood> Yes, that sounds good.
[20:58] <tdonohue> +1 sounds fine to me. My only issue here is that I'm not sure if I'm going to always remember this schedule (and catch everything that needs talking through in the 3rd IRC mtg). So, I'd appreciate help in tracking what it is we really want to talk through.
[20:59] <tdonohue> I can write myself a note to try and remember the 3rd IRC mtg part...it's more the tracking that I may not always be 100% on top of (depending on what's on my plate)
[20:59] <mhwood> Maybe the then-current RT could be responsible for that part of the meeting.
[20:59] <bollini> the 3rd IRC meeting will mean 15th January, so we have a full month to collect idea. We should announce this new initiative properly on the list and add to the contribution guideline
[21:00] <tdonohue> It'd be helpful if others could chip in on that. It's actually not the easiest to come up with these agendas (and sometimes our agendas may be lacking if I've been swamped most of the week) -- I'd love it if others were willing & able to chip in on meetings more
[21:02] <tdonohue> It's still a bit vague in my mind how we plan to "announce and collection ideas" for these meetings. Is this almost like a JIRA review (for brand new tickets with brand new ideas needing feedback)? Or are we talking about something else
[21:03] <bollini> something else imho. We are talking about something that you probably don't feel to be enought clear and defined to put on jira
[21:04] <mhwood> It sounds like time to deal with those "we should do X" ideas that flit across the lists, and try to get them moving.
[21:04] * helix84 notices that we're starting overtime, but of course, feel free to keep going
[21:04] <bollini> in most case, after that the discussion start on the mailing list we can suggest to open a jira issue
[21:05] <mhwood> Also to convert rumors that "someone is working on X" into issues.
[21:06] <mhwood> And a forum to say: "we are thinking about / building X. Is there interest in having this contributed?"
[21:07] <tdonohue> Since we are in "overtime", I do want to briefly mention that our next *two* meetings fall on major USA holidays (Dec 25 & Jan 1). I'm not going to be able to attend either of them. If folks want to meet, you are welcome to, but I will not be convening an official meeting. So, our next official meeting will not be until Weds, Jan 8
[21:08] <bollini> oh yes, also in Europe is likely that no one will attend the meeting in that days
[21:09] <tdonohue> regarding this IRC meeting thing: Maybe I'm still just confused. I guess I'm not exactly sure what we are announcing here. I do agree that it'd be good to quickly followup on recent email threads / brainstorms on lists in the next IRC meeting
[21:09] <helix84> so we should put these things on the agenda as we notice the emails
[21:09] <tdonohue> So, I guess, I'm saying.. I don't know what this thing "is", nor how I would report/announce it to other developers. It's rather vague
[21:10] <tdonohue> helix84++ that might be a way of doing this.
[21:11] <mhwood> Who will do the adding? Note that "anyone" usually turns out to mean "no one".
[21:11] <helix84> mhwood: I'll tryy to remember to do that sice I'm reading all the mail, anyway. Just in case I forget, we need others to remeber to do it, too :)
[21:12] <tdonohue> Well, I will note that helix84 actually adds things to the agenda on his own at times (and I appreciate it). Anyone can do that. But, yes, I agree that sometimes saying "anyone = no one"
[21:12] <mhwood> Thank you helix84.
[21:12] <tdonohue> I'm also willing to try and add such items to the agenda when I catch them. But, I'm not going to be able to promise that I'll catch *everything*, so the more eyes the better
[21:13] <bollini> ok, my proposal was a bit different we can review any idea that raise on the mailing list in the next IRC but we MUST assure that we will review ALL the idea in the next scheduled IRC (3rd of the month)
[21:15] <bollini> so we should announce that, we have decided to perform regulary a discussion session during the 3rd weekly IRC meeting with developers that will expose idea, work in progress on the mailing list and are available to chat
[21:16] <bollini> we can invite people to add item to the special IRC agenda herself or we can do that (helix84 will be probably the catchall, I will try to help too)
[21:17] <tdonohue> oh, so it's almost like how I had "office hours" in IRC? We invite folks to chat with us in IRC during that 3rd meeting of the month? (I will note that unfortunately no one ever attended my scheduled "office hours"...I think I had one person in the 3-4 months that I regularly held it)
[21:17] <mhwood> So the purpose of this is to turn vague notions into less-vague Jira issues? To capture more ideas, instead of waiting for others to do it?
[21:18] <bollini> as committer we should assure that at least (3?) of us will attend, so that the developers can have enought support (and try to collect vote for the future merge)
[21:18] <hpottinger> office hours still goes on, we just keep tdonohue company with JIRA backlog hour, too. :-)
[21:18] <bollini> mhwood the purpose is to have jira issue about unknown idea and work around the community
[21:19] <mhwood> To actively scan the environment and invite sharing of what we find.
[21:19] <helix84> I think there have been always at least 3 people on every DevMtg unless it was announced the week before that there's a holiday so noone is coming.
[21:20] <hpottinger> Proposal for discussion at the next "let's talk about features" meet up: what's up with this? http://dspace.2283337.n4.nabble.com/Psuedo-video-streaming-with-item-attachment-and-seeking-enabled-td4662291.html
[21:20] <kompewter> [ DSpace - Tech - Psuedo video streaming with item attachment and seeking enabled ] - http://dspace.2283337.n4.nabble.com/Psuedo-video-streaming-with-item-attachment-and-seeking-enabled-td4662291.html
[21:21] <bollini> helix84: yes, probably we have been - but people that don't frequent IRC don't known. The point here is that we will guarantee that we will be here
[21:23] <bollini> tdonohue: yes, it is likely your "office hours"... to be honest I have forget about that. Probably a reminder could be useful
[21:24] <hpottinger> so, the 3rd IRC meeting of every month will be "brainstorm hour?" Or possibly "hackathon hour?" (keep dreaming big, Hardy)
[21:24] <tdonohue> So, I like parts of this...but, I wonder if it can just be simplified to a "Let's talk about Features" meeting (every 3rd meeting of the month), to spin off hpottinger's idea. We just make it clear (on dspace-devel & elsewhere) that the entire meeting is devoted towards brainstorming new features (and following up on threads on email lists relating to such new features)
[21:25] <hpottinger> maybe different ground rules, though, how about "if you have code, you have the floor?"
[21:25] <tdonohue> My Office Hours was advertised every week for about 3-4 months... I've stopped advertising it, as only one person ever showed up in those 3-4 months. It's since changed into time for JIRA Backlog review, etc, and I provide support ad-hoc.
[21:27] <tdonohue> My worry here is that this is sounding similar... We could try it, but I'm just not sure that we'll have many folks show up. But, still, at the very least, maybe it provides us (Committers) a chance to dig deeper into recent email threads
[21:28] <bollini> tdonohue: ok, "Let's talk about Features" makes sense. We should start to include a "standard reply" to email about new feature, idea and development with a reminder to such IRC meeting
[21:28] <mhwood> So, perhaps, if you show up to the meeting then you will get a hearing about your idea. If not, but we heard of it anyway, we may pick a volunteer to ask you for it.
[21:29] <bollini> mhwood +1
[21:30] <tdonohue> Let's start with the "Let's talk about Features" idea, with some groundrules (which we need to still determine -- not sure if we'll get to them all today, we may need to discuss this more via email too, or after the holidays). It seems like it shouldn't be that hard, it's just more of an "open meeting format" once per month
[21:32] <tdonohue> I unfortunately have to head out of here very shortly. Will be back a bit later though. Do we want to bring the remainder of the "Let's talk about Features" discussion to email (dspace-commit)? Or followup again after the holidays on the "groundrules", etc?
[21:33] <bollini> both
[21:33] <mhwood> It's probably time for email. Discussion seems to have slowed. We should think a bit and then email for a bit and then wrap up in IRC when we see convergence beginning.
[21:34] <hpottinger> random idea: this jar ought to be in Discovery somewhere: http://projects.freelibrary.info/solr-iso639-filter/
[21:34] <kompewter> [ Solr-ISO639-Filter Project ] - http://projects.freelibrary.info/solr-iso639-filter/
[21:35] <tdonohue> sounds good. if someone can start this thread on dspace-commit, I'd appreciate it. I'll take care of the other dspace-commit email/discussion about requiring documentation before PRs can be merged
[21:35] <hpottinger> I think we can name this meeting after bollini, if he agrees to publicize it :-)
[21:36] <bollini> 8-)
[21:36] * tdonohue has to step out. Be back a bit later
[21:36] <helix84> hpottinger: I filed a more general ticket regarding that, but this is nice for this special use case (assuming it provides the data)
[21:37] <hpottinger> helix84: thanks for mentioning, have a ticket number for me? I was right about to make a new ticket
[21:37] <helix84> https://jira.duraspace.org/browse/DS-1141
[21:37] <kompewter> [ https://jira.duraspace.org/browse/DS-1141 ] - [DS-1141] Arbitrary SOLR queries in Discovery facets - DuraSpace JIRA
[21:37] <kompewter> [ [DS-1141] Arbitrary SOLR queries in Discovery facets - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1141
[21:38] <helix84> I piques Kevin's interest and convinced him to assign it, but that's no guarantee of success as he's been very busy lately
[21:38] * hpottinger shakes a fist at Jira: remember me!
[21:39] <bollini> http://air.unimi.it/simple-search?query=&submit=Cerca
[21:39] <kompewter> [ Search Results | Archivio Istituzionale della Ricerca ] - http://air.unimi.it/simple-search?query=&submit=Cerca
[21:39] <bollini> we have facet for fulltext
[21:40] <helix84> bollini: based on metadata?
[21:40] <bollini> our approach is to have a metadata that is automatically filled using the info from the bitstreams and the resourcepolicy
[21:41] <helix84> bollini: how do you fill it automatically?
[21:41] <helix84> BTW it used to work in 1.8 (fulltext:* or fulltext:[* TO *]) but it's broken since 3.0
[21:41] <bollini> well... we call this feature, "default values"
[21:42] <bollini> we have changed the InstallItem and the EditItem Servlet to call a "manager" before the item.update
[21:43] <bollini> the manager call all the registred "default values" plugin that can manipulate the item adding metadata or doing other
[21:43] <mhwood> That sounds like a Curation Task.
[21:43] <helix84> exactly
[21:43] <bollini> maybe
[21:44] <bollini> but we want that as part of the item transaction. We don't want that an archived item can go in archive without these metadata
[21:45] <bollini> this is the reason because we don't use event (that are also not friendly with changes)
[21:45] <helix84> bollini: there's a fulltext field in Solr already, so in theory it should continue to work (fulltext/nofulltext, not as detailed as in Milano) but I haven't figured out why it doesn't work anymore
[21:45] <mhwood> I was thinking that if this code were a task attached to the end of the workflow, then you wouldn't need to maintain custom versions of the servlets.
[21:46] <bollini> we have checked it at OR, it works but... the Hightlighter fails
[21:47] <helix84> I think we did look at it, but I have a very bad memory
[21:47] <bollini> mhwood: you need because admin can edit item, and we have default values that are generated on the basis of other metadata (we use it to build a "citation string")
[21:47] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[21:47] <helix84> I spent too much time trying to figure it out. Actually, just today I wrote a workaround SQL to find out which items are missing fulltext :(
[21:47] <mhwood> OK, just an idea.
[21:48] <hpottinger> aschweer: morning!
[21:48] <aschweer> morning folks
[21:48] <aschweer> or whatever the time is for you...
[21:48] <bollini> helix84: sorry, I forget about that until...now
[21:48] <hpottinger> meeting is over, but we're still bashing around an idea about a regular chat about new features
[21:49] <bollini> helix84: if you have a jira issue feel free to assign to me, I will try to look at it soon for the 4.1
[21:49] <aschweer> talking about new features earlier sounds like a great plan to me
[21:50] <helix84> DS-1601
[21:50] <kompewter> [ https://jira.duraspace.org/browse/DS-1601 ] - [DS-1601] fulltext:[* TO *] discovery query throws exception - DuraSpace JIRA
[21:50] <helix84> found it, assigned it. thanks in advance :)
[21:51] <helix84> aschweer: we all like the theory ;)
[21:51] <aschweer> :)
[21:52] <bollini> ok folks I need to go... time to sleep here :-)
[21:52] * bollini (~bollini@host175-103-dynamic.21-87-r.retail.telecomitalia.it) has left #duraspace
[21:52] <aschweer> just checking -- has anyone been able to deposit to 4.0 via sword?
[21:52] <aschweer> cos I haven't
[21:53] <hpottinger> ah, yes, now I remember what I've been forgetting, that SWORD comment on the mail list
[21:53] <helix84> aschweer: just file a ticket so it can haunt us. I personally don't use SWORD.
[21:53] <aschweer> yeah I was thinking about doing that. I suppose I like to check first whether it's just me -- probably silly since closing a jira ticket is cheap :)
[21:54] <mhwood> It was worth asking.
[21:54] <aschweer> hpottinger: yup, that one
[21:55] <mhwood> It sometimes happens that composing the issue brings forward new thinking, and one doesn't have to actually submit it. :-/
[21:58] <aschweer> mhwood: too true!
[21:58] <aschweer> here you go: https://jira.duraspace.org/browse/DS-1846
[21:58] <kompewter> [ [DS-1846] Cannot deposit new item via SWORD - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1846
[21:58] <kompewter> [ https://jira.duraspace.org/browse/DS-1846 ] - [DS-1846] Cannot deposit new item via SWORD - DuraSpace JIRA
[22:02] <mhwood> I have to go. 'bye, all.
[22:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:07] <hpottinger> is there a SWORD validation service?
[22:11] <aschweer> hpottinger: I don't know -- might be worth asking on the SWORD mailing list?
[22:12] <hpottinger> it's the sort of thing that would be Richard's cup of tea, I'd expect, standing up a useful service...
[22:12] <aschweer> if he gets JISC funding for it ;)
[22:12] <aschweer> http://sourceforge.net/mailarchive/forum.php?forum_name=sword-app-tech is the list
[22:12] <kompewter> [ SourceForge.net: SWORD: sword-app-tech ] - http://sourceforge.net/mailarchive/forum.php?forum_name=sword-app-tech
[22:14] <hpottinger> click, click click waiting for confirmation e-mail...
[22:18] <aschweer> there are specs on http://swordapp.org
[22:18] <kompewter> [ SWORD ] - http://swordapp.org
[22:22] <hpottinger> message sent
[22:22] <aschweer> thanks hpottinger :) it's the last day before the break here and I'm quite busy, otherwise I would have done this myself
[22:26] <hpottinger> no problem, hey, btw, that new base machine project? I'm working on a new release of it, I'm afraid the deb mirror method of setting up the apt/sources.list is a bit too fragile
[22:26] <hpottinger> it *might* work for you
[22:29] <aschweer> haven't had time to test it, sorry -- but thanks for all your work on it :)
[22:30] <aschweer> there's a METS validator here it seems: http://hul.harvard.edu/mets/
[22:30] <kompewter> [ METS Java Toolkit, Version 1.3 ] - http://hul.harvard.edu/mets/
[22:30] <aschweer> might help given that the exception message refers to an invalid METS manifest
[22:31] <hpottinger> so, you're pointing easy deposit at demo?
[22:34] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 272 seconds)
[22:36] <hpottinger> added a comment to 1846 with a link to the METS validator
[22:37] <aschweer> yes, I have an easydeposit instance pointed at demo and I also tried with a local 4.0 install
[22:39] <hpottinger> there is likely something just slightly "off" about the code for the patch for DS-1514
[22:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1514 ] - [DS-1514] Embargo settings on item import - DuraSpace JIRA
[22:39] <aschweer> that's my thinking too, I just didn't have time to look at it in detail
[22:40] <aschweer> I doubt it's something about the METS file really since easydeposit used to work fine with older DSpace versions
[22:41] <hpottinger> but 1514 "does stuff" to that information to support embargo
[22:43] <hpottinger> https://github.com/DSpace/DSpace/pull/345 much commentary
[22:43] <kompewter> [ DS-1514 AIP import simple embargo by helix84 · Pull Request #345 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/345
[22:45] <hpottinger> tdonohue in particular looked at the change that aschweer reverted in debugging 1846, I think
[22:45] <aschweer> yeah but he seemed to be concerned more about how the ingester/crosswalk processes the information in the mets file
[22:46] <aschweer> but the issue seems to be that the ingester now expects certain information in the mets file that isn't present when there is no embargo information
[23:06] <hpottinger> gotta go, night!
[23:06] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[23:06] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[23:57] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.