Sync our codes to OntoPortal

syphax-bouazzouni commented 6 months ago

Context

This topic was introduced and discussed in the Ontoportal 2023 workshop. For more details, please refer to the OntoPortal code management session notes.

After connecting our codes to OntoPortal in this GitHub issue, the next step is to define and implement procedures and tools to facilitate code updates for users of Ontoportal.

This topic can be divided into three main aspects:

1 - Update the Upstream Ontoportal Code

Currently, the Ontoportal upstream code represents the UI for the NCBO/Bioportal version and, for other components, an outdated version of Bioportal that is no longer synchronized with the latest release. Additionally, BiodivPortal, EcoPortal, and EarthPortal are using AgroPortal version 2.40, while Agroportal itself is in version 2.7.0, featuring major changes in UI and API.

The goal for the upcoming year (2024) is to have the Ontoportal upstream code synchronized with the latest version of Agroportal or any other proposed version.

2 - Notify Ontoportal Forks of Updates and New Releases and Assist in Getting the Latest Version

Every time the upstream Ontoportal is updated, all forks should be informed of the new version through a pull request that details the code changes, allowing them the option to merge or not.

3 - Update the Appliance Infrastructure

Updating the infrastructure manually is currently the only solution, as outlined here for minor version updates (which are rare). In the future, updating the infrastructure may become easier as we explore adopting Docker, making it programmatically simpler to update, add, or remove infrastructure components.

Action Items

In the upcoming year, we aim to:

[ ] Synchronize the Ontoportal upstream code with the latest version of Agroportal or any other proposed version.
[ ] Assist Ontoportal forks in obtaining the latest version if desired.
[ ] Establish a mechanism to notify Ontoportal forks of new code releases and facilitate incremental merging.
[ ] Continue progress on Dockerizing Ontoportal.

syphax-bouazzouni commented 6 months ago

The Bioportal case is a part of this roadmap, given its inherent complexity. One proposed solution involves deploying a testing version in parallel with the current Bioportal. This testing version would run on the latest Agroportal code while utilizing Bioportal data. The overarching goals of this solution are as follows:

Avoid Code Review and Merge Processes: By running a testing version in parallel, the complexity of reviewing all code changes and resolving merge conflicts can be avoided. Currently, attempting to merge Agroportal UI into Bioportal UI results in challenges, as illustrated by the image below, representing a diff between the two codebases:
Inspect or Implement New Instrumentation for Scalability and Debugging: This parallel deployment allows for the inspection of existing instrumentation or the implementation of new tools to debug the scalability of our code under large loads. It also provides the opportunity to catch bugs on the fly. Key metrics to focus on include page speeds, API call frequencies, and generated SPARQL queries.

jvendetti commented 6 months ago

In the upcoming year, we aim to:

Synchronize the Ontoportal upstream code with the latest version of Agroportal or any other proposed version.

@syphax-bouazzouni - could you clarify what you mean by "any other proposed version"? Are you also referring to AgroPortal here?

syphax-bouazzouni commented 6 months ago

In the upcoming year, we aim to: Synchronize the Ontoportal upstream code with the latest Agroportal or any other proposed version.

@syphax-bouazzouni - could you clarify what you mean by "any other proposed version"? Are you also referring to AgroPortal here?

Hello @jvendetti ,

By another version, I mean something that can be a sort of intersection of features that all people agree on, incrementally adding features to the Ontoportal upstream code. However, this approach will be a lot harder for us (AgroPortal) as we need to extract and tweak things, and it may take a lot more time (and resources that we may not have).

I prefer the approach where people take all our code and then disable, adapt (remove) things to suit their local needs, which I think is easier (an approach that I experimented with last year with Ecoportal – starting with the AgroPortal code and re-adding their existing local features by looking at their commit history).

jvendetti commented 6 months ago

Thanks for the added clarification @syphax-bouazzouni - I understand what you meant now

ontoportal / ontoportal-project