[FFmpeg-devel] Regarding Git Tooling

[martin schitter]

On 22.01.25 03:00, Soft Works wrote:
> It's a bit difficult to judge those repo providers without appropriate data, so I made copies of the ffstaging GitHub site (for creating PRs being sent to the ML), so the all have current ffmpeg data:
> 
> 
> Gitea
> 
> https://gitea.com/ffstaging/FFmpeg
> 
> 
> forgejo
> 
> https://v10.next.forgejo.org/ffstaging/FFmpeg
> 
> 
> GitLab
> 
> https://gitlab.com/ffstaging/FFmpeg


Perhaps you should also add a `radicle` (https://radicle.xyz/) test repo 
to the play, because it's one of the rare solutions, which takes 
decentralization, platform independent meta info within the git repo 
data itself and access by various means really serious. And it's core 
isn't based on one of this horrible web tech frameworks but using rust 
for a perfomance and safety critical server implementation. Only the 
web-browser-frontend uses svelte. Unfortunately it's still in very early 
development stage and hard to get used for newcomers.

In regard to the other three more common choices, you should definitely 
also ask about their CI, search and federation capabilities and current 
support.

Forgejo may look nice on first sight, because it's more or less just 
copying GitHub, which most of us became used over time, but it has a lot 
of really insufficient solved edges, which are very annoying in daily work.

Whenever I contribute to a codberg.org based project, I have to use some 
GitHub mirror in parallel, because the current search capabilities are 
so much worse in Forgjo. You may argue, that searching is a task, which 
you handle localy in your IDE or by old-fashioned command line tools 
anyway. But this will work only for code and commit content! All the 
info, which is placed in issue and merge request threads, isn't easily 
accessibly by other means. If you have to make changes in huge projects, 
you always spend lots of time to understand the history and decisions 
during the development process in the past. This info is usually placed 
in exactly this hidden corners, if available at all, just as here on 
this mailing list.

Better CI support, which is the strong side of GitLab, is IMHO just 
similar important as pure git repo hosting. It helps to automatically 
check merge requests, and report and step by step correcting the related 
issues in a significant more efficient way than here on the list. But 
good CI solutions, which are not just somehow glued together with the 
code management infrastructure, allow much more! They are not controlled 
and configured only by the repo owner by hidden setups, but are 
transparent and can be easily modified by users in their private forks 
or runners on their local machines. That's a very important feature in 
practice, because it motivates developers to also improve this test and 
build infrastructure together instead of just relaying on some 
non-transparent given infrastructure maintained by a few professionals.

martin