The goal of this project is to have a stable release of Hyku that does two things:
Leverages native Valkyrie objects.
Provides a means for migrating objects away from ActiveFedora and into Valkyrie objects.
Approach
As we encounter issues that we do not immediately resolve, we should create a draft issue on Violet’s board. As we determine where the issue belongs, we can add it to the corresponding repository.
The highest priority work is Hyrax, in part because Hyrax is sitting on a release candidate and we want to incorporate these changes sooner rather than later. From there, we need to address Bulkrax and IiifPrint to the best of our ability. Then we return to working on Hyku.
The end goal is to have newly released gem versions of Bulkrax and IiifPrint. To have a reasonably stable Hyrax branch for pinning Hyku. And to create a point release for Hyku.
Hyrax
The `double_combo` branch allows for us to lazily migrate content from ActiveFedora to Valkyrie by way of either the Frigga or Freyja adapter.
Our goal with Hyrax is to get the `double_combo` [branch](https://github.com/samvera/hyrax/pull/6221) ready to merge into `main`. In a [spreadsheet, we’re tracking the broken specs](https://docs.google.com/spreadsheets/d/17eaRJeHq3CTkeDD2w7cLGCiR0rcs_MkNdgMZSnSP6Uo/edit#gid=1142838539) in `double_combo`.
To consider Hyrax complete, we must:
- Get all specs passing.
- Address issues we drafted in [Violet’s board](https://github.com/orgs/scientist-softserv/projects/43); this does not mean we must resolve everything but we must triage what we must resolve and what we can defer.
- Discuss merging into `main`. This is now a long-running branch and will require deliberate consideration on the approach.
- For moving forward with the Knapsack work of PALS and HykuUp, we can proceed with using the `i35-valkyrize-hyku`; but the longer we wait to merge, the worse incorporating these changes will be.
Hyku
We’re working on the [i35-valkyrize-hyku branch of Hyku prime](https://github.com/samvera/hyku/tree/i35-valkyrize-hyku).
To merge `i35-valkyrize-hyku` into `main`:
- `FileSet` support working with the adapters of `double_combo`
- Wrap up [review of the Hyku/Hyrax files in variance](https://docs.google.com/spreadsheets/d/17eaRJeHq3CTkeDD2w7cLGCiR0rcs_MkNdgMZSnSP6Uo/edit#gid=112822896); Much of this is around collections and permissions
- Get all specs passing
- Point the `Gemfile` to release candidate versions of the following (note the release candidates can simply be `main`):
- Bulkrax
- IiifPrint
- Execute the Hyku test plan
- Mint versions of Bulkrax and IiifPrint
Bulkrax
The goal for Bulkrax is to remove direct calls to `ActiveFedora` methods and objects. We have a
For Bulkrax we need to:
- Merge `main` into the `hyrax-4-valkyrie-support` branch.
- Review changes in `hyrax-4-valkyrie-support` to determine if type of release.
- Then merge `hyrax-4-valkyrie-support` into main.
We need to reconcile the `hyrax-4-valkyrie-support` and `introducing-persistence-layer-for-bulkrax` branches. Which both will need to consider `FileSet` support
IiifPrint
For IiifPrint we have two primary considerations:
1. Avoid direct calls to `ActiveFedora` outside of a the [Bulkrax::PersistenceLayer::AbstractAdapter](https://github.com/samvera-labs/bulkrax/blob/3ae6402798c866c879ef57e1c4126b3165ba2bdb/lib/bulkrax/persistence_layer.rb)
2. Mirror the current Actor behavior through transactions and/or listeners
- `Hyrax::Actors::FileSetActor`,
- `Hyrax::Actors::CleanupFileSetsActor`, done after completing `Hyrax::Transactions::Steps::ConditionallyDestroyChildrenFromSplit`
To complete this work, we need to:
- Incorporate the abstract adapter into the implementation of `rails_hyrax_upgrade`.
- Merge `rails_hyrax_upgrade` into `main`.
- Mint a new version of `IiifPrint`.
The goal of this project is to have a stable release of Hyku that does two things:
Approach
As we encounter issues that we do not immediately resolve, we should create a draft issue on Violet’s board. As we determine where the issue belongs, we can add it to the corresponding repository.
We have four high-level considerations:
The highest priority work is Hyrax, in part because Hyrax is sitting on a release candidate and we want to incorporate these changes sooner rather than later. From there, we need to address Bulkrax and IiifPrint to the best of our ability. Then we return to working on Hyku.
The end goal is to have newly released gem versions of Bulkrax and IiifPrint. To have a reasonably stable Hyrax branch for pinning Hyku. And to create a point release for Hyku.
Hyrax
The `double_combo` branch allows for us to lazily migrate content from ActiveFedora to Valkyrie by way of either the Frigga or Freyja adapter. Our goal with Hyrax is to get the `double_combo` [branch](https://github.com/samvera/hyrax/pull/6221) ready to merge into `main`. In a [spreadsheet, we’re tracking the broken specs](https://docs.google.com/spreadsheets/d/17eaRJeHq3CTkeDD2w7cLGCiR0rcs_MkNdgMZSnSP6Uo/edit#gid=1142838539) in `double_combo`. To consider Hyrax complete, we must: - Get all specs passing. - Address issues we drafted in [Violet’s board](https://github.com/orgs/scientist-softserv/projects/43); this does not mean we must resolve everything but we must triage what we must resolve and what we can defer. - Discuss merging into `main`. This is now a long-running branch and will require deliberate consideration on the approach. - For moving forward with the Knapsack work of PALS and HykuUp, we can proceed with using the `i35-valkyrize-hyku`; but the longer we wait to merge, the worse incorporating these changes will be.Hyku
We’re working on the [i35-valkyrize-hyku branch of Hyku prime](https://github.com/samvera/hyku/tree/i35-valkyrize-hyku). To merge `i35-valkyrize-hyku` into `main`: - `FileSet` support working with the adapters of `double_combo` - Wrap up [review of the Hyku/Hyrax files in variance](https://docs.google.com/spreadsheets/d/17eaRJeHq3CTkeDD2w7cLGCiR0rcs_MkNdgMZSnSP6Uo/edit#gid=112822896); Much of this is around collections and permissions - Get all specs passing - Point the `Gemfile` to release candidate versions of the following (note the release candidates can simply be `main`): - Bulkrax - IiifPrint - Execute the Hyku test plan - Mint versions of Bulkrax and IiifPrintBulkrax
The goal for Bulkrax is to remove direct calls to `ActiveFedora` methods and objects. We have a For Bulkrax we need to: - Merge `main` into the `hyrax-4-valkyrie-support` branch. - Review changes in `hyrax-4-valkyrie-support` to determine if type of release. - Then merge `hyrax-4-valkyrie-support` into main. We need to reconcile the `hyrax-4-valkyrie-support` and `introducing-persistence-layer-for-bulkrax` branches. Which both will need to consider `FileSet` supportIiifPrint
For IiifPrint we have two primary considerations: 1. Avoid direct calls to `ActiveFedora` outside of a the [Bulkrax::PersistenceLayer::AbstractAdapter](https://github.com/samvera-labs/bulkrax/blob/3ae6402798c866c879ef57e1c4126b3165ba2bdb/lib/bulkrax/persistence_layer.rb) 2. Mirror the current Actor behavior through transactions and/or listeners - `Hyrax::Actors::FileSetActor`, - `Hyrax::Actors::CleanupFileSetsActor`, done after completing `Hyrax::Transactions::Steps::ConditionallyDestroyChildrenFromSplit` To complete this work, we need to: - Incorporate the abstract adapter into the implementation of `rails_hyrax_upgrade`. - Merge `rails_hyrax_upgrade` into `main`. - Mint a new version of `IiifPrint`.