Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Time: 11:00am Eastern Standard Time US (UTC-5)
U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
- Once on the call, enter participant code 2257295
IRC:
- Join the #duraspace-ff chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #duraspace-ff on irc.freenode.net

Attendees

Agenda

Back-porting bug policy, redux
1. DSpace policy
2. Ubuntu policy
Blank nodes plan
Migration tooling plans
New JIRA tickets
Audit Service design
Islandora
1. Proof of concept is now in the Vagrant build
2. Documentation (mkdocs)
3. Upgration
4. Interest group meeting, February 27, 2015
...

Minutes

Back-porting bugs
- Other projects:
  - dspace security patches go back 3 releases, bug patches are a best effort, sometimes going back one release
  - ubuntu has long-term support releases that are supported for 5 years
- What is our goal for a policy
  - Michael Durbin brought up that backwards compatibility should be considered
  - Andrew Woods indicated that our release policies (minor releases are non-backwards compatible, point releases are backwards compatible)
  - Michael Durbin suggested not backporting to point releases ever
  - Unknown User (acoburn) thought that for minor releases there was no need to backport
  - Unknown User (escowles@ucsd.edu) brought up the point that as the installed base grows, there may be prevalence of adopters who are more hesitant to keep up with the latest version.
  - Andrew Woods observed that perhaps we should wait to establish a policy at this time
  - Unknown User (escowles@ucsd.edu) said that we're in "early adopter mode" and don't support backporting, but later we may move to a more stable mode where we support the last 2 minor versions.
    - there appeared to be a consensus around this, and making a statement to the community about this including a definition about major, minor and point releases.
    - someone will make this statement to the community
Blank Nodes
- seems like this proposal will pass the vote (no negative votes so far) and the idea has been clarified
Upgration Tooling Planning
- Hydra-specific migration tooling exists and is great for Hydra and may be extenstible for non-hydra
- a migration tool collaboratively developed by Unknown User (daniel-dgi) and Michael Durbin to support generic migration
  - next sprint may ideally be able to support some work on that tool
  - Unknown User (daniel-dgi) is wrapping command line tool in Spring
  - Michael Durbin is working on higher levels of abstraction for migrator plugins
- Andrew Woods proposed a goal of having a bare-bones camel connection integration
  - would the command line program, kicked off manually send messages to a camel web application that would send things to fedora 4?
  - Unknown User (acoburn) and Unknown User (daniel-dgi) volunteered to be supportive of those new to camel doing development during the next sprint
  - Unknown User (daniel-dgi) suggested we collect a test assortment of objects for testing (collection, simple object, something like a "book" with child objects with datastreams)
  - Michael Durbin and Unknown User (daniel-dgi) will get some tickets together by Wednesday and would be willing to go to the sprint planning meetings at 11AM Monday or 2PM Wednesday
JIRA Tickets
- we reviewed the recent tickets, it was pointed out that you can subscribe to a weekly summary of them
- we discussed the "status" property and it was proposed that we tentatively move forward with deleting the fcrepo property and use the old fedora 3 predicate.
Islandora update was abbreviated, but it was suggested that those interested should attend the meeting... but should RSVP in case they exceed the capacity of the current call technology