Time/Place

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

Attendees

Agenda

  1. 4.7.5 release - Planning for week of January, 15th 2018
  2. Fedora 5.0.0
    1. Release date target
    2. PairTrees / AppleTrees
  3. Tickets requiring attention
    1. - Bethany Seeger
      1. Any more discussion needed here?  If a mimetype goes in, it should come out at the very least. 
      2. Bethany Seeger suggested an alternative implementation: https://github.com/fcrepo4/fcrepo4/pull/1272#issuecomment-353173508 that would move the check closer to the HTTP layer
      3. Ralf Claussnitzer: Sounds reasonable. HTTP servers should respond with BAD REQUEST if given an unparsable mime type string.  Should the repository layer check again?



  4. ...

Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

1. 4.7.5 release

2. 5.0 release

Release date

What are we lacking?

Looking for point people to verify alignment

Sprints?

Approach was to see how far we got before the holidays. Not a lot got done in the meantime.
Andrew: at a minimum, set up at least one sprint to finalize things
   Would another earlier sprint be useful?
Jared: just pick a time, can probably get time allocated. It is an effective way to clean up small chunks of work, get testing done
Peter suggesting a february/march sprint is a possibility
Most people would prefer a sprint versus doing adhoc work
Aaron: With a date for a sprint he can at least ask.
Andrew: inclination is to do two sprints:

b. PairTrees / AppleTrees

Andrew: our current approach is not buying us anything in terms of performance (post creates interim nodes). The logic in fedora basically traverses over pair trees to find the children, so that eliminates benefits.  Since the pair tree elements are there, you could write logic that doesn't automatically traverse

Peter: ended up going with requesting N-triples to get all the objects for a container, since the time-to-first byte was sufficient here to not cause timeouts.  Didn't feel comfortable relying on pair trees as a retrieval/paging feature
Andrew:original intent was a partitioning mechanism, so that when making a request you wouldn't get more than 256 children to keep responses quick.  Very quickly got feedback from people in the user interface that it was virtually impossible to find specific children when needing to drill down.

Esme: adding a Prefer header to manipulate that behavior would be nice. Effectively, header to turn off retrieving pair tree children
Andrew: haven't tried that yet, but is only a small piece of code to remove the pair tree children.  What is the ideal behavior for 5.0?
Esme: going to make a wiki page to outline the three options:

Bethany: Aaron C. mentioned blank nodes don't work well with Apple Trees, would want to check to make sure this is compatible
Andrew: Copy and move operations will not work with Apple Trees. Messages as they are currently emitted would not suppress the pair tree structure
Bethany: When 5.0 is put out there are ripple effects for the camel-toolbox since the messaging will have changed.
Aaron B: Does the apple/pair tree question have relevance to the import/export machinary that people might use to go from 4 to 5?
It sounds like we have one scenario where if we don't have pair trees in fcrepo5, would the intermediate nodes be 404s?
Is there a scenario where pair tree uris might be illegal in fcrepo5?
Esme: Thinks they would migrate over, but creating new uris might be different.  Definitely are questions about how behavior would need to be different in fcrepo5 when migrating from 4.
Aaron: Along those lines, what about someone migrating from fcrepo4 to a different fedora impl?
Andrew: import/export tool should help with that sort of migration. Decision of 5.0 should be independent.
Aaron: impls without concepts of pair trees could be an issue.
Esme will put together that wiki page to contain the discussion

3. Tickets requiring attention:

b. Tickets in review