Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- William Welling
- Andrew Woods
- Bruce Herbert
- Ralph O'Flinn
- Brian Lowe
- Michel Héon
- Don Elsborg
- Huda Khan
- Benjamin Gross
Agenda
- Current community sprint outcomes?
- ORCID
- Kafka
- Messaging
- Weill Cornell testing updates - Sarbajit Dutta
- 1.11.2 patch release
- Transition from JIRA to GitHub-Issues?
- Working towards 1.12
- To be reviewed
- Documentation needed
- 1.12 release planning
- Email of schedule to vivo-community
- Code freeze once i18n tickets are merged into the sprint-i18n branch (Jan 20th)
- Sprint to test merge of sprint-18n into master: week of Jan 25th
- 1.12 release candidate #1: Feb 1st
- Two week RC-1 testing period
- For each subsequent RC-2 (if required), adding another two weeks to the schedule
- Do we want the `war` install in 1.12? -
- To be reviewed
- Tickets that should be close to merge
- Post-i18n priorities
- VIVO-in-a-box
- Messaging
- Moving Scholars closer to core - next steps
Future topics
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be?
- Renaming of 'master' branch? (ZDNet, BBC)
- Guidance from GitHub
- DSpace has done it
- Fedora has done it
- Samvera is doing it
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
Attendees
- Andrew Woods
- Nicolas Dickner
- Michel Heon
- Bruce E Herbert
- Sacha Jerabek
- Ralph O’Flinn
- William Welling
- Paul Albert
- Sarbajit Dutta
- Brian Lowe
- Huda Khan
Notes
- Sacha: UQAM had internal sprint with web developer to restyle VIVO.
- Sprint updates: testing Kafka with ORCID - UQAM and TIB
- Michel: retrieved all users from ORCID; persons batch-pushed into VIVO using Kafka.
- Conversion from ORCID JSON to VIVO RDF; sent to Kafka channel; pushed to VIVO.
- TIB worked on listening to VIVO changes and sending them to Kafka channel.
- Next step is putting this work on Github.
- Will continue to develop this method of injection in December/January.
- Bash scripts will be converted to Java code/services.
- Advantage of this approach is reusable design patterns / Kafka consumers.
- All messages on Kafka channel are in “VIVO” format using VIVO vocabularies.
- Kafka workflow and ReCiter?
- Paul: Our VIVO is read-only, so won’t be used to syndicate content out via something like Kafka.
- Andrew: Kafka producer and consumer architecture can include mediation steps before being consumed by VIVO.
- William: Could any triple changed in VIVO be immediately streamed out via Kafka? Or would it need to buffer and batch up changes?
- Michel: Kafka intended to be used in real-time streaming applications using large amounts of data.
- William: seems like an advantage over something like ActiveMQ.
- Kafka consumers/producers should be internal to VIVO; use consumer instead of SPARQL API.
- Ralph: next week should be a data ingest meeting with demo from TIB. Vote for date/time on data ingest Slack channel.
- Messaging architecture may reduce need for or desirability of intermediate relational data stores between raw data sources and VIVO.
- Sarbajit: API bugfix testing
- Works as long as maxPostSize is also correctly set.
- Site admin users unable to add new individuals
- Huda: has taken an initial look at things; will make some more time to stare at the code. Huda and Andrew had looked at the options and while there are opportunities for long-term refactoring, it is probably better to release a patch that works right away and then consider a better long-term strategy. Brian will also try to look more at the issue and add hints to the JIRA issue if they suggest themselves.
- Using Github issues instead of JIRA
- Michel: sprint planning?
- Ralph: Github has features that match most of what JIRA has.
- Michel: Github generally seems like a big list of issues, but hard to categorize.
- Andrew: there are different labels to apply to issues.
- Tooling on top of Github issues?
- William: There are various projects for more elaborate Kanban or other things on top of Github issues. Lot of work to make it happen: may not be something we want to take on at this time.
- William: Might be good to have trial run with Github issues before moving everything other.
- Andrew: have meeting with Tim Donahue of DSpace project. DSpace has already done a similar transition. Will ask for feedback/advice.
Actions