March 8, 2017
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:
- Time: 1:00pm Eastern Daylight Time US (UTC-4)
- Dial-in Number: (641) 715-3570
- Participant Code: 304589#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #islandora on irc.freenode.net
- Nick Ruest
- Bryan Brown
- John Yobb
- Diego Pino
- Jared Whiklo ⭐
- Danny Lamb
- Don Richards
- Melissa Anez
- Natkeeran Ledchumykanthan
- Jennifer Eustis
- Marcus Barnes
- Jonathan Green
- Amanda Lehman
- Islandora-CLAW GitHub organization housekeeping
- What should be moved to Islandora Deprecated?
- Update Versioning policy
- Include only existing components
- Drupal modules
- Fedora 4 Deployments - more "in development" for Islandora? Pretty please?
- Syncing to filesystem?
- At the U of Manitoba we are considering not putting our binary files into Fedora 4 to ensure an easier upgrade path. Therefore we'd like to have a way to "sync" NonRdfSource objects to a filesystem path. Is this being considered anywhere else? Are there any hurdles or blocks to this type of workflow in the current plan?
- ... (feel free to add agenda items)
-
What is in the CLAW github organization but shouldn't be here?
Nick: All docker stuff, microservices, Crayfish, Chullo, claw install profile, Xpathfield all go to deprecated. It can come back later. I imagine the docker stuff will come back at some point.
*Danny: That seems in line what I was thinking, what is there currently gives people the wrong impression.
Jon Yobb: 👍 , Don: 👍 , Amanda : 👍
Bryan: Is there already deprecated repository organization?
Nick: Yes, https://github.com/islandora-deprecated
-
Updating the versioning policy.
The above makes our versioning policy easier to clean up.
http://islandora-claw.github.io/CLAW/technical-documentation/versioning/
We believed Drupal 8 modules would follow semantic versioning. They don't, so we should revise our policy. They do semantic versioning but they will not consider any changes a major update or release until 9.x
Is there a way to allow for small patch releases of each part, but still have a large repository that links together working parts to set a base..."setup" for people to try.
Diego: I'd like many small releases, but it seems like large releases are better.
Nick: We are going to have probably 3 years of releases where Islandora 7.x-1.x will also still be being released, how do we get support for both tools. In Fedora they cut a release candidate and ask the community to test it and let us know of any issues.
Diego: We are testing Islandora and Fedora and other tools that may have changed.
Nick: We are pinned to specific versions of these external tools and to upgrade we have to complete a task.
Jared: We are hoping that these have a specific API and those shouldn't change.
Danny: This is inline with the Fedora way, you try to test at each level and you hope to catch any issues. But things can fall through. We can tie the Islandora CLAW repo to pinned versions of all the parts and ask the community to test it because we have written the code and the tests. We will need support to ensure it is ready to go.
Nick: I will remove all the Drupal modules and update the versioning policy.
-
Fedora 4 deployments
Melissa: Someone asked why there was so little Islandora in it. If there is anyone else that would like to raise their hand to show those that are (even) in development.
Diego: We have moved to a different version of the code, so it is an alternative. But it is Islandora and Fedora 4.
Melissa: I'm sure a lot of the Hydra stuff is very custom, so I think if it is based on Islandora then you are good. Nick what level are you at.
Nick: Because we were committed to doing it and were the first Islandora upgration pilot. It would be great to have more of the involvement. There are people watching this list and it would be good to have more names on there.
Jon Yobb: Then you can add U of S to that list.
Jared: You can put the U of M there too
-
Syncing to filesystem
Jared: Coming out of some interesting discussions at previous Fedora Tech calls and to avoid some of the large scale import/export issues we are thinking about not putting our binaries into Fedora 4 and rather using External Content for those items. These can be served from some other webserver and that allows us finer grained control over filesystem setup. But we wanted to see if
1. Are we crazy to do this? 2. Are you thinking about doing this? 3. Please be aware we are thinking about doing this.Danny: At this point the MVP is essentially locked down. This is not an unreasonable request. If you're not the first then you'll probably not be the last. My questions would be how does Fedora 4 handle that, this is probably your major problem. Also how does API-X handle this, which we should be able to bend to our will. How Fedora fits into our piece of the puzzle, if we can adjust for having external storage.
Diego: We are also moving to external binaries to help with managing costs on storage. In Fedora 3 we are using Redirect datastreams. You lose checksums, but we are getting checksums via Amazon S3.
Danny: I would definitely get the checksum from an external source. Do you miss out with events with redirects?
Diego: You get events with RdfSource but not with the NonRdfSource.
Danny: I think we can handle that, we are pushing a lot of stuff up to the Fedora level.
Jared: Fedora 4 does not have Redirect datastreams it has External Content. So in Fedora 3 with a Redirect when you request the image Fedora goes to that external URL and gets the image and returns it. In Fedora 4 with an External Content when you request the image Fedora says "sure here's the URL, go get it yourself". That could add additional hiccups to the workflow but I think it would be worth it in the long run.
