ocis VS gitlab

I found a way to do this : just copying the data over WebDAV using rclone (https://github.com/owncloud/ocis/blob/b2323752289d31c4844f36ef71a2ba531bd749c2/docs/ocis/guides/migrate-data-rclone.md)

According to the README[1] on their source repository, that is, flatly, untrue.

They say:

> We are very happy that oCIS does not require a Contributor License Agreement (CLA) as it is Apache 2.0 licensed. We hope this will make it easier to contribute code. If you want to get in touch, most of the developers hang out in our rocket chat channel or reach out to the ownCloud central forum.

They also say:

> Some builds of stable ownCloud Infinite Scale releases provided by ownCloud GmbH are subject to an End User License Agreement.

Which seems both reasonable and sensible...

[1](https://github.com/owncloud/ocis/tree/master)

ownCloud recently released version 3 of ownCloud Infinite Scale (OCIS), which is completely rewritten in Go (which means it's fast) and uses micro-services instead of a PHP monolith. It doesn't have any features like mail/calendar/contacts/chat/etc.. yet, just file sync (but that's all I'm looking for).

This feature request (https://github.com/owncloud/ocis/issues/6558) aims to implement mind-mapping functionality in a free Open Source Software similar to Google Drive called ownCloud Inifite Scale (oCIS).

Since the relevant code appears to be in the "ee" directory <https://gitlab.com/gitlab-org/gitlab/-/blob/v16.11.0-ee/ee/l...> and is not present in the foss repo, I'm guessing the answer is no, at least for now. They do have a history of "releasing" features from EE back to CE but my suspicion is not for LLM stuff

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that https://hub.docker.com/layers/multiarch/qemu-user-static/7.2... actually mutates the binfmt_misc in buildx's context in order to exec the static copy of qemu in it https://github.com/multiarch/qemu-user-static/blob/v7.2.0-1/...

and, that the buildx plugin itself has some qemu magick in it, which got addressed in a minor version bump but I couldn't track down the relevant GitHub issue this second (I've flushed it from my mind, only recalling that there were a lot of actors in that tire fire)

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...