Page History

...

• Long term project.
• 1st step already passed: being able to move DSpace objects around. AIP exporter for the whole object (metadata, content, access rights, ...)
• Goal: using these AIP packages to feed a fedora with.
• Next step: how will this exported data be well represented in Fedora?
• After that: how to put business logic of DSpace on top of Fedora. Problem: not enough technical staff in Duraspace, so it will take a long while. In addition, DuraSpace doesn't want to do this work alone, as individual institutions better know the needs/requirements. DuraSpace is looking for other stakeholders to jump in, participate and speed things up.

Final Decision on a Version Numbering Scheme

• Background:
  • "DSpace 2" as a concept/version number has been floated for ~5 years
  • The definition's changed over time
  • Are we moving towards Dspace 2? Fedora-inside-DSpace == DSpace 2?
• Some Possible Version Numbering Options:
  • 1.8, 1.9, 1.10, 1.11 .... 2.0 (we decide when to make the major version shift to "2")
  • 8, 9, 10, 11 ... (drop the "1.", like Java)
  • YY.MM (eg. 12.11), like Ubuntu
  • YY or YYYY (e.g. DSpace 11 = 2011, or DSpace 2011)
• Scott: What's the problem we're trying to solve?
• Richard R: Expectations around 2.0, how close we are to it (as we approach 1.9, etc.), what we do to make it clear where 1.x is in relation to "2.0"
• Richard J: Shouldn't this be a marketing issue, not an issue for developers to figure out?
• Bram pointed out that encouraging sites to upgrade to the latest versions, and making those upgrades easy and painless, will result in more feedback and more interest from developers, and therefore more good code.
• Scott pointed out that even though 2.0 was "revolutionary" in its initial conception, in practice we've been evolutionary/incremental when it comes to actually releasing new features, versions, etc.
• Stuart pointed out that in recent years, we've been getting much better in terms of how often we release, restricting 1.x.1 releases only to bugfixes, etc.
• Over half the room raised their hand to "We don't ever want to release a 2.0". A good alternative being floated is to jump straight to 3.0 and then continue as normal, with major version reflecting major architectural change, and we know for the future that if we're planning big projects, we should use codenames instead of numbers!
• People who are currently happy users of DSpace and following current release will not care about new versioning schemes, and will upgrade in any case.
• There's a major opportunity in winning people again, who decided in the past that the DSpace product didn't fit their usecase.
• The Final Vote:
  1. 3 people voting for going from 1.x --> 3.0 (i.e. Skip over '2.x' version)
  2. 11 people voting for dropping major, eg. DSpace 3, 4, 5, 6 OR 9, 10, 11
     • By "dropping major" we mean moving from a "x.y.z" versioning to just a "y.z" versioning. So, rather than a 1.9.0, we'd just potentially call that "9.0" or we'd name it "3.0" instead
     • There was some indecision whether we should move to "3.0" after 1.x is done, or just drop the "1." and move right to "9.0", "10.0", etc.
  3. 4-5 people voting for date-based versioning (either YY or YY.MM)
• Results: 2.0 is gone, and we will move to a "major.minor" numbering scheme (instead of major.minor.subminor.
  • Do a strawman poll to find out exactly how the branding will work, whether we co-brand date and major number. (e.g. DSpace 3.0 (2012))
  • Feedback from others: We need to document our version numbering very well. What does it take to reach a "major" release, or do we just release a new "major" release each year. Needs to be clear to users what these version numbers "mean".
  • But the 1.x.y will definitely go, at some point. And 2.0 is definitely gone. RIP 2.0

...

• They've been taking new feature requests from JIRA, members pick issues that are of interest to their institution or that they've heard interest for, figure out prioritisation that way
• They've been through about 5 new feature requests this way so far
• Feedback from committers/developers is useful – coming back with further requirements, etc.
• Some issues require participation from the broader community, DCAT will be working to enable this
• Also working with DSpace ambassadors to try and reach repository managers that might not follow dspace-tech or be involved via usual channels
• Has been a bit slow to start, but it has been really helpful having Robin (in capacity as 1.8 release coordinator) and Tim join in the DCAT discussions
• Encouraging members with a particular interest in new features/issues to join in on IRC committer meetings
• Robin: One benefit has been giving repository managers a voice and making sure developers don't just follow their own pet projects, remind them of real-world priorities
• Tim: gives us a perspective outside of our own institution
• Stuart: Can we get a new flag or status in JIRA so we can get DCAT review of issues we've written code for
  (or issues we don't feel are clearly defined... instead of them ending up stale because we couldn't figure out how to move on them in a committer meeting)
  • TODO: Tim will investigate ways to "flag" an issue in JIRA as "needing a DCAT Review"
• Bram: How many of the 1000+ repository managers are involved in meetings/conferences/any kind of communication where they can express their requirements, issues, ideas? Eg. I use MS Word but I don't turn up to MS focus groups on word processor design. Would be really cool to cross-ref the list of dspace.org listed instances, and people registered on the mailing lists, to find out about those listed on dspace.org who are NOT on the mailing lists. They might need some extra attention to get involved.

Open Discussion Period

Topic 1: Enhancing metadata support (DC cleanup and/or adding metadata to all objects)

• Mark gave overview of how Fedora handles metadata as datastreams (eg. RELS-EXT and RELS-INT RDF, the DC datastream, representation in METS, etc).
• Breaking out from a "relational table" structure - schema.field.qualifier
• Use cases:
  • SWORD2 - have to do a mapping from regular dublin core to DSpace "dublin core"
  • Other Research Data systems - richer metadata than can be supported in dublin core (hierarchical schema needs - MODS or disciplinary based metadata schemas)
  • Theses & Dissertations - very specific ETD-MS metadata schemas (and sharing that metadata with aggregating systems)
• Quick Wins:
  • Remove any Hardcoding assumptions on Dublin Core
  • Cleanup our DC to be real Qualified Dublin Core
  • Provide some existing Schema files for other schemas so that you can import them easily
    • PRISM (page numbers) etc.
  • Redirect some of the Admin Metadata into a "DSpace" internal schemas (or local namespace)
  • Get input from DCAT on metadata schemas
    • What is the set(s) of metadata that should come "out-of-the-box" DSpace?
    • Can we improve Admin UI to help 'guide' people.
  • Training for users - Don't just stuff new things into Dspace metadata, look for a schema that it really fits into.

Topic 2: Configuration changes (dspace.cfg)

• Use Cases:
  • RichardR: Can already start to 'split' out dspace.cfg into 'config/modules' directory files
  • Scott: I want a separate "local" config for more non-default settings
  • Stuart: Should we just 'carve up' these configs for 1.8? (Some agreement)
    • But, is that a "painful" upgrade process?
  • Stuart: Could we do a "reload" method for Admin UI (avoid tomcat restart)
    • May need to avoid reloading some files (like DB settings)
• Quick Wins:
  • Split up dspace.cfg already for 1.8?
  • "Local Overrides" for 1.8?
  • Investigate "Reload" button for Admin UI
• Mark - Concerns on how Configuration Service also gets updates (via Reload)

Topic 3: REST API?

• Briefly discussed. General agreement that we want to release a 'beta version' in 1.8.0 release.

DSpace 1.8 Discussion

• Patches planned to go in, owner, status
• Tim: Backup/restore from Admin UI
• Mark: Configurable Reviewer Workflow
• Refactoring ConfigurationManager/PluginManager? Some more impl
• Stuart: Some batch metadata changes
• Stuart: Global changes (Kim: with regexes!)
• REST API? We should complete/polish the spec and include
• Tim: EasyInstaller... plan has changed since inception (see DS-802), might not be ready
• Robin: SWORD Client. Yes, sort of.
• Richard J: SWORD2 server. Probably not.
• Richard R: Context Guided Ingest: Cautiously optimistic.
• Mark: Discovery enhancements. Lots of new code in the module, needs committing to trunk
• Richard R: Creative Commons licensing rewrite. Still on schedule for inclusion in XMLUI. Needs volunteer for JSPUI. Robin pointed out we need to keep the Edit Item stuff in sync with this. Bonus: Keeping license text in metadata makes it all searchable, etc.
• Would be nice to get volunteers for: the quick wins in DC refactoring, dspace config split-up. Will throw them into JIRA.
• New Curation tasks:
  • Richard R: Format identification, virus scanning
  • Stuart: Link checker