3 December 2025 — Minutes

[atomizable]

OpenRiak Working Group Meeting Summary

Date: December 3, 2025

Roll Call

• Martin Sumner
• A.G. Madi / George Madi
• Adrian Fraiha
• Alistair Woodman
• Andrei Zavada
• Nicholas Adams
• Peter Clark
• Ted Burghart
• Robert Carbone

---

1. Documentation Updates & Processes

• Markdown documents are being converted to HTML using a simple Ruby-based template.
• Only basic features implemented so far; focus is on converting text, with support for code block highlighting.
• Mermaid diagrams are supported (with some flexibility issues). An example will be provided by Monday.
• Issues have been raised on GitHub for converting the template to Asciidoc and for CI improvements (spell-check, link-check, etc.).
• A public preview link for the docs will be published by the end of the week.
• Content review is now closed; focus shifts to presentation. Minor content tweaks may still occur, but the aim is to minimize content changes.
• Presentation changes will have a streamlined review process—if no objections within a working week, changes are assumed approved.

2. Release Preparation and Branching

• Default branch for all open repos will change to “openriak-3.4”.
• Cleanup planned for old branches and features (e.g., pipe and ensemble).
• Next personal priority: prototype for merge-branch behavior, which must be proven before adoption.
• Need for scaling up nonfunctional and performance testing for the upcoming release; hardware and cloud resource limitations are noted, and community help is requested.

3. Performance Testing and OTP Version Issues

• Two-year discussion about OTP 27/28 performance regressions compared to OTP 26, mainly due to binary handling refactors.
• Recent changes from Ericsson and local memory optimizations have closed the performance gap. The worst case is now about 10% slower (previously 30–40%). Issue is considered resolved for now, but future OTP versions will continue to be monitored.
• Testing across different hardware (Intel, ARM, etc.) has shown inconsistent results, so ongoing vigilance is planned.
• Appreciation expressed for Ericsson’s efforts and acknowledgment of the complexity of the underlying changes.

4. OpenRiak Website and Release Announcement

• Upon the 3.4 release, the OpenRiak.org site should be updated to include a prominent link to the release/announcement.
• Discussion about who controls the site and whether to move it under the OpenRiak GitHub org.

5. Working Group Proposal & Structure

• A new working group proposal document has been drafted, including a mission statement, organizational structure, objectives, and initial deliverables.
• Structure involves eight coordinator groups (e.g., performance/testing, observability/tooling, security/interconnection, interoperability/integration, etc.).
• The aim is to keep bureaucracy minimal while ensuring clear reporting and division of responsibilities.
• The group agrees to submit the current draft as-is, with the understanding that it can be revised in the future.

6. Other Technical Issues

• Minor questions/issues raised about PRs and dialyzer warnings, particularly relating to capability management and rollbacks.
• Plans to open tickets for lingering issues and track them in the core repo.

7. Action Items and Next Steps

• Rob will submit the working group proposal.
• Documentation preview and mermaid diagram example to be published.
• Start renaming branches and prepping for functional tests for the 3.4 release.
• Community help is requested for nonfunctional/performance testing.
• Announcement and website update planned for January release.
• Next meeting scheduled for January 7th, 2026

8. General Sentiment

• Group is focused on progressing towards the 3.4 release and establishing a sustainable, open, and community-driven future for OpenRiak.
• Emphasis on keeping processes lightweight, welcoming new contributors/funders, and maintaining flexibility for the future.

---

[mlarribe]

Regarding Community help is requested for nonfunctional/performance testing.

What kind of help are you requesting ?

[martinsumner]

Previously, a major Riak user would run non-functional tests for each release in their cloud environment. I would give them the basho_bench branch and script to test with, and they would setup a cluster and run the script, forwarding on any results as well as stats from the environment during the test. They would then run further tests with failure events, and with recovery processes under load.

They're not able to continue to do this for OpenRiak in the future, so we need to find an alternative. That could mean another user who could run the tests for the OpenRiak community, as the previous user did. Or just providing financial help to the Erlang Ecosystem Foundation for developers within the community to run the tests.

There are a mixture of 24-hour and 48-hour tests we would prefer to run for every major release. Ideally we would want to run a cluster for a month of testing, as we did with the initial preview of the 3.4 release a year ago. But the minimum is to have an environment for a week of testing.