...
- Slack channel for breaking changes during as Fedora 6 is being developed?
- Move most development conversations into a "bleeding edge" channel (which will replace the "sprint" channel), and then post to the "tech" channel if a backwards breaking change is made
- Demo Server
- Auto-updating on AWS every time a new image is pushed to Dockerhub (in theory)
- REST API is working, but UI isn't available. Andrew Woods and Danny Bernstein will circle up so they both have access and can work on it.
- "Next Demo" topic pushed back until David Wilcox gets back from vacay
- Committers / Leaders Call Debrief
- Getting everyone on Fedora 6 is top priority
- For 4/5
- Export content using Import/Export tooling (this exists)
- Import the exported content (does not exist yet)
- How best to manage the fact that you've got to double the data? Unavoidable, most likely just needs to be clearly explained to the user in documentation.
- Is there a chance to share common code between the other tooling (migration utils, import/export, etc...) when moving to Fedora 6?
- Migration tooling must be there before 6 can be an alpha
- Migration tool strategy:
- extract abstraction layer for writing fedora objects to ocfl from core into a common library
- extract read fcrepo4/5 export functionality from fcrepo-import export tool into another common library
- Use above libraries in the fcrepo-upgrade-util for transforming an export to Fedora OCFL.
- Danny Bernstein to create JIRAs to organize this work.
- Do we need progress meter for index rebuild activity? Is this even feasible?
- How about "resume" index build functionality?
- We would have to be able to assume that the OCFL repo had not changed
- We also do not know at this time how long it takes to iterate over the repo (without doing any index updates).
- How about "resume" index build functionality?
...