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