December 14, 2022

Time/Place

This meeting is held virtually via Zoom, with an open channel for chatter on Slack. Anyone is welcome to join. The hosting can be claimed by anybody with the host ID. The Host ID is in the header of the TAG slack channel.

• Time: Wednesday, 1:00pm Eastern Time US - click to convert time zone!
• Zoom link: https://zoom.us/j/97345581392
• Passcode: 919241
• Join us on the Slack Islandora Channel https://islandora.slack.com/archives/CM5PPAV28

Chair Roster

These are the core members of TAG and will take on chair of the meeting if there are no volunteers, and will support volunteers who are chairing for the first time:

• Don
• Seth
• Rosie 🪑
• Willow

Attendees

• Jordan Dukart ⭐
• Rosie Le Faive
• Nigel Banks
• Adam Vessey
• Alexander O'Neill
• Annie Oelschlager
• Dara Virks
• Don Richards
• Eric Luhrs
• Jeffery Atoniuk
• Jessica Colati
• Willow Gillingham
• Yamil Suarez

Agenda

Note that links are to the document repository only. New issues in other repositories or organizations will not appear in this list, and should be added by interested parties directly to the agenda.

1. Turn on RECORDING!
2. Buildkit PR "Issue 215 update alpine #238" (carry over from Dec 7)
3. Profiles proposal discussion (carry over from Dec 7)
4. Islandora Editions Proposal discussion:
5. PR Roundup- Link sorted by recently updated
6. Issue Roundup - Link sorted by recently updated
7. Review of mailing list
8. Feel free to add more, or add something from Islandora Discussions

Minutes

Given the technical nature of the discussions recordings were made that will have full context / notes. Recordings (incl video, audio, chat) Part 1, Part 2.

Discussion of https://github.com/Islandora-Devops/isle-buildkit/pull/238/files.

Nigel Banks introduced the PR and mentioned the following changes to be aware of:

• No longer containing FCREPO5 as FCREPO6 exists.
• Alpaca no longer using Karaf.
• Everything upgraded.

To facilitate an upgrade you will need to:

• Rebuild Solr.
• Migrate Matomo.
• Drupal updates moves from PHP 7.4 to PHP 8.1.
• Demo install profile dropped.

Full release notes are to come that will lay everything out in greater detail.

Nigel mentioned that re-working allows for automated tests to be written.

Don Richards posed concerns with existing forks and pulling in this substansial rework.

Nigel suggested extending the existing images in buildkit as opposed to forking.

Don asked about the ramifications for existing forks. That is for already customized buildkits what should be done?

Nigel suggested doing what he had described previously (extension of the images). For existing forked repositories they should pull in from HEAD buildkit once the open PR is merged.

Alexander O'Neill raised a question about ISLE-DC/Buildkit and if this changes relationship of how one uses the images. Are the make commands and so on obsolete?

Nigel mentions that for ISLE there'd be some changes like environment variables. However, there will be a pull to ISLE-DC to utilize these once the buildkit PR is merged.

Rosie introduces discussion about templates and editions and the corresponding document: https://docs.google.com/document/d/1kWUhpLzsh10thsEp9PEgryyfmDv-24AqO9LsENNhYeM

Template Discussion

Nigel begins the template discussion by stating the idea is to provide a template repository much like the starter site does. If you are going to run an Islandora site and want to make customizations you have to take upon yourself the responsibility of deciding the stack and components for deployment. Instead of forking the repository you make a copy of the repository and make the decisions that suit your use case. The Islandora community would not be responsible for on-going maintenance, the onus is on the people that make a copy of the template.

Don asks if this is going to fundamental change how we use ISLE? Currently, the bar is lowered to run one command to spin up a stack. Does this proposal change that expectancy or is this along aside it?

Nigel clarifies that this is along aside of it. It's not to replace ISLE-DC but it's an alternative way that's a bit more geared towards the long-term ongoing maintenance of an institution's site. There's a lot of responsibilities in ISLE-DC and to make it in such a way that a change can make someone's production would no longer be a concern as the template puts the onus on the adopter.

Rosie states that this proposal makes a lot of sense because this puts the responsibility where it needs to be. Let's the institution choose what components they want. Currently, it's hard for someone to pick and choose what components that they want but this is a step forwards to achieve that goal.

Nigel iterates that this hopefully reduces the burden of maintenance for the Islandora community. Documentation is still needed but it puts the choices back on the implementer.

Alexander asks does this pertain to every image in ISLE buildkit or just the Drupal image?

Nigel responds that this would only pertain to the Drupal image?

Alexander follows-up with asking if it is now mandatory for people to make their own images?

Nigel acknowledges that it is indeed now mandatory and he can't envision a scenraio where it can operate otherwise.

Editions discussion

Rosie introduces discussion on editions, an overarching way of versioning for the entire Islandora suite.

Nigel mentions that effectively we have a lot of different components that go into an Islandora site. There's a certain layer of compatibility between external components and Islandora that need to be used. Editions would allow us to identify more easily what versions of the components are being used as a whole.

Rosie walks through an image denoting how this could work: https://docs.google.com/drawings/d/1NBO2ogr4oW-MiC2SNIFx4v9ANjspO_a1gjO7CVnXJ7M.

Adam Vessey asks how much of these concerns go away if derivatives moved away from Crayfish?

Rosie responds that most of them could go away except Fedora.

Adam postulates that Fedora could also move away.

Rosie continues by saying that she feels config changes will be the hardest. In general the humans own the config. A person manages the back-end stack and sets the config. When you bump up the version there's going to need to be documentation about what changes to make. I don't think that's something we should try to automate as a general rule.

Don brings up the purpose of update hooks. For example the client is left without a white screen when we push out an update.

Rosie clarifies by saying if Matomo's routes or API changes we don't go ahead and try to automatically update.

Nigel responds by mentioning that update hooks and configuration changes are normally used differently in a Drupal context. For example if the configuration has changed in structure (schema). He does not think it's appropriate for setting specific values for example a URL has changed.

Rosie proposes an idea where Alpaca and Drupal could ping each-other to determine what versions they are both using and act accordingly given that context.

Adam highlights that there exist REST APIs that have versioning built into the URL structure such that when major breaking things are encountered it's clear to the end user. Introduces complexity if attempting to support multiple major version ranges at once.

Nigel states that editions allows a way to put a collective name to Islandora as opposed to doing traditional releases which doesn't really work with how modular the stack currently is. Mentions the Islandora Board had indicated that this typification is beneficial.

Rosie suggests that it gives us a way to define what is Islandora and what is the stuff we are maintaining. It could, if we wanted it to, give us way to define the product. This would push for parity between both ISLE and Playbook to support editions.

Call winds down and Jordan Dukart brings up the problem of frequency of editions and how maintenance and workflow may look if this was adopted.