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 

• Andrew Woods
• Nick Ruest
• Aaron Coburn
• David Wilcox
• Osman Din

• Esme Cowles

• Daniel Lamb
• Michael Durbin
• Kevin S. Clarke 
• Stefano Cossu
• Yinlin Chen
• Nianli Ma
• Andy Wagner

Agenda

1. Islandora/F4
   1. Feb. 27, 2015 Fedora IG meeting minutes
   2. Project update
2. Fedora GitHub organizations: fcrepo4, fcrepo4-labs, fcrepo4-extras??
   1. What does each GitHub organization mean?
   2. Where should the existing repositories in fcrepo4 belong?
3. Fedora 3 to 4 Upgration
   1. 2015-03-04 Migration Utils Discussion
   2. Related work/issues
      

      type	key	summary	assignee	reporter	priority	status	resolution	created	updated	due
      Unable to locate Jira server for this macro. It may be due to Application Link configuration.

   3. Schedule next call
4. Data modeling consensus: naming and hosting
5. New JIRA tickets

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

6. ...

Minutes

1. The Islandora/F4 priorities going forward will be focused on the migration side of things.  Also expect to be fleshing out a batch of tickets over the course of the next week so more developers can get involved. There are two links in the agenda for those interested in finding out more about the effort's current status.
2. The core project repositories live in fcrepo4. There are other systems and projects that aren't core to the repository. The question of where these repos should reside has been raised.  Some examples of this type of repo include the indexing modules, some implementations of camel routes, and the ontology repository.  The implementation of having these in fcrepo4-labs is that there is a possibility that they will be moved into the core fcrepo4 repository.  This may not always be the desired path (for things that use the Fedora repository but aren't core modules to it).  There is a proposal to add a new organization, fcrepo4-extra, for optionals that are not necessarily experimental, but also not intended to be a part of the core and supported in the same way that the core modules will be. There are some components that are in a grey area (like the authentication modules) until we refactor a little more. It may be okay for them to sit in the main fcrepo4 repository until we develop more clarity in the relationship between authorization and the repository. Also discussed was fcrepo4-build-tools.  It's not public facing, but a necessity for developers.  It may be in the future that it's folded into the main codebase.  There were some peculiarities of the build machinery that required it be separate, but this may no longer be a limitation. The answer seems to be that it would be good to split out components into fcrepo4 and fcrepo4-extras. How does this impact the release process?  Which modules should be included as a part of an official release?  There are some things that would go into fcrepo4-extras that would be helpful to include them as a part of an official release. Perhaps being in fcrepo4-extras (vs. being in fcrepo4-labs) indicates a level of inclusion (in releases) and support (e.g., more than one person uses it). Or, perhaps there is a greater level of granularity here: another space in addition to fcrepo4, fcrepo4-labs, and fcrepo4-extras.  Fcrepo4-tools? Tools would be things really needed as a part of the release, just not a part of the core repository. The main issue is what responsibilities are being accepted (regardless of what we name the space).  Will there be a release of every project in extras for a release of the core repository? Adam and Andrew were the most vocal on the call and Andrew suggests that we take it to the list for more consensus. Nick commented that, whatever we decide, we need to communicate it clearly so there isn't confusion about what the various GitHub repos represent.
3. Fedora 3 to Fedora 4 upgration... there are currently three paths to upgration: Penn State and Adam Wead's which is Hydra focused, Islandora's generalized Camel solution, and Mike Durbin's Fedora-level utility that works from FOXML on disk.  A meeting happened between the three efforts (or two of them?) and some tickets came out of the meeting.  Mike updated us that his and Danny Lamb's work have merged (so just two upgration paths now).  Both Hydra's and the UVa/Islandora's work will continue independently since they're using different tool sets (with different sets of dependencies, etc.)  Then we talked through the outstanding tickets related to Mike/Danny's work to discuss how they should be handled (by whom, when, etc.) There was some discussion of using the fcrepo4-java-client or Camel as the connector to the repository. There is a question of how we'll use Camel to facilitate the migration. After some discussion, there may be one or two tickets that could be assigned to someone else (someone on the current or a near future sprint, for instance).
4. We didn't get to agenda item number four.  Those that are interested can tune into IRC for continued discussion of this topic.,