[FFmpeg-devel] Regarding Git Tooling

[martin schitter]

On 25.01.25 08:54, Soft Works wrote:
>>> 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
> 
> This was nothing official nor planned, I just wanted to take a look at forgejo and got it going to quickly that I did the other two as well and posted the links to allow taking a look for those who like to. The "real thing" will be set up by others.


Just mirroring a pure git repo is indeed trivial and easily archived by 
a few clicks in all of these solutions. The troubles and more 
challenging compatibility issues and vendor lock in symptoms will appear 
  later in practical use and will soon make any radical changes and any 
transfer to an alternative solution very difficult.

>  From the radicle website:
> 
>> For now, Radicle only works on Linux, macOS and BSD variants.

Do you really want to host GitLab or Forgejo on Win11 or an Ipad? :)

Access to Web-Interface and more traditional ways of git exchange are 
anyway available on radicle hosted projects as well. It's just not the 
typical Web-First approach and the Web-GUI doesn't look really 
convincing. The development is more concentrated on the core parts and 
the challenges of distributed peering without only one central hosting 
instance. But even the tools required for this kind of usage could be 
easily ported to other platforms, if somebody really wants to spend 
efforts on this task.

> Besides, the intention is to make ffmpeg more accessible to developers rather than less. :-)

Sure, I also see the reasons why radicle will not be accepted by most 
users in its current state. The web-Interface is much to simple and 
inferior compared to the more common choices.

But radicle is definitely the only available example of an alternative 
git based source management solution until now, which somehow mastered 
to solve the requirements of decentralized identity management and 
application independent issue storing within git itself.
All other federation promises prospected by the other alternatives are 
still very far away from any real world implementation and will very 
likely also support only federated networks of very similar software, 
instead of focusing on exchange between more or less arbitrary git based 
platforms.

It's really a pity that the compromisless radicle approach is so much 
different to the expectations of most common users, that it will hardly 
have any chance to compete witch centralized services provided by a few 
big companies or those attempts to just copy the simplicity of their 
web-GUIs.

> In the test repo I was able to search code, PR discussions and issue
> conversations. What else you looking?

Yes, on first look it seems to work similar...

But in the case of F. you have to make two or three individual search 
requests if you really want to cover code, Issues and PR comments. And 
in all of them you have to always spend a few more clumsy clicks to 
change the search mode to “exact” and sort by “recently updated” anytime 
again before you finally get a somehow useful list of search result. 
These are the really annoying details in practice, which drive you crazy 
after a while.


>> 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.
> 
> I believe that both is required:
> 
> 1. Automated build and test runs

Yes -- I agree. But the tools have to be well integrated into the whole 
system, otherwise it doesn't help to establish a more efficient handling 
of merge requests.

> forgejo appears to have also cloned GH Actions where the action definitions are part of the code base.

Forgejos CI implementation is still in a very early and inferior stage. 
I wouldn't see it as a serious alternative to GitLab in any respect. But 
the very container and Kubernetes focused approach of GitLab also has 
its drawbacks. It's just very powerful and mature in comparison.

> 2. Organizational Automation Tasks
> 
> Other types of automation are probably of less interest or make no sense to be run by everybody individually, like for example:
> 
> - Extended Platform FATE tests
>    Running on platforms other than the usual CI runners run on
> - Run additional checks on PRs, like
>    - Commit message formatting and style
>    - Code style checking
>    - Check version bump requirement (if reasonably possible)
>    - Check doc change if options change (if possible)
> - Auto-determine maintainers and notify/tag them
> - Auto-apply tags (like for util, codec, format, tools)

It's hard to say, which tasks should be actually handled by mechanism 
provided by one of this Git related CI/CD solutions. Vendor lock in 
happens very quickly, and it's always very hard to find a satisfying 
balance between independent tooling and sufficient system integration.

martin