Time/Place
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://lyrasis.zoom.us/j/88068382811
- Meeting ID: 880 6838 2811
- Find your local number: https://lyrasis.zoom.us/u/ad6Xb7q3ia
Join fedora-project.slack.com on the "tech" channel
- Self-register at: http://slack.fcrepo.org/
Attendees
- Danny Bernstein
- Arran Griffith (out)
- Jared Whiklo
- Peter Winckles
- Ben Pennell
- Calvin Xu
- Michael Ritter
- Demian Katz
Agenda
- Announcements
- Pre 6.2.0 issues to resolve:
- FCREPO-3819 - Getting issue details... STATUS
- FCREPO-3820 - Getting issue details... STATUS
- 6.2.0 Release Testing
- Installed base information gathering option doc
- Updates on mysterious bugs
- FCREPO-3818 - Getting issue details... STATUS
- Updates on In Progress Tickets
- FCREPO-3674 - Getting issue details... STATUS
- FCREPO-3673 - Getting issue details... STATUS
- FCREPO-3813 - Getting issue details... STATUS
- Tickets to be aware of
- FCREPO-3423 - Getting issue details... STATUS
- FCREPO-3807 - Getting issue details... STATUS
- FCREPO-3806 - Getting issue details... STATUS
- Migration Report
Notes:
- Announcements
- Today is Peter's last meeting (though he plans to "hang around a bit") – best wishes to Peter!
- Pre 6.2.0 issues to resolve
- Jared has been working on FCREPO-3819 – he reports that the work wasn't horribly difficult, but he has some concerns about possible unexpected side effects caused by SPARQL manipulation. A PR is available for testing, but is it possible there's a better way? Should affected users fix their data, instead of having a long-term ongoing code change? (This problem should only impact users who started with an empty repo and populated it via API – not an issue for people coming in via migration-utils; could be fixed by a fairly simple external tool and might not even require a reindex). Peter pointed out that fixing the triples on disk will generate new OCFL versions, and would leave behind old versions with incorrect triples in them – though this is not necessarily a problem.
- Consensus: simple change and external tool is preferable to increasing code complexity in the core software.
- Suggestion: create an "OCFL Doctor" tool as a home for this kind of cleanup/checking/fixing functionality
- The tool could do a "dry-run" generating a report which could then be used as input for a "fix" run.
- Peter volunteered to get a start on this
- FCREPO-3820 did not require detailed discussion and is related to the above.
- Jared has been working on FCREPO-3819 – he reports that the work wasn't horribly difficult, but he has some concerns about possible unexpected side effects caused by SPARQL manipulation. A PR is available for testing, but is it possible there's a better way? Should affected users fix their data, instead of having a long-term ongoing code change? (This problem should only impact users who started with an empty repo and populated it via API – not an issue for people coming in via migration-utils; could be fixed by a fairly simple external tool and might not even require a reindex). Peter pointed out that fixing the triples on disk will generate new OCFL versions, and would leave behind old versions with incorrect triples in them – though this is not necessarily a problem.
- 6.2.0 release testing
- Should be able to begin release process next week
- Installed base information gathering option doc
- See link in committers channel; help with estimating time to complete outstanding tasks would be appreciated
- Updates on mysterious bugs: no updates
- Updates on in progress tickets
- Mike is working on FCREPO-3813; thinks this would be good for Calvin to test once ready
- Tickets to be aware of
- FCREPO-3815 is now on Mike's list and has been removed from here.
- Migration report
- Calvin reports his team is still testing migration validation.
- He will update tickets with latest findings.
- He reports that he is sometimes getting an empty HTML report (this may be related to using --failure-only mode). Seems possible there is a bug here.
- Will test migration work in PR next.
- Demian hopes to start migration tests on his repository next month, disk space availability permitting
- Calvin reports his team is still testing migration validation.