COOL TC meeting minutes: 2026-05-06

Development
1

Present:

  • Michael M, Noel, Andras, Caolan, Michael S, Stephan, Thorsten, Tomaz, Miklos

Completed action items

Pending action items

  • For next week set stats tool to monitor monorepo (Szymon)

Monorepo setup (Michael M)

  • Long way down this path already …

  • No perfect solution of which way to merge here (Miklos)

    • not re-writing history was a design feature.

  • git blame follows the renames nicely

  • git log –follow # is not working

  • Unhappy with core merged into online, not the other way around (Noel)

    • most of the commits are on the core side

  • What is the primary concern? (Michael M)

    • web links are not a concern (Michael S)

    • all other places where commits are referenced is a problem

    • possible: when rewrite the history, add a footer with the old hash

  • More happy with adding a footer header to the old git commit hash, if we do a rewrite (Stephan)

  • Can’t mirror to standard web hostings without this (Thorsten)

  • Lot of problems with redoing the work of the past month (Andras)

    • Concerned that this takes time instead of focusing on more important things

    • The required work sounds quite large, for little benefit

  • Pros

    • Can structure the tree the way we like, git-log works trivially

    • Can mirror to github

  • Cons

    • Redoing the done work of creating the monorepo (Andras)

    • Getting commits by old hashes requires some workaround or other

  • Who would be interested in doing the work here? (Michael M)

    • interested in writing the tooling (Noel)

    • branches? (Michael M)

  • What is the problem with broken objects ?

    • Some of the E-mail addresses have an invalid format – author/committer wrongly formatted

      • check for other things too [!] and test it.

    • ‘git fsck’ can detect these (Stephan)

      • github issue → could we clone existing broken LibreOffice github core repo – and re-purpose it as our online repo ?

      • And add our online around it ?

      • Can we take the core repo – move it into the engine/ directory

      • and as a 2nd root take the online repo ? …

  • Do we run clang-format on the changes ? (Michael)

    • keep re-write as minimal as possible – excited, and do lots of things
      improvements to the product.

    • clang-format breaks operators … and comments etc (Stephan)

  • git blame 564ec47db30e8^ sc/inc/document.hxx (Noel)

    • this runs in the top-level folder, but not inside engine/

  • real problems with configure.ac which is in engine/ and the core

  • Conclusion:

    • give this a bit more time – lets see if git log will work out of the box

    • re-visit in a while.

Release Engineering update (Andras)

  • Monorepo status

    • Still to be added on main: --enable-coplugin, fuzzer, lighthouse

    • Branches: this remains unchanged for now, only GitHub has CI (Andras)

    • Then make github readonly, moving patches across, then translations.

  • Releases (Andras)

    • CODE 26.04:

    • Need to write the packaging jobs for COOL & CODE – so far only snapshot bits.

    • Translation integration into repository / build needs doing

      • with weblate setup – checked in without line #’s

    • like to release new Collabora Office from same 26.04 code-base

      • for Windows/Mac/Linux etc.

CI status (Szymon)

  • Had a big backlog

    • Two problems were causing test failures recently

      • now fixed.

  • Time to build ~ 70 minutes

    • when splitting separately – desktop tests take ~40 minutes. (Andras)

      • previously we had four different Jenkins / CI jobs – so things ran in parallel

      • currently cypress does one after another – we should do them in parallel

      • We can do even more – we have 120 tests in desktop/

        • we have 60 tests in mobile, and fewer for the others.

    • Can we do something different ? (Noel)

      • one cypress jenkins job – and run more of the tests in parallel

      • currently we only run four in parallel.

      • Chrome has to be started, interface is clicked etc.

      • Noel has a patch in progress to run sixteen in parallel.

    • will switch to this scheme as/when can stop github jobs

      • why wait ? (Noel)

        • can we do this now ?

        • Requires stopping the CI for github immediately ? (Andras)

          • we have around 80 PRs there to test/merge before closing github down.

      • Many of these perhaps wait for gerrit to have good CI

    • Adria is moving checks from github → gerrit for co-25.04 branch → WIP.

    • Can remove 23.05 jobs soon – when this is EOL’d soon

      • we can re-enable the job if necessary – it’s the git objects and build artifacts.

  • Mohit’s monorepo test change

  • Flatpak builds really necessary for every patch? (Noel)

    • has a bottleneck of getting bits in the end-stages of the build assembled (Stephan)

      • this takes a while.

      • Instead of letting Jenkins build a flatpak which is different to flathub anyway

      • can build CODA-Qt as a non-flatpak as well, switch CI to do that – should be quicker without the flatpak overheads

    • flatpak is the limiting factor → even longer than cypress → ~80 minutes

      • pulling in the developer environments …

      • Need an LXC container it builds in …

        • If Alma-linux-11 has it – fine …

          • need a recipe for an LXC container that can build coda-qt

        • enough to suggest a distro that has an LXC container & so on.

      • Goal is nice developer experience …

    • Don’t have a Windows compilation job currently …

      • also planned → needs to be done – to have dependencies for CI windows machine
        so far have deps on package builder machine.

Patch review

Bug reporting

TTT talks

What’s cooking

  • Michael S

    • Poking at lots of release branches for security fixes

  • Stephan

    • JS UNO callback ideas going in …

    • Collaboration thing into some gerrit patches …

  • Andras

    • already published Snap package on the snap store …

    • Missing – to write a CI job to produce the snapshots regularly

      • marketing + home-pages on Ubuntu snap-store needs doing.

        • In theory can update at any time – need to move this to the monorepo …

  • Szymon

    • Missing Szymon

  • Quikee

    • Getting missing JSON primitive processor merged – then how to get online bits in too

      • trying to get the rendering working again – not just for thumbnails but whole slides

      • even today changes are going in …

  • Miklos

  • Caolán

    • crashtesting is up & running, many finds (~700), improving (~500)

    • merging a11y patches left and right too …

  • Thorsten

    • customer branch maintenance

  • Noel

    • cypress_test parallelization work

    • trying to find memory leaks

  • Michael M

    • faster spell-checking in calc cells… avoiding idle invalidation
2

Tried to send the below as an email reply, which this unhelpful thing refused to accept:


On 5/6/26 17:12, Miklos Vajna wrote:
[...]
>   <https://forum.collaboraonline.com#p-10045-monorepo-setup-michael-
>   m-4>Monorepo setup (Michael M)
[...]
>   *
>
>     What is the problem with broken objects ?
>
[...]
>       o
>
>         ‘git fsck’ can detect these (Stephan)
>
>           +
>
>             github issue → could we clone existing broken LibreOffice
>             github core repo – and re-purpose it as our online repo ?
>
>           +
>
>             And add our online around it ?
>
>           +
>
>             Can we take the core repo – move it into the engine/ directory
>
>           +
>
>             and as a 2nd root take the online repo ? …
Yes, we can.  The below is a throwaway script that I used right now to randomly set up <https://github.com/stbergmann/core> as a SHA-identical clone of <https://gerrit.collaboraoffice.com/online>:

> #!/bin/bash
> # Replicate the co/online (gerrit) repository into a GitHub fork of
> # libreoffice/core, with every commit SHA preserved.
> #
> # Why a fork of libreoffice/core: GitHub re-runs git-fsck on objects
> # new to the receiving repo and rejects malformed ones. Some of the
> # old core ancestors reachable from co/online have malformed author
> # identities. Pushing them as new objects would fail. But objects
> # already present in a repo's fork-network object pool are exempt
> # from fsck on receive. By forking libreoffice/core on GitHub, all
> # those old core ancestors land in the destination's pool for free,
> # and only the online + engine-merge commits are fsck'd at push time
> # (those are clean).
> #
> # The destination must already exist as a GitHub fork of
> # libreoffice/core (created via GitHub's "Fork" button, so the
> # object pool is shared).
> #
> # Usage: replicate-online-to-github.sh <work-dir>
>
> set -euo pipefail
>
> DEST_URL="git@github.com:stbergmann/core.git"
> SRC_URL="https://gerrit.collaboraoffice.com/online"
>
> if [ $# -ne 1 ]; then
>     printf "usage: %s <work-dir>\n" "$(basename "$0")" >&2
>     exit 1
> fi
>
> WORK_DIR="$1"
>
> if [ -e "$WORK_DIR" ]; then
>     printf "error: %s already exists\n" "$WORK_DIR" >&2
>     exit 1
> fi
>
> printf '==> Cloning source: %s\n' "$SRC_URL"
> git clone --progress "$SRC_URL" "$WORK_DIR"
> cd "$WORK_DIR"
>
> printf '==> Adding destination as remote "github": %s\n' "$DEST_URL"
> git remote add github "$DEST_URL"
>
> # Fetch the destination's refs so the subsequent push can compute a
> # minimal pack (it will skip every object the fork already has via
> # the libreoffice/core pool).
> printf '==> Fetching destination refs\n'
> git fetch --progress github
>
> # Sanity check. Issues reported here for old core ancestors are
> # expected and harmless: GitHub will not re-fsck them on push because
> # they live in the fork-shared pool. What matters is that no
> # online-side or merge-side commit has its own fsck issue, since those
> # WILL be fsck'd at push time. Inspect the log if push later fails.
> printf '==> Running git fsck (output saved to fsck.log)\n'
> fsck_log="$(pwd)/fsck.log"
> git fsck --strict --no-dangling 2>&1 | tee "$fsck_log" || true
>
> # Build refspecs for every branch and tag in the source. The "+"
> # prefix forces non-fast-forward updates; the destination is a fresh
> # fork whose refs we want to overwrite with co/online's.
> printf '==> Collecting refs to push\n'
> refspecs=()
> while IFS= read -r ref; do
>     branch="${ref#refs/remotes/origin/}"
>     [ "$branch" = "HEAD" ] && continue
>     refspecs+=("+$ref:refs/heads/$branch")
> done < <(git for-each-ref --format='%(refname)' refs/remotes/origin/)
>
> while IFS= read -r tag; do
>     refspecs+=("+$tag:$tag")
> done < <(git for-each-ref --format='%(refname)' refs/tags/)
>
> printf '    %d refs queued\n' "${#refspecs[@]}"
>
> printf '==> Pushing to %s\n' "$DEST_URL"
> git push --progress github "${refspecs[@]}"
>
> printf '==> Done. %s is now a SHA-identical copy of %s.\n' "$DEST_URL" "$SRC_URL"