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
- Don Elsborg
- Andrew Woods
- Huda Khan
- Steven McCauley
- Benjamin Gross
- Mike Conlon
- Ralph O'Flinn
- Alexander (Sacha) Jerabek
- Rachid Belkouch
- Michel Héon
- Brian Lowe
Agenda
- Announcements
- VIVO Scholar town hall meeting notes - Friday, April 3rd @10am ET
- Sprint planning - i18n
- Organizing the language files - performance, maintainability, completeness, usability
- Pre-sprint i18n GitHub Branch Clean-up
- Test data?
- Issue tracking?
- vivo-tech emails
- Vitro JMS messaging approaches
- Moving tickets forward
- - back on your plate, Mike Conlon
- - need one more review, who?
- - need one more review, who?
- Who is working on what?
- - no progress since last week
- - ease of installation is vital, anyone interested?
- Using community questions to lift the entire team
- 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
- Ralph O’Flinn
- Andrew Woods
- Brian Lowe
- Huda Khan
- Don Elsborg
- Benjamin Gross
- Michel Héon
2a. Organizing language files
- UQAM team likely not interested in consolidating; others may be interested in consolidating.
- Performance concerns. Brian agrees: having unnecessary language string triples in the triple store might slow things down even if only a few languages are enabled for display. Inner (unfiltered) RDFService still has to retrieve them, and filtering RDFService has to sort them.
- Ralph: storing together but only loading language data for languages that are enabled could be a solution.
- Benjamin: Having everyone maintain their own language repository is non-ideal. Leads to other application changes to better suit different linguistic environments that don’t get propagated back to the core application
- Andrew: Can we selectively load languages at runtime?
- Brian: Yes, would probably involve an adaptation of the filegraph-type loading logic for TBox and ABox data.
- Michel: Best practice in other projects is to keep separate language modules/directories even if they are in the same repository. Best to do it now since we will have to do it eventually. Not useful to load all language triples if we will never use certain ones in a specific installation.
- Benjamin: could rearrange the files in the existing repository so that each language is in a separate directory. Could either pull in specific directories or delete the ones you don’t want.
- Michel: Edit the pom.xml to include specific directories, or another solution would be to have a repository on Github per language.
- Andrew: Even though the current process involves editing pom.xml files, I’m working to change that pattern so that system administrators don’t need to know anything about Maven to install VIVO. Just need to install .war file.
- Ralph: Agree: administrator doesn’t need to know how to build it.
- Andrew: Seems to be agreement that there’s value in only loading the languages that you have enabled.
- Benjamin’s suggestion: Split languages into separate directories
- On startup, only load those directories that are enabled
- Michel: Could create an installer for VIVO where you can select what you want to include. For the first phase we can just modify the pom.xml file with the appropriate configuration that we want. In the sprint, can write the installer.
- Andrew: https://bitrock.com/ might be a starting point. Used in library communities. Moving to a .war file is still helpful.
- Michel: Installer can also install the other dependencies, not just build a .war file. Agree with consolidating languages into a single repository, but with a separate directory tree for each language.
- Group generally agrees with this single-repository, directory-per-language approach.
- Additional feature is selective loading of directories; can come later.
- Additional discussion needed about best mechanism for selecting/enabling languages: may be a pom file thing, may be something else.
2d. Sprint issue tracking
- Using normal JIRA vs. Github issues
- Ralph: would normally use Github issues, but might be useful to use JIRA so that all the project history is preserved in one place.
- Michel: need ability to capture screenshots. Andrew: both solutions support this.
- Andrew: In sprints, want lots of small, incremental changes that keep the software working rather than a branch full of changes requiring review. Make small pull requests into the master branch through the course of the sprint. Seems to make sense to use the normal process, i.e. JIRA.
- Michel agrees with JIRA.
- Andrew: Existing sprint has branches for VIVO, Vitro and the language repositories. Can this be broken up into smaller pieces that can be issued as pull requests?
- Michel: seems dangerous to try to do this without an adequate test harness.
- Michel: should create test case and make sure it passes with English. Then include the other language changes.
- Results in a single massive pull request when we’re satisfied that the sprint changes pass testing
- Targeted e.g. for a 1.12 release, not 1.11.2. Andrew agrees.
Actions
