Date

25 Aug 2020

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

Indicating note-taker

Vitro JMS messaging approaches - redux
1. Which architectural pattern should we take?
2. What should the body of the messages be?
Renaming of 'master' branch? (ZDNet, BBC)
1. Guidance from GitHub
2. DSpace has done it
3. Fedora has done it
4. Samvera is doing it
Incremental development initiatives
3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

Three unassigned bugs need to get looked at.
1a. VIVO-1837: looks like there is a clear path forward
- 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.

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:

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.