How to connect: https://notredame.zoom.us/j/94030214208 (link will launch Zoom client – if you do not have Zoom, expand the instructions below)
Expand | ||
---|---|---|
| ||
Meeting ID: 940 3021 4208 One tap mobile
Dial by your location
Meeting ID: 940 3021 4208 Find your local number: https://notredame.zoom.us/u/aPls29JbL Join by SIP 94030214208@zoomcrc.com Join by H.323
Meeting ID: 940 3021 4208 |
Time: 9:00am PDT / Noon EDT
...
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:
...
- 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
- Plans
- Carry on, when you release, if there is a Tag in the way, this gets clear
- Future practice: When a collision occurs, bump the Hyrax patch version, and start with a clean slate
- People are still going to be confused regarding which Tags reference valid releases
- If this is a small, restricted group of people getting confused, then perhaps this could just be added to the README
- This could be a warning with a list of the releases from RubyGems
- Action Items
- Jeremy volunteers to provide a PR for improving the README discussing points of potential confusion with regards to Tagging
- Tom volunteers to provide instructions for releasing Gems and improve the README
- This will include the expectation that releases should be signed
- Releases Page
- Releases appear to be valid after 1.0.5
- Scrolling after January 2015, there are problematic releases
- Jeremy will request a review from Lynette in order to ensure that questions related to working directly off of Tags are addressed
- Community Manager Position
- (Please check Slack for an update on the process of the Community Manager interview process)
- Next Scheduled Tech. Call
- Moderator: Chris Colvard
- Notetaker: Lynette Rayle
- Call concluded at 09:31 PDT/12:31 EDT