Date

Call-in Information

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

To join the online meeting:

Slack

Development Process

Attendees

(star) Indicating note-taker

  1. Ralph O'Flinn
  2. Tim Worrall 
  3. Muhammad Javed 

  4. Jim Blake 

  5. Don Elsborg (star)
  6. Andrew Woods
  7. Marijane White
  8. Huda Khan
  9. Alex Viggio

Agenda

  1. 1.10 Release Testing
    1. Released projects/artifacts (rel-1.10.0-RC-1)
      1. vivo
      2. vitro
      3. jenatools
      4. sample-data
      5. orcid-api-client
      6. VIVO-languages
      7. Vitro-languages
      8. VIVO-Harverster
      9. vivo-vagrant
  2. Post-VIVO Conference actions and opportunities
    1. Salient use cases
      • Standard, full-app with focus on profiles
      • Headless component of research intelligence ecosystem
      • Minimal store in support of modern, custom UIs
    2. Multi-source ingest: OpenHarvester, Combine, Reciter, etc
    3. ??
  3. Next sprint? Sept 17-28
  4. Suggested updates from Michael J. Giarlo
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Notes

Draft notes in Google-Doc

Don wants to discuss firsttime vs. everytime files and how to have modifications be displayed in existing VIVO

  • Huda - can place this data in the everytime   , if not using the interface, place the information

  • Jim -- so i want to override specifications in VIVO or Vitro tier.

    • So this is a problem, could have a file in 3rd tier that acts like a delete, then add this to 3rd tier

    • So place an empty file in firsttime, then move the file to everytime with my local changes

    • Don is concerned about consolidating files to a single file

    • 1.10 only consolidates ontology files

    • Don -- still need to change labels in ontology

    • Javed -- so could run a mapping to change labels against vivo.all.owl file to our own custom changes

    • Huda -- could do these things by determining what rdf needs to be moved, then load the files via the interface

    • Don -- how can I automate deployments for this?

Agenda 1

  • Andrew wants to focus on getting 1.10 out, release candidate goes a long ways but need to ensure testing is complete within advertise time frame of 3 weeks from now.

  • Release testing -- mike has done UI tests

  • Nothing else seems to have been tested

  • Want to use this test plan for future releases

  • What tests are critical?

    • Eg there are performance that’s that we’re not sure we can do yet? Andrew not sure if perf tests are blockers yet.

  • Don -- jena3tools failed on bad data with blanks in URL’s. Don will update the release test doc. Also, typo that unload should be jena2tools, not jena3tools

  • Ralph -- difficult because they’re jena tools -- working on better exception handling. Ralph has the jira for exception testing.

  • Andrew -- any ?? regarding API tests

  • Ralph -- performance tests, need to compare apples to apples

  • Andrew - need consistent dataset for performance tests. To Jim -- some timings could be collected via developer console.

  • Jim -- should be able to see timings of most of the performance items via dev console

  • Don can test sparqlquery API, load data using harvester, AFTER Cu is upgraded to 1.9.3

  • Group -- everybody is very busy -- so difficult to commit to time

  • Steve -- doesn’t have 1.10 running anywhere. Could get to some testing with some guidance.

  • Andrew -- indicate if a build worked for what system

  • Don -- want to add more detail to the sanity build table

  • Ralph -- perhaps the testing sheet should be a excel, google sheet table  -- Don +1

  • Andrew -- worried that adding google docs into this will create more complexity

  • Don -- link testing page wiki to google sheet

    • One sheet per testing group

    • Multiple people can comment on same test

    • Multi user user capability

  • Ralph will create sheet and link to page

  • Alex: place the google sheet in a common google drive which is part of a findable share folder. Ideally this will reside with other google docs from previous discussions. So this will make things more findable.

  • Nobody aware of master google drive for VIVO level, just group levels

  • Andrew -- can someone create a top level google drive for project? This is why he’s concerned because things get lost and spread out.

  • Ralph will help collect and organize, so will Don

  • Alex: the groupings really help, he can go back to previous conferences to find artifacts. Once a doc or sheet is “golden” it can be exported as pdf and attached to something else.

  • Andrew -- will give this a shot. Any counter arguments? …….. Crickets


    Conference discussion

  • Andrew -- great conf and meet people, discuss issues, directions. Any highlights, next steps?

    • Don -- moving vagrant forward, will have vagrant versions mimik vivo-project. Vagrant will have full source.

    • How to manage in github? Fork, clone, commiters?

    • Andrew -- create groups that have full rights for given projects. So for a project to move forward in vivo-community there needs to be a maintainer to initiates it and then works with other members. Andrew will create groups for vagrant and vivo-template.

    • Alex -- re product evolution -- broader discussion and turnout. Open to feedback and will follow up with conference attendees. More questions then answers on next steps. Will attend more dev meetings.

    • Andrew -- more communcation is in best interests

    • Andrew -- agenda 2a - salient use cases

      • standard, full-app with focus on profiles

      • Headless component of research intelligence ecosystem -- RIALTO. So a system that ties other components together

      • Minimal store in support of modern, custom UIs. So VIVO services simpler/modern UI’s

      • How do we support these use cases? Can we support them all?

Actions



  • No labels