Hi all, Here are the notes from yesterday's monthly Unomi meeting.
Attendees: Serge (Inoyu), Jérôme (Jahia), Jonathan (Jahia), François (Jahia) --- ## 1. Multi-tenancy PR breakdown & Git workflow Serge presented his approach to breaking down the large multi-tenancy work (PR #760 - "UNOMI-139 UNOMI-880 UNOMI-878 UNOMI-884: Multi-tenant platform core") into smaller, easier-to-review PRs using git-town ( https://www.git-town.com/) for stacked PR management. The main challenge is that PR #760 is still very large (both in number of files and lines changed) because the multi-tenancy changes affect many parts of the Unomi codebase. This is currently too large for some automated review tools such as GitHub Copilot's reviewer. Other stacked PRs are smaller and easier to review, but contain less of the core platform changes. ## 2. Review approach and guidelines François shared feedback from Jahia's perspective and a discussion followed about the review process. ### a) API compatibility and versioning François asked whether semver and API compatibility would be maintained as part of this work. Serge explained that the V2 compatibility layer should ensure backward compatibility, and that no breaking changes are currently expected, the goal being to keep this work within the 3.x release line. Serge also mentioned an API test harness (not yet contributed to the project) that may help validate API compatibility during this work. There was consensus on making every effort to adhere to semver strictly and to identify and correct any compatibility issues if they arise. If unavoidable breaking changes are discovered, versioning changes would need to be discussed separately on the mailing list. ### b) AI-assisted code review Because of the size and complexity of the changes, François suggested exploring a dedicated AI review agent beyond the default GitHub Copilot reviewer. Specifically, the Java reviewer agent from ECC ( https://github.com/affaan-m/ECC/tree/main) was mentioned as a candidate to review PR #760 locally (leveraging GitHub CLI and GitHub MCP), with custom review guidelines to provide contextual feedback. This was discussed as a practical way to support the review effort given the scale of the changeset. ## 3. Review capacity and project stability A discussion took place about how to approach reviewing the volume of changes while keeping the project stable for contributors and adopters. François expressed that from Jahia's perspective, having master in a stable and releasable state remains important — particularly as Jahia expects to increase its contributions to the project later in the year (bug fixes, minor improvements, production deployments). The group acknowledged that keeping master reasonably stable benefits all contributors and adopters. François also noted that if maintaining alignment on master stability proves impractical given the pace and scope of changes, Jahia may need to evaluate maintaining a separate fork to ensure continuity of its own production needs. This is not intended to slow down progress, quite the opposite, the goal is to support Serge's improvements moving forward. It is a practical consideration and the strongly preferred outcome remains continued collaboration on the project. ## 4. Proposed next steps - Serge to continue breaking down multi-tenancy work into smaller PRs where practical. - Continue efforts to validate API compatibility during the multi-tenancy work; consensus on making every effort to adhere to semver strictly and correct issues if found. - Explore whether the ECC Java reviewer agent (or similar tools) can help with reviewing PR #760. - Continue discussion on the mailing list as needed. --- Next meeting: June 11th, 9AM CET Best regards, François
