...
Moving forward reviewing PRs on VIVO and Vitro
- https://github.com/vivo-project/Vitro/pulls and https://github.com/vivo-project/VIVO/pulls
- Tiny and big PRs classification
- Assignment of reviewers
- VIVO open GitHub issues
- VIVO 2.0 architecture
Notes
- PRs on VIVO and Vitro
A short report about the first PRs pass from Ralph was expected. Unfortunately, Ralph was absent, therefore discussion is moved to the next committers call. - GitHub issues - VIVO
Dragan: I am reviewing open GitHub issues. I closed some issues (was already resolved or not reproducible). There are some issues which should be migrated to the ontology github repository. Also, some issues might be resolved only by French native speakers.
3. VIVO 2.0 architecture
Dragan: We started discussion at the end of previous meetings. We should align our visions and define direction.
Georgy: Step one sounds like a wrapper (REST facade) which might introduce new bugs. It would be nice that a REST api and new front-end is an option, but it might be risky to fully get rid of FreeMarker. It might look like the project is not active while we are working on this radical change, I am more for small steps in improvements which might allow us to continuously work on resolving bugs and implementing new features.
William: It sounds as a standard dilemma when you are thinking about removing some legacy code and reengineering. When is the right moment? I don’t like the fact that FreeMarker is server side rendering.
Benjamin: Not a big fan of FreeMarker, and more for replacing it with new UI framework, but there might be some nice feature with FreeMarker (easier for learning)
William: Whatever we decide we need specification and good plan
Georgy: Presented his idea about Dynamic API based on an ontology - https://wiki.lyrasis.org/display/VIVO/2021-11-02+-+VIVO+Development+IG?preview=/225150583/225150589/Dynamic%20API%20description%20example.pdf
Brian: Nice idea, might help in defining custom forms
William: What about notation for describing a task? Might be complex for implementation. What about performance?
Georgy: Notation of queries shouldn’t be hard as we have basic instruments to describe individuals in VIVO. Implementation might be slightly more complex in planning, but I think it will help reduce the amount of needed code significantly thereby reducing time of implementation. Cache component in the diagram should help reduce time consumption for read requests against triplestore by caching results and invalidating cache by listening for changed data in triplestore.
William: I like the idea, well-done.
Georgy: In this situation I believe we don’t have simple solutions, so we need a good plan.
4. Releases management
Brian: Where are we standing at the moment regarding releases? VIVO 1.12.1 is not yet functional? Maybe Ralph needs help. It would be nice that the procedure for releasing is simple enough that all committers might prepare a release.
Dragan: This will be on the agenda for the next meeting and discussed with Ralph who is the VIVO release manager.
Actions
- Ralph O'Flinn first pass through PRs and sending out an email to other committers
- All to read and provide feedback for VIVO 2.0 architecture https://docs.google.com/document/d/1z51mkqlAopQ2rLkitHiQVwRojijnPM9pB8tQelW-lSA/edit?usp=sharing
Previous actions
- Ralph O'Flinn first pass through PRs and sending out an email to other committers
- Brian Lowe Huda Khan Ralph O'Flinn to review GitHub issues assigned to them. Are you still interesting in those issues? Maybe it is even resolved meanwhile or not of interest for VIVO community (especially for issues opened 5 or more year ago).
- Dragan Ivanovic to continue first pass and reviewing of GitHub issues
- All to read and provide feedback for VIVO 2.0 architecture https://docs.google.com/document/d/1z51mkqlAopQ2rLkitHiQVwRojijnPM9pB8tQelW-lSA/edit?usp=sharing