Hello Jitsi developers. First of all: Thank you for creating this awesome software. We set up a small server with ~100 users which we’ll want to scale to a slightly bigger installation with about 20.000 users. We have a few ideas and wanted to know your feedback before jumping in head over heels.
Follow Jitsi upstream with Docker tags
While setting up Jitsi in a docker-compose environment, we became confused several times due to the nature of the Jitsi development process. As we’re not familiar with the codebase, it was pretty hard to find out which upstream version of jvb or prosody the image tags correspond to.
For example, if you want to know which software versions are in tag 4384, you’d have to correlate the dates of the jvb release with the docker build date.
Would it be possible to tag the images in a more intuitive way, so that one can ascertain directly which version the image corresponds to? For example if you use prosody 0.11, the docker image tag could be named prosody/0.11-build4384 or something like that.
Jenkins Tags / Git workflow
Currently, it seems like you’re auto-tagging releases with Jenkins after every commit to master on Github, e.g. for Jibri:
In our opinion, this is too verbose for an end user/admin. While scrolling through >3800 tags it’s not directly clear which changes occured in a release.
What Jenkins is doing is apparently just zipping the repository, not creating a runnable release, is that correct? Example: https://github.com/jitsi/jitsi-meet/releases
Versioning / Releases
You sometimes push directly to master, which again leads to Jenkins creating a new tag. Maybe the popular git-flow model would be beneficial for clarity. You could have a single “stable” branch (possibly master?) and only merge after someone reviewed the changes.
We think properly following SemVer/git-flow and having clearly worded change logs would be nice. Automatically tagging releases was a source of confusion for us, as described above.
Maybe internal releases don’t need to be published to the public. Tagging only “proper” releases which are ready and stable to use would be awesome.
Upstream Docker images
It would be cool if you could make more use of upstream docker images and try not to cook own images based on Debian.
For example, maybe nginx doesn’t need to be built based on a Debian base image if you only change the config files. There’s an official docker image for nginx which can be extended. These images have the advantage of being optimised for Docker usage and having more recent releases of nginx built directly from source into a Docker image.
Prosody’s official image on the other hand is borked, too – they use the Debian 9 “stretch” repository even though their github repository for Docker shows FROM debian:10 in the first line of their Dockerfile. While we’ll try to resolve this with Prosody upstream, we wouldn’t recommend using their Docker image. In the meantime you could maybe try using Debian 10 as a base image? The current setup leads to using Debian 9 with a backports repository for Prosody, which is a tad weird in our opinion as both Jitsi and Prosody seem to support Debian 10 “buster”.
What we can do for the project
We’re able to throw money onto this and possibly also contribute code/Pull Requests if the path you want to take is clear.
We’d like to start a discussion about the proper way to – possibly – restructure the development/deployment process to make it easier to contribute to the project, but of course do not want to overturn any decisions made by the dev team.
Kind greetings from Mannheim, Germany,
@itronik and helix