Date

19 Jun 2018

Call-in Information

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

To join the online meeting:

• Go to: https://duraspace.zoom.us/j/823948749
• Or iPhone one-tap :
  • US: +14086380968,,823948749#  or +16468769923,,823948749#
• Or Telephone:
  • Dial(for higher quality, dial a number based on your current location):
  • US: +1 408 638 0968  or +1 646 876 9923  or +1 669 900 6833
  • Meeting ID: 823 948 749
• International numbers available: https://duraspace.zoom.us/zoomconference?m=Qy8de-kt6W4fMMDQCAV_3qfH1W-lxAo5

Slack

• https://vivo-project.slack.com
  • Self-register at:  https://goo.gl/forms/JxQFkut4TYj4Ehww1 
    

Development Process

• See https://github.com/vivo-project/VIVO/wiki/Development-Processes

Attendees

 Indicating note-taker

1. Ralph O'Flinn
2. Tim Worrall  
3. Don Elsborg 
4. Andrew Woods 
5. Huda Khan 
6. Alex Viggio
7. Kitio Fofack
8. Sarbajit Dutta
9. Benjamin Gross
10. Steven McCauley
11. Mike Conlon
12. Martin Barber

Agenda

1. 1.10 Release Testing updates
2. Working towards a unified VIVO technical vision
   
   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. 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

1. Filegraph discussion: Don brought up a question on the email list and we discussed an approach on slack. It would be useful to to document the solution and share on the email list, as people will sometimes search for discussions on the list.
2. Don: Would like to understand the process for the documentation.
   1. Have tested this, put it on GitHub
   2. Would like to document in the VIVO wiki and reference that from ours
   3. Andrew: if you have documentation already, useful to share with team/community and then separately decide where to put this on the wiki
   4. Don: Zero-size file in first-time - i.e. a change based on the suggestions discussed. 
   5. Action – Don will document this in CU BOulder wiki, circulate this doc to email list and discuss as a team how to integrate this in VIVO documentation
3. Release candidate testing:
   1. At around mid-point https://wiki.duraspace.org/display/VIVO/Release+Testing+-+1.10.0
   2. People who are testing can update the wiki directly or the linked Google doc: https://docs.google.com/spreadsheets/d/1opyO0Koj5f0nsGGet8scHW7-6SYcTnTIMzdsNWq9usg/edit?usp=sharing
   3. Ralph and Kitio have said they will facilitate the testing of the release
   4. Andrew slotted in an hour to start working on the testing. Super straightforward and easy - just in an hour’s time, pulled down code and release candidate branches, did a local build, and ran through some of the initial UI tests. We just want to make sure the basic functionality serving the vanilla case works on multiple platforms. 
      1. Need to do this kind of testing so we can provide release to community with more confidence
      2. May schedule time across a few days if it might be helpful to tackle some of these tests in a concerted fashion
   5. Kitio may have time to do some testing: perhaps Thursday and Friday
   6. Don: For those who don’t want to do vagrant, they can also look at vivo community template -> https://github.com/vivo-community/vivo-project-template/tree/rel-1.10.0-RC
      1. Vivo template is a github repo that uses submodules and has nothing to do with vagrant. Use Git to checkout this template, and then you can update all the submodules up to that level.
      2. Vagrant just checks out the VIVO template - allows for more abstraction, otherwise would need to put more clutter (i.e .version numbers etc.) in the Vagrant layer
   7. Andrew: how to use this template project in release testing?
      1. Don: Provides consistency between VIVO, Vitro, and a third-tier. Important to ensure all three tiers are at the same commit versions - and also runtime.properties etc. are in the right location. Moves some of the scripting that would have to be done in Vagrant into another place.
   8. Don: Transitive chain of credit giving (giving Benjamin credit for giving Ted credit)
   9. Andrew: who is the audience?
      1. Don: documentation that says this is a three-tier build, etc. would be useful to link from that documentation to this work since the template work provides scaffolding.
      2. Mike: Documentation on this is incomplete and more help would be appreciated. Need to include what to actually do step by step. 
      3. Benjamin: By using the submodules, you are committing to your GitHub the actual point of VIVO and Vitro repositories (versions) so you aren’t just changing versions without having a record of it. 
   10. Don: Template for recent branches (e.g. 1.9.3, dev-workshop, release 1.10) - you can see they all go to specific commits. 
   11. Andrew: for release testing, not sure if code would be expanded to use the template. Useful to address issues Mike was seeing, document, and share with community.
4. Mike: Note about release. As we conclude testing and move forward, documentation events should be happening simultaneously. Would need to ensure documentation matches release. Much more in 1.10 than in 1.9 but still need additional documentation such as for how to do a three-tier build. Useful for people working on release to also be aware of the documentation related. Open issues in JIRA marked as 1.10 and documentation. Not tagged as blockers. 
   1. Andrew: would you like to recruit people for this?
   2. Mike: yes, want to understand how to proceed. Might want to think about what we want to do. 
   3. Ralph: Guessing some of them will be closed as we go through issues. 
   4. Don: has action item to do three-tier build documentation
   5. Andrew: for 1.10, see three documentation tasks. 
5. Andrew: What is the barrier for people who are generally interested in VIVO to pick some easier tasks (low-hanging fruit)? E.g. documentation.
   1. Mike: Created documentation issue as a semi-blocker to ensure discussion around consistency between documentation and release happens 
   2. Issue 1274: What we’re trying to do that. Waiting for process
   3. 1450: Don. 1495: Mike. Require some additional writing
   4. Simple theming: written but needs review
   5. Preparing for production: written but needs review. Leave a comment in the JIRA 
   6. 772 and 1500: ready for review
   7. Copied from Slack: https://jira.duraspace.org/issues/?jql=project%20%3D%20VIVO%20AND%20issuetype%20%3D%20Documentation%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
      1. Needs review: https://jira.duraspace.org/browse/VIVO-1500
      2. Needs review: https://jira.duraspace.org/browse/VIVO-772
6. Andrew: Committing time on Thursday/Friday where we can all meet on Slack and walk through issues.
   1. Ralph: Friday works. Also around Thursday afternoon
   2. Don: No. Signed up for issue and may take time. 
   3. Mike: On the road
   4. Benjamin: could do Friday if something is organized
   5. Time that works? 
      1. Benjamin is open until 4 pm Mountain time. (A VIVO miracle).
      2. 1-3 PM ET? Yes.
7. Andrew: Release testing is very important. 
8. Don: SDB vs. TDB discussion at conference. May be useful to test this out - ACID and maybe performance testing
   1. Andrew: Seems a different domain than that for release testing
   2. Don: Pre-conference vagrant is TDB
   3. From slack: Commit where Ted converted Vagrant to TDB https://github.com/vivo-community/vivo-vagrant/commit/0cdca6de5aa894f81400735908cdf8c731bf8691
9. Mike: 1521: JIRA issue about moving to TDB and there are comments there as well. 
10. Kitio: Later, perhaps testing TDB as well would be way to go.
11. Andrew: Suggesting people do testing with Vagrant, so possible people already testing with TDB setup. 
    1. Branch for update be called rel-1.10.0-RC, and then tags for rel-1.10.0-RC-1 and rel-1.10.0-RC-2. 
    2. Primary branch will be SDB right now. That might change based on future discussions/decisions regarding the default back-end
12. Andrew pulls out gymnastics metaphor (I think) “I get the sense we will land this”. (Actually, that could be many things…) 
13. Dates proposed for an upcoming sprint: Sep 17-28. Not yet publicized (sp?).
    1. Inclined to lock that in for now 
    2. Don: Typical time period for changes for faculty around start of classes, so may be a busy time. 
    3. Kitio: 2 weeks for development. May be inclined to say earlier in September. Quite busy in October. 
14. Andrew: Next week, would like to spend time considering how to enable use cases that the community seems to be wanting/moving towards

Actions

• Don Elsborg to document "firsttime" resolution in CU BOulder wiki, circulate this doc to email list and discuss as a team how to integrate this in VIVO documentation