[FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Lynne]

---
 src/contact | 11 +++++++++++
 src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)

diff --git a/src/contact b/src/contact
index 6943d06..8a59864 100644
--- a/src/contact
+++ b/src/contact
@@ -1,3 +1,14 @@
+<div class="well">
+  <h3 id="Contributions">
+    <i class="fa fa-pencil"></i>
+    Contributions</h3>
+  <div style="color: white">
+    <p>
+      To contribute to FFmpeg, login or sign up for an account on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>.
+      The main repository of the project is <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>.
+    </p>
+  </div>
+</div> <!-- well -->
 
 <div class="well">
   <div class="row">
diff --git a/src/index b/src/index
index 52829e1..1f45dec 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,58 @@
     News
   </h1>
 
+  <h3 id="forge">July 22nd, 2025, Modernization of contributions</h3>
+  <p>
+    The project is modernizing its contribution methods and switching to a software forge.
+  <p>
+  </p>
+    We have setup a platform on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>. The new process
+    features continuous integration on all commits and merge requests, labelling for categorization,
+    conflict resolution, and logging in via OpenID or Github.
+  </p>
+  <p>
+    The main repository will become <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>,
+    with all others being mirrored to it.
+    Users are encouraged to begin using it, effective now.
+  </p>
+  <p>
+    Mailing lists have supported our development for
+    <span title="with a total of 346,615 emails since April 2005">nearly 25 years</span>,
+    but as more and more contributors started to become involved, the ratio of merged patches to total mails begun
+    <span title="perhaps just correlation">falling</span>. Mailing lists became a source of friction,
+    with discussions frequently stalling and uncategorized noise drowning out patches by bumping them down in inboxes.
+  </p>
+  <p>
+    Although <a href="https://patch.ffmpeg.org/">patchwork.ffmpeg.org</a> was set up to track submissions,
+    it was less than reliable, with many patches and mails slipping though. Since its activation exactly
+    9 years ago, it recorded 54,476 patches, with 53,650 patches having the state of not archived.
+    In comparison, the mailing list has had a total of 150,736 emails during the same time period.
+  </p>
+  <p>
+    Additionally, new users have frequently encountered difficulties with mailing list development.
+    From finding out the correct SMTP login details, configuring git send-email, new email security
+    mechanisms interfering with mailing list operations, and finally not having a comfortable workflow
+    to review patches.
+  </p>
+  <p>
+    After years of discussions, and a vote, we officially announce the new platform,
+    <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, running <a href="https://forgejo.org/">Forgejo</a>.
+    Documentation will be updated to reflect the change.
+  </p>
+  <p>
+    Mailing lists will continue to be monitored, and used for project discussions and other topics
+    better discussed elsewhere, but traffic and noise should become significantly reduced over time.
+  </p>
+  <p>
+    Bugs/issues will be accepted on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, alongside
+    with <a href="https://trac.ffmpeg.org/">trac.ffmpeg.org</a> for the time being.
+  </p>
+  <p>
+    We are also hoping that this will significantly reduce the amount of unmerged patches.
+    If you submitted a patch which received no replies or conclusion, we apologize, and you are encouraged
+    to resubmit it on the new platform.
+  </p>
+
   <h3 id="pr7.1">September 30th, 2024, FFmpeg 7.1 <span title="Rózsa Péter">"Péter"</span></h3>
   <p>
     <a href="download.html#release_7.1">FFmpeg 7.1 "Péter"</a>, a new
-- 
2.50.0
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kacper Michajlow]

On Tue, 22 Jul 2025 at 05:54, Lynne <dev@lynne.ee> wrote:
>
> ---
>  src/contact | 11 +++++++++++
>  src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 63 insertions(+)
>
> diff --git a/src/contact b/src/contact
> index 6943d06..8a59864 100644
> --- a/src/contact
> +++ b/src/contact
> @@ -1,3 +1,14 @@
> +<div class="well">
> +  <h3 id="Contributions">
> +    <i class="fa fa-pencil"></i>
> +    Contributions</h3>
> +  <div style="color: white">
> +    <p>
> +      To contribute to FFmpeg, login or sign up for an account on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>.
> +      The main repository of the project is <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>.
> +    </p>
> +  </div>
> +</div> <!-- well -->

doc\git-howto.texi and doc\developer.texi needs to also be updated

>  <div class="well">
>    <div class="row">
> diff --git a/src/index b/src/index
> index 52829e1..1f45dec 100644
> --- a/src/index
> +++ b/src/index
> @@ -35,6 +35,58 @@
>      News
>    </h1>
>
> +  <h3 id="forge">July 22nd, 2025, Modernization of contributions</h3>
> +  <p>
> +    The project is modernizing its contribution methods and switching to a software forge.

Mention which one specifically.

> +  <p>
> +  </p>
> +    We have setup a platform on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>. The new process

`set up`

> +    features continuous integration on all commits and merge requests, labelling for categorization,

Forgejo calls them "Pull Requests", it's not gitlab.

> +    conflict resolution, and logging in via OpenID or Github.

What do you mean by `conflict resolution`? I don't think there is any
editing in the browser.

Also could mention `issue tracking`, if that's going to be used.

> +  </p>
> +  <p>
> +    The main repository will become <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>,
> +    with all others being mirrored to it.
> +    Users are encouraged to begin using it, effective now.
> +  </p>
> +  <p>
> +    Mailing lists have supported our development for
> +    <span title="with a total of 346,615 emails since April 2005">nearly 25 years</span>,
> +    but as more and more contributors started to become involved, the ratio of merged patches to total mails begun
> +    <span title="perhaps just correlation">falling</span>. Mailing lists became a source of friction,
> +    with discussions frequently stalling and uncategorized noise drowning out patches by bumping them down in inboxes.

Could just mention in a more neutral way that modern code forges are
better in keeping track of patches, new revisions, review and
comments.

> +  </p>
> +  <p>
> +    Although <a href="https://patch.ffmpeg.org/">patchwork.ffmpeg.org</a> was set up to track submissions,

What is `patch.ffmpeg.org`?

> +    it was less than reliable, with many patches and mails slipping though. Since its activation exactly
> +    9 years ago, it recorded 54,476 patches, with 53,650 patches having the state of not archived.
> +    In comparison, the mailing list has had a total of 150,736 emails during the same time period.

Can mention that patchwork doesn't really help tracking active patches
and revisions, just makes some of the comments categorized. But also
we don't need to "shit on" other software. We can in more netural way
that new forget will be an improvement to patch tracking over existing
patchwork, and that's all.

> +  </p>
> +  <p>
> +    Additionally, new users have frequently encountered difficulties with mailing list development.
> +    From finding out the correct SMTP login details, configuring git send-email, new email security
> +    mechanisms interfering with mailing list operations, and finally not having a comfortable workflow
> +    to review patches.

Just a 2 cents from me, I don't think sending email itself is a
problem, but at the same time sending them feels like throwing a coin
into a big pond. Unless someone picks it up in "a few days", it's
likely lost, because there is no way to go back to previous changes,
label them. For both small and big changes, the submitter needs to
actively bump them to keep it on the table. With proper storing and
categorization this wouldn't be an issue.

> +  </p>
> +  <p>
> +    After years of discussions, and a vote, we officially announce the new platform,
> +    <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, running <a href="https://forgejo.org/">Forgejo</a>.
> +    Documentation will be updated to reflect the change.
> +  </p>
> +  <p>
> +    Mailing lists will continue to be monitored, and used for project discussions and other topics
> +    better discussed elsewhere, but traffic and noise should become significantly reduced over time.

Incidentally, I never thought that FFmpeg ML had much noise. It's just
an inherent issue with one big bucket for everything, any discussion
is shadowing anything else that is happening on ML.

> +  </p>
> +  <p>
> +    Bugs/issues will be accepted on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, alongside
> +    with <a href="https://trac.ffmpeg.org/">trac.ffmpeg.org</a> for the time being.
> +  </p>
> +  <p>
> +    We are also hoping that this will significantly reduce the amount of unmerged patches.
> +    If you submitted a patch which received no replies or conclusion, we apologize, and you are encouraged
> +    to resubmit it on the new platform.
> +  </p>
> +
>    <h3 id="pr7.1">September 30th, 2024, FFmpeg 7.1 <span title="Rózsa Péter">"Péter"</span></h3>
>    <p>
>      <a href="download.html#release_7.1">FFmpeg 7.1 "Péter"</a>, a new
> --
> 2.50.0
> _______________________________________________
> 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".

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Jacob Lifshay]

On Tue, Jul 22, 2025 at 1:44 AM Kacper Michajlow <kasper93@gmail.com> wrote:
> On Tue, 22 Jul 2025 at 05:54, Lynne <dev@lynne.ee> wrote:
> > +    Additionally, new users have frequently encountered difficulties with mailing list development.
> > +    From finding out the correct SMTP login details, configuring git send-email, new email security
> > +    mechanisms interfering with mailing list operations, and finally not having a comfortable workflow
> > +    to review patches.
>
> Just a 2 cents from me, I don't think sending email itself is a
> problem,

If you don't need to send patches, email isn't really a problem.

however, imo figuring out how to get git send-email to work is a
significant problem (it took me like 20-30min to set up since I was
also figuring how to securely store the gmail app password in gnome
keyring using a git credential helper), I have contributed to quite a
few FOSS projects over the last 10yr or so and FFmpeg is the only(?)
one that requires using git send-email. the vast majority of them are
using a git forge or you just point them to your git forge of choice
and they'll pull from there.

tbh the only reason I'm contributing now using git send-email is
because I'm being paid to, if I weren't being paid I'm much less
likely to have bothered even when I had the code in a git repo.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Leo Izen]

On 7/21/25 23:53, Lynne wrote:
> ---
>   src/contact | 11 +++++++++++
>   src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 63 insertions(+)
> 

In addition to what kasper said, you should also update README.md's 
contributing section at the bottom of the file.

May be wise to do that in a separate patch, don't know.

- Leo Izen (Traneptora)

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1906 bytes --]

Hi Lynne

On Tue, Jul 22, 2025 at 12:53:29PM +0900, Lynne wrote:

[...]

> +  <p>
> +    Bugs/issues will be accepted on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, alongside
> +    with <a href="https://trac.ffmpeg.org/">trac.ffmpeg.org</a> for the time being.
> +  </p>

People should not submit bug reports randomly to 2 trackers, thats a problem.
It would make searching for issues 2x as hard.

If we discuss and decide to change the bug tracker (which we have not discussed,
less decided) -> than we should import all the issues from trac into the new tracker first.

In fact i suggest we make the forgejo issue tracker forward people to trac currently


> +  <p>
> +    We are also hoping that this will significantly reduce the amount of unmerged patches.
> +    If you submitted a patch which received no replies or conclusion, we apologize, and you are encouraged
> +    to resubmit it on the new platform.
> +  </p>

The announcment should probably mention that performance, as in number of
submissions / percentage of applied / not reviewed patches will be
monitored compared to the mailing list.

(and obviously someone has to do that, i do think such basic performance
 monitoring is important after/ during such a change)

later then (in a month or whatever) we should make an announcment with
the performance numbers

[And if we want to have strong statistics, then it is neccessary
 to pre-announce _exactly_ when and what will be meassured how.
 https://en.wikipedia.org/wiki/Preregistration_(science) ]

just thought this would be a interresting subject for a statistics paper,
if someone (maybe outside the ffmpeg team) wants to do it ...

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Lynne]

On 23/07/2025 08:04, Michael Niedermayer wrote:
> Hi Lynne
> 
> On Tue, Jul 22, 2025 at 12:53:29PM +0900, Lynne wrote:
> 
> [...]
> 
>> +  <p>
>> +    Bugs/issues will be accepted on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, alongside
>> +    with <a href="https://trac.ffmpeg.org/">trac.ffmpeg.org</a> for the time being.
>> +  </p>
> 
> People should not submit bug reports randomly to 2 trackers, thats a problem.
> It would make searching for issues 2x as hard.
> 
> If we discuss and decide to change the bug tracker (which we have not discussed,
> less decided) -> than we should import all the issues from trac into the new tracker first.
> 
> In fact i suggest we make the forgejo issue tracker forward people to trac currently

I disagree, I think we need a fresh start to track bugs properly. BtbN 
suggested he could redirect the new issue button on trac to Forgejo.

>> +  <p>
>> +    We are also hoping that this will significantly reduce the amount of unmerged patches.
>> +    If you submitted a patch which received no replies or conclusion, we apologize, and you are encouraged
>> +    to resubmit it on the new platform.
>> +  </p>
> 
> The announcment should probably mention that performance, as in number of
> submissions / percentage of applied / not reviewed patches will be
> monitored compared to the mailing list.
> 
> (and obviously someone has to do that, i do think such basic performance
>   monitoring is important after/ during such a change)
> 
> later then (in a month or whatever) we should make an announcment with
> the performance numbers

We all know there were plenty of patches left over. What we need to do 
is to start earning back the trust of casual submitters by at least 
letting them know that patches which might have gotten lost will get a 
second chance.
I already included data which hints at how many patches were left out in 
the form of ML vs patchwork stats.
> [And if we want to have strong statistics, then it is neccessary
>   to pre-announce _exactly_ when and what will be meassured how.
>   https://en.wikipedia.org/wiki/Preregistration_(science) ]
> 
> just thought this would be a interresting subject for a statistics paper,
> if someone (maybe outside the ffmpeg team) wants to do it ...
We could announce it later once we open the gates and start gathering data.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Lynne]

On 23/07/2025 00:01, Leo Izen wrote:
> On 7/21/25 23:53, Lynne wrote:
>> ---
>>   src/contact | 11 +++++++++++
>>   src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 63 insertions(+)
>>
> 
> In addition to what kasper said, you should also update README.md's 
> contributing section at the bottom of the file.
> 
> May be wise to do that in a separate patch, don't know.

Its in a separate repository, this is for ffmpeg-web.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Lynne]

On 22/07/2025 17:44, Kacper Michajlow wrote:
> On Tue, 22 Jul 2025 at 05:54, Lynne <dev@lynne.ee> wrote:
>>
>> ---
>>   src/contact | 11 +++++++++++
>>   src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 63 insertions(+)
>>
>> diff --git a/src/contact b/src/contact
>> index 6943d06..8a59864 100644
>> --- a/src/contact
>> +++ b/src/contact
>> @@ -1,3 +1,14 @@
>> +<div class="well">
>> +  <h3 id="Contributions">
>> +    <i class="fa fa-pencil"></i>
>> +    Contributions</h3>
>> +  <div style="color: white">
>> +    <p>
>> +      To contribute to FFmpeg, login or sign up for an account on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>.
>> +      The main repository of the project is <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>.
>> +    </p>
>> +  </div>
>> +</div> <!-- well -->
> 
> doc\git-howto.texi and doc\developer.texi needs to also be updated
> 
>>   <div class="well">
>>     <div class="row">
>> diff --git a/src/index b/src/index
>> index 52829e1..1f45dec 100644
>> --- a/src/index
>> +++ b/src/index
>> @@ -35,6 +35,58 @@
>>       News
>>     </h1>
>>
>> +  <h3 id="forge">July 22nd, 2025, Modernization of contributions</h3>
>> +  <p>
>> +    The project is modernizing its contribution methods and switching to a software forge.
> 
> Mention which one specifically.
> 
>> +  <p>
>> +  </p>
>> +    We have setup a platform on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>. The new process
> 
> `set up`
> 
>> +    features continuous integration on all commits and merge requests, labelling for categorization,
> 
> Forgejo calls them "Pull Requests", it's not gitlab.
> 
>> +    conflict resolution, and logging in via OpenID or Github.
> 
> What do you mean by `conflict resolution`? I don't think there is any
> editing in the browser.
> 
> Also could mention `issue tracking`, if that's going to be used.

I mean that it would let you know if your PR has conflicts with current 
master.

> 
>> +  </p>
>> +  <p>
>> +    The main repository will become <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>,
>> +    with all others being mirrored to it.
>> +    Users are encouraged to begin using it, effective now.
>> +  </p>
>> +  <p>
>> +    Mailing lists have supported our development for
>> +    <span title="with a total of 346,615 emails since April 2005">nearly 25 years</span>,
>> +    but as more and more contributors started to become involved, the ratio of merged patches to total mails begun
>> +    <span title="perhaps just correlation">falling</span>. Mailing lists became a source of friction,
>> +    with discussions frequently stalling and uncategorized noise drowning out patches by bumping them down in inboxes.
> 
> Could just mention in a more neutral way that modern code forges are
> better in keeping track of patches, new revisions, review and
> comments.

I think we first need to mention what issues we faced with MLs.

> 
>> +  </p>
>> +  <p>
>> +    Although <a href="https://patch.ffmpeg.org/">patchwork.ffmpeg.org</a> was set up to track submissions,
> 
> What is `patch.ffmpeg.org`?

patchwork.ffmpeg.org, fixed locally

> 
>> +    it was less than reliable, with many patches and mails slipping though. Since its activation exactly
>> +    9 years ago, it recorded 54,476 patches, with 53,650 patches having the state of not archived.
>> +    In comparison, the mailing list has had a total of 150,736 emails during the same time period.
> 
> Can mention that patchwork doesn't really help tracking active patches
> and revisions, just makes some of the comments categorized. But also
> we don't need to "shit on" other software. We can in more netural way
> that new forget will be an improvement to patch tracking over existing
> patchwork, and that's all.

Its just far from perfect and the stats illustrate that. I don't think 
there's a way to skip implying patchwork doesn't work great.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2045 bytes --]

Hi Lynne

On Wed, Jul 23, 2025 at 01:01:06PM +0900, Lynne wrote:
> 
> 
> On 23/07/2025 08:04, Michael Niedermayer wrote:
> > Hi Lynne
> > 
> > On Tue, Jul 22, 2025 at 12:53:29PM +0900, Lynne wrote:
> > 
> > [...]
> > 
> > > +  <p>
> > > +    Bugs/issues will be accepted on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, alongside
> > > +    with <a href="https://trac.ffmpeg.org/">trac.ffmpeg.org</a> for the time being.
> > > +  </p>
> > 
> > People should not submit bug reports randomly to 2 trackers, thats a problem.
> > It would make searching for issues 2x as hard.
> > 
> > If we discuss and decide to change the bug tracker (which we have not discussed,
> > less decided) -> than we should import all the issues from trac into the new tracker first.
> > 
> > In fact i suggest we make the forgejo issue tracker forward people to trac currently
> 
> I disagree,

You can disagree, but you cannot "in the name of the community" suggest
things that have never been discussed by the community


> I think we need a fresh start to track bugs properly.

IMHO:

1. We need to understand the problem,
2. then think about how to solve it (and choose a solution)
3. then implement the solution
4. then evaluate the implementation/solution

About 1. (IMHO)
* The problem is that carl has become inactive and stoped doing user
  support and maintain the 10000+ bugs on the tracker.

About 2. (IMHO)
* The solution is to hire carl or someone else (or find a volunteer)
  to do this work. Changing the tracker will not fix this.

  FFlabs should have  enough captial to hire carl for this. People should ask
  FFlabs to hire him and carl to accept to be hired for this work.
  Or a "bugs maintaince and user support" should be on the STF 2025 page
  with conditions that someone agrees to, to do that work.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2266 bytes --]

Hi Lynne

On Wed, Jul 23, 2025 at 01:01:06PM +0900, Lynne wrote:
> 
> 
> On 23/07/2025 08:04, Michael Niedermayer wrote:
> > Hi Lynne
> > 
> > On Tue, Jul 22, 2025 at 12:53:29PM +0900, Lynne wrote:
[...]
> > > +  <p>
> > > +    We are also hoping that this will significantly reduce the amount of unmerged patches.
> > > +    If you submitted a patch which received no replies or conclusion, we apologize, and you are encouraged
> > > +    to resubmit it on the new platform.
> > > +  </p>
> > 
> > The announcment should probably mention that performance, as in number of
> > submissions / percentage of applied / not reviewed patches will be
> > monitored compared to the mailing list.
> > 
> > (and obviously someone has to do that, i do think such basic performance
> >   monitoring is important after/ during such a change)
> > 
> > later then (in a month or whatever) we should make an announcment with
> > the performance numbers
> 
> We all know there were plenty of patches left over. What we need to do is to

yes, but the patches arent "forgotten". Everyone, including myself have them
in their ffmpeg-devel mailbox.

Iam not reviewing them not because iam unaware of them but because its just
way too many patches for one person, who than also has many other things to do
besides reviewing patches.

Once one understands this, the solution should be clear
1. we have to split up responsibilities, that is the maintainers system
   each area should have a maintainer who would not waste time with noise outside
   her area. And also not have to endlessly argue with people not maintaining the
   specific code.
2. hire more reviewers/maintainers, so we have more manpower, FFlabs and STF are
   options here, both these options should be used.
3. better tools to get the right patches to the right reviewer with less work,
   I hope forgejo will achieve this
4. We should try to shift work that others can do, away from key people,
   so they have more time for work that we have noone else who can do it.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

z(9) = an object that transcends all computable functions describable
in finite terms. - ChatGPT in 2024

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kieran Kunhya via ffmpeg-devel]

>
>
>
> About 2. (IMHO)
> * The solution is to hire carl or someone else (or find a volunteer)
>   to do this work. Changing the tracker will not fix this.
>
>   FFlabs should have  enough captial to hire carl for this. People should
> ask
>   FFlabs to hire him and carl to accept to be hired for this work.


The commercial decisions of FFlabs are for its shareholders during its
internal meetings, not this mailing list. Not is it relevant to suggest
people should petition a private company (of which I understand you are a
shareholder).

It doesn't take a business mastermind to understand why this plan is flawed.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1038 bytes --]

Hello Kieran

On Wed, Jul 23, 2025 at 10:39:01AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> >
> >
> >
> > About 2. (IMHO)
> > * The solution is to hire carl or someone else (or find a volunteer)
> >   to do this work. Changing the tracker will not fix this.
> >
> >   FFlabs should have  enough captial to hire carl for this. People should
> > ask
> >   FFlabs to hire him and carl to accept to be hired for this work.
> 
> 
> The commercial decisions of FFlabs are for its shareholders during its
> internal meetings, not this mailing list.

Thats a misunderstanding.

Let me quote the president and CEO:

"The company is just a way to finance the community to work on the same
 things as usual."

and

"To me, the company should be transparent to the project. It's just a way
 to funnel money to the community."


thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kieran Kunhya via ffmpeg-devel]

On Wed, Jul 23, 2025 at 10:59 AM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hello Kieran
>
> On Wed, Jul 23, 2025 at 10:39:01AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> > >
> > >
> > >
> > > About 2. (IMHO)
> > > * The solution is to hire carl or someone else (or find a volunteer)
> > >   to do this work. Changing the tracker will not fix this.
> > >
> > >   FFlabs should have  enough captial to hire carl for this. People should
> > > ask
> > >   FFlabs to hire him and carl to accept to be hired for this work.
> >
> >
> > The commercial decisions of FFlabs are for its shareholders during its
> > internal meetings, not this mailing list.
>
> Thats a misunderstanding.
>
> Let me quote the president and CEO:
>
> "The company is just a way to finance the community to work on the same
>  things as usual."
>
> and
>
> "To me, the company should be transparent to the project. It's just a way
>  to funnel money to the community."

One is the vision of the CEO whereas in reality the legal requirements
(articles of association) matter.
Again a topic for your board meeting, not this ML.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Nicolas George]

Michael Niedermayer (HE12025-07-23):
> Let me quote the president and CEO:
> 
> "The company is just a way to finance the community to work on the same
>  things as usual."
> 
> and
> 
> "To me, the company should be transparent to the project. It's just a way
>  to funnel money to the community."

Let me quote a former French president: “Promises only bind people who
listen to them.”

What a CEO says to get you to trust them into depending on their company
and what a CEO does to cultivate the profits of its shareholders are two
completely different things.

Regards,

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Nicolas George]

Michael Niedermayer (HE12025-07-23):
> 2. hire more reviewers/maintainers, so we have more manpower, FFlabs and STF are
>    options here, both these options should be used.

It seems to me that the influence of FFlabs on the project has done much
more harm than good, especially with regard to our ability to work on
fun experimental things rather than boring maintenance. Let us not give
them even more influence please.

Regards,

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[compn]

On Tue, 22 Jul 2025 02:15:22 -0700, Jacob Lifshay wrote:

> On Tue, Jul 22, 2025 at 1:44 AM Kacper Michajlow <kasper93@gmail.com> wrote:
> > On Tue, 22 Jul 2025 at 05:54, Lynne <dev@lynne.ee> wrote:  
> > > +    Additionally, new users have frequently encountered difficulties with mailing list development.
> > > +    From finding out the correct SMTP login details, configuring git send-email, new email security
> > > +    mechanisms interfering with mailing list operations, and finally not having a comfortable workflow
> > > +    to review patches.  
> >
> > Just a 2 cents from me, I don't think sending email itself is a
> > problem,  
> 
> If you don't need to send patches, email isn't really a problem.
> 
> however, imo figuring out how to get git send-email to work is a
> significant problem (it took me like 20-30min to set up since I was
> also figuring how to securely store the gmail app password in gnome
> keyring using a git credential helper), I have contributed to quite a
> few FOSS projects over the last 10yr or so and FFmpeg is the only(?)
> one that requires using git send-email. the vast majority of them are
> using a git forge or you just point them to your git forge of choice
> and they'll pull from there.

people can always just manually attach patches to emails sent to
ffmpeg-devel list. no need for git send mail.

git-send-email is not a requirement to contribute to ffmpeg. in fact,
i've never used git send email to send patches.

git send-email is not listed as a requirement on our mailing list
information page:
https://ffmpeg.org/contact.html#MailingLists
likewise , the submitting patches developer documentation does not make
git send-email a requirement.
https://ffmpeg.org/developer.html#Introduction

also i'm sure whatever development toolset you use can be scripted to
send a patch via email? are you using github or some other non command
line git to write code? maybe there is an easier workflow for you if
git send-email is not to your liking?


thanks for detailing out how other projects do it though, we are
always looking to improve.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Jacob Lifshay]

On Thu, Jul 24, 2025 at 8:40 PM compn <ff@hawaiiantel.net> wrote:
> people can always just manually attach patches to emails sent to
> ffmpeg-devel list. no need for git send mail.

ok, I prefer to never do that though because it makes reading the
patches very annoying. Anyone should be able to read the patches
without having to download files and open them in their editor (which
is particularly annoying on phones), leaving a bunch of unwanted files
around when you're done reading. Yes, I know there's patchwork, but
that's also annoying to get to from the corresponding email since
there's no links to it from the patch email, so you have to go to the
website and search for the patch series you were trying to read.

> also i'm sure whatever development toolset you use can be scripted to
> send a patch via email?

sending emails from my command line is the majority of the annoyance,
since however I do that requires essentially the same steps as setting
up git send-email.

> are you using github or some other non command
> line git to write code?
no, just using git on Debian 12.

> maybe there is an easier workflow for you if
> git send-email is not to your liking?

yes, git push to a new branch, then click on the link to create a new
PR. (hence why I like code.ffmpeg.org)

> thanks for detailing out how other projects do it though, we are
> always looking to improve.

thanks for trying to improve!

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[compn]

On Wed, 23 Jul 2025 11:59:23 +0200, Michael Niedermayer wrote:

> Hello Kieran
> 
> On Wed, Jul 23, 2025 at 10:39:01AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> > > About 2. (IMHO)
> > > * The solution is to hire carl or someone else (or find a volunteer)
> > >   to do this work. Changing the tracker will not fix this.
> > >
> > >   FFlabs should have  enough captial to hire carl for this. People should
> > > ask
> > >   FFlabs to hire him and carl to accept to be hired for this work.  
> > 
> > 
> > The commercial decisions of FFlabs are for its shareholders during its
> > internal meetings, not this mailing list.  
> 
> Thats a misunderstanding.
> 
> Let me quote the president and CEO:
> 
> "The company is just a way to finance the community to work on the same
>  things as usual."
> 
> and
> 
> "To me, the company should be transparent to the project. It's just a way
>  to funnel money to the community."
> 

hello,

fflabs should have its use and goals documented on its
website https://fflabs.eu/services/

otherwise, the fflabs website looks like it hasnt been updated in 2
years, is written in broken english, and looks like just an organization
to hire consultants.

said another way, fflabs doesnt look like anything to do with the ffmpeg
community. at all. besides being some ffmpeg developers for consultant
work.

https://www.linkedin.com/company/fflabs/
"FFLABS is a FFmpeg consulting company"
does not sound like a community focused company at all.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[compn]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Thu, 24 Jul 2025 20:58:19 -0700, Jacob Lifshay wrote:

> On Thu, Jul 24, 2025 at 8:40 PM compn <ff@hawaiiantel.net> wrote:
> > people can always just manually attach patches to emails sent to
> > ffmpeg-devel list. no need for git send mail.  
> 
> ok, I prefer to never do that though because it makes reading the
> patches very annoying. Anyone should be able to read the patches
> without having to download files and open them in their editor (which
> is particularly annoying on phones), leaving a bunch of unwanted files
> around when you're done reading. Yes, I know there's patchwork, but
> that's also annoying to get to from the corresponding email since
> there's no links to it from the patch email, so you have to go to the
> website and search for the patch series you were trying to read.

attaching text patches with the proper mime type or file extension
(.txt) usually allows the email client to handle displaying it without
having to do extra steps. see this email for example.

i just did git diff > patch.txt , then attached patch.txt to this email,
in my normal gui email client.

 
> > also i'm sure whatever development toolset you use can be scripted to
> > send a patch via email?  
> 
> sending emails from my command line is the majority of the annoyance,
> since however I do that requires essentially the same steps as setting
> up git send-email.
> 
> > are you using github or some other non command
> > line git to write code?  
> no, just using git on Debian 12.
> 
> > maybe there is an easier workflow for you if
> > git send-email is not to your liking?  
> 
> yes, git push to a new branch, then click on the link to create a new
> PR. (hence why I like code.ffmpeg.org)

if you have suggestions of any workflows which make it easier for you
or anyone else to contribute, let us know. much thanks :)

-compn

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 246 bytes --]

diff --git a/README.md b/README.md
index f8c23f2870..6b040ab05f 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-FFmpeg README
+FFconvert README
 =============
 
 FFmpeg is a collection of libraries and tools to process multimedia content

[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Nicolas George]

Jacob Lifshay (HE12025-07-24):
> ok, I prefer to never do that though because it makes reading the
> patches very annoying. Anyone should be able to read the patches
> without having to download files and open them in their editor (which
> is particularly annoying on phones), leaving a bunch of unwanted files
> around when you're done reading.

I see your complaint about mail. But then I notice that you are posting
from GMail.

You have to realize that GMail's software is not meant for the likes of
you or me, it is not meant for people who see a plain text file and
think text/plain, it is meant for people who see a plain text file and
look for the way to set it in Comic Sans.

GMail's software is designed to sustain Google's cyberfeudalism market
model: make it very easy to enter and very hard to leave. Making it hard
to leave has the unavoidable consequence to give very little control
that power users can use.

You, and anybody who does not exclaim “I'm not a computer scientist” when
they see a dialog box with more than two buttons, would greatly benefit
from replacing your use of GMail's software with a real mail client
running under your own control.

Not just for your contributions to FFmpeg but for your daily use of mail
also. For example, where GMail only shows you a “conversation” with all
mail in chronological order, a real mail software can show you it as a
tree, making it clear who is responding to who. When the discussion is
not linear, it makes a world of difference.

Note that you can use a real mail client running under your
responsibility and still use Google's gratis hosting, you just need to
connect your client to your GMail account.

And even if you do not want to change your habits, even if you want to
continue to use the GMail webmail-for-lusers in your day to day use of
mail, you can still use a second client just for the patches on the
mailing-list, preferably automating it: a few shell scripts and the
patches will be ready for you in the format you prefer.

In short and imaged, I see you arguing that screws are too difficult to
use and we should use twisted vines instead, but the real issue is that
you are using a Playskool Plastic Tool Set instead of a proper
screwdriver.

Regards,

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kieran Kunhya via ffmpeg-devel]

On Fri, 25 Jul 2025, 12:41 Nicolas George, <george@nsup.org> wrote:

> Jacob Lifshay (HE12025-07-24):
> > ok, I prefer to never do that though because it makes reading the
> > patches very annoying. Anyone should be able to read the patches
> > without having to download files and open them in their editor (which
> > is particularly annoying on phones), leaving a bunch of unwanted files
> > around when you're done reading.
>
> I see your complaint about mail. But then I notice that you are posting
> from GMail.
>
> You have to realize that GMail's software is not meant for the likes of
> you or me, it is not meant for people who see a plain text file and
> think text/plain, it is meant for people who see a plain text file and
> look for the way to set it in Comic Sans.
>
> GMail's software is designed to sustain Google's cyberfeudalism market
> model: make it very easy to enter and very hard to leave. Making it hard
> to leave has the unavoidable consequence to give very little control
> that power users can use.
>
> You, and anybody who does not exclaim “I'm not a computer scientist” when
> they see a dialog box with more than two buttons, would greatly benefit
> from replacing your use of GMail's software with a real mail client
> running under your own control.
>
> Not just for your contributions to FFmpeg but for your daily use of mail
> also. For example, where GMail only shows you a “conversation” with all
> mail in chronological order, a real mail software can show you it as a
> tree, making it clear who is responding to who. When the discussion is
> not linear, it makes a world of difference.
>
> Note that you can use a real mail client running under your
> responsibility and still use Google's gratis hosting, you just need to
> connect your client to your GMail account.
>
> And even if you do not want to change your habits, even if you want to
> continue to use the GMail webmail-for-lusers in your day to day use of
> mail, you can still use a second client just for the patches on the
> mailing-list, preferably automating it: a few shell scripts and the
> patches will be ready for you in the format you prefer.
>
> In short and imaged, I see you arguing that screws are too difficult to
> use and we should use twisted vines instead, but the real issue is that
> you are using a Playskool Plastic Tool Set instead of a proper
> screwdriver.
>
> Regards,
>

The internet is there to sustain cyber feudalism of big tech. You should be
using Faxes and BBSs hosted on true analogue telephone systems. None of
this digital nonsense.

Kieran

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3631 bytes --]

Hi

On Thu, Jul 24, 2025 at 06:05:12PM -1000, compn wrote:
> On Wed, 23 Jul 2025 11:59:23 +0200, Michael Niedermayer wrote:
> 
> > Hello Kieran
> > 
> > On Wed, Jul 23, 2025 at 10:39:01AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> > > > About 2. (IMHO)
> > > > * The solution is to hire carl or someone else (or find a volunteer)
> > > >   to do this work. Changing the tracker will not fix this.
> > > >
> > > >   FFlabs should have  enough captial to hire carl for this. People should
> > > > ask
> > > >   FFlabs to hire him and carl to accept to be hired for this work.  
> > > 
> > > 
> > > The commercial decisions of FFlabs are for its shareholders during its
> > > internal meetings, not this mailing list.  
> > 
> > Thats a misunderstanding.
> > 
> > Let me quote the president and CEO:
> > 
> > "The company is just a way to finance the community to work on the same
> >  things as usual."
> > 
> > and
> > 
> > "To me, the company should be transparent to the project. It's just a way
> >  to funnel money to the community."
> > 
> 
> hello,
> 

> fflabs should have its use and goals documented on its
[...]
> does not sound like a community focused company at all.

i agree and i raised that issue with the CEO yesterday and asked
where I could send proposed changes.
But he is quite busy so dont expect that he will look into
this right away.

About raising the issue of employing carl.
I have raised that multiple times, and i remember none of the shareholders
objecting. But it never happened.
This may make more sense if you consider that to employ him, 3 things
really need to happen at the same time
1. carl needs to want to work for FFlabs
2. It has to fit into the greater strategy of FFlabs
3. FFlabs needs to have sufficient funds.

In the early days, FFlabs simply did not have the funds to employ more people
And also needed to concentrate on growth that is on people directly doing
consulting work that brings in more money and customers
Funds are available now AFAIK, but carl is no longer here


Keep in mind 3 people quit in 2025 and revenue keeps growing so we should have
funds to contract or employ more people. But there is of course also more work
that needs to be done.
And the promise our CEO gave to the community was to finance the community.
So i think it does make sense that the community monitors it and if needed
politely reminds and insists on adjustments ...
Also if noone from the FFmpeg community wants to do any contract work or be
employed by FFlabs in 2025. People need to understand that FFlabs is a
"for profit" company and it cannot accumulate captial without paying taxes.
So it would be wastefull, and FFlabs will likely use the captial for
other things this year and it will just be lost for the FFmpeg community.

In summary i think it does make sense for the FFmpeg community to think
about where money could help teh most and then propose this to FFlabs
as a clear and executable suggestion.

PS: of course all funds available in FFlabs should be used in a way that
    grows FFmpeg and FFlabs. More money in FFlabs means more money available
    to the FFmpeg community. Thats why spending money in a way that brings in
    more money should be prioritized as long as we dont have enough to fund
    everything in FFmpeg that we want to fund.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Derek Buitenhuis]

On 7/22/2025 4:53 AM, Lynne wrote:
> ---
>  src/contact | 11 +++++++++++
>  src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 63 insertions(+)

So I am a bit unclear, is development now Forgejo or ML, or both?

Because right now, it seems like both, and that is basically the worst
possible outcome. It is very difficult to follow both, and the amount
of people reviewing or even looking at patches on either is now significantly
splintered/reduced, allowing lower quality code to wade itself in the meantime,
IMO.

Also, as far as I can tell, the git access list was not really carried over in
any way.

It all seems a bit chaotic and directionless... or rather, with 0 plan.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Timo Rothenpieler]

On 7/26/2025 7:03 PM, Derek Buitenhuis wrote:
> On 7/22/2025 4:53 AM, Lynne wrote:
>> ---
>>   src/contact | 11 +++++++++++
>>   src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 63 insertions(+)
> 
> So I am a bit unclear, is development now Forgejo or ML, or both?
> 
> Because right now, it seems like both, and that is basically the worst
> possible outcome. It is very difficult to follow both, and the amount
> of people reviewing or even looking at patches on either is now significantly
> splintered/reduced, allowing lower quality code to wade itself in the meantime,
> IMO.
> 
> Also, as far as I can tell, the git access list was not really carried over in
> any way.
> 
> It all seems a bit chaotic and directionless... or rather, with 0 plan.

It's still an extended test. You cannot push to it, since it's just a 
mirror.

How do you expect to suddenly switch every last person over from the ML 
to a new tool?
There's always going to be a transition period where both are in use, 
gradually shifting.
So yes, for now there needs to be eyes on both.

Hopefully pushing to it/hitting the merge button should be possible soon 
(hinges on cooperation with Videolan), making more people look at it and 
subscribe to E-Mail notifications of what's going on there.

I also still intend to write a script that forwards at least PRs to the 
ML for the time being, without causing the massive spam that just 
forwarding notifications does.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Derek Buitenhuis]

On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
> It's still an extended test. You cannot push to it, since it's just a 
> mirror.

That's not what written in the announcement, and the fact it is "still
a test" has not been communicated on this list, to my knowledge. It's
all about as clear as mud...

It's possible I am the only one dumb enough to miss that fact, but I suspect
(hope) probably not.

> How do you expect to suddenly switch every last person over from the ML 
> to a new tool?

You do it once, decisively, with no point where it is both dev paths simultaniously.
VideoLAN managed it, and countless companies and other projects have managed it with
no overlap. Many of which I have experienced first hand. It's one thing to slowly
move projects from an org/community over, but having several extant methods of
contributing and reviewing the same repo's code is pretty much the #1 thing that
is avoided.

This isn't really unique to FFmpeg.

> There's always going to be a transition period where both are in use, 
> gradually shifting.

... why? It's not necessary, and is a pretty terrible experience for not
much gain except more time for people to argue.

> So yes, for now there needs to be eyes on both.

Unfortunate.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Timo Rothenpieler]

On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
> On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
>> It's still an extended test. You cannot push to it, since it's just a
>> mirror.
> 
> That's not what written in the announcement, and the fact it is "still
> a test" has not been communicated on this list, to my knowledge. It's
> all about as clear as mud...
> 
> It's possible I am the only one dumb enough to miss that fact, but I suspect
> (hope) probably not.

It's what the whole vote was about, the vote was not "Let's migrate to 
this", but "Let's put this through a more extended test".
So I'd say the list was very much informed about that?

>> How do you expect to suddenly switch every last person over from the ML
>> to a new tool?
> 
> You do it once, decisively, with no point where it is both dev paths simultaniously.
> VideoLAN managed it, and countless companies and other projects have managed it with
> no overlap. Many of which I have experienced first hand. It's one thing to slowly
> move projects from an org/community over, but having several extant methods of
> contributing and reviewing the same repo's code is pretty much the #1 thing that
> is avoided.

Videolan hat the exact same transitional period, where both the ML and 
Gitlab were in use for at least a couple months to half a year.

vlc-devel is still active to this day, even with the very occasional 
stray patch still landing there, just not for patches.
I expect this to go similar for FFmpeg.
At some point there will be a more strong PSA sent out that Patches via 
ML will no longer receive the same attention. But so far now is not that 
time.


> This isn't really unique to FFmpeg.
> 
>> There's always going to be a transition period where both are in use,
>> gradually shifting.
> 
> ... why? It's not necessary, and is a pretty terrible experience for not
> much gain except more time for people to argue.

How do you intend to get everybody into one boat to move over all at once?
VLC has a central governing body who is able to make such decisions and 
force the issue if need be.
FFmpeg does not, so I don't see who would be able to make such a call, 
and specially then also have everyone follow it.

>> So yes, for now there needs to be eyes on both.
> 
> Unfortunate.
> 
> - Derek
> _______________________________________________
> 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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kacper Michajlow]

n Sat, 26 Jul 2025 at 21:29, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>
> On 7/26/2025 7:03 PM, Derek Buitenhuis wrote:
> > On 7/22/2025 4:53 AM, Lynne wrote:
> >> ---
> >>   src/contact | 11 +++++++++++
> >>   src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>   2 files changed, 63 insertions(+)
> >
> > So I am a bit unclear, is development now Forgejo or ML, or both?
> >
> > Because right now, it seems like both, and that is basically the worst
> > possible outcome. It is very difficult to follow both, and the amount
> > of people reviewing or even looking at patches on either is now significantly
> > splintered/reduced, allowing lower quality code to wade itself in the meantime,
> > IMO.
> >
> > Also, as far as I can tell, the git access list was not really carried over in
> > any way.
> >
> > It all seems a bit chaotic and directionless... or rather, with 0 plan.
>
> It's still an extended test. You cannot push to it, since it's just a
> mirror.
>
> How do you expect to suddenly switch every last person over from the ML
> to a new tool?
> There's always going to be a transition period where both are in use,
> gradually shifting.
> So yes, for now there needs to be eyes on both.
>
> Hopefully pushing to it/hitting the merge button should be possible soon
> (hinges on cooperation with Videolan)

I agree with Derek on this topic, I think it is unreasonable to have
two ways to merge patches into the main repository.

Once the "merge button" is operational, all direct push to the
repository should be restricted and always required to go through PR.

There may still be communication/review overlap between ML/forgejo,
but ultimately it should go through one path of merge/approve.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Timo Rothenpieler]

On 7/26/2025 10:14 PM, Kacper Michajlow wrote:
> n Sat, 26 Jul 2025 at 21:29, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>
>> On 7/26/2025 7:03 PM, Derek Buitenhuis wrote:
>>> On 7/22/2025 4:53 AM, Lynne wrote:
>>>> ---
>>>>    src/contact | 11 +++++++++++
>>>>    src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>    2 files changed, 63 insertions(+)
>>>
>>> So I am a bit unclear, is development now Forgejo or ML, or both?
>>>
>>> Because right now, it seems like both, and that is basically the worst
>>> possible outcome. It is very difficult to follow both, and the amount
>>> of people reviewing or even looking at patches on either is now significantly
>>> splintered/reduced, allowing lower quality code to wade itself in the meantime,
>>> IMO.
>>>
>>> Also, as far as I can tell, the git access list was not really carried over in
>>> any way.
>>>
>>> It all seems a bit chaotic and directionless... or rather, with 0 plan.
>>
>> It's still an extended test. You cannot push to it, since it's just a
>> mirror.
>>
>> How do you expect to suddenly switch every last person over from the ML
>> to a new tool?
>> There's always going to be a transition period where both are in use,
>> gradually shifting.
>> So yes, for now there needs to be eyes on both.
>>
>> Hopefully pushing to it/hitting the merge button should be possible soon
>> (hinges on cooperation with Videolan)
> 
> I agree with Derek on this topic, I think it is unreasonable to have
> two ways to merge patches into the main repository.
> 
> Once the "merge button" is operational, all direct push to the
> repository should be restricted and always required to go through PR.
> 
> There may still be communication/review overlap between ML/forgejo,
> but ultimately it should go through one path of merge/approve.

I agree, but unfortunately don't feel like it's a realistic expectation.
Forcing everyone into a new workflow all at once is not going to go well 
with everybody.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kacper Michajlow]

On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>
> On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
> > On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
> >> It's still an extended test. You cannot push to it, since it's just a
> >> mirror.
> >
> > That's not what written in the announcement, and the fact it is "still
> > a test" has not been communicated on this list, to my knowledge. It's
> > all about as clear as mud...
> >
> > It's possible I am the only one dumb enough to miss that fact, but I suspect
> > (hope) probably not.
>
> It's what the whole vote was about, the vote was not "Let's migrate to
> this", but "Let's put this through a more extended test".
> So I'd say the list was very much informed about that?
>
> >> How do you expect to suddenly switch every last person over from the ML
> >> to a new tool?
> >
> > You do it once, decisively, with no point where it is both dev paths simultaniously.
> > VideoLAN managed it, and countless companies and other projects have managed it with
> > no overlap. Many of which I have experienced first hand. It's one thing to slowly
> > move projects from an org/community over, but having several extant methods of
> > contributing and reviewing the same repo's code is pretty much the #1 thing that
> > is avoided.
>
> Videolan hat the exact same transitional period, where both the ML and
> Gitlab were in use for at least a couple months to half a year.
>
> vlc-devel is still active to this day, even with the very occasional
> stray patch still landing there, just not for patches.
> I expect this to go similar for FFmpeg.
> At some point there will be a more strong PSA sent out that Patches via
> ML will no longer receive the same attention. But so far now is not that
> time.
>
>
> > This isn't really unique to FFmpeg.
> >
> >> There's always going to be a transition period where both are in use,
> >> gradually shifting.
> >
> > ... why? It's not necessary, and is a pretty terrible experience for not
> > much gain except more time for people to argue.
>
> How do you intend to get everybody into one boat to move over all at once?

I don't think moving over is something that requires significant
effort. It just needs clear communication about this.

Also, I don't think the current ML workflow is very sophisticated on
ffmpeg-devel, so there are likely not many tools to migrate to the new
one.

I may be wrong, but ffmpeg development is still within git, so in
terms of producing patches / updating repositories nothing changes.
Except the last mile of sending patches for review and handling this
review. It's a change, but if something is reluctant to do this step
now, I don't think having more time changes this situation.

It's just my personal opinion and it doesn't reflect anyone else in
the community.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Derek Buitenhuis]

On 7/26/2025 9:14 PM, Timo Rothenpieler wrote:
> It's what the whole vote was about, the vote was not "Let's migrate to 
> this", but "Let's put this through a more extended test".
> So I'd say the list was very much informed about that?

I'd say this announcement should be amended to reflect this then, because it
does not read at all like testing, but the new sole way to contribute.

(I did indeed miss the single sentence that missed testing at the beginning there, for the
steps like "* announce code.ffmpeg.org publically so people can start submittin and reviewing
on it as an alternative to the ML".)

>>> How do you expect to suddenly switch every last person over from the ML
>>> to a new tool?
>>
>> You do it once, decisively, with no point where it is both dev paths simultaniously.
>> VideoLAN managed it, and countless companies and other projects have managed it with
>> no overlap. Many of which I have experienced first hand. It's one thing to slowly
>> move projects from an org/community over, but having several extant methods of
>> contributing and reviewing the same repo's code is pretty much the #1 thing that
>> is avoided.
> 
> Videolan hat the exact same transitional period, where both the ML and 
> Gitlab were in use for at least a couple months to half a year.

I remember a period where patches that got sent to the ML got told to
use the new method, but not a period where it was treated simultaniously
as an equal and continuing method to contribute. Very possible I am
misremembering, but that's that I recall.

> vlc-devel is still active to this day, even with the very occasional 
> stray patch still landing there, just not for patches.

Unrelated, really. Nobody proposed killing this list for discussion purposes.

> I expect this to go similar for FFmpeg.
> At some point there will be a more strong PSA sent out that Patches via 
> ML will no longer receive the same attention. But so far now is not that 
> time.

As above, suggest rewording the ffmpeg.org change then to better reflect this.

> How do you intend to get everybody into one boat to move over all at once?

Update the contrib docs, and start replying to ML patches (either automated or
not) with instructions on using Forgejo. After a short period, you disable the
old method and/or repo, and only allow the new one (not an extended period).

During the period above, do not treat ML contributions as business as usual.

> VLC has a central governing body who is able to make such decisions and 
> force the issue if need be.

Does the GA not cover this? I did notice the vote was very specifically not
put to GA vote, meaning there can be further endless arguing and refusal to
move.

> FFmpeg does not, so I don't see who would be able to make such a call, 
> and specially then also have everyone follow it.

GA. Vote on it, implement it. That's the end of it.

Either that, or ditch the GA, as it is literally pointless, and acknowledhe
FFmpeg is Michael's project.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Derek Buitenhuis]

On 7/26/2025 9:24 PM, Kacper Michajlow wrote:
> It's just my personal opinion and it doesn't reflect anyone else in
> the community.

It also broadly reflects my view, FWIW.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kacper Michajlow]

On Sat, 26 Jul 2025 at 22:23, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>
> On 7/26/2025 10:14 PM, Kacper Michajlow wrote:
> > n Sat, 26 Jul 2025 at 21:29, Timo Rothenpieler <timo@rothenpieler.org> wrote:
> >>
> >> On 7/26/2025 7:03 PM, Derek Buitenhuis wrote:
> >>> On 7/22/2025 4:53 AM, Lynne wrote:
> >>>> ---
> >>>>    src/contact | 11 +++++++++++
> >>>>    src/index   | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>    2 files changed, 63 insertions(+)
> >>>
> >>> So I am a bit unclear, is development now Forgejo or ML, or both?
> >>>
> >>> Because right now, it seems like both, and that is basically the worst
> >>> possible outcome. It is very difficult to follow both, and the amount
> >>> of people reviewing or even looking at patches on either is now significantly
> >>> splintered/reduced, allowing lower quality code to wade itself in the meantime,
> >>> IMO.
> >>>
> >>> Also, as far as I can tell, the git access list was not really carried over in
> >>> any way.
> >>>
> >>> It all seems a bit chaotic and directionless... or rather, with 0 plan.
> >>
> >> It's still an extended test. You cannot push to it, since it's just a
> >> mirror.
> >>
> >> How do you expect to suddenly switch every last person over from the ML
> >> to a new tool?
> >> There's always going to be a transition period where both are in use,
> >> gradually shifting.
> >> So yes, for now there needs to be eyes on both.
> >>
> >> Hopefully pushing to it/hitting the merge button should be possible soon
> >> (hinges on cooperation with Videolan)
> >
> > I agree with Derek on this topic, I think it is unreasonable to have
> > two ways to merge patches into the main repository.
> >
> > Once the "merge button" is operational, all direct push to the
> > repository should be restricted and always required to go through PR.
> >
> > There may still be communication/review overlap between ML/forgejo,
> > but ultimately it should go through one path of merge/approve.
>
> I agree, but unfortunately don't feel like it's a realistic expectation.
> Forcing everyone into a new workflow all at once is not going to go well
> with everybody.

I agree. But like mentioned in the previous message, I don't think
giving more time changes this in practice. It will likely just move
the "pain point" to a different date. Because at some point there will
be "the date".

Of course this hinges on the fact we will actually use forgejo, it
would be unreasonable to force people to move and then say we are
going back to ML or something. A test period is required, so the
decision can be made.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Derek Buitenhuis]

On 7/26/2025 9:29 PM, Kacper Michajlow wrote:
> I agree. But like mentioned in the previous message, I don't think
> giving more time changes this in practice. It will likely just move
> the "pain point" to a different date. Because at some point there will
> be "the date".

+1

> Of course this hinges on the fact we will actually use forgejo, it
> would be unreasonable to force people to move and then say we are
> going back to ML or something. A test period is required, so the
> decision can be made.

This announcement should not be made at all if this is not a decisive
change, IMO.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Timo Rothenpieler]

On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
> On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>
>> On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
>>> On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
>>>> It's still an extended test. You cannot push to it, since it's just a
>>>> mirror.
>>>
>>> That's not what written in the announcement, and the fact it is "still
>>> a test" has not been communicated on this list, to my knowledge. It's
>>> all about as clear as mud...
>>>
>>> It's possible I am the only one dumb enough to miss that fact, but I suspect
>>> (hope) probably not.
>>
>> It's what the whole vote was about, the vote was not "Let's migrate to
>> this", but "Let's put this through a more extended test".
>> So I'd say the list was very much informed about that?
>>
>>>> How do you expect to suddenly switch every last person over from the ML
>>>> to a new tool?
>>>
>>> You do it once, decisively, with no point where it is both dev paths simultaniously.
>>> VideoLAN managed it, and countless companies and other projects have managed it with
>>> no overlap. Many of which I have experienced first hand. It's one thing to slowly
>>> move projects from an org/community over, but having several extant methods of
>>> contributing and reviewing the same repo's code is pretty much the #1 thing that
>>> is avoided.
>>
>> Videolan hat the exact same transitional period, where both the ML and
>> Gitlab were in use for at least a couple months to half a year.
>>
>> vlc-devel is still active to this day, even with the very occasional
>> stray patch still landing there, just not for patches.
>> I expect this to go similar for FFmpeg.
>> At some point there will be a more strong PSA sent out that Patches via
>> ML will no longer receive the same attention. But so far now is not that
>> time.
>>
>>
>>> This isn't really unique to FFmpeg.
>>>
>>>> There's always going to be a transition period where both are in use,
>>>> gradually shifting.
>>>
>>> ... why? It's not necessary, and is a pretty terrible experience for not
>>> much gain except more time for people to argue.
>>
>> How do you intend to get everybody into one boat to move over all at once?
> 
> I don't think moving over is something that requires significant
> effort. It just needs clear communication about this.

The problem is the lack of any kind of governing body who can 
communicate it in the first place.

> Also, I don't think the current ML workflow is very sophisticated on
> ffmpeg-devel, so there are likely not many tools to migrate to the new
> one.

You'd be surprised about the sophisticated tooling a lot of people have 
built around patch wrangling via a mailing-list.

A lot of people will need to learn an entire new workflow, and I can 
absolutely understand that being forced to do so from one day to the 
next is very disruptive and off putting.

> I may be wrong, but ffmpeg development is still within git, so in
> terms of producing patches / updating repositories nothing changes.
> Except the last mile of sending patches for review and handling this
> review. It's a change, but if something is reluctant to do this step
> now, I don't think having more time changes this situation.

Again, many people have literal decades of experience and tooling set up 
to deal with this exact workflow.
Some kind of transitional period is absolutely warranted.

> It's just my personal opinion and it doesn't reflect anyone else in
> the community.

I'm completely with you that we desperately need to move forward.
But there just are a lot of people who've been with the project for a 
long time who are not comfortable with it or outright reject it.
Do we really want to just leave them behind, and not even give them a 
chance to learn new tools?

> - Kacper


Here's an idea I had to make the transition a bit more rapid:

  - Retire git.videolan.org, make it a pure mirror nobody can push to 
(except the mirror script).
  - Make source.ffmpeg.org point to git.ffmpeg.org instead. This will 
cause host key mismatches for everyone, but if it's clearly announced, 
with the new host keys in the announcement, it should not be too horrible.
  - Set up git.ffmpeg.org to forward all pushes to code.ffmpeg.org, 
without them ever hitting the local repo
  - code.ffmpeg.org then becomes the main repo, so the merge button can 
be enabled without causing a split-brain situation.
  - The same mirror scripts will then keep git.ffmpeg.org up to date for 
pulling.

This allows people to keep their current workflow without being forced 
to sign up on Forgejo, while allowing Forgejo to be fully operational.
Worst that might happen is for people who push directly to g.v.o, who 
will have to reconfigure their remote.

In theory the same kind of forwarding is possible directly from g.v.o, 
but it requires a custom script and then manual maintenance of keys 
allowed to push (or a patched gitolite), so that's unlikely to happen 
and will be annoying to maintain.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Derek Buitenhuis]

On 7/26/2025 9:41 PM, Timo Rothenpieler wrote:
> Again, many people have literal decades of experience and tooling set up 
> to deal with this exact workflow.

https://xkcd.com/1172/
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Kacper Michajlow]

On Sat, 26 Jul 2025 at 22:42, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>
> On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
> > On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@rothenpieler.org> wrote:
> >>
> >> On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
> >>> On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
> >>>> It's still an extended test. You cannot push to it, since it's just a
> >>>> mirror.
> >>>
> >>> That's not what written in the announcement, and the fact it is "still
> >>> a test" has not been communicated on this list, to my knowledge. It's
> >>> all about as clear as mud...
> >>>
> >>> It's possible I am the only one dumb enough to miss that fact, but I suspect
> >>> (hope) probably not.
> >>
> >> It's what the whole vote was about, the vote was not "Let's migrate to
> >> this", but "Let's put this through a more extended test".
> >> So I'd say the list was very much informed about that?
> >>
> >>>> How do you expect to suddenly switch every last person over from the ML
> >>>> to a new tool?
> >>>
> >>> You do it once, decisively, with no point where it is both dev paths simultaniously.
> >>> VideoLAN managed it, and countless companies and other projects have managed it with
> >>> no overlap. Many of which I have experienced first hand. It's one thing to slowly
> >>> move projects from an org/community over, but having several extant methods of
> >>> contributing and reviewing the same repo's code is pretty much the #1 thing that
> >>> is avoided.
> >>
> >> Videolan hat the exact same transitional period, where both the ML and
> >> Gitlab were in use for at least a couple months to half a year.
> >>
> >> vlc-devel is still active to this day, even with the very occasional
> >> stray patch still landing there, just not for patches.
> >> I expect this to go similar for FFmpeg.
> >> At some point there will be a more strong PSA sent out that Patches via
> >> ML will no longer receive the same attention. But so far now is not that
> >> time.
> >>
> >>
> >>> This isn't really unique to FFmpeg.
> >>>
> >>>> There's always going to be a transition period where both are in use,
> >>>> gradually shifting.
> >>>
> >>> ... why? It's not necessary, and is a pretty terrible experience for not
> >>> much gain except more time for people to argue.
> >>
> >> How do you intend to get everybody into one boat to move over all at once?
> >
> > I don't think moving over is something that requires significant
> > effort. It just needs clear communication about this.
>
> The problem is the lack of any kind of governing body who can
> communicate it in the first place.
>
> > Also, I don't think the current ML workflow is very sophisticated on
> > ffmpeg-devel, so there are likely not many tools to migrate to the new
> > one.
>
> You'd be surprised about the sophisticated tooling a lot of people have
> built around patch wrangling via a mailing-list.
>
> A lot of people will need to learn an entire new workflow, and I can
> absolutely understand that being forced to do so from one day to the
> next is very disruptive and off putting.
>
> > I may be wrong, but ffmpeg development is still within git, so in
> > terms of producing patches / updating repositories nothing changes.
> > Except the last mile of sending patches for review and handling this
> > review. It's a change, but if something is reluctant to do this step
> > now, I don't think having more time changes this situation.
>
> Again, many people have literal decades of experience and tooling set up
> to deal with this exact workflow.
> Some kind of transitional period is absolutely warranted.
>
> > It's just my personal opinion and it doesn't reflect anyone else in
> > the community.
>
> I'm completely with you that we desperately need to move forward.
> But there just are a lot of people who've been with the project for a
> long time who are not comfortable with it or outright reject it.
> Do we really want to just leave them behind, and not even give them a
> chance to learn new tools?

No, of course not. I didn't mean it like that. Though sooner or later
the migration will happen, if I understand the current situation
correctly.

I guess it would be easier if Forgejo would allow creating PRs by
email. Though as I understand this is not supported and would have
challenges of its own anyway.

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Timo Rothenpieler]

On 7/26/2025 11:07 PM, Kacper Michajlow wrote:
> On Sat, 26 Jul 2025 at 22:42, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>
>> On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
>>> On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>>>
>>>> On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
>>>>> On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
>>>>>> It's still an extended test. You cannot push to it, since it's just a
>>>>>> mirror.
>>>>>
>>>>> That's not what written in the announcement, and the fact it is "still
>>>>> a test" has not been communicated on this list, to my knowledge. It's
>>>>> all about as clear as mud...
>>>>>
>>>>> It's possible I am the only one dumb enough to miss that fact, but I suspect
>>>>> (hope) probably not.
>>>>
>>>> It's what the whole vote was about, the vote was not "Let's migrate to
>>>> this", but "Let's put this through a more extended test".
>>>> So I'd say the list was very much informed about that?
>>>>
>>>>>> How do you expect to suddenly switch every last person over from the ML
>>>>>> to a new tool?
>>>>>
>>>>> You do it once, decisively, with no point where it is both dev paths simultaniously.
>>>>> VideoLAN managed it, and countless companies and other projects have managed it with
>>>>> no overlap. Many of which I have experienced first hand. It's one thing to slowly
>>>>> move projects from an org/community over, but having several extant methods of
>>>>> contributing and reviewing the same repo's code is pretty much the #1 thing that
>>>>> is avoided.
>>>>
>>>> Videolan hat the exact same transitional period, where both the ML and
>>>> Gitlab were in use for at least a couple months to half a year.
>>>>
>>>> vlc-devel is still active to this day, even with the very occasional
>>>> stray patch still landing there, just not for patches.
>>>> I expect this to go similar for FFmpeg.
>>>> At some point there will be a more strong PSA sent out that Patches via
>>>> ML will no longer receive the same attention. But so far now is not that
>>>> time.
>>>>
>>>>
>>>>> This isn't really unique to FFmpeg.
>>>>>
>>>>>> There's always going to be a transition period where both are in use,
>>>>>> gradually shifting.
>>>>>
>>>>> ... why? It's not necessary, and is a pretty terrible experience for not
>>>>> much gain except more time for people to argue.
>>>>
>>>> How do you intend to get everybody into one boat to move over all at once?
>>>
>>> I don't think moving over is something that requires significant
>>> effort. It just needs clear communication about this.
>>
>> The problem is the lack of any kind of governing body who can
>> communicate it in the first place.
>>
>>> Also, I don't think the current ML workflow is very sophisticated on
>>> ffmpeg-devel, so there are likely not many tools to migrate to the new
>>> one.
>>
>> You'd be surprised about the sophisticated tooling a lot of people have
>> built around patch wrangling via a mailing-list.
>>
>> A lot of people will need to learn an entire new workflow, and I can
>> absolutely understand that being forced to do so from one day to the
>> next is very disruptive and off putting.
>>
>>> I may be wrong, but ffmpeg development is still within git, so in
>>> terms of producing patches / updating repositories nothing changes.
>>> Except the last mile of sending patches for review and handling this
>>> review. It's a change, but if something is reluctant to do this step
>>> now, I don't think having more time changes this situation.
>>
>> Again, many people have literal decades of experience and tooling set up
>> to deal with this exact workflow.
>> Some kind of transitional period is absolutely warranted.
>>
>>> It's just my personal opinion and it doesn't reflect anyone else in
>>> the community.
>>
>> I'm completely with you that we desperately need to move forward.
>> But there just are a lot of people who've been with the project for a
>> long time who are not comfortable with it or outright reject it.
>> Do we really want to just leave them behind, and not even give them a
>> chance to learn new tools?
> 
> No, of course not. I didn't mean it like that. Though sooner or later
> the migration will happen, if I understand the current situation
> correctly.

My point is that there is nobody/nothing that can make a definite call 
"migrate now".
I guess the group of server admins kinda has that power, in that we 
could just make it so, and only allow PRs and no direct pushes anymore.
But that would definitely not go down well and I don't think anyone will 
go that route.

> I guess it would be easier if Forgejo would allow creating PRs by
> email. Though as I understand this is not supported and would have
> challenges of its own anyway.
While it's not possible to create them via E-Mail, it's absolutely 
possible to create them via CLI with the tea tool.

https://gitea.com/gitea/tea

So except for initial signup, you can interact with Forgejo entirely 
from CLI and E-Mail notifications if you so desire.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2103 bytes --]

Hi Timo

On Sat, Jul 26, 2025 at 10:41:57PM +0200, Timo Rothenpieler wrote:
> On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
> > On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@rothenpieler.org> wrote:
> > > 
> > > On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
> > > > On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
[...]
> > Also, I don't think the current ML workflow is very sophisticated on
> > ffmpeg-devel, so there are likely not many tools to migrate to the new
> > one.
> 
> You'd be surprised about the sophisticated tooling a lot of people have
> built around patch wrangling via a mailing-list.
> 
> A lot of people will need to learn an entire new workflow, and I can
> absolutely understand that being forced to do so from one day to the next is
> very disruptive and off putting.

yes, we need decissions that everyone is on board with, even if they
did not vote for the winning choice.

I think the gitlab vs forgejo decission was such a decission, it had
a very clear outcome.

This testing period can show that forgejo works better and that it leads
to more contributors and fewer unreviewed patches.
Or it can fail to do so.

I think having the result of that testing, could convince most people
which is the right choice


[...]
> 
> > It's just my personal opinion and it doesn't reflect anyone else in
> > the community.
> 
> I'm completely with you that we desperately need to move forward.
> But there just are a lot of people who've been with the project for a long
> time who are not comfortable with it or outright reject it.
> Do we really want to just leave them behind, and not even give them a chance
> to learn new tools?

yes, exactly, i think we should make sure everyone moves together

and just speaking about myself how do i replace git send email ?
do we have a drop in replacement for that ?

will reply to the suggestion in a seperate mail

thx
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1511 bytes --]

Hi

On Sat, Jul 26, 2025 at 10:41:57PM +0200, Timo Rothenpieler wrote:
[...]
> Here's an idea I had to make the transition a bit more rapid:
>

>  - Retire git.videolan.org, make it a pure mirror nobody can push to (except
> the mirror script).

+1


>  - Make source.ffmpeg.org point to git.ffmpeg.org instead. This will cause
> host key mismatches for everyone, but if it's clearly announced, with the
> new host keys in the announcement, it should not be too horrible.

+1

The 2 steps above also remove the one special case we have and should simplify
the git setup


>  - Set up git.ffmpeg.org to forward all pushes to code.ffmpeg.org, without
> them ever hitting the local repo

At first glance this sounds like a reasonable step, if it has been tested


>  - code.ffmpeg.org then becomes the main repo, so the merge button can be
> enabled without causing a split-brain situation.

clear improvment, yes


>  - The same mirror scripts will then keep git.ffmpeg.org up to date for
> pulling.
>

> This allows people to keep their current workflow without being forced to
> sign up on Forgejo, while allowing Forgejo to be fully operational.
> Worst that might happen is for people who push directly to g.v.o, who will
> have to reconfigure their remote.
>

yes


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [PATCH] web: announce code.ffmpeg.org

[Timo Rothenpieler]

On 7/27/2025 12:44 AM, Michael Niedermayer wrote:
> Hi Timo
> 
> On Sat, Jul 26, 2025 at 10:41:57PM +0200, Timo Rothenpieler wrote:
>> On 7/26/2025 10:24 PM, Kacper Michajlow wrote:
>>> On Sat, 26 Jul 2025 at 22:14, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>>>
>>>> On 7/26/2025 10:01 PM, Derek Buitenhuis wrote:
>>>>> On 7/26/2025 8:29 PM, Timo Rothenpieler wrote:
> [...]
>>> Also, I don't think the current ML workflow is very sophisticated on
>>> ffmpeg-devel, so there are likely not many tools to migrate to the new
>>> one.
>>
>> You'd be surprised about the sophisticated tooling a lot of people have
>> built around patch wrangling via a mailing-list.
>>
>> A lot of people will need to learn an entire new workflow, and I can
>> absolutely understand that being forced to do so from one day to the next is
>> very disruptive and off putting.
> 
> yes, we need decissions that everyone is on board with, even if they
> did not vote for the winning choice.
> 
> I think the gitlab vs forgejo decission was such a decission, it had
> a very clear outcome.
> 
> This testing period can show that forgejo works better and that it leads
> to more contributors and fewer unreviewed patches.
> Or it can fail to do so.
> 
> I think having the result of that testing, could convince most people
> which is the right choice
> 
> 
> [...]
>>
>>> It's just my personal opinion and it doesn't reflect anyone else in
>>> the community.
>>
>> I'm completely with you that we desperately need to move forward.
>> But there just are a lot of people who've been with the project for a long
>> time who are not comfortable with it or outright reject it.
>> Do we really want to just leave them behind, and not even give them a chance
>> to learn new tools?
> 
> yes, exactly, i think we should make sure everyone moves together
> 
> and just speaking about myself how do i replace git send email ?
> do we have a drop in replacement for that ?

Pretty much just with a push to a branch in your personal fork of 
FFmpeg/FFmpeg on code.ffmpeg.org

When you push to a new branch, git itself will echo you a link to create 
a new Pull Request from it right then.
You can of course also ignore that link and manually create it via the 
Web UI, or use the tea CLI tool to create it.

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