June 2012 Agenda and Notes

Owned by Bill Branan
Last updated: Jun 16, 2017Version comment
1 min read


Logistics

  • Meeting Location: University of Virginia
  • Clark Hall (building 11) at 291 McCormick Rd, Central Grounds UVa or section D4 on this map
  • Dates:Wednesday June 6 - Friday, June 8
    • Wednesday: 11 AM Assembly, 11:30 AM start time (Clark Hall/Brown Science and Engineering Library, 148)
    • Thursday: Steering 8:00-9:30 AM, Partner's Meeting starting 9:30 AM, end 5 PM (ClarkHall/Brown Science and Engineering Library, 148)
    • Friday: Partner's Meeting starting 8:00 AM, wrap-up 5 PM (Clark Hall/Brown Science and Engineering Library, 148)

Attendees

Partners' meeting

  • Institutional Updates
  • Preservation and Fedora
  • Fedora Development Roadmap & how it relates to Hydra
  • APT & DPN
  • Fedora performance, scalability
    • Scholarsphere
    • MediaShelf Fedora sharding project / benchmarks
  • Date and venue of next meeting (September)? ND? RockHall?
  • New Release Managers
  • Should the website have more 'up front' info about software releases? (See Islandora.ca)
    • which website?
  • UI code and the Hydra stack
    • How do *you* create a new hydra head?
    • Splitting out UI code
      • how feasible is this
      • who will maintain it?
      • how maintain integrity of full stack?  (i.e. if changes to a part of the framework breaks the UI)
  • is there enough overlap to warrant an institutional repository hydra head?
    • is there enough commonality?   data, modeling, ui needs, etc.?
    • make this the demo instance?
  • demo instance
  • Documentation checkup (non-technical)
    • what is missing?  what gaps exist?  how will we fill them?
    • are the different web site purposes clear?  (projecthydra.org, duraspace, github ...)
    • can folks find what they need?  (newbies, wannabes, explorers, etc.)
    • Related Jira issues, aka "The Hierarchy of Promises"
  • Tech doc basic requirements  (e.g. "documentation must be sufficient for newly adopting developers to be able to ...")
  • OR12 planning
    • Talks and their presentation (calendar?)
      • Workshop
      • Hydrasphere FUG talk
    • Table/stall for demos and as focus for conversation
    • Social?
  • Code license review
  • Software/hardware stack exchange of information (to be carried on in the developers meeting as required)
    • Where is everyone with the different software components (i.e., what is the stage of implementation for each site)?
    • How can local institutions best keep pace with keeping local apps in sync with latest developments?
    • What issues have arisen in upgrading (and could be useful learning for prospective partners)
    • What hardware stack are partners using, and what pros/cons have been identified in these choices?
  • Fall webinars for DuraSpace
  • HH5 update and planning
  • Hypatia update (if Ben A. is attending)
  • ScholarSphere demo/update
  • HydraCamp
    • 2012 details
    • potential 2012 attendees/institutions
    • evolving the model, expanding attendance, etc.
  • Repository service management: support flows, etc.

Partners' meeting - developers

  • Technical Release planning
    • Hydra-head
      • 4.1+
        • Will have all the code deprecated
      • 5.0
        • Will have removed deprecated code in Hydra-Head
      • 6.0
        • No plans
    • ActiveFedora
      • 4.x
        • Needs deprecations brought up to current standards.
      • 5.0
        • Will have deprecated code removed. (MetadataDatastream, ask Adam Wead (and the list) whether he cares)
    • OM/Solrizer
      • 2.0 (not sure if anyone will actually tackle this. Might be cbeer)
        • Optimized documents (fewer fields created by default)
        • Insert and remove node with templates
        • Separating concerns
          • Addressing xml nodes
          • creating a solr document
        • Proxies can't override term indexing attributes (Ben will write a ticket for this)
        • Proxy vs Ref is confusing
        • More transparency to Nokogiri (path vs xpath)
  • Deprecation/Removal code practices
    • How do we decide what to deprecate?
      • TOMORROW
    • How are we deprecating (syntax) 4.1
      • What version it was deprecated in (as code comment).
      • Target removal release.
      • extend Deprecation
      • deprecation_deprecate :method_name (For each method that will be removed)
      • YARD @deprecated documentation 
      • Classes/modules do not need any deprecation warning, so long as all the methods are deprecated
      • Deprecation.silence(ClassName)
        Unknown macro: { deprecated_method_call() }
        on our code using deprecated methods.
    • When do we deprecate?
      • DECIDED: When we deprecate functinoality in a minor (e.g. 4.1) we can remove it in the next major release (e.g. 5.0)
  • which ruby platforms are we supporting?
    • Survey the list -  What version of ruby is everyone deployed to?
    • can we NOT insist on a particular rubygem version
      • YES - this was because of a bug.
    • Can we get rid of .rvmrc
      • YES - have your own .rvmrc  (don't check it in to git)
    • Git rid of Gemfile.lock (in AF)
      • YES put in the .gitignore
    • Recommendation: Keep Gemfile.lock at app level
  • Splitting out UI code
    • how?
      • Whiteboard exercise for tomorrow
    • Out-of-the-box Hydra Heads?
    • Hydra-as-a-framework helpers
  • Documentation
    • what is missing?  what gaps exist?  how will we fill them?
  • Hudson fun
  • Ruby autoload is going away in 3.0 (or at least deprecated)
  • OM roadmap
    • "insert node", "remove node" approach per Hydrus
  • Solrizer default behaviors (strategies for making Om terminologies less verbose in solr)
  • Security - Datastream-level permissions
  • The "depositor" field, apply_depositor_metadata, and the deprecated properties datastream
  • How to stay on the bleeding edge without bleeding out
    • Was a bug that HH was pinned to a specific version of AF.
  • Technical Documentation needs
  • HYDRA-804 What is necessary for creating a hydra model?
  • Test coverage
    • what is missing
    • how do we fill gaps
  • Course reserves
  • Wrangle Jira tickets older than a year
  • HYDRA-696 Ben worked on this.
Additional issues for developers brought up at the June 4 committer's call
  •  

Steering Group

  • where should Hydra be in one year? Two years?
  • December meeting. Steering Group only? Where?
    • discuss with Partners. Dec Partner meeting valuable?
  • Protecting the Hydra brand. Trade mark process $5-10,000 ???
    • talk to lawyers
  • Hydra Community Use Cases
  • Hydra Meetings - SG, Partner and Developer Meetings
    • Sept 2012 and beyond:
      • Name should allow for mix of SG, partners and developer activities "Hydra Meeting"
      • Increased use of multi-track
      • Demos limit to twice per year at multi track meetings
      • Engineer Code Swap annual hackfest type meeting is desired (e.g. DIL or ScholarSphere into other IRs) Winter prior to Cod4Lib and DevConX would be good
      • An annual SG retreat to focus on strategic direction would be useful
    • Winter Meeting, Jan San Diego
      • Co-location with developers would allow combined dinner discussion
      • Time for SG to step aside and take a fresh look at Hydra direction
      • smaller number of people
      • visioning retreat
    • Overall
      • Winter Jan Developer & SG Retreat
      • Spring Mar LibDevConX & Hydra MultiTrack
      • Summer Hydra MultiTrack potentially co-located with OR?
      • Fall Hydra MultiTrack