Versions Compared

Old Version 3

changes.mady.by.user Danny Bernstein

Saved on

compared with

New Version Current

changes.mady.by.user Ben Pennell

Saved on

Key

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

...

Attendees 

Agenda

  1. Announcements
    1. 4.7.5 Release Process begins
  2. 4.7.5 release - Planning for week of January,15th 2018
    1. Release manager - Osman Din
    2. Volunteers
      1. Testers
        1. Danny Bernstein
        2. Joshua Westgard
        3. Peter Eichman
        4. ?
      2. Someone to review 4.7.5 commit message for signs of missing documentation?

      3. Preparers of Module Release CandidatesModules

        ModuleWho?
        fcrepo-module-auth-rbacl

        Osman Din

        fcrepo-module-auth-xacml

        Osman Din

        fcrepo-module-auth-webac

        Osman Din

        fcrepo-mint

        Osman Din

        fcrepo-audit

        Osman Din

        fcrepo-webapp-plus

        Osman Din

        fcrepo4-vagrant

        Osman Din


    3. Resources:
      1. component release process tracker: https://docs.google.com/spreadsheets/d/1I_zTMxh2l2rf2wpafoTwhSTR5GZuEoaTcZmTKCI3xT4/edit#gid=1769378986
      2. Release Testing - 4.7.5
  3. Fedora API Test Suite... needing:
    1. Try the tool against an API implementation
    2. Code reviewing the tool... lots of low-hanging fruit
  4. Simple, synchronous query in Fedora
    1. What will it take to make this happen?
    2. Prior art
    3. Queries to support
      1. select ?s where {?s ?p ?o}
      2. select ?s where {?s <some-pred> ?o}
      3. select ?s where {?s <some-pred> <some-object>}
  5. Tickets requiring attention
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2520
      - Bethany Seeger to review?
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2659
      - Ralf Claussnitzer to explore?
    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2650
      - Ben Pennell to explore?
    4. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2544
       - on hold or close?
  6. 5.0.0 release
    1. API Alignment
    2. Pairtrees?
      Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2617
      - Danny Bernstein working this?
      1. Is tying Memento creation to modeshape a bad idea?
        https://github.com/whikloj/fcrepo4/blob/fcrepo-2617/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/services/VersionServiceImpl.java#L72
    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2632
      - Daniel Lamb working this?
  7. Beyond 5.0.0 - Areas of improvement
    1. Persistence?
    2. Journaling?
    3. Simple, synchronous query?
  8. ...

  9. Tickets In-Review

    Expand

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


...

  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

Danny B will be hosting next week's call

...

  1. OCFL call
    1. round robin survey of digital preservation at 6 institutions
    2. application independent disk/fs layouts
    3. [Danny B] key takeaways?
      1. covered tooling/specifications for standardizing file storage layouts
      2. effort from Stanford called "Moab" to group these tools, adds process as a layer on top, does versioning
      3. looking for common elements across institutions' digital preservation file storage strategies
    4. [Bethany] more "what are we doing" conversations useful
    5. [Bethany] what about distributed setups for serving the data?
    6. assume we are writing to disk
    7. "disk" is not fully specified
    8. scale wrt lots of content but not performance issues
  2. 1.b. think about using Slack more on the technical side of Fedora?

...

  1. [Carrick] it is on DevOps TODO list, should happen in the next 2 weeks (11-22 Dec)

...

  1. aim to get a RC out soon (this week or next)
  2. [Danny B] will review master on Monday for bugfixes that should be backported, cherrypick onto 4.7-maintenance
  3. do release off 4.7-maintenance branch
  4. look for unresolved bugfix tickets
  5. [Peter] can do RC testing first week of January
  6. [Carrick] can also RC testing first week of January, w/Avalon & Hyrax
  7. [Danny B] will put out RC next week
  8. [Jared] will assist
  9. will likely have to push out the Jan 15 release date
  10. review tickets for anything you want in 4.7.5 that is not yet

...

  1. [Doron] we hold DC Fedora Users Group twice a year
  2. had a smaller meeting at UMD to focus on architecture needs, upcoming needs, and a discussion of community status
  3. attendees: Doron, Esmé, Josh Westgard, Peter, Mohamed, Ben Wallberg
  4. NLM is just beginnning additional projects that require architecture buildout of enduser admin tools
    1. currently on F3, want to migrate, ran into issues before
    2. discussed Hyrax, Figgy, Valkyrie
    3. IR vs. digital repository, CMS-like feature that we don't need
    4. current model is to have large files on fs, external links in F3, would like to continue this model in F4
    5. would like F4 to support the "rebuild repo from fs" capability that OCFL promises
    6. NLM thinks F4 conceptually seems fine for modelling
    7. performance is still an issue in migration
  2. [Aaron B] F4 is more akin to a resource store rather than an object store
    1. provides primitives to model objects
    2. resources are managed and versioned individually
  3. OCFL defining object repo in the filesystem
    1. resembles the F3 object notion
  4. F4 provides tools to model objects, but not persisted and managed as a unit
  5. OCFL object members are collocated in some structure
  6. can F4 provide guidance on structuring resources in the userspace level?
  7. [Doron] looking for F4 to provide an object store
    1. want to publish RDF on the web
    2. fine with using multiple tools for object store and object publishing
  8. [Andrew] reflect on the API spec and imagine if your achitecture can use it
    1. related to the question of what services should Fedora offer
    2. not ideologically bound to the single subject restriction
  9. [Doron] where should LDP functionality live in the stack
  10. Fedora is not a triplestore, its an object store
  11. [Aaron B] "object store" is not defined anywhere
    1. F4 API describes resources, not objects
    2. objects is a high-level concept that is constructed through relationships
    3. left as an exercise for the user to define objects in terms a of linked data
  12. [Peter] F3 had built in object model
    1. need to start object model sharing and reuse discussion?
    2. [Andrew] PCDM was the first attempt at object model consensus
    3. [Aaron B] F4 not opinionated wrt object models
    4. [Andrew] mapping flexibility of resources on F4 to OCFL will be an interesting exercise

...

2. Release

  • Esme can help with Samvera testing
  • Osman will perform builds of module release candidates, unless he wishes to delegate
  • May be a challenging release given holidays

3. API test suite been running for a while. Has anyone had a chance to look at it?

  • Danny hasn't looked at it yet, but seems easy to use. Going to try it out this week
  • Interested in people trying it against other implementations, like Trellis and Cavendish.
  • Bethany: Is this considered done as far as the contractors are concerned?
    • Danny: Good question, the repo doesn't say how complete it is. Will check in with Andrew
    • Since the API alignment isn't complete, it shouldn't pass against modeshape impl yet
    • Code reviewing the tool?

4. Simple querying in Fedora?

  • Previously, cbeer had added this functionality, but it had been later removed
  • Is data structured for this in modeshape to be reasonably performant?
  • Mike: Was one of the agitators for this, opposed it being cut
    • Some stuff is inferred, some not directly searchable
    • What types of queries do we want to support?
    • What exceptions are we willing to tolerate?
    • Extension spec?
    • Is it okay if it doesn't work consistently on server managed triples, like date fields?
    • Just wants to be able to search dc:identifier. This would work, modeshape has an index that can be searched.
  • Esme: Valkyie, making a list of queries that the repository needed.
    • Needed queries
      • all objects of given type
      • Doing a search for dc:identifiers
      • They will come up with a list of queries they need
  • Danny: Would it be helpful at this point to fill out the list
    • Discuss some of the known limitations of modeshape's internal indices
      • Mike: Last modified date is across two fields. Might need to normalize way stored in fedora. Need to work out if this is needed
      • Esme: Types and containment triples are harder to make searchable
      • Search for non-server managed triples that are directly assigned are easy.
      • RDF type are not stored in the index modeshape maintains. That is inserted into responses.
      • Use case: find all objects of a type in order to do bulk object on it
      • Can't search on fcr namespace and ldp namespace. Might be okay to not support those, but it would be weird to have an LDP server that didn't support it
      • Could add support for this in after if there is demand for it
  • Mike will start document to gather first pass at known limitations of implementation and requirements

5. Tickets requiring attention

  • 2520
    • Bethany would like more feedback on what expectations are for mimetype
    • She will take another look at it to try to work through what the validation issue is
  • 2650
    • Bethany will take a look
  • 2544
    • there was a work around for that, using a different accept type. No one has strong feelings that it shouldn't be closed, so will make a note on ticket
    • Josh - as a larger strategy, this is something we will need to address
    • Paging mechanism is problematic in RDF rest api, but something we will need to deal with
    • Work around okay for now, but many members issue needs to be addressed in future implementations

6. 5.0.0 release?

  • Need to wrap up creation of mementos, one of the last main things to bring into alignment with spec
  • Pairtrees - Do we want to remove them?
    • Peter (?): In favor of removing them
    • Significant bit of internal work to hide them at fedora level, while still might need them in jcr
    • Danny: In doing away with pair trees, they would still be around internally
    • Peter: Need them, otherwise performance tanks after about 1000 children
    • Esme: Might want to look at Aaron Coburn's Appletree implementation. Takes checksum, makes path based on that. Includes hiding internal paths
    • Esme: would involve renaming everything in your repository, so it would need to take place as part of a major version change
    • Esme: Would either need migration tooling, or tooling for enabling/disabling the feature
    • Danny: how hard would a migration tool be to created?
      • Esme: Would be complex, but possible. If you have been using auto-generated UUIDS, could go through repo and remove pairtree.
    • Danny: interesting proposal, do we need community feedback?
      • Yes, more feedback would be good.
      • Esme: to write up brief description of proposal for fedora-tech
      • For discussion in new year

Action Items

Action: Check in with Andrew about completeness of the test suite

Action: Mike will put together a document with first pass at the feature set.

Action: Esme to write up brief description of proposal to remove pair trees for fedora tech

...