...
- Should also contact the Tech. List (samvera-tech)
- Two use cases
- Shouldn't render the files at all
- Perhaps permit configuration to render or hide these Files?
Hyrax 2.0 Stable Support
Johnson
- Two weeks, the 2.0 stable build has been broken
- 5 individual dependency shifts caused some problem
- SimpleForm breaks, for example
- Fixes were not backported
- Johnson has been addressing technical debt in order to ensure that 2.0 stable continues to be stable when these updates are applied
- How best to address this collectively?
- https://github.com/samvera/hyrax/pull/2765
- Was merged this morning by Colvard
- 2.0 is now, once again, stable
- What commitment do we have to stable releases?
Van Tuyl
- Has the community had a policy or standard around this?
- If not, what does everyone see as the best practices
Colvard
- No established practices
- Adopters are expected to undertake the backporting
- Certain institutions might want to stay with 2.0 build given the issues involved in supporting dependency updates
Giarlo
- Demand for maintenance on existing builds has far exceeded the resources available to undertake this work
Johnson
- Many of the solutions required more time to sort through the commit history
- Ideally, this time could be reduced significantly through improving reviewing of commits
Lindner
- Code Stability WG is attempting to address these types of problems
- Beyond simply regression tests, how can one diagnose a particular problem
Myers
- Might this be related to Gemspecs with too loosely-versioned Gem dependencies
Johnson
- No, for example, SimpleForm had a bugfix which broke hydra-forms functionality
Myers
- But, when moving to a stable release, if a Gemspec versions were tighter, perhaps these problems could be mitigated
- Not advocating that every Gem be pinned down for a patch release, but this should be addressed for a stable release
Rayle
- Addressing changes in dependencies by pinning releases can be done
- But more broadly, labeling which commits/pull requests resolve specific bugs might resolve this more effectively
Gondron
- Perhaps could research which releases are affected by a given bug before one starts to resolve the bug
Rayle
- That's ideal, but requires a system in place to support back-releases
- Requiring one to analyze other releases before resolving a bug might further reduce the number of potential contributors
Giarlo
- Governance WG has released recommendations around how this could be better organized
- Resourcing
- Finding adequate resourcing is essential
- Forming a new WG to develop a model for better resourcing (particularly for addressing maintenance)
- Invitation for others to become involved
Colvard
- Feedback for the findings of the Governance WG is due today
Van Tuyl
- Is there a more immediate need to deal with backporting issues before process is defined
Johnson
- It could be fine right now
- Triaging before a bug is resolved sounds fine
- Finding which Hyrax versions are supported, and which features are being backported
- If you are doing code review, you might be looking for this type of difference
- Answering that for supported Hyrax releases would be an improvement
Van Tuyl
- Added this topic to the next Hyrax Roadmap Advisory IG meeting
- Any other issues can come to the tech. call as they arise
Moderator:
Lindner
Notetaker:
Colvard
(Hyrax Pull Request Grooming Follows)