\\ h2. Logistics * *Meeting Location: University of Virginia* * *Clark Hall (building 11) at 291 McCormick Rd, Central Grounds UVa* or section D4 on this *[map|http://www.virginia.edu/webmap/GMcCormickRoadArea.html]* ** [C'ville Accommodations] * *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) h2. Attendees * [*Attendee Roster/Registration*|Attendees list]\\ h3. 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" *** [HYDRA-507|https://jira.duraspace.org/browse/HYDRA-507] *** [HYDRA-509|https://jira.duraspace.org/browse/HYDRA-509] * 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. h4. 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 *** {color:#333333}deprecation_deprecate :method_name (For each method that will be removed){color} *** YARD @deprecated documentation *** Classes/modules do not need any deprecation warning, so long as all the methods are deprecated *** {color:#008080}Deprecation{color}{color:#333333}*.*{color}{color:#333333}silence{color}{color:#333333}(ClassName){color} { deprecated_method_call() } {color:#333333}on our code using deprecated methods.{color} ** 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|https://jira.duraspace.org/browse/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|https://jira.duraspace.org/browse/HYDRA-696] Ben worked on this. h6. Additional issues for developers brought up at the June 4 committer's call * h3. 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 |