Proposal for regular release schedule/process, like we have been doing for ISLE-7

[noahwsmith]

Hi everyone! We’re getting to the point where ISLE is being used in production, and we need to accomplish a few basic but currently incomplete items for proper adoption:

1. We need to create an initial non-alpha release
2. We need to establish a release manager / lead maintainer role who can commit to ensuring that timely releases continue to happen

We propose addressing the first item by simply creating a new tagged 1.0.0 release [edit: as Nigel notes, this should be from https://github.com/Islandora-Devops/isle-buildkit/pull/183]. There are enough groups using this in local, staging and even a few production environments that the critical issues have been uncovered and patched. We at Born-Digital are confident in ISLE in its current state, and propose that this tag be released ASAP. As we heard in the last Islandora Open Meeting, this will allow adoption from institutions who are blocked from going live with “alpha” tagged images.

Then we propose establishing this release manager role, and working iteratively over the next few months and years to build a rigorous process for vetting and releasing containers on a regular monthly schedule, with provisions for emergency releases as needed when critical issues are found. We at Born-Digital are happy to volunteer for this role, and if accepted, will base our initial processes on the ones we use now for ISLE7.

You can view that process in detail here, but in summary we propose:

• Convene a 30-minute ISLE tech call after every other regular Islandora Tech Call (bi-weekly) to coordinate activity and ensure progress
• Monthly we trigger a build of new images, we utilize automated testing procedures to validate the images as much as possible, do a quick internal check with our (real) QA systems, and publicly release these images.
  • We post release notes to the project, as well as post to the ISLE listserv.
  • What goes in these releases?
  • Security updates from upstream projects (e.g. Alpine, Java, Mariadb, other packages, etc)
  • PRs since the last release that have been accepted and merged to isle-buildkit’s “main” branch according to the isle-buildkit project’s existing process and standards
• Occasionally we will need to co-release ISLE-DC updates as well, which we will coordinate
• At Born-Digital, within a week we move into testing these images in our client staging environments, and within a week of that we move things along to prod.
  • When and if issues are found, the release is updated or a new point release is cut.

Any objections, or can we move forward with this work? There are a lot of details to work out, but we believe they can be worked out as we move ahead and develop a rhythm and updated processes.

Thanks for your thoughts in advance, @noahwsmith and @g7morris

[nigelgbanks]

Could we get https://github.com/Islandora-Devops/isle-buildkit/pull/183 in and a bump in the versions of solr, etc before releasing a 1.0.0, to deal with the outstanding vulnerabilities?

[kstapelfeldt]

In the tech call there are no objections to this raised, but also no expertise or cycles for this work among those attending the meeting. Is there still an ISLE interest group that might capture ISLE relevant people to to coordinate this work? @noahwsmith ?

[noahwsmith]

Yes @kstapelfeldt , this proposal includes resurrecting the ISLE Interest group as 30 minute calls that happen every other week right after the regular tech call.

@nigelgbanks you're right, https://github.com/Islandora-Devops/isle-buildkit/pull/183 probably should be the basis for the 1.0.0 tag. So I'll amend our proposal with that change - thanks.

Any other comments before we proceed with setting this up?

[rosiel]

Will updates to the islandora suite make it into this release? You mention upstream like mariadb, but not changes that go into islandora, advanced search, controlled access terms, islandora defaults, etc.

[noahwsmith]

Good question, but unfortunately the answer is fuzzy because of the nature of Composer. I think the correct process in the long run is to have a base "composer.json" file that is lined up with the "current release" of all those Islandora things, and then these isle-buildkit releases just run off the latest stable release of all the islandora things. But at least for the first few releases, I expect that we'll be iterating to find that stable point and it'll be a little bit more hands-on than this. Does that help describe both my expectations for the long-run and how I think the short term will be?

[rosiel]

I think so.

[nigelgbanks]

Will updates to the islandora suite make it into this release? You mention upstream like mariadb, but not changes that go into islandora, advanced search, controlled access terms, islandora defaults, etc.

At the moment only the demo image installs any islandora modules, etc. With the work that you've been doing to get it based off of https://github.com/Islandora-Devops/islandora-sandbox will make isle-buildkit releases follow in tandem with releases of https://github.com/Islandora-Devops/islandora-sandbox. Though releases of isle-buildkit can also be triggered by updates to things like mariadb, or changes in how micro-services or the queue system works etc.

Production sites are unlikely to use the demo image as their drupal image and will likely customize. So for most folks they probably will only pull in updates to packages etc. Managing their own drupal-project/composer.json however best works for them.

[DonRichards]

@nigelgbanks I would probably argue the opposite is likely to be true about using the demo images for most institutions. I agree they "should" use their own but I have doubts about universities investing in that when it's not absolutely required. We should probably add a section in the documentation on to how to fork & use the images and the pros/cons on using vs forking the community demo images if we want to encourage adaptation.

[nigelgbanks]

I think it will end in pain for folks to not manage their own config , composer.json, composer.lock files. Anything changed, from adding a field or changing the colour of the theme results in a change in configuration. Configuration and the versions of modules installed is very closely linked. I imagine the second they would go to upgrade their site would break.

Probably better to recommend folks fork https://github.com/Islandora-Devops/islandora-sandbox when it's ready and then have them manage the updates to their site in the normal Drupal fashion as is recommended by Drupal. Or something akin to that.

[jefferya]

Production sites are unlikely to use the demo image as their drupal image and will likely customize. So for most folks they probably will only pull in updates to packages etc. Managing their own drupal-project/composer.json however best works for them.

This sums the workflow at CWRC regarding the Drupal container. We use a custom image for Drupal based off islandora/drupal:${TAG} and manage config, composer.json, composer.lock, theme, and likely install_profile (very new to Drupal 8/9 and this setup so might be missing parts and trying to tease out these questions).

[nigelgbanks]

@jefferya as far as I can glean from the Drupal documentation your approach matches the recommendations by Drupal. Also that is the intention of having the islandora/drupal:${TAG} image.

[g7morris]

Just an update for everyone that a new section called docs has been created which contains the following subdirectories and content

• maintainers
  • Contains materials for how-to prep for monthly releases, versioning and more
• release-notes
  • Contains materials for what went into a release (PRs) etc and additional documentation for endusers as needed.

Please note these directories will grow over time and we're just starting out.

[g7morris]

All testing from my side has concluded @nigelgbanks I think you can cut a May official release when you're ready. Thanks!!

/cc @noahwsmith

[g7morris]

Wahoo! :tada: @nigelgbanks cut the new official 1.0.0 isle-buildkit Release. Well done Nigel you are a :star:

See you in June for the next round. :grin:

[g7morris]

Closing this issue now that the release has been completed.