...
Indicating note-taker
- Ralph O'Flinn
- Kitio Fofack
- Tim Worrall
- Brian Lowe
- Don Elsborg
- Andrew WoodsBenjamin Gross
- Marijane White
- Huda Khan
- Mike ConlonAlex Viggio
Agenda
- 1.10 Release Testing
- Released projects/artifacts (rel-1.10.0-RC-1)
- vivo
- vitro
- jenatools
- sample-data
- orcid-api-client
- VIVO-languages
- Vitro-languages
- VIVO-Harverster
- vivo-vagrant
- Released projects/artifacts (rel-1.10.0-RC-1)
- Post-VIVO Conference actions and opportunities
- Salient use cases
- Standard, full-app with focus on profiles
- Headless component of research intelligence ecosystem
- Minimal store in support of modern, custom UIs
- Multi-source ingest: OpenHarvester, Combine, Reciter, etc
- ??
- Salient use cases
- Next sprint? Sept 17-28
- Suggested updates from Michael J. Giarlo
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1502 Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1503
Notes
Release
Andrew: pleased to note that the identified blockers have been removed. So far as I know, we are good to go with the release candidate.
Benjamin: the .pom file for the Jena tools might need to be incremented to the next version, and someone probably needs to upload it to Maven Central.
Mike: Not user-friendly to make someone download Jena tools separately, so yes. Need to update the jars in Maven Central.
Ralph: need to change .pom file and create new jar files.
Andrew: Benjamin, create pull request?
Benjamin: yes, put part I can’t do is upload jars to Maven Central.
Andrew: I can do that and request that your name be added to the list.
Mike: I can test when you have it there.
...
Andrew: we need to have green check marks across the board on this page in order to do the release.
When you’ve done testing, indicate that you did it, plus any comments about what you saw.
This is a new page, so it probably has bugs. Also worth making sure that this is the page we want it to be.
Is it comprehensive enough? Does it cover the functionality? Is it clear enough that people can actually do the testing?
Mike added a whole bunch of content recently that further fleshes this out.
Mike: added things based on experience in the past, e.g. performance tests. Don’t want to go backwards on performance from one release to the next.
Andrew: Do we have performance tests?
Mike: We need to generate test data for performance tests, e.g. profile with 1500 publications. Also need tooling.
Jim: Developer tools allow you to log the time taken to execute any SPARQL query.
Jim will add link to documentation about the developer tool SPARQL query logging.
Andrew: Section on Vagrant testing on wiki page. What is the scope of the tests we would like to do on the Vagrant environment?
There are performance tests listed here and it’s not clear that that’s relevant to Vagrant.
Don: Have Vagrant three-tier build template based on what Ted did. I can replicate whole CU site in 1.9.3, will continue doing the same for 1.10.
Have a complex CONSTRUCT query that we use; can run comparison between 1.9.3 and 1.10.
Andrew: Opportunity to have a whole institutional environment in Vagrant.
Will ask Alex about whether the CU data can be shared more broadly for testing elsewhere.
Mike: Expect Vagrant to be our primary VIVO evaluation mode.
Might have to build out data for evaluation purposes. The more data the better VIVO looks in evaluations
Andrew: Want to have empty Vagrant to test that it works, plus an easy script to populate Vagrant VIVO with data for testing.
Andrew: Clearly would be good if we could add additional links to documentation from the testing plan.
In the future, would be good to have these set up as automated integration tests. Right now just building a manual process.
Andrew: Can I ask for volunteers to do some testing? (In the weeks after the conference)
Ralph, Benjamin, Don, Mike, Javed (UI + Jena tools)
Jim: interested but not ready to commit until sees how things stand after the conference.
Andrew: Which artifacts should be part of the release? (Tag in Github, actual release, .pom version updated, etc.)
Ralph: I thought it was all of them.
Andrew: Is it complete?
Some of these have never actually been released, so I wondered if it was appropriate to include them. (E.g. vivo-languages.) What does that mean?
Mike: Never been associated with a release. They’re on their own. Here we’re trying to take some ownership of it and make sure it works.
Andrew: How do the languages get pulled in or used?
Benjamin: Have to add dependency to your .pom for them to be used. Have to find the documentation that says how to do it and then add the dependency.
There definitely should be a release of the languages for 1.10.
Andrew: Is ORCID API client tied to the release, or can it have its own numbering scheme?
Jim: tied to release of API, not to release of VIVO.
Ralph: ORCID API is on 2.0. Do we track with that?
Jim: That way lies madness.
Andrew: 0.4 seems reasonable.
Andrew: Creating tars and zips seems to be a manual process.
Do we know of any tools, and are they good release artifacts?
Mike: Reasonable goal for 1.10.1 to improve tooling, but don’t let it hold up release.
Andrew: Process will be to examine artifacts for previous releases and replicate their structure.
Steps: Creating release candidate branch, tagging branch, and creating artifacts. Andrew needs help preparing the release candidate: Ralph will help and expects to get it out sometime today. Kitio would like to assist. Ralph will be in the dev slack channel.
Andrew: Start to document some of this stuff on the release process document (1d). Committers, we may need help creating the branches and tags if Ralph and Kitio don’t have permission.
VIVO development workshop
...
Don: Created Google Drive folder and believe Alex was going to share it.
...
Prerequisites: Try to get Vagrant working, and if not get a working Tomcat and Eclipse, also Github account.
...
Work off of forked repo?
...
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?
E.g., how to do a three-tier build inside Eclipse?
Please put anything else in there that you really want to learn?
...
Don: Will send out to community mailing list
...
Huda: If we focus on the participants that probably makes more sense. Would be good to know if the workshop participants have something they want to work on.
...
Andrew: In terms of prerequisites, I added a link to Git Desktop. Bridges the gap for Windows folks with tools like ssh -- often a blocker for this type of workshop.
...
#dev-workshop Slack channel
Slack topic
Skipping for now.
3. Unconference ideas
Interconnecting VIVOs?
Getting together as committers?
Collaborating across initiatives, communicating across channels
Huda: How is this going to be decided? Will we vote at beginning of conference, or just sign up?
Mike: No one knows.
Andrew: Sounds like people will have the opportunity to pitch their session. Other than that, not sure.
4. Next sprint in September
5. Local Stanford customizations to roll in if we would like
...