This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Audio/Video Conference Link: https://duraspace.zoom.us/my/fedora
+1 408 638 0968
+1 646 876 9923
+1 669 900 6833
812 835 3771
Join fedora-project.slack.com on the "tech" channel
- Danny Bernstein
- Peter Eichman
- Ben Pennell
- James Silas Creel
- Bethany Seeger
- Yinlin Chen
- Aaron Birkland
- Jared Whiklo
- David Wilcox
- Release Candidate 3
- Release candidate
- Release Testing
- Tickets and Pull Requests
- Backup / Restore: deprecated in wiki (as of 5.0) and code (as of 4.7.1)
- Copy / Move: deprecated in code (as of 5.0), not in wiki
- Non-Specification features
- Fixity service
- Release Testing
- Ecosystem tools:
- Camel Toolbox
- Java Client
- Import Export
<Your Discussion Point Here>
Please squash a bug!Click here to expand...
Tickets resolved this week:Click here to expand...
Tickets created this week:Click here to expand...
- Moved the end of RC-3 testing to December 14. Hoping to get the release out before the holidays begin. Only need to release the fcrepo4/fcrepo4 repository. Should test fcrepo-mint.
- Tickets resolved for this RC are Windows build, exploding Shiro and correct responses to interaction model changes.
- Java client refactoring - all tickets are complete, there is one PR is left to review. Once that goes in then we could release a 5.0.0 version of that and would be great to get it out close to the fcrepo4 5.0.0 release. Once the fcrepo-camel-toolbox can read the ActivityStreams it should be ready to continue indexing.
- Import/Export - what would be the best way forward. We want to be able to import and export from and to 5.0.0 but also export for 4.7 and import into 5.0.0.
- Depends on how difficult it would be, but one of the major purposes of the import/export tool was to help with migrations between versions. So it would be nice to allow people to use the one tool to export from their 4.7 Fedora, alter and import into Fedora 5.0. If these stay in the import/export tooling we could end up with a lot of code to convert between versions. But if we keep them small it could be more consistent. Perhaps using the OCFL effort as a guide for on disk representation?
- WebACs have changed between 4.7 and 5.0 and this is a data model change. Those changes need to be accounted for and these types of changes will be different for each version of Fedora.
- Have to see what the import/export workflow will look like before we can understand what to do.
- WebACs used to be linked to the resource they protected, now are implicit so we need to alter the RDF to remove these triples.
- What about transactions and fixity, should it remain in the core codebase or move to a plugin or API-X tool.
- UMD may have demoed an API-X fixity service which could do the work.
- Smaller institutions may find this a benefit because they get it for free. But if we are thinking about deprecating the fixity and transaction service, we should start the discussions with the community at large to see what they are expecting. If we are looking at using an external service then we need to ensure it is easy enough to implement.
- If we want to deprecate these for 6.0.0 then do we need to add those messages to the 5.0.0 release? Suggestion to add deprecation notices to the wiki and add the messages to the code in a 5.0.1 or 5.1.0 release.
- Aaron is not aware of an API-X persistence fixity service.
- Andrew Woods to update CTS to skip (if necessary) "changing interaction models" tests
- Danny Bernstein to write short technical summary for the newsletter
- Danny Bernstein create ticket for looking at Java 11
- Danny Bernstein to add issue to test suite about LDP tests