Versions Compared

Key

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

...

Attendees

  1. Andrew Woods (out)
  2. Danny Bernstein
  3.  Ben Pennell Aaron Birkland (star)
  4. Jared Whiklo  (star)
  5. Aaron Birkland
  6. Peter Eichman
  7. Bethany Seeger
  8. David Wilcox
  9. Jon Roby
  10. James Silas Creel

Agenda

  1. Announcements

  2. Fedora Design Meeting Debrief
  3. Next Steps:  Sprints
    1. Fedora 66  - https://doodle.com/poll/4am7iqptx5arb4ce
    2. Import Export
    Upcoming 2019-02 Fedora Design Meeting
    1. Use Cases
    2. Topics
    3. OCFL considerationshttps://doodle.com/poll/cshgyw3wr87ivckf
  4. Way forward on Camel Tooling:
    1. Stay the course (fix karaf) or setup to run without karaf
      1. if run without karaf
    In-Review tickets:
      1. , what are our options?
    1. vagrant and docker


  5. Expand

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


  6. 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


  7. 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


  8. 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. Fedora design meeting was successful. Further debrief to come. 
  2. James Silas Creel indicating that the CAP system has changes and documentation to make it work with alternate authentication systems. These will be ready for a forthcoming release.
  3. Camel toolbox is not working and seems to be problematic to move to work with Fedora 5.
    1. Some time needs to be spent on how the parts still work together.
    2. If we are moving to a deployable jar then the structure should considered to allow.
    3. Jared Whiklo will continue to work on the fcrepo-camel-toolbox in Karaf, but a implementation as a JAR/WAR could be.
    4. https://github.com/fcrepo4-labs/fcrepo-camel-webapp - an old wrapper for the fcrepo-camel that allows you to compile in whichever options you want in a single WAR file.
    5. Bethany Seeger mentioned that at Amherst they are working with Gradle and maybe there are simpler fixes there.
    6. Aaron Birkland suggests that each executable component would result in an executable JAR, then each could be deployed separately and connected as needed.
  4. Clear resolution on how to map OCFL to LDP model. Review the Fedora 6 sprint document and comment on the page and/or ask questions in Slack.
    1. Transactions are expected to remain, but there is some desire to not have the API change. Perhaps using the sidecar transaction specification for the time being.
    2. Aaron Birkland has written up a high-level summary for JHU which might have people understand the decisions - https://docs.google.com/document/d/1-VXJ3JjtWWUooxCWegptWAUwvCp1SYjgzqZI9a1r45c/edit
  5. We need to clarify the plan for transactions:   no change to current interaction approach or do we intend to ratify and align the codebase with the side-car spec?
  6. Announcements
    1. OCFL released, minor updates, beta not likely to change much
      1. Peter: Discrepancy between terminology section OCFL object and in section 3, it seems to imply in not-normative text that the id be a URI, then later it is a "should" be a URI. Should either not say that it is a URI, or make it a MUST in the normative section about inventories. Will raise in the OCFL channel
    2. 5.0.2 release went well.
  7. Travis svg PR
    1. Going ahead and merging, difference isn't too obvious
  8. Upcoming design meeting
    1. Old and new use cases distilled into short list of high level use cases
    2. What is Dynamic scalability? Avoid performance loss from scale. Are we intending to include clustering/sharding concepts
    3. John Hopkins will be adding a bunch of use cases soon.
      1. Includes object validation use cases, such as verifying resource requirements and that datastreams are present
    4. Andrew: How can we facilitate fedora caring about the shape of the objects?
    5. Peter: https://www.w3.org/TR/shacl/ could view this like an ACL situation, link headers to identify constraints doc for container and children, have a service which goes through and validates resources against this.
      1. Could be an on-request service, or on update (but would be challenging since it may take multiple requests to reach a valid state)
      2. John Hopkins would be okay with on-request
    6. OCFL, think about how to structure OCFL if every resource mapped to an OCFL object.
  9. Status of fcrepo-camel-toolbox updates
    1. Has there been any intent to move away from OSGI into standalone jar file? There had been previous discussion, hadn't come up recently.
      1. Ben has been using it in a webapp in a jetty container - will check to see if anything relevant from this approach
      2. Would be helpful to have a version that is a standalone jar, and a wrapper on for it to put in OSGI
      3. Jared going to continue looking at this.
  10. Import/export
    1. Andrew has been using set from a sprint a while back
      1. Imported with fcrepo restore, put 16000 resources in. Then exported it, then ran verifier over this set.
      2. Blew away repo, put repo in relaxed mode, did the import which worked, then ran the verifier which failed, some missing rdf:types
      3. ArgParser class line:546 in master has an curly bracket issue in formatter
      4. PR has a lot of commits, andrew doesn't appear to be able do a local squash.
        1. It is a difficult PR review, intent is to do some more testing then get it merged in
        2. Redirect to a 4.x maintenance branch, Andrew is going to create that branch.
        3. Pull out some improvements that are applicable to 5.x
      5. Ben might try fcrepo backup on hyrax repo, see if its possible to share
  11. Revisit Next Generation Repositories
    1. Important that we, in the Fedora community, be involved in next generation repos conversation
    2. Identify which aspects are appropriate or not for Fedora
    3. People are encouraged to give it a read, provide feedback
  12. Fcrepo-1889Peter will take a look at this, run tests, get an idea of where we stand on this issue.
  13. Actions
  •  Peter Eichman  is planning to work on documenting UMD's fixity check system on the  Fedora in Production: Case Studies wiki page. Peter Eichman  will take charge of the fcrepo-camel/fcrepo-camel-toolbox release process.
  •  Peter Eichman :  will complete review of 
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-1889
     when Jared Whiklo  is finished with the above.
  •  Danny Bernstein will test the updates to Ben Pennell 's PR for 
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2459
  •  Ben Pennell : to dig up local camel-toolbox code that deploys as a webapp into Jetty... instead of OSGi
  •  Jared Whiklo : to take the baton on 
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2787
  •  Peter Eichman : to review 
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-1889

...