Versions Compared

Old Version 12

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version Current

changes.mady.by.user Brian Lowe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: move the star

...

  1. Don Elsborg 
  2. Andrew Woods
  3. Huda Khan
  4. Steven McCauley 
  5. Benjamin Gross 
  6. Mike Conlon 
  7. Ralph O'Flinn
  8. Alexander (Sacha) Jerabek  (star)
  9. Rachid Belkouch
  10. Michel Héon
  11. Brian Lowe (star)

Agenda

  1. Announcements
    1. VIVO Scholar town hall meeting notes - Friday, April 3rd @10am ET
  2. Sprint planning - i18n
    1. Organizing the language files - performance, maintainability, completeness, usability
      1. https://github.com/vivo-project/Vitro-languages
      2. https://github.com/vivo-project/VIVO-languages
      3. Other?
    2. Pre-sprint i18n GitHub Branch Clean-up
    3. Test data?
    4. Issue tracking?
  3. vivo-tech emails
    1. Missing N3-PP writer and RiotException
      1. http://soft.vub.ac.be/svn-pub/PlatformKit/platformkit-kb-jena-doc/doc/jena/IO/iohowto.html#rush
      2. https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/n3/N3JenaWriter.java#L72
  4. Vitro JMS messaging approaches
  5. Moving tickets forward
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1658
       - back on your plate, Mike Conlon
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1756
       - need one more review, who?
    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1755
       - need one more review, who?
  6. Who is working on what?
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1443
       - no progress since last week
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1752
       - ease of installation is vital, anyone interested?
  7. Using community questions to lift the entire team 
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1749
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1750
  8. Incremental development initiatives
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1688
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1751
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

...

  1. Status of In-Review tickets

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14416
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Notes 

Attendees

  1. Ralph O’Flinn
  2. Andrew Woods
  3. Brian Lowe
  4. Huda Khan
  5. Don Elsborg
  6. Benjamin Gross
  7. 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.

Draft notes in Google-Doc

...