Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- Rachid Belkouch
- William Welling
- Benjamin Gross
- Brian Lowe
- Andrew Woods
- Don Elsborg
- Alexander (Sacha) Jerabek
- Huda Khan
Agenda
- 2020-08 - i18n Editing Sprint - working towards a merge to 'master'
- Decoupling dependencies on VitroRequest
- Need a close review of all files that have been touched in both 'master' and the 'sprint-i18n' branches
- Needs debugging
- Three unassigned bugs
- Two unassigned documentation tickets
- Decoupling dependencies on VitroRequest
- VIVO 1.12.0 release timeframe
Future topics
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be?
- Renaming of 'master' branch? (ZDNet, BBC)
- Guidance from GitHub
- DSpace has done it
- Fedora has done it
- Samvera is doing it
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
Attendees
- Andrew Woods
- William Welling
- Rachid Belkouch
- Sacha Jerabek
- Don Elsborg
- Huda Khan
- Brian Lowe
Notes
- i18n sprint
- Three unassigned bugs need to get looked at.
- 1a. VIVO-1837: looks like there is a clear path forward
- Raises issues of setters/getters where things are not always set and you don’t know when to expect null.
- Brian will create an issue to review the newly-added RDFService.get/setVitroRequest() methods and ideally eliminate them.
- Other longer-term issues to address similar problems with tight coupling / undesirable references to other objects elsewhere in the codebase:
- Andrew wonders whether there is specific functionality (such as frontend decoupling) that will help surface and address some of these issues.
- William thinks a new dependency injection approach is required first in order to avoid perpetuating bad patterns on both sides of the decoupling.
- Huda has a good sense of where the cleavage points are for surfacing data to the API.
- 1b. Need to examine files that have been touched by both the sprint branch and recent core development to make sure that core changes have not been lost/reverted.
- 1c. Might be a matter of making sure that the initial RDF file loader recognizes the .nt (N-Triples) file extension and doesn’t try to parse as RDF/XML.
- Sacha: need to figure out how to address backlog of documentation tasks.
Git process (William)
- Propose two sprint branches: base branch (unchanging) plus staging branch. Features are developed off of the base branch. Conflicts get resolved in staging.
- Most important benefit is feature isolation. Conflicts should be resolved at the end of the feature instead of all throughout feature development.
- Also avoids race to get into staging.
- Current sprint-i18n branch is effectively staging, but we don’t all start developing new features from the same point. Makes it hard to build pull requests and test them in isolation because there isn’t an agreed-upon base branch.
- Something for next sprint, not to try to change now.
- If conflict occurs when merging to staging, create new feature-merge branch to resolve the conflicts without polluting the feature branch.
- Integrating of all features / conflict resolution occurs at end of sprint.
- Major refactoring happens just prior to sprint so that the base branch includes the refactoring.
- Cleanup happens at end as well.
Spring post-meeting 11 AM EDT Monday 24 Aug.
Actions