Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Developers Meeting on Weds, July 24, 2013

Agenda

Regular Items

  • "JIRA Backlog Hour" : Every Weds at 19:00UTC in #dspace IRC we will be working together to tackle our JIRA Backlog of "Received" tickets. This regular meeting will continue until we've been able to catch up on our backlog.

Discussion Topics

  1. Pull Request Reviews (first 10 minutes or so) - Starting with #196
  2. DSpace 3.2 release
  3. DSpace 4.0 planning
    1. Need to start thinking about our possible release timeline, and whether there's anything we want to change from the 3.0 release timeline.
      1. 3.0 Deadlines were:
        1. Aug 24, 2012 (Friday) - Code Submission Deadline
        2. Sept 14, 2012 (Friday) - Feature Freeze
        3. Oct 8, 2012 (Monday) - RC1 released  (Initial Testathon began Oct 10, Wednesday)
  4. Developer's feedback on  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  requested by Kostas (could make it into 4.0)
  5. Travis CI + GitHub : Should we all be using this?
    1. Travis CI allows each developer to have their own Continuous Integration on their own GitHub Repo
    2. Also integrates with GitHub and will provide a warning if your Pull Request to DSpace causes build failures in Travis CI
    3. All it requires is a ".travis.yml" file in our GitHub Repo
    4. http://about.travis-ci.org/docs/user/getting-started/
  6. Other topics for discussion?

Additional Ongoing Topics

  1. Brainstorming Features/Changes for future. Can we work towards development teams around any of these projects?

Individual Status Updates

If you have status items to report, please enter them below at least 1 hour before the meeting starts.

Meeting Notes

Meeting Transcript

  • Full IRC Transcript is available at - http://irclogs.duraspace.org/index.php?date=2013-07-24

  • DuraLogBot crashed before the meeting and failed to capture the logs.  Here's a copy of tdonohue's logs from the meeting (Times are all in CDT):

    (8:10:13 AM) The topic for #duraspace is: [Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]
(8:10:13 AM) Topic for #duraspace set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 at 8:19:41 PM on 10/21/2010
(8:38:57 AM) hpottinger [~hpottinge@mu-162198.dhcp.missouri.edu] entered the room.
(2:48:11 PM) KevinVdV [~KevinVdV@d5153D041.access.telenet.be] entered the room.
(2:48:58 PM) KevinVdV: Hi everybody
(2:49:31 PM) mhwood: [everybody] Hi KevinVdV
(2:52:37 PM) kstamatis [b03abb63@gateway/web/freenode/ip.176.58.187.99] entered the room.
(2:57:38 PM) l_a_p [~chatzilla@37.102.192.205] entered the room.
(2:58:17 PM) PeterDietz [~peterdiet@128.146.173.70] entered the room.
(3:00:14 PM) tdonohue: Hi All, it's time for our weekly DSpace Developers Mtg.  Agenda for today is up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-24
(3:00:17 PM) kompewter: [ DevMtg 2013-07-24 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-24
(3:00:46 PM) tdonohue: We'll kick things off with a quick PR review (or two) https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
(3:00:47 PM) kompewter: [ Pull Requests -  DSpace/DSpace -  GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
(3:01:11 PM) tdonohue: starting with #196 today: https://github.com/DSpace/DSpace/pull/196 (related to DS-1503)
(3:01:12 PM) kompewter: [ DS-1503 by ottenhoff -  Pull Request #196 -  DSpace/DSpace -  GitHub ] - https://github.com/DSpace/DSpace/pull/196
(3:01:14 PM) kompewter: [ https://jira.duraspace.org/browse/DS-1503 ] - [#DS-1503] ShibAuthentication depends on use of non-recommended Apache UseHeaders setting - DuraSpace JIRA
(3:02:48 PM) tdonohue: I'm not as familiar with Shib, but based on the description in Ds-1503, this sounds totally reasonable
(3:03:32 PM) kstamatis: from Shibboleth documentation "ShibUseHeaders : Defaults to "Off", this turns on the use of request headers to publish attributes to applications. Use of this option should be avoided. Be sure to review the topic on spoof checking if you enable it."
(3:04:31 PM) tdonohue: Anyone here familiar enough with Shib to review/test this work?  It seems like good work to me, but I don't have a Shib to try it out against or similar.
(3:04:39 PM) hpottinger: I can review
(3:05:21 PM) tdonohue: thanks hpottinger, do you want to go ahead and just "claim" Ds-1503 then as well?  This sounds like a good addition, just needs a quick review from someone else
(3:05:22 PM) PeterDietz: ...funny, I just sat through a two hour session on shibboleth, from our local designer OF shibb
(3:06:18 PM) mhwood: Seems reasonable.
(3:06:50 PM) hpottinger: I have a contribution to the shib.authentication plugin that I'll toss on the pile for 4.0, it's a tiny one, but helpful for us
(3:07:51 PM) tdonohue: Sounds good. Ok, so, hpottinger will review Ds-1503 / PR #196.  Several of us feel this seems like a good fix, just needs a quick review.
(3:08:21 PM) tdonohue: gonna move along to the next one. PR #202 : https://github.com/DSpace/DSpace/pull/202/
(3:08:22 PM) kompewter: [ Multilingual help for JSPUI by lyncodev -  Pull Request #202 -  DSpace/DSpace -  GitHub ] - https://github.com/DSpace/DSpace/pull/202/
(3:08:35 PM) tdonohue: related to DS-1508
(3:08:37 PM) hpottinger: assigned 1503 to myself, "accepted" it, but my brain is mush, not much more to be done about it today
(3:08:37 PM) kompewter: [ https://jira.duraspace.org/browse/DS-1508 ] - [#DS-1508] Multilingual Help improvement for JSPUI - DuraSpace JIRA
(3:09:07 PM) tdonohue: huh...um, 1508 is closed as "won't fix"
(3:09:42 PM) tdonohue: (closed by claudia it seems)
(3:11:20 PM) tdonohue: not sure what to do with this one myself...perhaps just a comment asking what the status is, whether this still needs review?
(3:13:38 PM) tdonohue: added a comment to PR #202, as I'm not sure what else to do.
(3:13:46 PM) mhwood: Yes.
(3:13:58 PM) tdonohue: We'll stop the PR reviews there for today, as there's plenty more to talk about today
(3:14:32 PM) tdonohue: Next topic for today: DSpace 3.2!
(3:14:44 PM) hpottinger: there *is* another PR: https://github.com/DSpace/DSpace/pull/263
(3:14:44 PM) kompewter: [ backporting patch to DS-1603 to dspace 1.8 by hardyoyo -  Pull Request #263 -  DSpace/DSpace -  GitHub ] - https://github.com/DSpace/DSpace/pull/263
(3:15:21 PM) tdonohue: hpottinger and I ran into some "last minute" snags with the 3.2 release process.  But, you all are the *first* to know that DSpace 3.2 is now released (on Maven Central).  We just need to send out the formal announcement
(3:16:32 PM) tdonohue: hpottinger just linked to the backporting of DS-1603.  We're still working on doing a backported 1.7.3 and 1.8.3 security release for those users.
(3:16:33 PM) kompewter: [ https://jira.duraspace.org/browse/DS-1603 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
(3:17:08 PM) hpottinger: anybody want to press that merge button? I know it's yellow, but it's not my fault :-)
(3:17:43 PM) mhwood: "Merge with caution", ooo, that's one I've never seen before.
(3:18:18 PM) tdonohue: "Merge with caution" is the Travis CI + GitHub integration (also on our agenda today..near the end)
(3:18:18 PM) hpottinger: that's a warning from Travis-ci.org
(3:18:32 PM) kstamatis: https://travis-ci.org/hardyoyo/DSpace/builds/9446837 for more details
(3:18:33 PM) kompewter: [ Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community ] - https://travis-ci.org/hardyoyo/DSpace/builds/9446837
(3:18:52 PM) tdonohue: It's actually a cool feature... Travis CI checks your PR's branch and tells you whether it looks like it will build properly...
(3:19:21 PM) tdonohue: In this case though, the reason it's "merge with caution" is because we don't have Travis CI properly configured in our GitHub codebase...
(3:20:47 PM) tdonohue: hpottinger: I'll press the button on Pull #263 as it looks good, and I know Travis CI is complaining about something other than your code ;)
(3:20:58 PM) hpottinger: yay!
(3:21:40 PM) tdonohue: button pressed. I mostly just waited so that everyone could see the Travis CI integration in action  (even if it was the "yellow warning") :)
(3:22:13 PM) hpottinger: OK, path to 1.8.3 is clear, need to cherry pick to 1.7 and then we'll have 1.7.3 ready, too
(3:22:58 PM) tdonohue: So, it sounds like that's the remainder of the updates on 3.2 / 1.8.3 / 1.7.3.  The last step after those releases will be the announcements to lists...which I have (mostly) ready
(3:24:12 PM) tdonohue: Next on the agenda is 4.0 planning.  This is obviously an ongoing topic on the agenda.  Mainly, just a reminder here that we need to set some release timelines soon.  Wondering if we need to start this discussion on dspace-release?
(3:25:45 PM) hpottinger: fyi, I'm a bit distracted right now, working on the cherry pick from 1.8 to 1.7, shout at me if you need me
(3:26:12 PM) mhwood: I will send a note to dspace-release to get some discussion started.
(3:27:25 PM) tdonohue: sounds good mhwood. That's probably the best place to start to iron it out... although we have quite a few people here, not so many committers today actually.
(3:27:57 PM) tdonohue: Anything else anyone wants to add on 4.0?
(3:28:47 PM) hpottinger: mhwood, last time around, for the schedule, Robin just revamped the previous schedule with new dates, and proposed that as the new schedule. During the process, Tim suggested adding two deadlines
(3:29:48 PM) hpottinger: so, my suggestion would be similar: propose a schedule based on the previous one, and let people agree to it, it's easier than discussing schedule design from scratch, I think
(3:30:23 PM) tdonohue: +1 in past we've always usually based the "new proposed dates" on the last release.  Just easier that way.  
(3:31:21 PM) tdonohue: but, we should feel free to tweak it as needed...  No need to keep the same set of deadlines, it can be changed as we see fit
(3:31:25 PM) mhwood: I'm still toying with the idea that each sizable contribution needs its own schedule, so that it may be possible to somewhat coordinate landing dates.  Of course, creative work is hard to keep to a rigid schedule....
(3:32:16 PM) tdonohue: mhwood: yea, I like that idea.  Just not sure how much "hand-holding" / pestering would be involved in reminding folks of their promised "schedule"
(3:32:55 PM) mhwood: Using the previous schedule is a good way to set dates generally, and then point out that we would like to spread landing dates for features out a bit ahead of those dates where possible.
(3:33:17 PM) tdonohue: but, I think it (or something similar) could be worth a try. We definitely want to try to avoid the "everything is contributed in the last week before the deadline" syndrome of past releases (3.x especially)
(3:34:10 PM) hpottinger: especially since big merges (can) break existing PRs
(3:34:19 PM) tdonohue: +1
(3:35:31 PM) hpottinger: little merges should be pushed by their own committers (IMHO) :-) while "max day" was good fun last year, I would prefer not to do things that way again
(3:35:36 PM) mhwood: Exactly.  I think it would help to ask people to "sign up" for landing dates in advance of the general dates, to give us some time to straighten out any conflicts.
(3:36:24 PM) mhwood: Yeah, one thing the RT can do is say, "just go ahead and put that in" where a contribution is small or simple.
(3:36:56 PM) tdonohue: yes, ideally we work to get "little merges" in quickly (so they don't "break" from something bigger).  Bigger mergers/features need to either "sign up" for a landing date, or need to meet some sort of earlier "deadline"
(3:37:13 PM) tdonohue: seems like a reasonable direction to me
(3:38:22 PM) tdonohue: Ok, any other thoughts on 4.0 release planning?  Sounds like main next step is to get a thread going on dspace-release list
(3:40:04 PM) tdonohue: hearing nothing... so we'll move along (and continue this discussion on dspace-release)
(3:40:51 PM) tdonohue: next topic:  kstamatis wanted to get some feedback on DS-491 (ideally for possible 4.0 inclusion).
(3:40:53 PM) kompewter: [ https://jira.duraspace.org/browse/DS-491 ] - [#DS-491] Ability to map collections to multiple communities - DuraSpace JIRA
(3:41:12 PM) kstamatis: Actually, I didn't want to bother the dev meeting with just an issue, but I was wondering what is the procedure, after some work on a specific issue, to raise dev attention on that
(3:42:49 PM) tdonohue: kstamatis: one option is to actually ask for some quick feedback in these meetings (or at least see if there's anyone here willing to add feedback later on, after meeting, etc.). 
(3:43:17 PM) mhwood: Or on dspace-devel.
(3:43:21 PM) tdonohue: another option is to try to get more developer feedback on dspace-devel
(3:44:08 PM) kstamatis: OK, I thought that the email that was be sent after the JIRA comment would be sufficient to raise the attention
(3:44:20 PM) tdonohue: I'm *guessing* though that, in this case, we might be able to look at how "Item Mapping" works and use that to implement something similar for "Collection Mapping".
(3:45:05 PM) kstamatis: i did that... item mapping has a major difference... each item has an "owning collection", which is not the case for collections
(3:45:21 PM) tdonohue: kstamatis: yea, JIRA also emails dspace-devel. But, admittedly, sometimes folks ignore or don't pay as much attention to the automated JIRA emails.  It doesn't hurt to write a quick email to dspace-devel to also try and raise attention/awareness
(3:46:01 PM) kstamatis: tdonohue: that's ok, of course
(3:46:24 PM) joaomelo [~kvirc@144.64.48.118] entered the room.
(3:47:51 PM) tdonohue: regarding "collection mapping", I actually wonder if a Collection *would need* an "owning community".   Just cause it may make some questions a bit easier to answer.  Otherwise with two (or more) parent communities, it's hard to determine who "inherits" rights to the Collection, etc. 
(3:48:02 PM) joaomelo: hi all
(3:48:29 PM) tdonohue: but, I don't feel strongly about that... just brainstorming a bit here.  Otherwise those questions seem hard to answer
(3:50:07 PM) kstamatis: I guess that "owning community" answers some questions...
(3:50:31 PM) ***hpottinger waves to joaomelo.
(3:50:42 PM) kstamatis: because you then know where to inherit policies from
(3:51:48 PM) tdonohue: kstamatis: yep, exactly.  Without some sort of "owning community" concept, it'd be hard to answer any of those questions (cause you'd have no idea which community was more "important" to inherit from)
(3:51:51 PM) mhwood: I'd say that a Collection inherits from the Community in which it was created, and mapping doesn't affect it.  That seems to fit with the static inheritance model that we use now.  I don't think that a Collection needs to be "owned" by a Community; it's just a handy place to get default permissions at creation and means nothing afterward.
(3:52:27 PM) joaomelo: +1 mhwood
(3:52:29 PM) mhwood: I see that I'm assuming, here, that a Collection is created in a single Community and then mapped later.
(3:53:00 PM) kstamatis: mhwood: you are assuming right
(3:53:02 PM) tdonohue: mhwood: yea, I agree with that.  I was just calling the "Community in which it was created" the "owning Community" for that collection.   Same as how the "Collection in which an item was created" is the "owning Collection" for that item.
(3:53:34 PM) tdonohue: so, I'm actually saying the same thing as mhwood...just was using the term "owning" to representing "where it was created".  But, maybe that's not the best term for it
(3:53:50 PM) joaomelo: but do we need to be persistent?
(3:54:18 PM) kstamatis: OK, this solves the major problems with this issue
(3:54:34 PM) mhwood: Coming from a VMS background, I have a bit of an allergy to the notion of one link being "special". :-/
(3:55:44 PM) joaomelo: VMS?
(3:55:59 PM) mhwood: VAX/VMS operating system.
(3:57:50 PM) tdonohue: So, have we cleared up DS-419 more? Or are there still questions/comments here?
(3:57:53 PM) kompewter: [ https://jira.duraspace.org/browse/DS-419 ] - [#DS-419] Setting embargo.field.terms to an unqualified field throws uncaught exception on item submission - DuraSpace JIRA
(3:58:04 PM) pdurbin: wow. VAX/VMS :)
(3:58:08 PM) tdonohue: ugh..DS-491 (bad typing on my part)
(3:58:09 PM) kompewter: [ https://jira.duraspace.org/browse/DS-491 ] - [#DS-491] Ability to map collections to multiple communities - DuraSpace JIRA
(3:58:43 PM) kstamatis: tdonohue: I will sent an email to dspace-devel to see if anyone else is interested in this topic, but I got some nice answers in here\
(3:58:56 PM) tdonohue: sounds good, kstamatis. 
(3:59:34 PM) tdonohue: So, in the last minute, just wanted to bring up the final agenda topic:  Travis CI (https://travis-ci.org/) + GitHub
(3:59:35 PM) kompewter: [ Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community ] - https://travis-ci.org/)
(4:00:09 PM) tdonohue: For those not familiar with Travis CI, it's free, and it lets you do Continuous Integration (automated builds) based on your *own* GitHub forks of DSpace
(4:00:45 PM) tdonohue: It also has cool features (as we saw earlier) that will warn you if your Pull Request branch fails to build -- it'll warn the committers to about the PR
(4:00:52 PM) joaomelo: that's huge!
(4:01:27 PM) hpottinger: it
(4:01:28 PM) tdonohue: So, I know a few folks have already started using Travis CI. Namely hpottinger & PeterDietz.  I plan to start using it soon myself, as it looks very cool
(4:01:36 PM) hpottinger: is pretty awesome :-)
(4:02:24 PM) mhwood: Very nice.
(4:02:24 PM) pdurbin: feel free to ask me about https://travis-ci.org/openscholar/openscholar :)
(4:02:24 PM) kompewter: [ Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community ] - https://travis-ci.org/openscholar/openscholar
(4:02:49 PM) mhwood: I've tinkered with integrating Jenkins with GitHub, but that requires a host of your own.
(4:02:52 PM) tdonohue: The one "catch" (and it's a small one) is to ease the integration of Travis CI + DSpace GitHub, we need to add a small ".travis.yml" config file to our DSpace GitHub repo ("master" branch, and any others we want to hook into Travis CI)
(4:03:01 PM) tdonohue: more on setting up Travis CI: http://about.travis-ci.org/docs/user/getting-started/
(4:03:01 PM) kompewter: [ Travis CI: Getting started ] - http://about.travis-ci.org/docs/user/getting-started/
(4:03:32 PM) pdurbin: i.e. https://github.com/openscholar/openscholar/blob/SCHOLAR-3.x/.travis.yml
(4:03:32 PM) kompewter: [ openscholar/.travis.yml at SCHOLAR-3.x -  openscholar/openscholar -  GitHub ] - https://github.com/openscholar/openscholar/blob/SCHOLAR-3.x/.travis.yml
(4:03:47 PM) hpottinger: I almost committed it by accident earlier this week
(4:04:14 PM) tdonohue: yea, hpottinger has a .travis.yml we could use for DSpace.  So we could politely ask him to submit a Pull Request ;)
(4:04:31 PM) joaomelo: is there any manual/tutorial?
(4:04:38 PM) hpottinger: I stole it from PeterDietz :-)
(4:05:25 PM) tdonohue: joaomelo: The main "manual" is the docs at: http://about.travis-ci.org/docs/ (there's some guides on the right hand side there as well)
(4:05:26 PM) kompewter: [ Travis CI: Travis CI Documentation ] - http://about.travis-ci.org/docs/
(4:05:51 PM) PeterDietz: .travis.yml       ---->          language: java
(4:05:54 PM) joaomelo: thanks
(4:06:03 PM) PeterDietz: Thats all you need for a java app that supports mvn test
(4:06:30 PM) hpottinger: the gist of it is you sign up, give Travis permission to write hooks to your repositories, it does so, and then starts failing
(4:06:40 PM) tdonohue: So, if we all plan to start using Travis CI (which I'd recommend, for those interested), we could also start our own "Travis CI tips" (if needed) on the DSpace wiki.  Though, from what I've seen so far, it seems pretty easy to get running quickly
(4:06:45 PM) hpottinger: (unless you're a Ruby developer, that is)
(4:07:28 PM) pdurbin: tdonohue: I'd love Travis CI tips for Java projects
(4:07:54 PM) PeterDietz: Another key difference is that with bamboo, when it crashes you gotta wait some time for someone to kick it, or kick it yourself, or kick someone to have them kick it. With travis, they will ensure it keeps on running and, running updated projects, and finding resources to do builds.
(4:07:59 PM) tdonohue: pdurbin: I don't know of any tips yet. Just saying as we learn it we can write them up.  :)
(4:08:28 PM) hpottinger: that one liner above is all you need for .travis.yml, and it "just works"
(4:10:13 PM) tdonohue: So, since several of us seem interested in trying out Travis CI, I'd suggest the following:  (1) hpottinger or PeterDietz create a JIRA ticket & PR suggesting we add ".travis.yml", (2) we let the other Committers know / make them aware of it too by pointing them at that JIRA ticket, (3) we merge the PR and start trying it out.
(4:10:52 PM) hpottinger: I will also suggest back porting to 1.8.x and 1.7.x
(4:11:06 PM) hpottinger: since they're all nice and spiffy now
(4:11:38 PM) tdonohue: (after much work) 1.8.x and 1.7.x are "nice and spiffy now"
(4:12:03 PM) hpottinger: to translate: you can use the Git branches to roll new releases and such
(4:12:42 PM) hpottinger: which, erm, I'm supposed to be doing right now...
(4:12:59 PM) tdonohue: yea, 1.8.x and 1.7.x branches are now "GitHub" / "Git" friendly.  You can now fork them and actually use them, etc.  Previously, they were still just "copies of code" from our old Subversion, and actually trying to use them from GitHub didn't really work
(4:13:58 PM) tdonohue: Ok. Well, I don't have any other topics on our agenda for today.  Unless anyone else has something important to bring up, we can go ahead and close the meeting.
(4:14:09 PM) hpottinger: it's a pretty huge deal, if someone has been putting off switching from Subversion to Git, because they're supporting a repository based on 1.7 or 1.8, now's the time to switch
(4:15:15 PM) mhwood: Sounds good, but I have to go now.  Thanks, all!
(4:15:50 PM) mhwood left the room.
(4:15:53 PM) kstamatis: goodbye everyone
(4:15:55 PM) kstamatis left the room.
(4:16:03 PM) KevinVdV: I have a small thing to bring up for DSpace 4.0, for those still present. I created a pull request a while ago make discovery the default search engine for DSpace. I believe if we want to do this it should find its way into the code base as soon as possible.
(4:16:55 PM) tdonohue: yep, it would be good to get a new PR as soon as possible for that
(4:17:06 PM) joaomelo: +1
(4:17:33 PM) joaomelo: about the i18n support, any decision from the last meetings?
(4:18:28 PM) KevinVdV: Well I have one: https://github.com/DSpace/DSpace/pull/218 for those willing to test/review
(4:18:29 PM) kompewter: [ [DS-1272] Enable Discovery By Default for the XMLUI by KevinVdV -  Pull Request #218 -  DSpace/DSpace -  GitHub ] - https://github.com/DSpace/DSpace/pull/218
(4:19:01 PM) KevinVdV: Just requires some testing by somebody that isn't ME
(4:19:16 PM) tdonohue: joaomelo: by "i18n support", are you talking about Bram's suggestion to use 'translationwiki.net' to help with translations?  If so, Bram just sent an email to dspace-tech about that a few hours ago
(4:19:41 PM) joaomelo: hmm
(4:20:29 PM) l_a_p left the room (quit: Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]).
(4:21:32 PM) tdonohue: KevinVdV : oh, I didn't realize there was a new PR. I must've missed that.   Well, this is something again we could ask for feedback on via dspace-devel... or we could try and schedule it for next week's meeting, so that we get more eyes on it
(4:23:24 PM) KevinVdV: Well IF I can make it for next weeks meeting I would be glad to add it to it, since like I said before if want to include better as soon as possible (Kinda hard though to tell IF I can attend since my wife is 40 weeks pregnant tomorrow & the baby is expected at any time now)
(4:23:57 PM) tdonohue: oh wow. congrats to you and your wife, KevinVdV! 
(4:24:24 PM) KevinVdV: Thanks :-)
(4:24:36 PM) joaomelo: Congratulations :)
(4:25:15 PM) tdonohue: So, I can write myself a note to mention this next week. But if you want more immediate feedback, maybe it's worth sending a brief note to dspace-devel asking for someone to review it for 4.0?   We can also discuss it next week and add our comments directly to the PR so you can see them at a later time
(4:25:42 PM) KevinVdV: Agreed, I'll type up an email now and we will see where it goes from there
(4:25:48 PM) tdonohue: sounds good
(4:30:16 PM) pdurbin: tdonohue: ok (the tips). thanks
(4:32:13 PM) joaomelo: well, goodbye everyone
(4:32:26 PM) joaomelo left the room (quit: Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/).
(4:34:14 PM) KevinVdV: If you don't have time to review the pull request but support to idea, feel free to add it to the mail thread I just started around the default discovery.
(4:37:29 PM) KevinVdV: Need to run now, hopefully until next week
(4:37:35 PM) KevinVdV left the room (quit: Quit: KevinVdV).
(4:40:40 PM) helix84 [~a@ip4-95-82-147-170.cust.nbox.cz] entered the room.
(4:43:00 PM) DuraLogBot [~PircBot@atlas.duraspace.org] entered the room.
(4:43:00 PM) DuraLogBot: (notice) This channel is logged - http://irclogs.duraspace.org/
(4:44:04 PM) hpottinger: oh, hai, DuraLogBot, nice to see you!
(4:45:46 PM) helix84: since DuraLogBot crashed, Tim was kind enough to promise to paste the log to https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-24
(4:45:47 PM) kompewter: [ DevMtg 2013-07-24 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-07-24

Action Items

(Action items go here, if any)

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.