CCMWG - 03/01/19

Owned by Trey Pendragon
Last updated: Mar 04, 2019 by James Griffin
6 min read

Attending

Time:12:00PM PDT/03:00PM EDT - 01:00PM PDT/04:00PM EDT

Zoom: https://princeton.zoom.us/j/281265700


Participants


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
  • We need to test the versions of Ruby and Rails which we've agreed to test

Ruby Versions

  • 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/
  • Trey: The major release number is more for branding, but there are API incompatible changes in minor releases for Ruby
  • Definitely going to test 2.4, as possible test for 2.5 and 2.6
  • Matrix complexity for two Rails versions becomes burdensome
  • Mark: If we put 2.6 in, and find that it breaks tests, then delegate it to this WG
  • Bess: But we should put 2.6 into the test matrix
  • Trey: Concerned about adding 2.6 to test matrix, it does slow the builds, but we should add it if it does not break tests
  • Tom: CircleCI with 4 builds running parallelized with 4 containers will provide 16 container environments
  • Trey: We agreed upon three most recent versions of Ruby
  • Mark: Articulate what we test vs. what we guarantee for stability
  • At various points, there will be pressure to introduce support for a newer release of Ruby
  • Noah: We can't necessarily issue a guarantee this once a Ruby minor release is issued at the end of the year
  • Trey: This seems more like a documentation problem, we can document the cases where the three latest Ruby versions cannot be supported

CircleCI Builds for Non-Essential Tests

  • Trey: Technical limitation: CircleCI has no concept of "this test failed, but it's okay"
  • Tom: Will investigate this further

Rails Versions

  • Trey: What is the policy for Hyrax
  • Tom: No policy on Rails versions
  • Currently support 5.1, but this will become a problem soon
  • Trey: Rails Policy: https://guides.rubyonrails.org/maintenance_policy.html
  • Bess: Proposes that we don't support any Rails release which is not receiving any security updates
  • Noah: More consistency with the Rails community practices would be best
  • Trey: Should preserve the same caveats as will be in place for the support for Ruby versions
  • Mark: Should surface the issues which arise in this WG in order to report to the Partners Meetings
    • A more formalized report on the status of core components would be valuable
    • "There are risks currently because this Gem is not up to support for Rails/Ruby version ..."
    • Even just a dashboard on Rails and Ruby compatibility would be beneficial
    • (This was added to the scope and objectives of this WG)

Mechanics of Getting the Work Done

  • Trey: In the past, we've structured sprints
  • Should this be abandoned?
  • Should institutions have us commit to this work and check in weekly?
  • Noah: It would be valuable to have someone to undertaken project management and delegate or identify issues which are resolved asynchronously
  • Mark: Sprints are useful as an organizing principle, not necessarily as something regularly scheduled
  • Trey: Do we want to organize a sprint?
  • Mark: Trying to argue in favor of deprecating om as a component
  • This is outlying as a task, and could be addressed during a first sprint
  • Deprecated simply means that the Gem is no longer a dependency for any Gems in the samvera GitHub Organization
  • Sprint 1: om Deprecation, hydra-works release without om, and addressing CircleCI build matrices
  • Trey: Will create the Doodle Polls for scheduling
  • WG will find issues to delegate to Noah (as they currently do not have the availability to offer FTE-level commitment to the sprint)


Meeting was adjourned at 15:54 EST/12:54PST