Page History

...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Minutes

1. fcr:fixity endpoint
   1. discussed in fcrepo leadership
   2. Andrew: fixity as a test case that highlights need for clear feedback and communication channels between community, tech, leaders, and committers
   3. tech thread and leadership thread: do we want fixity service? yes
      1. open discussions about resources needed to maintain this feature
      2. if it is important for community it should be in the spec
   4. github issue: https://github.com/fcrepo/fcrepo-specification/issues/373
      1. open question about whether there could be an additional header to RFC 3230 that returns a success/failure status
   5. deprecation status?
      1. should it be in the core? seems to be a ciritial preservation feature
      2. Peter: fine with moving this to a header if we can get a status header a la Andrew's GitHub issue
      3. Josh: agrees that this needs to be a core responsibility of Fedora
         1. external content wrinkle
         2. external content is beneficial to large content repos
         3. external content is not covered by current fixity
         4. Josh has been looking at extensions to check fixity for external content
      4. Bethany: copy and proxy will check fixity on new external content implementation; only redirect is left out
         1. could use some further testing
         2. Josh: how does it perform?
   6. Andrew: interested in the header approach
      
      1. Peter: can we use a link header for this?
   7. Bethany: are the spec writers talking about this?
      
      1. Andrew: no, this is why github issue has been added
   8. Jared: where do we store the digests? have to persist check
      1. external content is a bigger concern for performance
      2. redirect seems hard to implement
      3. Jared: need to store checksum where it is always available; similar to MIME type
      4. Peter: sounds like a server-managed triple?
         1. Bethany: store as a property on the binary itself?
         2. Jared: if server-managed triple do you return it in your graph?
         3. Andrew: these seem to be issues in general about server-managed triples
      5. Jared: the reference implementation should only implement the spec
         1. adding additional features to reference implementation means the spec is lacking
         2. Josh: API-X as an alternative to core?
         3. Jared: should also be discussion around the github issue
         4. if it is a vital part of Fedora then it should be in the spec; discuss how (MUST/MAY/SHOULD?)
         5. Andrew: agrees essential features should be in spec
      6. fixity service only answers the question of "is this resource what you think it is?"
         1. "self-healing repo" feature is out of scope; current/future fixity service does not address the question of "what next?"
         2. Jared: interested parties should speak up in comments on the github issue
         3. Bethany: we should send a follow-up email on the original thread(s) that highlights the github issue
      7. Doran: seems to be two issues: a) should we have the service? b) how should it be implemented?
2. getting to 5.0
   1. PR for external content went in this week
      1. handful of issues to check
      2. any other 5.0 developments last week? no
   2. documentation updates
      1. ongoing effort
      2. Andrew: note the red X's indicating pages that need work; reviewer should add notes about what kind of changes are suggested
      3. Josh: can contribute to documentation effort
         1. are there instructions about what should be done for updates? procedure?
         2. Bethany: just go in and edit the 5.x versions of pages
         3. if you work on a page work on the whole page, or note where you stop
      4. Kevin: reviewer status?
         1. Peter: use the star
         2. Bethany: do we need to track who reviewed?
         3. Kevin: add reviewer name in the "Who?" column
   3. another sprint
      1. timeframe: July? maybe 2 sprints
      2. Andrew: did a Doodle go out
         1. no one seems to have seen a Doodle
         2. action: send out a Doodle to get a timeframe (Andrew)
      3. Andrew: 2 sprints sound good
         1. earliest/latest dates? July-October
3. messages emitted
   1. what do we need to do to move FCREPO-2604 along?
   2. Andrew: Kevin's point: does a change to a inbound reference warrant a message?
      1. if yes, close ticket as complete
      2. if no, need more work
   3. Josh: inbound reference shouldn't change the state of the target resource
      1. Bethany: agrees
   4. Kevin: implication is just for resources that need to know that inbound references changed
   5. Bethany: can we distinguish between different kinds of changes
      1. Andrew: we don't track individual properties, so might be weird if we track this but not individual properties
   6. Josh: could this be useful for indexing
      1. Peter: does this have enough information to be useful for indexing
   7. Bethany: puts the work on the client?
   8. Jared: can we use different ActivityStream type for these type of change messages?
      1. there are object/link type relationships
      2. makes for easier filtering
      3. Bethany, Peter: agree
      4. Andrew: requires Fedora to know that a change is due to an inbound reference
      5. action: new JIRA ticket to explore nature of changes before messages are emitted (Jared)
4. fcrepo cloud migrator tool
   1. Carrick: can do an overview next week
   2. has anyone tried ingesting edited Turtle? not yet
   3. Peter: looks like RDF 1.0 to 1.1 conversion issue (explicit to implicit string type)

Actions

•  Look at fcr:fixity in JIRA - creating a ticket and look at options
•  See if possible option for fixity checking could be an API-X service
•  Talk to API Spec group about returning fixity check result as an additional header, returned on 'want-digest'.  
•  Peter Eichman - See how tightly bound our current implementation is to modeshape, in regards to the fixity endpoint.  Can look at at the end of next week.
•  Message to list-serve to see who might be using fcrepo-java-client outside of fcrepo-camel
•  Jared Whiklo - New JIRA ticket to explore nature of changes before messages are emitted
•  Andrew Woods - Send out a Doodle poll to get a timeframe for next 5.0 sprints (July-October dates)