Attending
Time:12:00PM PDT/03:00PM EDT - 01:00PM PDT/04:00PM EDT
Zoom: https://princeton.zoom.us/j/281265700
Participants
- Trey Pendragon (Princeton University Library)
- Mark Bussey (Data Curation Experts)
- tamsin johnson (UC Santa Barbara)
- bess (Data Curation Experts)
- Noah Botimer (U. Michigan)
- James Griffin (Princeton University Library)
Agenda
- Review membership and figure out how much we can do.
- Determine priorities for this session - assume we're going until Early November, so we can regroup after Samvera Connect.
- Roadmap Council representation in Ben's Absence
Notes
Quick Review (Trey):
What our expected deliverables are: (Reviewed the items on the Confluence Page)
Mark has updates from the Roadmap Council
Trey: Better that we run until Samvera Connect 2019
Mark: We can also solicit participation at the Partner Meeting
Noah: Our objective should be to ensure that this WG becomes a standing operation
Updates from the Roadmap Council (Mark):
Has had similar issues resuming after the holidays
Initial plan was to have a product owner and developer representative from this WG on that council
Nobody opposes that...but the amount of effort required to attend biweekly meetings...if members would prefer to develop on the WG without attending these meetings, this might be more efficient
Definitely open to another member of this WG serving on the Roadmap Council rather than Mark alone (given that Ben Armintor can no longer serve on this WG)
Mark will serve as the sole representative
Membership (Trey):
There are six of us and sixteen core components
Should we push for more membership? Otherwise, we need to determine what is reasonable in our current time frame and prioritize
Mark: Our core components might grow larger, as there are several samvera-labs repositories which might need to be promoted
Trey: Catch22 in promotion guidelines (found when trying to promote Valkyrie)
One requirement is a maintenance plan
CCMWG requires that the component already be promoted
Hence, if it always has a maintenance plan before it gets promoted, CCMWG need to do nothing
Tom: A proposal for another interpretation:
Have a tech Lead (optional) and Product Owner, with a small paragraph outlining priorities for maintenance, with the understanding that the CCMWG will address this for maintenance
All agree with this proposal
Trey: Are we going to issue another call for participation?
Mark: We should at least put out another call
We don't want this to consume members of the community who might also participate the Hyrax WG
Tom: Hyrax WG is short of testing resources and front-end designers
As it stands, the development resources are sound, and the energy around Valkyrie/Hyrax is also very position
Mark:
Partner Meeting in 6 weeks, putting out a call for more developers
Offer an option for a deep interest in Hyrax along with core component maintainers
Don't know if developers with front-end experience are needed for this WG
Mark agrees to represent the needs of this WG for the Partners Meeting, including a call for participation
Priorities for Core Components (Trey)
Expect to focus on Ruby and Rails release compatibility first
Bess: Hyrax has switched over to using CircleCI, is there a desire to switch over for the other Core Components?
Is there a need? Ideally we would be consistent, but it may not be a high priority
Tom: Could see the strength in the consistency argument
Trey: Try one or two core components, and look to develop a template CircleCI configuration
This would assist us in navigating between the different Gems
Tom: Candidate first component? hydra-head?
Trey: hydra-head would be useful due to its complexity
(All agreed with this as the candidate)
Trey volunteered to exploring this, along with Noah
Need to test the versions of Ruby and Rails which we've agreed to test
Which have we agreed to test?
Tom: For Hyrax, there is a policy for dropping deprecated Ruby versions
When a Hyrax major release comes out, unsupported Ruby versions on that date are dropped
Whenever they can, update the support for the latest Ruby releases
Trey: Guidelines state that it is up to the product owner
Should we revisit that?
Noah: This WG has the opportunity to provide some guidance given that the Product Owners may be more focused elsewhere
Trey: Are we supporting Ruby versions under normal maintenance (not security maintenance) or just not EOL?
Tom: We support Ruby versions which are just not EOL
Trey: Which Ruby versions easily installed on operating systems (such as Ubuntu) using package managers
Noah: If it is practical to align with Ruby community calendars, then we should aim for this
Trey: We are not supporting 2.2
2.3 will be EOL'd before this WG concludes this phase
Proposes that we only support Ruby releases under normal maintenance)
Mark: End of this month is the end of support for 2.3
Tom: Assuming that Hyrax 3.0.0 is released before this date, we would drop support
Trey: Each EOL for a Ruby release should trigger a Gem release for components
We will support the last three Ruby versions
See if this is reasonable, we might not support 2.6
Bess: We want to be testing against 2.6
Trey: Yes, 2.6, 2.5, 2.4
Mark: Do we have the resources to commit to that explicitly?
2.4 and as we can support 2.5 and 2.6 without a guarantee
Trey: Agrees
Noah: Ruby is semantically versioned
Trey: For testing purposes, we just test 2.4
If others want to use later features of Ruby, then it is not our fault, as we fall back to the adherence to semantic versioning on the part of the Ruby community
Tom: The reality for Hyrax is that, if a Gem drops support for Ruby 2.4, that has little impact on the community's ability for the latest Ruby version
Solution bundle then can't support the latest until all of the Gem dependencies can support the latest Ruby version
Delay time on getting support in for the latest Ruby versions is important for Gem dependencies
Mark: We still can look to call for support from the community in order to bring support for later Ruby versions for Gems
Bess: Ruby versions do drop support for methods (e. g. they don't exist anymore)
Noah: https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/