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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
