Versions Compared

Old Version 6

changes.mady.by.user Bethany Seeger

Saved on

compared with

New Version 7

changes.mady.by.user Ben Pennell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2520
      - 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?


    2. Expand
      titleIn Review...

      Jira
      serverDuraSpace JIRA
      jqlQueryfilter=13100
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  4. ...

...

  1. Please squash a bug!

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13122
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  2. Tickets resolved this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13111
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  3. Tickets created this week:

    Expand
    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13029
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Minutes

1. 4.7.5 release

  • Branches have been pulled together, entering release candidate review period, targeting February 5 for release
  • Release candidate is out, ready for release testing, looking for signups
  • Reaching out for someone to do windows testing
  • This should be a backwards compatible release, so it would be helpful if someone could drop the new war file on top of existing data.

2. 5.0 release

  • Primarily focused on API alignment
  • Conversations within committer group to work out what exactly is in scope for this release.

Release date

  • Keeping in mind the calendar that the API specification itself is working around
  • Back and forth in terms of implementations of spec and writing of spec.
  • Want to have two implementations of the specification as part of releasing it. One is the modeshape 5.0 implementation.
  • Intent is to finalize API by April, which would imply that there are implementations at that time.

What are we lacking?

  • Memento
    • Jared - would like more people to look at this.
    • Danny will be helping review this and get it over the hump
  • Webac is fairly close.
  • Page with all the test results from comparison: https://wiki.duraspace.org/display/FEDORAAPI/Fedora+API+Spec+and+Delta+Document+Verification
  • Compatibility test suite - which is intended to be completed around April. Roughly a bit over halfway done, but needs to be verified.
  • CRUD operations are pretty close, just a few things remaining

Looking for point people to verify alignment

  • Memento - Jared and Danny
  • CRUD - Jared
  • Webac - Aaron and Peter(?). There are testing scripts, including Authz tests.
  • Fixity - Bethany
  • Messaging - Aaron

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:

  • First sprint: Finalize alignment of various components
  • Second sprint: tie up loose ends prior to release

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:

  • Keep configuration how it is
  • Use Apple Trees instead
  • Simplify config so it doesn't create pair trees, but smooths the path to creating pair or apple trees by the client

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

  • 2656 - local-file uris. Needs some more review and the conversation on the mailing list is part of it
  • 2636 - Can disable versioning of children through a modeshape. Andrews inclination is to close the ticket as no-fix.
  • 2604 - Audit of messages being emitted, no need for a PR. Keeping it around for when doing the audit of messaging implementation. Leave in review and close when messaging is where we want it to be.
  • 2591 - Changing interaction models for containers. Andrew is suggesting that current behavior stay the same, aka if you don't specify a model then you get a basic container. Cannot change the model after creation. Reopen ticket and assign it to API spec.
  • 2544 - Been back and forth about time to first byte, Maryland has had the same issue. Can it be closed based on decisions Peter has made? Peter will take a look.
  • 2520 - Reopen and assign to Bethany. Move check up to the http layer. Where did we get agreement from Ralph from? Going to circle back with him.
  • 2459 - import of verisons. put on hold for more discussion
  • 1786 - inclined to reopen and put in API alignment epic