Time/Place

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

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• 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 

• Andrew Woods
• Nick Ruest 
• Michael Durbin
• Unknown User (escowles@ucsd.edu)
• Yinlin Chen
• David Wilcox
• (Please add your name)

Agenda

1. proposed fedora 4 fcr:versions changes
2. RELS-EXT namespace discussion
3. Post-holidays priority features
4. LDP paging
5. Future focusing

Minutes

1. Discussion around Michael Durbin's proposal.
   1. Agreement for items 1a, 1b, 3, 4, 5 of the proposal.

   2. It was decided not to do number 2.

   3. Instead of 2, it was decided to spend the next day or so trying to clean up as much as possible, and add a notice saying this functionality is likely to change.

2. Follow up discussion of the RELS-EXT namespace discussion from Hydra folks with the collapse of the namespace
   1. Unknown User (escowles@ucsd.edu): all is fine.
3. Release plans
   
   1. Monday, Tuesday, Wednesday of next week reserved for testing release candidate
   2. Thursday, release of the 4.0 production
4. January - June 2015
   1. Migrations (3.x -> 4)
   2. Bug fixes: Addressing issues that we currently not aware of
   3. High priority features
5. Feature discussion
6. 1. Batch operations
   2. Authorization
   3. Hydra perspective
   4. 1. what is outlined should satisfy the Hydra needs
   5. Islandora
   6. 1. Will know more once project get started in January
      2. Generic Islandora Fedora 3.x to 4 migration scenario
   7. Performance issues
   8. 1. autopath generator should address the issue
      2. deeper more balanced tree
      3. Usability issue with including the children
   9. Clearly defining our APIs and aligning them to existing standards
   1. 1. 1. CRUD API
         2. Versioning API
         3. Locking API
      2. Auditing