Samvera Tech Call 2025-02-12

Meeting Logistics:

• Time: 9:00am PDT / Noon EDT

• Zoom Meeting URL: Join our Cloud HD Video Meeting
  (link will launch Zoom client – if you do not have Zoom, expand the instructions below)
  
  

Agenda (meeting notes below)

• Slight hiccup and delay with full Rails 7.2 compatibility

  • The Hyrax engine forces Rails to 7.2, but test apps were still set to run with 6.0 configuration defaults

  • Setting defaults to 7.2 breaks a lot of things, from building to test failures

• Discussion/opinions on two strategies for targeting 7.2 configuration defaults:

  • Set defaults to 7.2 and go fix everything

  • Selectively set individual settings back to pre 7.2 values to prevent significant refactoring

  • Example of two approaches for autoloading issues: PR #7014 versus PR #7016

Moderator: @Randall Floyd

Notetaker: @dmoles

Attendees:

• @Chris Colvard

• @Heather Greer Klein

• @Daniel Pierce

• @Nicholas Mark Homenda

• @Nic Don Stanton-Roark

• @Bradley Watson

Meeting Process

Notes

1. 7.2 / Zeitwerk

   1. a newly generated Rails 7.2 / Hyrax app doesn’t run, even though Dassie & Koppie do—but that’s because they still have 6.0 config defaults (a Rails backward-compatibility mechanism). Rails 7’s Zeitwerk autoloading esp. doesn’t play well with our code layout etc.

   2. highlights that our tests etc. depend on test app settings & not just on the Hyrax engine itself

   3. two fix approaches:

      1. just update everything to 7.2 and fix it (see #7014)

         1. con: changes a lot, probably requires re-QAing everything & we already don’t have enough manual QA resources

      2. use an initializer to incrementally enable/disable 7.2 features (see #7016)

         1. con: Hyrax won’t be fully aligned with 7.2 conventions

   4. @Randall Floyd's gut feeling: let’s take the conservative approach pro tem so we don’t have to redo all the QA; incrementally move toward 7.2 conventions in future work—what we’ve done so far is valuable & could be incorporated into a future release; we can put the whole thing in one initializer and that will hopefully make it easy to sort out remaining test failures (e.g. w/view specs)

   5. discussion:

      1. @Daniel Pierce: not urgent to move to the new autoloading mode; mostly the gain would be in efficiency; moving code around will probably cause problems for existing Hyrax apps

      2. @Chris Colvard: agrees we should get value out of the QA we’ve already done; but make sure we deprecate stuff and make sure we move forward

      3. @dmoles : agrees w/general approach; suggests we might want to periodically go through the “set up a new app” documentation

   6. additional notes/action items

      1. we’re not testing the generators

         1. @Daniel Pierce - we used to do this with EngineCart but it was taking a long time to do it with every commit; but now Dassie specs already take 40 minutes, so that might not add much

         2. @Randall Floyd : testing spreadsheet could include a task to try bringing up a new Rails app (or make sure a developer tries)

            1. @Nicholas Mark Homenda so long as we know how to document it

      2. @Heather Greer Klein : we should probably put updating docs into next sprint (@Nicholas Mark Homenda will add to board), and communicate both in partner call (@dmoles will be attending) and via samvera-tech mailing list / google group

2. UCSC possible ACL issue from Jan 15-16 (Slack: https://samvera.slack.com/archives/C0F9JQJDQ/p1737058344389349?thread_ts=1736799387.009699&cid=C0F9JQJDQ ) still could use some more eyes. Per @dmoles :

   1. it seems like for a logged-in user, the set of viewable collections is maybe being computed incorrectly, both on the "view all collections" page and when trying to query solr for a single work. given a permalink at least (e.g. from "featured collections" on the home page), the page for a single collection displays fine (including thumbnails of all the works). Without logging in, you just get all public collections (AFAICT).
      I don't understand the access controls well enough (particularly when looking at code that far back) to know just how the set of visible collections is determined.
      But as far as why it might start happening now without code changes, UCSC did suffer a power failure in December and I could imagine that if some process was trying to update, say, both Solr and Fedora, or Solr and the Rails database, or whatever, and that was interrupted, there might be inconsistencies. (Or if backups were restored from slightly different timepoints, maybe?)

3. some PRs to make sure versions are updated (e.g. #6994)—pre-7.2 release are being made from branch

4. next week’s notetaker: @Chris Colvard