[POLL] [VOTE] code.ffmpeg.org
Hi all Do people want Forgejo or Gitlab on code.ffmpeg.org for testing? F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org) After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel) * extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up) * announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML * and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
G but hosted by videolan On Sun, 13 Jul 2025, 12:44 Michael Niedermayer, <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 7/13/2025 1:43 PM, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab I'm indifferent about this, either works for me.
Just want to note that hosting Gitlab is quite a bit more expensive than Forgejo, for which I'm currently just paying out of pocket. So for an official Gitlab test setup, I'd occasionally forward accumulated bills for refund by SPI.
Hi On Sun, Jul 13, 2025 at 01:58:44PM +0200, Timo Rothenpieler wrote: [...]
Just want to note that hosting Gitlab is quite a bit more expensive than Forgejo, for which I'm currently just paying out of pocket. So for an official Gitlab test setup, I'd occasionally forward accumulated bills for refund by SPI.
Can you elaborate on the source of this additional cost ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment.
On 7/13/2025 5:57 PM, Michael Niedermayer wrote:
Hi
On Sun, Jul 13, 2025 at 01:58:44PM +0200, Timo Rothenpieler wrote: [...]
Just want to note that hosting Gitlab is quite a bit more expensive than Forgejo, for which I'm currently just paying out of pocket. So for an official Gitlab test setup, I'd occasionally forward accumulated bills for refund by SPI.
Can you elaborate on the source of this additional cost ?
It's written in Ruby, which is not exactly fast or light on resources. The recommended minimum instance Gitlab defines is one with 16GB RAM and 8 cores. Gitlab also does not officially support running on aarch64, though it does supposedly work, you'd be on your own supporting that setup. So while a Forgejo instance suitable for our expected usage can run on an CAX21 instance (4 CPUs, 8GB RAM, aarch64) which costs 7,13€ a month, the Gitlab minimum specs demand a CX42 or CPX41 instance for 18,92€ or 29,39€ a month (both are 8CPU, 16GB RAM, the more expensive "P" one being faster AMD CPUs, the non P one Intel). The Intel CPUs are likely fine, performance wise, but it's still almost triple the cost at a minimum. If Gitlab could run on aarch64 the respective CAX31 instance would cost only 14,27€ a month.
On 7/13/2025 6:07 PM, Timo Rothenpieler wrote:
On 7/13/2025 5:57 PM, Michael Niedermayer wrote:
Hi
On Sun, Jul 13, 2025 at 01:58:44PM +0200, Timo Rothenpieler wrote: [...]
Just want to note that hosting Gitlab is quite a bit more expensive than Forgejo, for which I'm currently just paying out of pocket. So for an official Gitlab test setup, I'd occasionally forward accumulated bills for refund by SPI.
Can you elaborate on the source of this additional cost ?
It's written in Ruby, which is not exactly fast or light on resources. The recommended minimum instance Gitlab defines is one with 16GB RAM and 8 cores. Gitlab also does not officially support running on aarch64, though it does supposedly work, you'd be on your own supporting that setup.
So while a Forgejo instance suitable for our expected usage can run on an CAX21 instance (4 CPUs, 8GB RAM, aarch64) which costs 7,13€ a month, the Gitlab minimum specs demand a CX42 or CPX41 instance for 18,92€ or 29,39€ a month (both are 8CPU, 16GB RAM, the more expensive "P" one being faster AMD CPUs, the non P one Intel). The Intel CPUs are likely fine, performance wise, but it's still almost triple the cost at a minimum.
If Gitlab could run on aarch64 the respective CAX31 instance would cost only 14,27€ a month.
Actually, I just noticed there are aarch64 packages and images now, since the very latest version apparently: https://hub.docker.com/r/gitlab/gitlab-ce/tags?name=18 So the cost difference is a bit smaller, but still there. It costs roughly double to host Gitlab vs. Forgejo, though that double boils down to something like ~7€ a month extra.
On Sun, 13 Jul 2025, 17:07 Timo Rothenpieler, <timo@rothenpieler.org> wrote:
On 7/13/2025 5:57 PM, Michael Niedermayer wrote:
Hi
On Sun, Jul 13, 2025 at 01:58:44PM +0200, Timo Rothenpieler wrote: [...]
Just want to note that hosting Gitlab is quite a bit more expensive than Forgejo, for which I'm currently just paying out of pocket. So for an official Gitlab test setup, I'd occasionally forward accumulated bills for refund by SPI.
Can you elaborate on the source of this additional cost ?
It's written in Ruby, which is not exactly fast or light on resources. The recommended minimum instance Gitlab defines is one with 16GB RAM and 8 cores.
This is not a lot of resources in 2025. FFmpeg is not a high school project and the miniscule difference between cheap servers should make no difference. If we choose Gitlab it should be hosted on a powerful server (for arguments sake 32 cores) and SPI funds use to pay for it. Kieran
F, due to it feeling faster and more responsive while navigating.
G but some people may not be comfortable voting in public like that.
On July 13, 2025 4:43:57 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
i'll note that I ran into some important upsides and downsides with both of those when picking which to use for projects i've worked on, hopefully this info is useful for ffmpeg: * gitlab just recently decided their open source version won't be supporting pull mirroring (where the server actively pulls every so often from a remote repository): https://gitlab.com/gitlab-org/gitlab/-/issues/23166#note_2620944560 * forgejo doesn't yet support scoped permissions for oauth, so if you use a forgejo account for authenticating with some website/program, that effectively gives that website/program full permissions to anything you can access/modify through your forgejo account (it says administrative privileges, so maybe even more than that?): https://forgejo.org/docs/latest/user/oauth2-provider/ (not to be confused with using e.g. google to log into your forgejo account which afaik has no significant issues) * forgejo's runner (for CI) is almost completely compatible with github actions (though forgejo doesn't aim for compatibility), so that makes running CI easier in some ways since iirc basically every github action I've tried on forgejo just works. Jacob
On 7/13/2025 5:56 PM, Jacob Lifshay wrote:
On July 13, 2025 4:43:57 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
i'll note that I ran into some important upsides and downsides with both of those when picking which to use for projects i've worked on, hopefully this info is useful for ffmpeg:
* gitlab just recently decided their open source version won't be supporting pull mirroring (where the server actively pulls every so often from a remote repository): https://gitlab.com/gitlab-org/gitlab/-/issues/23166#note_2620944560
* forgejo doesn't yet support scoped permissions for oauth, so if you use a forgejo account for authenticating with some website/program, that effectively gives that website/program full permissions to anything you can access/modify through your forgejo account (it says administrative privileges, so maybe even more than that?): https://forgejo.org/docs/latest/user/oauth2-provider/ (not to be confused with using e.g. google to log into your forgejo account which afaik has no significant issues)
* forgejo's runner (for CI) is almost completely compatible with github actions (though forgejo doesn't aim for compatibility), so that makes running CI easier in some ways since iirc basically every github action I've tried on forgejo just works.
On that note it's also worth mentioning that Forgejo/Gitea CI is still marked as experimental. While it does work fine in practice and is unlikely to experience any super disruptive changes at this point, Gitlab CI is considerably more mature. Though it does need to be completely re-learned, since it's not at all compatible with GHA CI.
On Sun, Jul 13, 2025 at 01:43:57PM +0200, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
F. TLDR below: * Forgejo is community maintained * Cheaper to operate (see timos reply) * Its faster Gitlab is a publicly traded company, its executives must by law act in the interest of gitlab and its shareholders. Gitlab can only provide free licenses to free software projects, as long as doing so gives gitlab and its shareholders a benefit. publicly traded companies must try to maximize profits. Its simply not in FFmpegs interrest to make ourselfs dependant on that. Unless theres a large benefit from doing that. I dont belive gitlab is better by a large enough amount in any way to make us dependant on it. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
G, preferably hosted by videolan. On Sun, Jul 13, 2025 at 7:44 AM Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 7/13/2025 8:04 PM, Ronald S. Bultje wrote:
G, preferably hosted by videolan.
The main issue I have with Videolan Gitlab is the ultra locked down signup policy. People appear in Videolan IRC multiple times a week asking to get their account activated, and only sometimes actually get help. Often they already waited multiple days. It's an understandable anti-spam measure, but also extremely hostile to any potential contributor. Also, Videolan Gitlab is very often, like at the moment of writing, EXTREMELY slow. It just took it over a full minute to render the main page of the VLC repo, and this isn't the first time I've seen it this slow. There's periods where it's decently responsive, but I feel like I have seen it slow more often than fast. It's probably also bogged down by the flood of LLM scrapers, but there do not seem to be any countermeasures in place.
On Sun, Jul 13, 2025 at 7:44 AM Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Hi Ronald On Sun, Jul 13, 2025 at 02:04:15PM -0400, Ronald S. Bultje wrote:
G, preferably hosted by videolan.
This poll really is about, what we should setup on our server. If you want to discuss giving up our autonomy (not sure thats what you meant) We can discuss that, though iam not sure email is the medium over which i can convey my position successfully. But let me try. My vission for FFmpeg was, and is that it should be and remain the leading multimedia framework. (I mean its even in teh "about" of ffmpeg) And i very much would like to move in this direction together with everyone who shares this vission. (including all the innovation, AI and so on in ffmpeg) I also belive that decissions in FFmpeg should be made by the community (who shares a similar vission). And really the leading multimedia framework needs its own server and cannot be hosted by another multimedia framework. Thats on top of reasons related to performance, independance, and flexibility Theres also the more personal reason, that i dont want to work on a #2 framework or appendix under some other framework. Id like to compete and win and be working on #1 :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
On Sun, 13 Jul 2025, 22:47 Michael Niedermayer, <michael@niedermayer.cc> wrote:
Hi Ronald
On Sun, Jul 13, 2025 at 02:04:15PM -0400, Ronald S. Bultje wrote:
G, preferably hosted by videolan.
This poll really is about, what we should setup on our server.
If you want to discuss giving up our autonomy (not sure thats what you meant) We can discuss that, though iam not sure email is the medium over which i can convey my position successfully.
But let me try. My vission for FFmpeg was, and is that it should be and remain the leading multimedia framework. (I mean its even in teh "about" of ffmpeg) And i very much would like to move in this direction together with everyone who shares this vission. (including all the innovation, AI and so on in ffmpeg)
I also belive that decissions in FFmpeg should be made by the community (who shares a similar vission).
And really the leading multimedia framework needs its own server and cannot be hosted by another multimedia framework.
Thats on top of reasons related to performance, independance, and flexibility
Theres also the more personal reason, that i dont want to work on a #2 framework or appendix under some other framework. Id like to compete and win and be working on #1 :)
thx
Ffmpeg has been using Videolan infra for git for over a decade. Kieran
On Sun, 13 Jul 2025 13:43:57 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
thx
F. I do not actually have a strong opinion, but I know Timo already got Forgejo set up, and so we should take advantage of that. --phil
On 7/13/2025 11:55 PM, Philip Langdale via ffmpeg-devel wrote:
On Sun, 13 Jul 2025 13:43:57 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
thx
F.
I do not actually have a strong opinion, but I know Timo already got Forgejo set up, and so we should take advantage of that.
I want to point out that I primarily set up Forgejo since I have never done so before, while I have some limited experience with Gitlab from work. And since I figured more people had never used Gitea/Forgejo before than Gitlab, a test instance made sense to me. I can set up Gitlab in the span of one evening in place of Forgejo, so Forgejo already being there should not be a criteria.
F (see below for my reasoning) While I would be fine with either outcome, and had helped extensively for the GitLab migration of VLC and at that time was quite convinced its the best solution out there, my opinion on this has changed, and also Gitea or now its fork Forgejo changed quite a bit and also some things on GitLabs side I got increasingly frustrated with. My main issue with GitLab is the enterprise edition. While I understand the need for them to have some sensible business model, I fundamentally disagree with some of their allegedly business features, just to name a few that I very much disagree with: - Scoped labels (https://docs.gitlab.com/user/project/labels/#scoped-labels) - Configurable issue boards (https://docs.gitlab.com/user/project/issue_board/) - Custom fields in issues (https://docs.gitlab.com/user/work_items/custom_fields/) Also, while I don't necessary disagree with this being a more enterprise-ish feature, merge trains are incredibly useful for big open source projects for merging multiple changes efficiently: - Merge trains (https://docs.gitlab.com/ci/pipelines/merge_trains/) Once a feature is in the enterprise edition it is really hard to get it moved into the community edition (Free tier) and also obviously means that no open source contributor could build such a feature and submit it upstream for the community edition. Also GitLabs codebase is very hard to approach as a new contributor, making it quite hard to quickly add a missing feature or fix an annoying issue. There are also somewhat trivial features not implemented for a very long time, just to name one example: - Multiple artifacts for a CI job (https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_2603279227) Also for this feature they consider it being an "advanced" one and therefore to be an enterprise edition feature: https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_899915876 Of course this doesn't mean Forgejo is perfect but I am personally more hopeful for its future than I am for GitLab. So I think it would be at least worth a try to go that route. Note also that it doesn't mean anything is set in stone, we could change again if it turns out Forgejo doesn't work well for us… Sorry for the long email, have a nice start of the week everyone! Regards, Marvin Scholz
On Jul 14, 2025, at 06:22, Marvin Scholz <epirat07@gmail.com> wrote:
F (see below for my reasoning)
F. You convinced me.
While I would be fine with either outcome, and had helped extensively for the GitLab migration of VLC and at that time was quite convinced its the best solution out there, my opinion on this has changed, and also Gitea or now its fork Forgejo changed quite a bit and also some things on GitLabs side I got increasingly frustrated with.
My main issue with GitLab is the enterprise edition. While I understand the need for them to have some sensible business model, I fundamentally disagree with some of their allegedly business features, just to name a few that I very much disagree with:
- Scoped labels (https://docs.gitlab.com/user/project/labels/#scoped-labels) - Configurable issue boards (https://docs.gitlab.com/user/project/issue_board/) - Custom fields in issues (https://docs.gitlab.com/user/work_items/custom_fields/)
Also, while I don't necessary disagree with this being a more enterprise-ish feature, merge trains are incredibly useful for big open source projects for merging multiple changes efficiently:
- Merge trains (https://docs.gitlab.com/ci/pipelines/merge_trains/)
Once a feature is in the enterprise edition it is really hard to get it moved into the community edition (Free tier) and also obviously means that no open source contributor could build such a feature and submit it upstream for the community edition.
Also GitLabs codebase is very hard to approach as a new contributor, making it quite hard to quickly add a missing feature or fix an annoying issue. There are also somewhat trivial features not implemented for a very long time, just to name one example:
- Multiple artifacts for a CI job (https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_2603279227)
Also for this feature they consider it being an "advanced" one and therefore to be an enterprise edition feature: https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_899915876
Of course this doesn't mean Forgejo is perfect but I am personally more hopeful for its future than I am for GitLab. So I think it would be at least worth a try to go that route. Note also that it doesn't mean anything is set in stone, we could change again if it turns out Forgejo doesn't work well for us…
Sorry for the long email, have a nice start of the week everyone!
Regards, Marvin Scholz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Marvin Scholz <epirat07@gmail.com> 于2025年7月14日周一 06:22写道：
F (see below for my reasoning)
F. looks reasonable
While I would be fine with either outcome, and had helped extensively for the GitLab migration of VLC and at that time was quite convinced its the best solution out there, my opinion on this has changed, and also Gitea or now its fork Forgejo changed quite a bit and also some things on GitLabs side I got increasingly frustrated with.
My main issue with GitLab is the enterprise edition. While I understand the need for them to have some sensible business model, I fundamentally disagree with some of their allegedly business features, just to name a few that I very much disagree with:
- Scoped labels (https://docs.gitlab.com/user/project/labels/#scoped-labels) - Configurable issue boards (https://docs.gitlab.com/user/project/issue_board/) - Custom fields in issues (https://docs.gitlab.com/user/work_items/custom_fields/)
Also, while I don't necessary disagree with this being a more enterprise-ish feature, merge trains are incredibly useful for big open source projects for merging multiple changes efficiently:
- Merge trains (https://docs.gitlab.com/ci/pipelines/merge_trains/)
Once a feature is in the enterprise edition it is really hard to get it moved into the community edition (Free tier) and also obviously means that no open source contributor could build such a feature and submit it upstream for the community edition.
Also GitLabs codebase is very hard to approach as a new contributor, making it quite hard to quickly add a missing feature or fix an annoying issue. There are also somewhat trivial features not implemented for a very long time, just to name one example:
- Multiple artifacts for a CI job (https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_2603279227)
Also for this feature they consider it being an "advanced" one and therefore to be an enterprise edition feature: https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_899915876
Of course this doesn't mean Forgejo is perfect but I am personally more hopeful for its future than I am for GitLab. So I think it would be at least worth a try to go that route. Note also that it doesn't mean anything is set in stone, we could change again if it turns out Forgejo doesn't work well for us…
Sorry for the long email, have a nice start of the week everyone!
Regards, Marvin Scholz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Sun, Jul 13, 2025 at 1:44 PM Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
F.
On 13/07/2025 20:43, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well. F.
It loads full diffs instantly, doesn't error randomly when loading MRs, it lacks paid versions, lacks AI chatbots, and we can fix it if it needs fixing. Its already pretty much fully setup, anyone can test it on code.ffmpeg.org
On 2025-07-13 05:13 pm, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
F. Regards, Gyan
On 2025-07-13 13:43 +0200, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
F. * the UI is more intuitive IMHO and I suspect it will be to the majority of newcomers * Gitlab follows the Open Core model which is prone to all kinds of unwanted developments * I actually did look a little at the sources and didn't get far with Gitlab where in Forgejo I could find my way around easily For Gitlab it was hard to find the source to begin with, when starting at their website. After multiple hops and wading through lists I ended up here: https://gitlab.com/gitlab-org/gitlab/ Later I randomly found out - by inspecting the README going to one of their web pages because of a different reason - that there is also: https://gitlab.com/gitlab-org/gitlab-foss/ For Forgejo it's scrolling down the home page and click a button or on every page in the footer via "Community Code". You are instantly on the repo hosted on Codeberg: https://codeberg.org/forgejo/forgejo Some superficial stats from a bit of line counting to get a feeling: | SLOC without comments | backend | frontend | ----------- | --------------------- | ------- | -------- | gitlab | ~4_600_000 | 70% | 30% | gitlab-foss | ~2_900_000 | 70% | 30% | forgejo | ~416_440 | 90% | 10% | To be fair, I didn't do any deeper analysis and be sure to take this numbers with a grain of salt. There is a mismatch of features etc. between these code bases and so we cannot just compare them easily. There are lots of features in Gitlab that we probably would never use. The ancestor of Forgejo is Gogs. Gogs initially achieved something quite remarkable. It provided a lot with very little. As far as I can judge this also transferred and to its forks Gitea/Forgejo and still mostly holds. If the Forgejo code base and project is the best in 5 years or in 10 years is not easily to be predicted today, but I would say the project has good chances to be in good shape. Currently I don't see any clearly better alternatives. Alexander
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael Niedermayer Sent: Sonntag, 13. Juli 2025 13:44 To: FFmpeg development discussions and patches <ffmpeg- devel@ffmpeg.org> Subject: [FFmpeg-devel] [POLL] [VOTE] code.ffmpeg.org
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
F Feels more open, more accessible, more lightweight, more familiar, more flexible and fits my work and thought processes better than GitLab. Thanks, sw
On 7/13/25 07:43, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
F. My reasons are mostly that every Gitlab instance I've used as a developer (e.g. videolan, freedesktop) has been incredibly slow, and I have not had experiences like such with forgejo. - Leo Izen
On Sun, 13 Jul 2025, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
No strong opinion between the two. I have a lot of experience with Gitlab (which I find quite workable - although perhaps not the nicest thing in the world), no experience with Forgejo.
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
I'd like to point out that we probably shouldn't be flip-flopping too much between different tools - as the review history of patches ideally should be kept available for future readers of the code as well. But running a couple-month experiment and then deciding to switch fully or not, sounds like a reasonable way to me. But the end goal should be one canonical tool/process, not many in parallel IMO. // Martin
On 15/07/2025 03:09, Martin Storsjö wrote:
On Sun, 13 Jul 2025, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
No strong opinion between the two. I have a lot of experience with Gitlab (which I find quite workable - although perhaps not the nicest thing in the world), no experience with Forgejo.
* and a month or 2 after that we can re-asses how many people use code.ffmpeg.org and how many use the ML. Then we could decide to keep using both in parallel or switch back to ML or just use code.ffmpeg.org. Or in fact we could switch between Gitlab or Forgejo here still as well.
I'd like to point out that we probably shouldn't be flip-flopping too much between different tools - as the review history of patches ideally should be kept available for future readers of the code as well. But running a couple-month experiment and then deciding to switch fully or not, sounds like a reasonable way to me. But the end goal should be one canonical tool/process, not many in parallel IMO.
+1 -- Frank
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Martin Storsjö Sent: Dienstag, 15. Juli 2025 20:09 To: FFmpeg development discussions and patches <ffmpeg- devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [POLL] [VOTE] code.ffmpeg.org
[..]
like a reasonable way to me. But the end goal should be one canonical tool/process, not many in parallel IMO.
+1 I'd rather stick to the ML - no matter how much I dislike it - than having split communication and needing to visit and work at two places. For a test/transition phase it's fine of course. Best regards, sw
On Sun, 13 Jul 2025 at 13:44, Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
I cannot tell. While Forgejo looks fine on the surface, the devil is in the details. I know GitLab and its (dis)advantages. Forgejo is unknown to me, except from a limited look, so it's hard to make educated guess if it will work fine. As for the performance argument, is this something that was measured? I agree GitLab can be slow, but what makes you believe Forgejo is faster? Comparing videolan's GitLab without any scraping protection in place to the test instance of ffmpeg's Forgejo is comparing apples and oranges, they are different in size and use atm. Also, while I understand the reluctance due to GitLab’s corporate background, this ensures that it is maintained, supported and is already more mature. What's the difference between a company "pulling the plug" and Forgejo becoming unmaintained over the years, or lacking fixes/improvements due to a lack of interest/funding? And don't give me "Forgejo is open source, we can maintain it", I'm sure none of ffmpeg contributors would be interested in maininging Forgejo. That said, I think both choices would be fine. Whatever we chose it would be adaptation to a new environment anyway. I think for basic code/patches management both are fine, for all the stuff around that, like CI, it's hard to say. - Kacper
Hi all On Sun, Jul 13, 2025 at 01:43:57PM +0200, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
7 day period passed, Quick count says: Gitlab : 3 Votes Forgejo: 12 Votes
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
timo, ping can you post the patches ?
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
anyone wants to set this up ?
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
suggestions for news (patch) and twitter announcement welcome! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
On 7/21/2025 2:54 AM, Michael Niedermayer wrote:
Hi all
On Sun, Jul 13, 2025 at 01:43:57PM +0200, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
7 day period passed,
Quick count says: Gitlab : 3 Votes Forgejo: 12 Votes
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
timo, ping can you post the patches ?
I'll rebase them into one patch and post them.
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
anyone wants to set this up ?
I can add forgejo to my sync cronjobs, yeah.
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
Just be aware that merging is not possible, since the sync script will just force push anything merged away.
suggestions for news (patch) and twitter announcement welcome!
thx
[...]
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Mon, Jul 21, 2025 at 03:03:08AM +0200, Timo Rothenpieler wrote:
On 7/21/2025 2:54 AM, Michael Niedermayer wrote:
Hi all
On Sun, Jul 13, 2025 at 01:43:57PM +0200, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
7 day period passed,
Quick count says: Gitlab : 3 Votes Forgejo: 12 Votes
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
timo, ping can you post the patches ?
I'll rebase them into one patch and post them.
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
anyone wants to set this up ?
I can add forgejo to my sync cronjobs, yeah.
please do thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB For a strong democracy, genuine criticism is necessary, allegations benefit noone, they just cause unnecessary conflicts. - Narendra Modi
On Mon, Jul 21, 2025 at 3:03 AM Timo Rothenpieler <timo@rothenpieler.org> wrote:
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
Just be aware that merging is not possible, since the sync script will just force push anything merged away.
That seems like a big oversight to me, and makes me wonder why noone else has asked about it. If we actually start using such a platform, shouldn't the full workflow be represented on it for a fair assessment? Can we work towards enabling merging? - Hendrik
Hendrik Leppkes (HE12025-07-22):
Can we work towards enabling merging?
We refused merging with pure Git not for technical reasons. Has this changed? Regards, -- Nicolas George
On Tue, Jul 22, 2025 at 9:13 AM Nicolas George <george@nsup.org> wrote:
Hendrik Leppkes (HE12025-07-22):
Can we work towards enabling merging?
We refused merging with pure Git not for technical reasons. Has this changed?
Merging does not necessarily imply an actual merge commit, but applying a PR in any fashion. - Hendrik
On Tue, 22 Jul 2025 at 10:46, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Tue, Jul 22, 2025 at 9:13 AM Nicolas George <george@nsup.org> wrote:
Hendrik Leppkes (HE12025-07-22):
Can we work towards enabling merging?
We refused merging with pure Git not for technical reasons. Has this changed?
Merging does not necessarily imply an actual merge commit, but applying a PR in any fashion.
It should be restricted to the "Rebase and Merge" strategy in Forgejo (or however it's called there) to push only fast-forward. I fully agree that not merging code through Forgejo is a big oversight and will be jarring with PR workflow. - Kacper
On 22/07/2025 08:15, Hendrik Leppkes wrote:
On Mon, Jul 21, 2025 at 3:03 AM Timo Rothenpieler <timo@rothenpieler.org> wrote:
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
Just be aware that merging is not possible, since the sync script will just force push anything merged away.
That seems like a big oversight to me, and makes me wonder why noone else has asked about it. If we actually start using such a platform, shouldn't the full workflow be represented on it for a fair assessment? Can we work towards enabling merging?
Forgejo would have to be the main repo to enable merging pull requests. We would then first need to shut down our current main repo on git.videolan.org and turn it into a mirror, or make it redirect to Forgejo. Then we can just click merge on MRs, and I can enable branch protections again to disallow force pushes. My understanding of this was it just being an extended test-drive, not a full on switch yet.
On 22/07/2025 21:26, Timo Rothenpieler wrote:
On 22/07/2025 08:15, Hendrik Leppkes wrote:
On Mon, Jul 21, 2025 at 3:03 AM Timo Rothenpieler <timo@rothenpieler.org> wrote:
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
Just be aware that merging is not possible, since the sync script will just force push anything merged away.
That seems like a big oversight to me, and makes me wonder why noone else has asked about it. If we actually start using such a platform, shouldn't the full workflow be represented on it for a fair assessment? Can we work towards enabling merging?
Forgejo would have to be the main repo to enable merging pull requests. We would then first need to shut down our current main repo on git.videolan.org and turn it into a mirror, or make it redirect to Forgejo.
Then we can just click merge on MRs, and I can enable branch protections again to disallow force pushes.
My understanding of this was it just being an extended test-drive, not a full on switch yet.
I think it should be no issue to make the current repo redirect to the Forgejo instance. Then we can push from both Forgejo and have devs still use the old push URL (with a different signature, but we've already had to update it once recently). Force pushing would still be enabled for the "test-drive", though we all know it'll be what we end up using.
On 21/07/2025 09:54, Michael Niedermayer wrote:
Hi all
On Sun, Jul 13, 2025 at 01:43:57PM +0200, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo G. code.ffmpeg.org should run Gitlab
all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "G." / "Gitlab" End time is in 7 days unless teh community wants to extend that. (or do people want a formal vote to be setup? on vote.ffmpeg.org)
7 day period passed,
Quick count says: Gitlab : 3 Votes Forgejo: 12 Votes
After we decide what to run on code.ffmpeg.org, I intend to * apply the CI patches which timo currently keeps rebasing on the Forgejo git (maybe timo can post these to ffmpeg-devel)
timo, ping can you post the patches ?
* extend my github cronjob to autosync Forgejo or Gitlab too (or someone else can set one up)
anyone wants to set this up ?
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
suggestions for news (patch) and twitter announcement welcome!
I'll write something up for the website.
* announce code.ffmpeg.org publically so people can start submitting and reviewing on it as an alternative to the ML
May want to add it to this page somehow, since it's in use now, so people know there's two? https://trac.ffmpeg.org/ And that's the "go to" bug submission page... Cheers!
participants (22)
-
Alexander Strasser -
Frank Plowman -
Gyan Doshi -
Hendrik Leppkes -
Jacob Lifshay -
Kacper Michajlow -
Kieran Kunhya -
Leo Izen -
Lynne -
Martin Storsjö -
Marvin Scholz -
Michael Niedermayer -
Nicolas George -
Philip Langdale -
Roger Pack -
Ronald S. Bultje -
Rémi Denis-Courmont -
softworkz . -
Steven Liu -
Timo Rothenpieler -
Yalda -
Zhao Zhili