Date

Call-in Information

Time: 10:00 am, Eastern Time (New York, GMT-04:00)

Attendees

(star)  Indicating note-taker

  1. Dragan Ivanovic  
  2. Georgy Litvinov 
  3. William Welling 
  4. Brian Lowe (star) 
  5. Ralph O'Flinn 
  6. Benjamin Gross 
  7. Huda Khan 

Agenda

  1. Faux data  properties
    1. https://github.com/vivo-project/Vitro/pull/352
  2. Merging i18n redesign branch
  3. Publishing VIVO 1.14.0 release
  4. Demo meeting

Notes

  1. Faux data  properties
    1. https://github.com/vivo-project/Vitro/pull/352
      1. Brian approved.  Dragan will add second approval of requested changes and merge.
  2. Merging i18n redesign branch
    1. William will review code; will also attempt to spin up an instance to test.  May enlist others to try creating new translations, but will wait on this for the moment.
    2. Brian will review the ontology for representing the UI translations.
  3. Publishing VIVO 1.14.0 release
    1. William wonders whether use of branches through the release process should be revisited.  And should there be more transparency and window of opportunity for the community to review or comment?
    2. William: should have Cypress UI testing.
    3. Brian: At one time we had a suite of Selenium tests; not sure how easy to resurrect at this point, or whether it’s too old to bother with.
  4. Demo meeting
  5. Deployment/installation
    1. Maven build versus package installation.
    2. William: could have both, but which should be default?
    3. Georgy: No Ansible actions can easily be used at this time.  Current situation pushes towards bad practices.
    4. William: May need to assist institutions like Michel’s as VIVO’s deployment changes.  Not clear how their integration with Eclipse may affect things.  The project owner can decide that certain functionality will no longer be supported after a certain version.
    5. Dragan:  Institutions don’t want to have to invest more effort just to retain the same functionality; they are more likely to invest in modifying their deployment practices in order to get access to new features in new versions.  When we decouple the front end and back end it may be the opportune time to introduce deployment changes.
    6. William: feature deployment shouldn’t be blocked by deployment changes. Should be decoupled.
    7. Georgy: Really outdated now; shouldn’t be frozen where it is.
    8. William: Artifact shouldn’t make any assumptions about deployment.  Deployment should be up to the implementer.  Should not be coupled in the versioning of the codebase.

Draft notes on Google Drive

Actions

Previous actions 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.