Developers Meeting on Weds, June 29, 2011

Agenda

• First 20+ minutes: JIRA Catch-Up – starting with issue DS-820
  • We will continue "Quick Review" format (2 minutes per issue, with extensions only as necessary), as we need to try to review JIRA issues more quickly. (More details on "Quick Review" format at JIRA Cleanup Sessions)
  • Search for all Unresolved Issues (since DS-820)

• General Announcements:
  • New "Unreleased Documentation" Space in Wiki: DSDOCDEV (You can start adding 1.8.0 Docs here immediately!)
    1. DSDOCDEV -> Developers write new docs/update docs here (before release)
    2. DSDOC -> This space always points to the latest released docs
  • Reminder: GSoC's Weekly Update meeting immediately after this meeting (21:00 UTC) (also GSoC Mailing List)

• Discussion:
  • DS-935 : REST-API Has a dependency on the dspace-jspui-api, it would be nice if this could be removed.

• GSoC Discussion Topic (May wait until GSoC Meeting at 21:00UTC)
  • How can we support "infrastructure" for GSoC projects? For example, supporting a virtual server for demoing/testing
    • General answer from DuraSpace. There's a few options:
      1. Students/Mentors could set up a Free Amazon Virtual server. If somehow you went beyond the needs of the "Free" category during GSoC, DuraSpace would reimburse you up to a limit (Need to determine that limit, but likely not more than the $500 received from Google for each project).
      2. DuraSpace could host a GSoC virtual server on our Amazon account. But as this costs us money (NOT free), it would either be: (a) temporary (will be taken down almost immediately after GSoC), or (b) there would be one virtual server for all GSoC projects to share.
         • If we went this route, management of the software (DSpace & prerequisites) on the server would likely fall to GSoC mentors and students.

General Reminders

• GSoC General Reminders:
  • GSoC's Weekly Update meeting immediately after this meeting (21:00 UTC)
  • New GSoC Public Mailing List this year (shared with Fedora & DuraCloud):
  • Important Dates (full timeline)
    • May 24: GSoC Begins
    • August 22: GSoC Ends

Topics in the Waiting...

• Topics which are still on the "back burner" (which need someone to lead a "Special Topic" meeting around them)
  • Do we want to schedule a meeting to go over proposed Modularization / Refactoring work in near future?
    • Restructure Trunk Projects
    • Refactoring the DSpace Domain Model
    • Others listed under Development Proposals
  • Discuss improving how DSpace handles Metadata. Several ideas mentioned recently:
    • Updating to current DCMI standards: DS-805
    • Creating a new "dspace" internal usage schema (for administrative, or non-DC metadata)? Formalize the "dc" schema to be strictly valid QDC/DC?
    • Metadata on all DSpace objects (not just Items)
    • Per discussion at OR11, DCAT is going to make recommendations on Metadata Schemas that DSpace should support.
  • Discuss forming a "Documentation Management Team"? Or reworking our procedures for managing/reviewing/approving Docs on the Wiki.
  • More discussion of Proposed RoadMap to 2.0
    • In meantime, feel free to forward thoughts on to Tim or everyone (via dspace-devel or dspace-commit).
  • Followup on some Async Discussions (both from last week and from recent email threads):
    • Tim & Mark D had a discussion about potentially reorganizing the SVN "Modules" area into more specific "groupings", to make it more clear which modules/projects are "supported" and which may be experimental, etc. Would like to consider possibly reorganizing into these general 'groupings':
      1. "Sandbox" - all modules which are still experimental (or very outdated?) should likely move to existing SVN Sandbox area
      2. "Core Modules" (may need a better name) - These are fully supported modules which actually are released as part of out-of-the-box DSpace.
      3. "Extension Modules" (may need a better name) - These are modules which should be considered "more stable" than those in Sandbox. But, they are not released as part of out-of-the-box DSpace (rather they can be installed separately as "addons" or "extensions" to DSpace).
    • The idea would be that "Sandbox" and "Extensions" areas are open to any/all developers to take part in development. But that the "Core" area is likely managed more like current SVN TRUNK (where you need to be a "Committer" or "Highly Trusted Developer" to commit code there).

Meeting Notes

JIRA Review, Welcome Andrea Schweer as new Committer, New DSDOCDEV wiki space, DS-935 review

Meeting Transcript

• Full IRC Transcript is available at - http://irclogs.duraspace.org/index.php?date=2011-06-29