...

Attendees

 Indicating note-taker

1. William Welling 
2. Andrew Woods 
3. Brian Lowe
4. Benjamin Gross 
5. Nicolas Dickner 
6. Georgy Litvinov
7. Ralph O'Flinn        
8. Benjamin Kampe 
9. Michel Héon 
10. Huda Khan 
11. Alexander (Sacha) Jerabek 
12. Don Elsborg 

Agenda

1. Releasing a 1.12 alpha
   1. Tickets to be resolved

      1. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1762

      2. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1802

      3. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1814

      4. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1914

      5. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1941

      6. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1950

      7. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1956

      8. Jira
         server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1959

   2. Timing
      1. 1.12 alpha-1: Feb 15st19th
         1. Two week RC-1 testing period
         2. For each subsequent RC-2 (if required), adding another two weeks to the schedule
   3. Process - are we prepared to turn the crank? VIVO Release Process
   4. Communication
2. New developments

   1. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1963

   2. Possible issue with duplicated edits?
   3. TDB "direct" versus "mapped" mode.

   4. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1962

3. Post-i18n priorities
   1. VIVO-in-a-box
   2. Ingest / Kafka
   3. Advanced Role Management
   4. Moving Scholars closer to core - next steps

...

1. 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
2. Incremental development initiatives

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1688

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-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 server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Notes 

Draft notes in on Google -Doc 

As Andrew is leaving Zoom links are going to be changed.

Significant milestone is going to be achieved with the merging of vivo-1958. Brian reviewed and tested new changes. Ralph was doing sanity checking. Checked new building process. Checked on multiple systems like Windows, Mac and Linux, multiple browsers. Ralph is working on checking i18n.

1. I18n Pull requests

Andrew asks about pull requests.

Either merge PR today or get some feedback on them. Some tickets on hold because of them.

Ticket 1958 should help with testing new functionality.

No code review expected at this point. There already have been code reviews.

Need basic testing.

William will try to test, at the same time VIVO needs a lot of resources for testing. 

2. Digest file

Diest file is now being created. The idea is now with 1959 we copy war file in tomcat. When tomcat starts VIVO Home directory got populated with war contents. As a part of that VIVO creates an md5 base file. With tomcat restart digest file is being read to find changes since last startup with files in VIVO Application. If files in war and on disk differ then files in home directory rewrites only if they were not changed. Digest file gets updated every time VIVO restarts. 

On restart it recreates files map with md5.

Only untouched files are getting overwritten. 

If somebody want to look at this - you are welcome.

Benjamin says it works good.

3. Tickets to be closed

Ticket 1802  Nicolas says it is expected behaviour. Ticket should be closed.

4. Putting out alpha release

We want to ensure users can upgrade. Upgrade should work with i18n and without it.

People in both scenarios should have upgrade instructions without issues.

All 1958 dependencies should be resolved shortly.

Merge all by the end of the week.

Reshuffling of RDF is ok for now as it doesn’t create any problems.

Given the pace of things Andrew wont be able to push Alpha and RCs.

Timing, Process, Communication with community 

Release on monday or next week ? Release alpha by the end of next week.

Send announcement for the community that alpha is ready, test it.

Encourage testing! A day for extensive testing RCs after internal testing alpha.

Advanced role management

VIVO-1436 It was targeted against main. Could have merge conflicts after 1958.

It could not be merged in 1.12 at this stage.

Plan for merging after 1.12, maybe release in 1.13

Misc

Publish docker container on docker hub to simplify using VIVO.

Individuals removal

George proposed a new configuration property (for example, display: hasDeleteQuery) to associate an ontology class with a query to retrieve dependent individuals to be deleted along with the target individual when it is deleted.

...

Drive

• Pre-main agenda
• Congrats to Brian on new position!
•  Zoom link has not changed YET

1. Releasing a 1.12 alpha
   1. VIVO-1762 - i18n: Document how to add new languages -for developer- In Progress
   1. Brian: Do we think this is a critical issue to address for the release?
   2. Michel: Not a blocker
   3. Benjamin: Nice to have before actual release but does not see like a blocker for alpha
   2. VIVO-1802 - i18n : Wrong label / untranslated items in "Same as" form Closed
   3. VIVO-1814 - i18n : French version of VIVO Publication graphic mouseover message is truncated Closed
   4. VIVO-1914 - i18n: Document how to upgrade existing site to use new i18n functionality Open
      1. If there is an existing 1.10/1.11 VIVO, what would need to be updated?
      2. More general question around upgrade process with Docker
      1. Recast this to make sense for 1.12
      2. Add text to approach customizations
      1. Mention changes to ontology.  Linguistic “en-us” tag at end of each label.
      1. Wasn’t required in the old VIVO but will be required in 1.12
      2. Brian: Data displayed by language filtering RDF service.  If it doesn’t find matching label, gives a random one. 
      1. Intention: Any place where end-user sees triples coming from triple store, it should have a fallback.
      2. Would the value disappear if no language tag?
      3. Michel: If stays en-US, should be fine.  If adding a language when editing data, the French tag will be in data.  Not sure if “en-US” will be added to the English string as a result of this edit.  
      4. Brian: Need to review this further
      5. Michel: Perhaps set up a helper asking what default language they want and then add that language to the strings?
      6. Brian: Utility (like Jena Tools) that could be run outside the app to set the tag?
      7. Michel: Yes
      8. Benjamin: Having a separate tool which does not need to be carried forward with VIVO: makes sense
      9. Brian: Alternative proposal.  Don’t want to carry around, but perhaps simpler if we just added a property in runtime properties to set locale.  This could be read in and then startup listeners could kick off conversion. 
      10. Benjamin: Less documentation this way.
      11. Brian: yes
      12. Georgy: When users do it intentionally, the separate tool might be better.  Otherwise, they may not think about what is happening. 
      13. Brian: Cannot necessarily account for complex changes for mixtures of languages (some as unintended side effects of editing)
      1. If all the language was to be in Spanish or English, if offered option to pick the locale that you expected your data to be.  Code will switch everything to that language, whether there was already a language tag or not.  
      2. Could be done by documentation using example SPARQL Update queries by named graphs, etc.
      3. Benjamin: worry about queries like that against large databases and stalling the system 
      14. Michel: Can’t build a solution for all cases, but need to specify that some process required on the data and cannot just be ported as is to 1.12 with i18n support. 
      15. Brian: Would prefer having this run as part of the tool
      1. Should we instead go with the documentation approach or command line approach?
      2. Volunteering to make a simple tool that would run inside VIVO, and then can review the pull request to see if acceptable or whether a separate tool is required. Brain to pick this up.
   1. Brian: Might be a little more critical. 
   2. May link to 1763 which is ready to go.  
   3. Benjamin: What needs to be done differently beyond the regular upgrade process
   4. Brian: https://wiki.lyrasis.org/display/VIVODOC111x/Upgrading+VIVO
   5. Michel
   5. VIVO-1941 - i18n - Refactor i18n properties and templates Open 
   1. E.g. there are custom templates in the fr_CA language repos. Properties have been added to existing .ftl files. Vision: Reform core FTL files so concatenation is no longer done… create longer i18n strings. 
   2. Michel in past has asked us to look at better way to look at syntax. 
   3. Benjamin - I don’t think it’s realistic to go back and try to address this at this point since it will require creating new i18n properties in multiple languages that will need reviewed by native speakers.
   6. VIVO-1950 - Google visualization libraries not loading - sparklines broken Closed
   1. Benjamin: Seems to be working fine.  Changed the URL for the request and callback.  Not seeing it load multiple times so it seems to be working. 
   7. VIVO-1956 - i18n - Re-Ensure consistency of RDF files Open
   1. Brian to look at this
   8. VIVO-1959 - When no selectable languages are enabled, interface is broken if browser's accept-language does not match an installed language Open
      1. Michel: Loads every time ?
      2. Brian: Selectable languages uncommented, and had French/German and not English, only those two are loaded
      1. If browser locale does not match anything in the selectable language list, it will default to the first selectable language 
      2. If browser locale matches something in the selectable language, it will pick the browser locale language
   1. Main blocker bug Brian assigned to self
   2. If running VIVO without enabling languages (default installation), and browser accept language is set to something (e.g. RO-RO for Romanian), get errors. 
   3. Changes to runtime properties so a sensible default would be set.
   4. Raises questions for future
   5. When don’t have selectable languages enabled in runtime properties, and no forced locale explicitly set, it doesn’t find a default language, and HttpServlet request does not get wrapped in a method which uses the getLocale.  Gets browser language.  Then, the properties file is attempted for retrieval, but is not found, and errors occur.
   6. RDF Files loading: where it decides to load en-US in absence of other languages.  That checks selectable locales and if empty adds en-US
   7. Quick fix for release: use that method instead. Refactor into general locale handling class.  That should allow us to get around issue. 
   8. Brian: Is this ok as a fall-back?
   1. If you add concept/class/individual, the i18n mechanism doesn’t work in this view. 
   2. Also doesn’t work in navigation or editing
   3. In French: Adding new class.  Linguistic tag not put in label description. 
   4. Brian: Tested with new code in main?
      1. Site info/page titles for page management, etc. : updated so that when a different language is set, it inserted the new value in the correct language and also preserved the other values in other languages
      2. In general, editing on administrative side with a different language should be fixed at this point
      3. Ontology editor: some areas not translated.  Domain/range, etc. Most of those properties get displayed in English b/c currently not providing translations for those. 
   1. Michel: Can test this with new code in main
   2. Brian: Worked with this area.  Initially reported by Benjamin for labels.  
   3. Michel: UQAM next week will be in sprint.  Talked about this with Sacha. Sacha will make systematic test in administrative portion. Next two/three weeks: probably additional tickets. 
   4. Benjamin: Will probably need point releases or a new releases for resolving blockers that are brought up now.  Fine to be part of testing for 1.12 but should not be blockers for 1.12.
   5. Nicolas (from chat): 
   1. https://jira.lyrasis.org/browse/VIVO-1947
   1. 1.12 alpha-1: Feb 19th
   1. Two week RC-1 testing period
   2. For each subsequent RC-2 (if required), adding another two weeks to the schedule
1. Plan: Alpha release by Friday. Two weeks of internal testing after which we’d announce it to community.  Then RC-1 after two weeks.
2. Will probably need some concerted effort for the remaining few open positions
3. Tickets to be resolved
4. Michel found bug in the administrative part.
5. Timing
6. Process - are we prepared to turn the crank?VIVO Release Process
7. Communication
2. Alpha release on track for end of week!
3. Georgy - working on advanced property removal logic. 
1. Original effort was too slow, but switched to DESCRIBE statements and seems to be better
2. Will clean up code and add redirect code for after deletion. 
3. Possible issue: what if user has ability to delete first object, but doesn’t have permission to delete objects that the deletion logic traverses?

...

Actions