How to connect: https://notredame.zoom.us/j/94030214208 (link will launch Zoom client – if you do not have Zoom, expand the instructions below)
Time: 9:00am PDT / Noon EDT
Moderator: Jeremy Friesen(University of Notre Dame)
Notetaker: James Griffin (Princeton University Library)
Attendees:
- Collin Brittle (Emory)
- Jeremy Friesen (Notre Dame)
- Chris Colvard (Deactivated) (Ubiquity Press)
- tamsin woo (UC Santa Barbara)
- Lynette Rayle (Cornell University)
Agenda
Roll call by timezone per following order - ensure notetaker is present (moderator)
folks outside North and South America
Eastern timezone
Central timezone
Mountain timezone
Pacific timezone
folks who were missed or who dialed in during roll call
- Remind everyone to sign in on agenda.
- Welcome all newcomers!
- Agenda (moderator)
- Call for new agenda items (moderator)
- Hyrax tags, all 300+ of them. How can we wrangle with this? Jeremy Friesen
- <add open agenda items here>
- Samvera help follow-up
- Pull request review
- Moderator & notetaker for next time
- Moderator:
- Notetaker:
- After call, this week's notetaker should create the agenda for the next call:
Open template agenda titled "Samvera Tech Call 2020-xx-xx"
- Click on ... in the top right corner, and select copy.
- Popup will open for location. It should contain:
- Space: Samvera
- Parent page: 2020
- Select copy. New page should be created.
- Modify the title to remove "copy of", update it with the next date, add moderator, notetaker, and any carry-over agenda info. Click Publish.
- PR Review
- Review issues:
- PR review coordinator for next time:
Notes
- Hyrax GitHub Repository Tags
- Quite a number of Tags exist
- Tag cleanup requires coordination from the community
- Perhaps this could be proposed as a Dev. Congress activity?
- There is effort involved in squashing Tags which needs to be considered
- There are collisions between version numbers for Hyrax and Sufia in the past
- Perhaps remove Tags from Sufia which are invalid now (as they don't reference any Hyrax releases)
- There would be a way through RubyGems to find all of the Hyrax-referencing Tags
- Scripting against the API might support querying this and doing this in batch
- Is it possible to limit push Tag permissions in GitHub?
- Tom could not find any setting for this
- It might not be realistic to assume that we can purge these Tags continuously without restricting the ability for contributors to push Tags
- Perhaps engage with contributors and ask them to delete any existing `git checkouts`, as the Tags can be pushed
- Hence, we would need to restrict `git push` rights for a small number of contributors
- GitHub Actions does provide a hook for tagging
- Maybe there is some automation here?
- Clarification: It's people's `git push` behavior which leads to these problems
- Maintainers have deleted Tags, and they have reappeared
- Perhaps there is some way of listening for new pushes with Tags, and intercepting this
- GitHub Tag Collisions
- If Alice and Bob both push with the same Tag name, how is this conflict resolved?
- If the person minting a Hyrax version needs to perform Tag cleanup locally, then that new version Tag won't be getting obliterated is the desirable behavior
- Tag Confusion
- People think that 2.5.2 is a Tag which doesn't reference a valid release
- This did not even come from the Sufia merge
- People think that 2.5.2 is a Tag which doesn't reference a valid release
- Annotated Tags
- These are full commits associated with the Tag
- Does `rake release` include this functionality?
- Tom did perform a `rake release` with an annotation and with signing the Tag
- This should be a strongly recommended practice
- GitHub Actions
- Can we, through Actions and RubyGems API, clean up on `git push`?
- Concern: It would be preferred to explore supporting this in CircleCI, as otherwise GitHub Actions would conflate multiple CI platforms
- Generating a list of the Tags which we've generated from RubyGems
- This would provide us with a means of providing a chronology between the Tags and the releases
- We definitely need a document describing the release process
- If Tag annotations are going to be supported, we should no longer use `rake release`
- We should still explore whether or not `rake release` supports annotating Tags
- Those releasing should also sign each release