...
- Sprint starting next week -
- Danny Bernstein will not be available for the first day of sprint next week
- Danny Lamb switching to second sprint
- Aaron Coburn asking about the consideration of current features that are necessarily API spec features? (like webac, versioning subtrees, pairtree)
- (responses from Aaron Birkland)
- There may be some changes that might break the exisiting behaviors of fedora that are not part of the API spec.
- We do not have a policy that we'll be maintaining some of these hard to maintain behaviors
- the consensus from last weeks call was that backwards compat is not maintainable
- no concrete decisions about taking things out yet.
- based on discussion at start of sprint, things may end up getting taken out.
- some of the old behavior that's in the way or complicates things may be subject to removal
- bug regarding pairtree - Unknown User (acoburn) encourages discussion around this at start of sprint (taking out pairtree behavior)
- versioning - most concerning regarding impllementing momento that's consistent with the spec - it may be the case that we have to change the way that versioning is reflected in modeshape.
- Update on memory leak issue from Peter Eichman
- modeshape bug - fixed in modeshape 5.4, he has been unable to reliably get the system to fail and hang in test case.
- With avoiding transaction rollbacks they were able to run the remainder of the load and it completed successfully.
- tested with batch loader? Not gotten back to that yet
- ran into another issue which may or may not be related - there were some binaries where the metadata was there, but the binaries themselves were not in the system and may never have been.
- binaries were probably large enough to not hit the 4k minimum size (repository.json config)
- related to modeshape upgrade? no, this was happening in the modeshape 5.3 system causing the failed transactions he was seeing.
- these files may never have actually gotten written to the file system (based on looking at backups)
- next steps: might write files directly to the file system to replace them, though knows that's a bit dangerous
- one file was a xml file - one jp2 (and a few other types) – maybe one of the directories where these files were sitting got deleted? It's two pages in a row that are missing.
- JIRA issue https://jira.duraspace.org/browse/FCREPO-2544
- Do we use the sprint to remove this type of behavior?
- If we are going to break things, lets do it now
- Is this a reference implementation?