Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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, the Fedora Community identified a number of Hyrax implementers that hope current development efforts will lead to a migration path to Fedora 6 for Hyrax. 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 and plan the work necessary for Hyrax to use Fedora 6.

The specific objectives are listed below. The objectives also provide examples of what work might need to be done; these examples are not exhaustive so the working group can identify additional work or remove work based on its findings.

  • 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, 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 engaged in Hyrax / Fedora 6 work that might help 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 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).

  • 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).

Deliverables & Timeframe

The following work should be accomplished in three months. Remember that this is planning work, not development work.

...

Pre-work outcomes document. Create a document that summarizes any pre-work the group has engaged in, any lessons learned for this work, and any next steps future working groups or development teams might need to engage in.

...

An infrastructure proposal. Create a one page proposal outlining what infrastructure is needed in order to complete development for Hyrax / F6 development. Include potential options for funding this infrastructure (if necessary).

...

A scoping document. Create a one but no more than three page document that outlines the problem we are trying to solve, the proposed solution for the problem, the risks associated with the work, and any work that is explicitly out of scope for the effort.

...

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:

  1. Sirenia as a fully functional application of Hyrax 5.0 + Fedora 6.x with Valkyrie.

    1. Acceptable % of tests passing, as defined by the WG, from the following: Hyrax 5.0.0 sirenia testing .xlsx

    2. Identify and create tickets for issues related to failing tests from the testing sheet above.

      1. From the identified tickets, the WG will be responsible for distributing workload and/or recruiting community involvement to resolve the outstanding tickets.

  2. Performance Testing of Hyrax 5.0 + Valkyrie + Fedora 6.x

    1. 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.

      1. Review any other available performance results from Hyrax 5 testing with other backend solutions (ie. Postgres).

    2. Using Nurax, or an established testing environment, explore the current performance of the repository infrastructure under a pre-defined set of profiles and situations

      1. Establish limits for pass/fail

      2. Identify issues and document recommendations for optimization

      3. Compare testing results to any other available metrics from Hyrax 5 testing with other backend solutions (ie. Postgres).

    3. The results of the performance testing will be shared with the community as outputs of this work.

  3. Migration Considerations

    1. 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.

    2. 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

...

Child pages (Children Display)
depth1
allChildrentrue
style
pageWG Meeting Notes
sortAndReverse
first0

Documents

Child pages (Children Display)
allChildrentrue

...