Scope & Objectives
As of writing, the current stable release of Hyrax (https://github.com/samvera/hyrax/releases/tag/hyrax-v3.6.0) uses Fedora 4 as its back end for both file storage and metadata store. In recent community conversations, Fedora has identified a number of Hyrax implementers that are hoping current development efforts would lead to a migration path to Fedora 6. To date, however, a development plan for Hyrax 4.x and Fedora 6 has not been documented. The Hyrax Fedora 6 Working Group will work with the Hyrax Product Owner and Tech Lead to identify the work necessary so that Hyrax is able to use Fedora 6.
The specific objectives are listed below and provide examples of what might need to be done. The examples listed in the objectives are not exhaustive so the working group should feel free to identify additional work not included in the examples.
Identify and complete any pre-work to determine the scope of development. Working with the Fedora Tech Lead, Hyrax Tech Lead, and the Hyrax Product Owner to identify any pre-work that should occur in order to determine the scope of development (e.g., a Fedora 4 to 6 migration of an example Hyrax / Fedora repository; set up a test Hyrax 4.x and Fedora 6 to determine viability; etc.). Work with existing community members that have engaged in work that might help to clarify the scope of development (e.g., Emory’s work with Hyrax and Fedora 6; Indiana’s work with Avalon and Fedora 6; etc.).
Determine the scope of development. Working with the Hyrax Tech Lead, the Hyrax Product Owner, and the Fedora Tech Lead, identify the scope of development to ensure Hyrax 4.x works with Fedora 6 (e.g., the group should identify if their goal is to create a greenfield Hyrax 4.x and Fedora 6 or if the goal is to migrate an existing Hyrax 4.x and Fedora 4 repository to Hyrax 4.x and Fedora 6).
Create a high-level outline for the development work. Working with the Hyrax Tech Lead, the Hyrax Product Owner, and the Fedora Tech Lead, create a high-level outline for the development work (e.g., create high-level epics that can later be translated into sprints or be broken up into tickets).
Determine what infrastructure is needed to engage in the scoped development. Identify what infrastructure is needed to ensure that the scoped development is successful (e.g., should Nurax’s existing infrastructure be used or should separate infrastructure be utilized for this development work). If necessary, identify a funding source for additional infrastructure (e.g., request funding from the Samvera Board or request a partner institution host the infrastructure).
Deliverables & Timeframe
Meeting Times & Communication Channels
Meeting Notes
...
The Hyrax Fedora 6 Working Group (WG) was originally created to evaluate, document and scope the work required for Hyrax to use Fedora 6.x as a back end - See the original charter here. Through focused community efforts to complete the Valkyrization of Hyrax to support a variety of back ends and deliver Hyrax 5.0, a pathway to Hyrax 5.0 with Fedora 6.x via Valkyrie is on the horizon. Much of the pre-work initially identified by this WG was either in-progress or completed by the time the group was beginning to look at it, which led to the re-evaluation of the purpose of this WG - see Completed Work on the Hyrax Fedora 6 Working Group wiki page.
As of January 2024, the WG has committed to continuing to support the efforts to see Hyrax 5.0 released and working with Fedora 6.x via Valkyrie. This working group will be responsible for the following:
Deliverables & Timeframe
The following work aims to be accomplished before the end of the calendar year:
Sirenia as a fully functional application of Hyrax 5.0 + Fedora 6.x with Valkyrie.
Acceptable % of tests passing, as defined by the WG, from the following: Hyrax 5.0.0 sirenia testing .xlsx
Identify and create tickets for issues related to failing tests from the testing sheet above.
From the identified tickets, the WG will be responsible for distributing workload and/or recruiting community involvement to resolve the outstanding tickets.
Performance Testing of Hyrax 5.0 + Valkyrie + Fedora 6.x
Using the use cases gathered (Stakeholder Use Cases) as a starting point, identify what performance metrics are considered essential and would be of interest to the community more broadly.
Review any other available performance results from Hyrax 5 testing with other backend solutions (ie. Postgres).
Using Nurax, or an established testing environment, explore the current performance of the repository infrastructure under a pre-defined set of profiles and situations
Establish limits for pass/fail
Identify issues and document recommendations for optimization
Compare testing results to any other available metrics from Hyrax 5 testing with other backend solutions (ie. Postgres).
The results of the performance testing will be shared with the community as outputs of this work.
Migration Considerations
The WG will continue to discuss migration efforts required to move from older versions of Hyrax + Fedora 4.x to Hyrax 5.x + Fedora 6.x and continue to explore options for this work.
The WG may be able to provide recommendations for migration tooling or documentation based on the outputs of these on-going discussions.
Meeting Times & Communication Channels
Meeting Notes
| Child pages (Children Display) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Documents
| Child pages (Children Display) | ||
|---|---|---|
|
Members
Collin Brittle (Emory University)
Emily Porter (Emory University)
Ayoub Belemlih (Emory University)
Bradley Watson (Emory University)
Daniel Pierce (Samvera Hyrax tech lead/Indiana University)
Rebekah Kati (Samvera Hyrax product owner/UNC Chapel Hill)
Randall Floyd (Indiana University)
Dan Field (Fedora Developer/Lyrasis)
Kevin Kochanski (SoftServ)
Juliet Hardesty (Indiana University)
Ben Pennell (UNC Chapel Hill)
Thomas Wrobel (Bodleian Libraries, University of Oxford)