[FFmpeg-devel] Regarding Git Tooling

[Soft Works]

Hi,

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> martin schitter
> Sent: Wednesday, January 22, 2025 7:42 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> 
> 
> 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

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.

> 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.

From the radicle website:

> For now, Radicle only works on Linux, macOS and BSD variants.

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


> 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. 

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

The only bit that I'm sometimes missing is an easy way to find the corresponding pull request discussion for a certain commit, but even GitHub doesn't help with that.


> 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

This is something that should be possible to run for everybody, both locally and in their forks repositories.
forgejo appears to have also cloned GH Actions where the action definitions are part of the code base.


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)

forgejo provides WebHooks for many different events, so even a bot like GGG could be done which reacts to certain "/command" comments in PR discussions. I wouldn't see it as a problem when such things are running elsewhere.

sw