[FFmpeg-devel] [POLL] [VOTE] code.ffmpeg.org vs. ML

[FFmpeg-devel] [POLL] [VOTE] code.ffmpeg.org vs. ML

[Michael Niedermayer via ffmpeg-devel]

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

Hi all

2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
heres the "after testing" discussion and vote

do we want to keep Forgejo or switch back to the ML workflow
(or something else)

F. keep Forgejo as primary forge for patch/git workflow
M. switch back to the ML for patch/git workflow

all GA members can vote, by publically replying here with a
"F." / "Forgejo" vs "M." / "ML"
End time is in 7 days unless teh community wants to extend that.
(Also if results are inconclusive like because a 3rd option emerges
 then ill restart this with condorcet on vote.ffmpeg.org)

* If we keep forgejo we will likely transition our issue tracker tickets
  into forgejo too, discussing with timo yesterday night indicates that
  this likely can be done cleaner and neater than at first expected.

* if we switch back to the ML, we still could have subsystem maintainers
  using their own forge


thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates

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

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Diederick C. Niehorster via ffmpeg-devel]

F

On Tue, Sep 16, 2025 at 10:50 AM Michael Niedermayer via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
>
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
>
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"
> End time is in 7 days unless teh community wants to extend that.
> (Also if results are inconclusive like because a 3rd option emerges
>  then ill restart this with condorcet on vote.ffmpeg.org)
>
> * If we keep forgejo we will likely transition our issue tracker tickets
>   into forgejo too, discussing with timo yesterday night indicates that
>   this likely can be done cleaner and neater than at first expected.
>
> * if we switch back to the ML, we still could have subsystem maintainers
>   using their own forge
>
>
> thx
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Timo Rothenpieler via ffmpeg-devel]

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

Staying with Forgejo, so option "F".

On 9/16/2025 10:49 AM, Michael Niedermayer wrote:
> Hi all
> 
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
> 
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
> 
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
> 
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"
> End time is in 7 days unless teh community wants to extend that.
> (Also if results are inconclusive like because a 3rd option emerges
>   then ill restart this with condorcet on vote.ffmpeg.org)
> 
> * If we keep forgejo we will likely transition our issue tracker tickets
>    into forgejo too, discussing with timo yesterday night indicates that
>    this likely can be done cleaner and neater than at first expected.
> 
> * if we switch back to the ML, we still could have subsystem maintainers
>    using their own forge
> 
> 
> thx
> 


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 bytes --]

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Martin Storsjö via ffmpeg-devel]

On Tue, 16 Sep 2025, Michael Niedermayer wrote:

> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
>
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
>
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"

Any vote on anything that can be even potentially contentious should be 
made with closed voting, not requiring everybody to publicly state their 
preference.

// Martin

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Michael Niedermayer via ffmpeg-devel]

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

Hi Martin

On Tue, Sep 16, 2025 at 02:12:20PM +0300, Martin Storsjö via ffmpeg-devel wrote:
> On Tue, 16 Sep 2025, Michael Niedermayer wrote:
> 
> > Hi all
> > 
> > 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> > Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> > heres the "after testing" discussion and vote
> > 
> > do we want to keep Forgejo or switch back to the ML workflow
> > (or something else)
> > 
> > F. keep Forgejo as primary forge for patch/git workflow
> > M. switch back to the ML for patch/git workflow
> > 
> > all GA members can vote, by publically replying here with a
> > "F." / "Forgejo" vs "M." / "ML"
> 

> Any vote on anything that can be even potentially contentious should be made
> with closed voting, not requiring everybody to publicly state their
> preference.

You mean a "secret ballot"

First, id like to say thanks, for you commenting here, even if we dont
agree. I think such debate is a good thing as long as its friendly
and you always have been friendly!

my current oppinion on the subject:

The main goal of a secret ballot is to protect the citizen so she can delegate
her power to a "office holder" freely

OTOH,

The "office holder" must be acountable and must vote in public. Not only
must the citizens know what their representatives do, but just in general
the decission makers need to take responsibility for their actions. Even
if they are not elected. The citizens may for example choose to protest
against non elected "office holders" even if they cannot vote them out.

I think members of the General Assembly are not mere citizens in this case.
So unless there are matters of privacy or other special cases.
i think theres an argument that the votes should be public

In this specific case, the decission affects many hundread contributors
while only members of the General Assembly can vote.
I dont think this should be a secret vote
I think the contributors (who cannot vote themselfs) have a right to know
who voted which way

Also i think its better for a government to stand up to its decissions

thx

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

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

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

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Martin Storsjö via ffmpeg-devel]

On Tue, 16 Sep 2025, Michael Niedermayer via ffmpeg-devel wrote:

> On Tue, Sep 16, 2025 at 02:12:20PM +0300, Martin Storsjö via ffmpeg-devel wrote:
>> On Tue, 16 Sep 2025, Michael Niedermayer wrote:
>>
>>> Hi all
>>>
>>> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
>>> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
>>> heres the "after testing" discussion and vote
>>>
>>> do we want to keep Forgejo or switch back to the ML workflow
>>> (or something else)
>>>
>>> F. keep Forgejo as primary forge for patch/git workflow
>>> M. switch back to the ML for patch/git workflow
>>>
>>> all GA members can vote, by publically replying here with a
>>> "F." / "Forgejo" vs "M." / "ML"
>>
>
>> Any vote on anything that can be even potentially contentious should be made
>> with closed voting, not requiring everybody to publicly state their
>> preference.
>
> You mean a "secret ballot"
>
> First, id like to say thanks, for you commenting here, even if we dont
> agree. I think such debate is a good thing as long as its friendly
> and you always have been friendly!
>
> my current oppinion on the subject:
>
> The main goal of a secret ballot is to protect the citizen so she can delegate
> her power to a "office holder" freely

No, that is not the point at all.

The point is having one's voice and vote count, without needing to 
disclose it publicly. On potentially contentious matters, people eligible 
to vote may wish to do so, without having to publicly state their 
preference attached to their name.

Or like Rémi explained it in 
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-August/347939.html:

> A public ballot, also known as plebiscite, is by nature a performative 
> exercise.
> 
> A secret ballot allows people to express their opinion based purely on 
> the technical and moral merits without the fear of a bad perception and 
> self-censorship.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Nicolas George via ffmpeg-devel]

Martin Storsjö via ffmpeg-devel (HE12025-09-16):
> No, that is not the point at all.
> 
> The point is having one's voice and vote count, without needing to disclose
> it publicly. On potentially contentious matters, people eligible to vote may
> wish to do so, without having to publicly state their preference attached to
> their name.

“The point of secret voting is that people can vote secretly.”
Nice circular reasoning.

Historically, the point of secret ballot in democracies was to prevent
coercion and corruption. This is why citizen not only can vote secretly:
they must. Citizen have to be alone in the voting booth, they cannot
take anything with them that proves what they voted so that nobody can
force them to with a threat of the promise of a bribe.

This principle has been weakened with provisions for remote voting, but
it is still the logical justification for vote secrecy as we have in
democracies.

Note than in other contexts, vote is not secret, because the constraints
are different. Michael already mentioned elected officials. We can also
mention company shareholders: when the shareholders vote on something,
the votes are usually public, at least within the company.

The relationship of FFmpeg developers with the project is more akin to
the relationship of shareholders to a company than to the relationship
of a citizen to their country.

Anyway, the project leader who decides, when polling members, whether
the poll is public or private is a perfectly normal way of managing the
project.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Michael Niedermayer via ffmpeg-devel]

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

Hi Martin

On Tue, Sep 16, 2025 at 10:54:19PM +0300, Martin Storsjö via ffmpeg-devel wrote:
> On Tue, 16 Sep 2025, Michael Niedermayer via ffmpeg-devel wrote:
> 
> > On Tue, Sep 16, 2025 at 02:12:20PM +0300, Martin Storsjö via ffmpeg-devel wrote:
> > > On Tue, 16 Sep 2025, Michael Niedermayer wrote:
> > > 
> > > > Hi all
> > > > 
> > > > 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> > > > Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> > > > heres the "after testing" discussion and vote
> > > > 
> > > > do we want to keep Forgejo or switch back to the ML workflow
> > > > (or something else)
> > > > 
> > > > F. keep Forgejo as primary forge for patch/git workflow
> > > > M. switch back to the ML for patch/git workflow
> > > > 
> > > > all GA members can vote, by publically replying here with a
> > > > "F." / "Forgejo" vs "M." / "ML"
> > > 
> > 
> > > Any vote on anything that can be even potentially contentious should be made
> > > with closed voting, not requiring everybody to publicly state their
> > > preference.
> > 
> > You mean a "secret ballot"
> > 
> > First, id like to say thanks, for you commenting here, even if we dont
> > agree. I think such debate is a good thing as long as its friendly
> > and you always have been friendly!
> > 
> > my current oppinion on the subject:
> > 
> > The main goal of a secret ballot is to protect the citizen so she can delegate
> > her power to a "office holder" freely
> 
> No, that is not the point at all.

“democracies die behind closed doors.”


> 
> The point is having one's voice and vote count, without needing to disclose
> it publicly.

The purpose of a government is to govern, to make the right decissions
and to take responsibility, especially when the decissions where wrong.

A secret ballot conflicts with this.

Also if you want an example
The classical Assembly (Ekklesia) in ancient greece voted in public

And in most modern Democracies, parliamentary votes are public

In governments where each area has a minister, decissions can be associated
with the specific minister.

There are situations where fully public ballots are bad. like when
deciding military strategy
Or when the citizens elect their representattives (see nicolas reply)


> On potentially contentious matters, people eligible to vote may
> wish to do so, without having to publicly state their preference attached to
> their name.

Certainly. I understand people prefer to have power without having to
stand with their name behind their decission (and take responsibility
if it was the wrong decission)
But i think thats not in the interrest of FFmpeg or the community.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban

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

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Martin Storsjö via ffmpeg-devel]

On Tue, 16 Sep 2025, Michael Niedermayer wrote:

> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
>
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"
> End time is in 7 days unless teh community wants to extend that.
> (Also if results are inconclusive like because a 3rd option emerges
> then ill restart this with condorcet on vote.ffmpeg.org)

F - I think we should keep using Forgejo, not moving back to the mailing 
list for code review.

// Martin

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Marvin Scholz via ffmpeg-devel]

On 16 Sep 2025, at 10:49, Michael Niedermayer wrote:

> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
>
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
>
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"
> End time is in 7 days unless teh community wants to extend that.
> (Also if results are inconclusive like because a 3rd option emerges
>  then ill restart this with condorcet on vote.ffmpeg.org)

F (Keep Forgejo)
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Alexander Strasser via ffmpeg-devel]

On 2025-09-16 10:49 +0200, Michael Niedermayer via ffmpeg-devel wrote:
> 
[...]
> 
> * If we keep forgejo we will likely transition our issue tracker tickets
>   into forgejo too, discussing with timo yesterday night indicates that
>   this likely can be done cleaner and neater than at first expected.

I would say this is not an absolute requirement and you also say likely.

Just saw Timo voicing his concerns in #ffmpeg-devel , not on the
technical part but about if it really is a good idea.

I'm not entirely sure what is best and on the practicality and effort.
Could also imagine to leave a static readonly version online and add a
banner at the top on how to proceed with new issues.

Just saying IMHO we should postpone this detailed discussion to a later
point iff our Forgejo instance will be the primary forge.

Also in that case I think migrating our Trac Wiki would be a good idea
and should be done first (before tackling our Trac issues).


Best regards,
  Alexander (beastd)
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Michael Niedermayer via ffmpeg-devel]

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

Hi Alexander

On Tue, Sep 16, 2025 at 03:59:38PM +0200, Alexander Strasser via ffmpeg-devel wrote:
> On 2025-09-16 10:49 +0200, Michael Niedermayer via ffmpeg-devel wrote:
> > 
> [...]
> > 
> > * If we keep forgejo we will likely transition our issue tracker tickets
> >   into forgejo too, discussing with timo yesterday night indicates that
> >   this likely can be done cleaner and neater than at first expected.
> 
> I would say this is not an absolute requirement and you also say likely.
> 
> Just saw Timo voicing his concerns in #ffmpeg-devel , not on the
> technical part but about if it really is a good idea.
> 
> I'm not entirely sure what is best and on the practicality and effort.

The effort to handle 2 issue trackers is real, especially for users
and would make ffmpeg look incompetent on top of that

I read some random comments on redmine and people spoke about
transitioing from trac to redmine from redmine to gitlab.
I mean that they done that and no longer needed trac import support thus.

If you look at google they switched their tracker for ther fuzzer
stuff, all issues where transitioned there are no "static html"
with banners


> Could also imagine to leave a static readonly version online and add a
> banner at the top on how to proceed with new issues.

we moved the whole history from cvs to svn then from svn to git


> 
> Just saying IMHO we should postpone this detailed discussion to a later
> point iff our Forgejo instance will be the primary forge.
> 

> Also in that case I think migrating our Trac Wiki would be a good idea
> and should be done first (before tackling our Trac issues).

As long as the wiki is only in one place the wiki can wait.

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

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

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Balint Marton via ffmpeg-devel]

On Tue, 16 Sep 2025, Michael Niedermayer via ffmpeg-devel wrote:

> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)

Forgejo was not bad, but I remember some issues:

- When doing individual patch reviews and quoting code the code context
   gets messed up, maybe it is references the combined diff?
- Comparing pull request versions does not remove the upstreamed commits
   from the comparison, so if a new version is newly rebased, I see
   upstream commits as well in the comparison.
- I am not sure what would be the counterpart of doing a last-chance ping
   before applying a series in the foregejo system, it was a useful thing
   in the ML workflow. Maybe some "auto-apply this in 1 day even if there
   are no approvals" checkbox with mail notificaitons could work, and that
   would also resolve the issue of self-approval.
- Bumping versions and final commit polishing is a bit tiresome with
   foregjo. E.g. it would be nice if I could also edit the commit message,
   not just the commit title in the web page...
- Pull requests show up on the mailing list but not force pushes, so
   people only reading patches via email won't get notifications of new
   versions.

Not sure how many of these are fixable...

>
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
>
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"
> End time is in 7 days unless teh community wants to extend that.
> (Also if results are inconclusive like because a 3rd option emerges
> then ill restart this with condorcet on vote.ffmpeg.org)
>
> * If we keep forgejo we will likely transition our issue tracker tickets
>  into forgejo too, discussing with timo yesterday night indicates that
>  this likely can be done cleaner and neater than at first expected.

Forgejo issue tracker is seriously lacking features:
- severities
- resolutions
- issue workflow
- votes
- custom keywords for components (e.g. mxf, mpegts)
Simple tags to emulate all these is a hack, e.g. how can you 
enforce a single severity or a single resoluton for a resolved issue? Or 
do ordering by severity or status?

So this vote being about ML v.s. forgejo should not cause any decision 
regarding the issue tracker, that should be another vote if any. Until 
forgejo catches up, I'd rather keep trac.

Regards,
Marton

>
> * if we switch back to the ML, we still could have subsystem maintainers
>  using their own forge
>
>
> thx
>
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Timo Rothenpieler via ffmpeg-devel]

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

On 9/16/2025 11:12 PM, Balint Marton via ffmpeg-devel wrote:
> 
> 
> On Tue, 16 Sep 2025, Michael Niedermayer via ffmpeg-devel wrote:
> 
>> Hi all
>>
>> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
>> Forgejo. And as said in that vote, (and surprisingly, i have not 
>> forgotten it)
>> heres the "after testing" discussion and vote
>>
>> do we want to keep Forgejo or switch back to the ML workflow
>> (or something else)
> 
> Forgejo was not bad, but I remember some issues:
> 
> - When doing individual patch reviews and quoting code the code context
>    gets messed up, maybe it is references the combined diff?

That's a bug in Forgejo, which was introduced in Gitea, when someone 
tried to fix that exact bug:
https://codeberg.org/forgejo/forgejo/pulls/9264

> - Comparing pull request versions does not remove the upstreamed commits
>    from the comparison, so if a new version is newly rebased, I see
>    upstream commits as well in the comparison.

Yeah, that's definitely an issue.
I've kinda started to manually work around it by doing separate pushes 
for rebases and actual changes.

GitHub is also not entirely free from this, though does handle it a bit 
smoother.

> - I am not sure what would be the counterpart of doing a last-chance ping
>    before applying a series in the foregejo system, it was a useful thing
>    in the ML workflow. Maybe some "auto-apply this in 1 day even if there
>    are no approvals" checkbox with mail notificaitons could work, and that
>    would also resolve the issue of self-approval.

That's not an option, but could be emulated with CI to some extend.
But generally if someone wants to insta-merge a PR, they can. Given they 
could just push it manually.

> - Bumping versions and final commit polishing is a bit tiresome with
>    foregjo. E.g. it would be nice if I could also edit the commit message,
>    not just the commit title in the web page...

I'm not entirely sure what you're referring to here.
Editing commit messages via Web UI? Where do you ever do that?

> - Pull requests show up on the mailing list but not force pushes, so
>    people only reading patches via email won't get notifications of new
>    versions.

That's an intentional decision. I could send mails for every single 
thing that happens in a PR, but I opted not to to not completely flood 
the ML.

> Not sure how many of these are fixable...
> 
>>
>> F. keep Forgejo as primary forge for patch/git workflow
>> M. switch back to the ML for patch/git workflow
>>
>> all GA members can vote, by publically replying here with a
>> "F." / "Forgejo" vs "M." / "ML"
>> End time is in 7 days unless teh community wants to extend that.
>> (Also if results are inconclusive like because a 3rd option emerges
>> then ill restart this with condorcet on vote.ffmpeg.org)
>>
>> * If we keep forgejo we will likely transition our issue tracker tickets
>>  into forgejo too, discussing with timo yesterday night indicates that
>>  this likely can be done cleaner and neater than at first expected.
> 
> Forgejo issue tracker is seriously lacking features:
> - severities
> - resolutions
> - issue workflow
> - votes
> - custom keywords for components (e.g. mxf, mpegts)
> Simple tags to emulate all these is a hack, e.g. how can you enforce a 
> single severity or a single resoluton for a resolved issue? Or do 
> ordering by severity or status?
> 
> So this vote being about ML v.s. forgejo should not cause any decision 
> regarding the issue tracker, that should be another vote if any. Until 
> forgejo catches up, I'd rather keep trac.
> 
> Regards,
> Marton
> 
>>
>> * if we switch back to the ML, we still could have subsystem maintainers
>>  using their own forge
>>
>>
>> thx
>>
>> -- 
>> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I have often repented speaking, but never of holding my tongue.
>> -- Xenocrates
>>
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 bytes --]

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Marton Balint via ffmpeg-devel]

On Wed, 17 Sep 2025, Timo Rothenpieler via ffmpeg-devel wrote:

> On 9/16/2025 11:12 PM, Balint Marton via ffmpeg-devel wrote:
>>
>>
>>  - I am not sure what would be the counterpart of doing a last-chance ping
>>     before applying a series in the foregejo system, it was a useful thing
>>     in the ML workflow. Maybe some "auto-apply this in 1 day even if there
>>     are no approvals" checkbox with mail notificaitons could work, and that
>>     would also resolve the issue of self-approval.
>
> That's not an option, but could be emulated with CI to some extend.
> But generally if someone wants to insta-merge a PR, they can. Given they 
> could just push it manually.

Yeah, I know I can always push manually, it just more work than pressing a 
simple button on the web UI. Also notifying the others that I intend to 
push something soon (even if there are no approvals) is a feature which we 
now miss.

>
>>  - Bumping versions and final commit polishing is a bit tiresome with
>>     foregjo. E.g. it would be nice if I could also edit the commit message,
>>     not just the commit title in the web page...
>
> I'm not entirely sure what you're referring to here.
> Editing commit messages via Web UI? Where do you ever do that?

When applying other people's work, it is quite common that the patch is 
good but the commit message is bad. It is less work for me to reword the 
commit message (and apply the patch) instead of describing what need to be 
changed. Yeah, I could pull the branch, fix the commit message, force push 
it, and apply, but that is cumbersome... Forgejo already has the ability 
to edit commit message title, so editing the commit message as well should 
not be too hard.

>
>>  - Pull requests show up on the mailing list but not force pushes, so
>>     people only reading patches via email won't get notifications of new
>>     versions.
>
> That's an intentional decision. I could send mails for every single thing 
> that happens in a PR, but I opted not to to not completely flood the ML.

Force pushes to pull requests are like patch v2 / v3, etc. If we send the 
original pull request as a patch to the ML, we should also send updated 
patches to the ML.

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Timo Rothenpieler via ffmpeg-devel]

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

On 9/17/2025 8:32 PM, Marton Balint via ffmpeg-devel wrote:
> 
> 
> On Wed, 17 Sep 2025, Timo Rothenpieler via ffmpeg-devel wrote:
> 
>> On 9/16/2025 11:12 PM, Balint Marton via ffmpeg-devel wrote:
>>>
>>>
>>>  - I am not sure what would be the counterpart of doing a last-chance 
>>> ping
>>>     before applying a series in the foregejo system, it was a useful 
>>> thing
>>>     in the ML workflow. Maybe some "auto-apply this in 1 day even if 
>>> there
>>>     are no approvals" checkbox with mail notificaitons could work, 
>>> and that
>>>     would also resolve the issue of self-approval.
>>
>> That's not an option, but could be emulated with CI to some extend.
>> But generally if someone wants to insta-merge a PR, they can. Given 
>> they could just push it manually.
> 
> Yeah, I know I can always push manually, it just more work than pressing 
> a simple button on the web UI. Also notifying the others that I intend 
> to push something soon (even if there are no approvals) is a feature 
> which we now miss.

You can still just comment that in the same way you do with a mail. And 
it's how it's already being done on multiple PRs.

>>
>>>  - Bumping versions and final commit polishing is a bit tiresome with
>>>     foregjo. E.g. it would be nice if I could also edit the commit 
>>> message,
>>>     not just the commit title in the web page...
>>
>> I'm not entirely sure what you're referring to here.
>> Editing commit messages via Web UI? Where do you ever do that?
> 
> When applying other people's work, it is quite common that the patch is 
> good but the commit message is bad. It is less work for me to reword the 
> commit message (and apply the patch) instead of describing what need to 
> be changed. Yeah, I could pull the branch, fix the commit message, force 
> push it, and apply, but that is cumbersome... Forgejo already has the 
> ability to edit commit message title, so editing the commit message as 
> well should not be too hard.

Does it? You can edit the PR title, but with the rebase based merged we 
do, that has no impact on the commit messaged.
It'd only be used in a squash merge.
Or am I missing a feature somewhere?

>>
>>>  - Pull requests show up on the mailing list but not force pushes, so
>>>     people only reading patches via email won't get notifications of new
>>>     versions.
>>
>> That's an intentional decision. I could send mails for every single 
>> thing that happens in a PR, but I opted not to to not completely flood 
>> the ML.
> 
> Force pushes to pull requests are like patch v2 / v3, etc. If we send 
> the original pull request as a patch to the ML, we should also send 
> updated patches to the ML.

The problem is they can be very frequent. And not only force pushes.
So the current implementation is a compromise between visibility and 
spam-level.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 bytes --]

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Nicolas George via ffmpeg-devel]

Timo Rothenpieler via ffmpeg-devel (HE12025-09-18):
> The problem is they can be very frequent. And not only force pushes.
> So the current implementation is a compromise between visibility and
> spam-level.

They are not more frequent than v2, v3, etc., used to be, and therefore
below acceptable spam threshold.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Jacob Lifshay via ffmpeg-devel]

On Thu, Sep 18, 2025 at 12:03 AM Nicolas George via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> Timo Rothenpieler via ffmpeg-devel (HE12025-09-18):
> > The problem is they can be very frequent. And not only force pushes.
> > So the current implementation is a compromise between visibility and
> > spam-level.
>
> They are not more frequent than v2, v3, etc., used to be, and therefore
> below acceptable spam threshold.

I don't know about you, but whenever I'm developing code, I sometimes
push new changes multiple times in a day and then only ask for more
review after I'm done developing whatever thing I'm working on, maybe
after several days -- pushing code is way more often than I might send
out patch sets via mail since that tends to directly imply I want the
latest code to be reviewed now and I think it's ready, rather than
just git pushing so the code is on the server in case I want to access
it from a different computer or just see if CI passes or something.

Jacob
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Nicolas George via ffmpeg-devel]

Jacob Lifshay via ffmpeg-devel (HE12025-09-18):
> I don't know about you, but whenever I'm developing code, I sometimes
> push new changes multiple times in a day and then only ask for more
> review after I'm done developing whatever thing I'm working on, maybe
> after several days -- pushing code is way more often than I might send
> out patch sets via mail since that tends to directly imply I want the
> latest code to be reviewed now and I think it's ready, rather than
> just git pushing so the code is on the server in case I want to access
> it from a different computer or just see if CI passes or something.

If this web monster does not let you push code in your private fork
without asking to include it upstream, it is one more reason not to use
that thing.

PS: please do not bypass reply-to headers.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Jacob Lifshay via ffmpeg-devel]

On September 18, 2025 2:15:22 AM PDT, Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> If this web monster does not let you push code in your private fork
> without asking to include it upstream, it is one more reason not to use
> that thing.

It does let you push to your private fork without updating an open PR when you're pushing to any ref other than the branch the PR was created from.

> PS: please do not bypass reply-to headers.

Ok, I'll try to pay attention.

On other mailing lists I've been asked to use reply all, so I have that as the default in gmail.

Jacob
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Niklas Haas via ffmpeg-devel]

On Thu, 18 Sep 2025 01:52:31 -0700 Jacob Lifshay via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> On Thu, Sep 18, 2025 at 12:03 AM Nicolas George via ffmpeg-devel
> <ffmpeg-devel@ffmpeg.org> wrote:
> >
> > Timo Rothenpieler via ffmpeg-devel (HE12025-09-18):
> > > The problem is they can be very frequent. And not only force pushes.
> > > So the current implementation is a compromise between visibility and
> > > spam-level.
> >
> > They are not more frequent than v2, v3, etc., used to be, and therefore
> > below acceptable spam threshold.
>
> I don't know about you, but whenever I'm developing code, I sometimes
> push new changes multiple times in a day and then only ask for more
> review after I'm done developing whatever thing I'm working on, maybe
> after several days -- pushing code is way more often than I might send
> out patch sets via mail since that tends to directly imply I want the
> latest code to be reviewed now and I think it's ready, rather than
> just git pushing so the code is on the server in case I want to access
> it from a different computer or just see if CI passes or something.

We could send a copy to the ML whenever the PR author requests a review
(via the web interface). Normally, in a scenario like the above, I would
first make any changes until I'm happy and then (re-)request a review.
>
> Jacob
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Marton Balint via ffmpeg-devel]

On Thu, 18 Sep 2025, Timo Rothenpieler via ffmpeg-devel wrote:

> On 9/17/2025 8:32 PM, Marton Balint via ffmpeg-devel wrote:
>>
>>
>>  On Wed, 17 Sep 2025, Timo Rothenpieler via ffmpeg-devel wrote:
>>
>>>  On 9/16/2025 11:12 PM, Balint Marton via ffmpeg-devel wrote:
>>>> 
>>>>
>>>>   - I am not sure what would be the counterpart of doing a last-chance
>>>>  ping
>>>>      before applying a series in the foregejo system, it was a useful
>>>>  thing
>>>>      in the ML workflow. Maybe some "auto-apply this in 1 day even if
>>>>  there
>>>>      are no approvals" checkbox with mail notificaitons could work, and
>>>>  that
>>>>      would also resolve the issue of self-approval.
>>>
>>>  That's not an option, but could be emulated with CI to some extend.
>>>  But generally if someone wants to insta-merge a PR, they can. Given they
>>>  could just push it manually.
>>
>>  Yeah, I know I can always push manually, it just more work than pressing a
>>  simple button on the web UI. Also notifying the others that I intend to
>>  push something soon (even if there are no approvals) is a feature which we
>>  now miss.
>
> You can still just comment that in the same way you do with a mail. And it's 
> how it's already being done on multiple PRs.

Ok.

>
>>>
>>>>   - Bumping versions and final commit polishing is a bit tiresome with
>>>>      foregjo. E.g. it would be nice if I could also edit the commit
>>>>  message,
>>>>      not just the commit title in the web page...
>>>
>>>  I'm not entirely sure what you're referring to here.
>>>  Editing commit messages via Web UI? Where do you ever do that?
>>
>>  When applying other people's work, it is quite common that the patch is
>>  good but the commit message is bad. It is less work for me to reword the
>>  commit message (and apply the patch) instead of describing what need to be
>>  changed. Yeah, I could pull the branch, fix the commit message, force push
>>  it, and apply, but that is cumbersome... Forgejo already has the ability
>>  to edit commit message title, so editing the commit message as well should
>>  not be too hard.
>
> Does it? You can edit the PR title, but with the rebase based merged we do, 
> that has no impact on the commit messaged.
> It'd only be used in a squash merge.
> Or am I missing a feature somewhere?

You are right, it only allows editing the pull request title. I assumed 
when I clicked on a specific commit in the pull request it shows (and 
possibly edits) the commit title on the top of the page, but no, that is 
the pull request title regardless of the commit I clicked on...

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Niklas Haas via ffmpeg-devel]

On Tue, 16 Sep 2025 23:12:55 +0200 Balint Marton via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> [...]
>
> - Comparing pull request versions does not remove the upstreamed commits
>    from the comparison, so if a new version is newly rebased, I see
>    upstream commits as well in the comparison.
>
> [...]

I think this is a bit of a moot point in a thread about ForgeJo vs ML because
the ML workflow does not offer the ability to diff patch versions against
each other at all, unless you count manually applying, rebasing and comparing
branches locally. (Which you can still do with ForgeJo)
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Philip Langdale via ffmpeg-devel]

On Tue, 16 Sep 2025 10:49:00 +0200
Michael Niedermayer <michael@niedermayer.cc> wrote:

> Hi all
> 
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and
> tested Forgejo. And as said in that vote, (and surprisingly, i have
> not forgotten it) heres the "after testing" discussion and vote
> 
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
> 
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow
> 
> all GA members can vote, by publically replying here with a
> "F." / "Forgejo" vs "M." / "ML"
> End time is in 7 days unless teh community wants to extend that.
> (Also if results are inconclusive like because a 3rd option emerges
>  then ill restart this with condorcet on vote.ffmpeg.org)
> 
> * If we keep forgejo we will likely transition our issue tracker
> tickets into forgejo too, discussing with timo yesterday night
> indicates that this likely can be done cleaner and neater than at
> first expected.
> 
> * if we switch back to the ML, we still could have subsystem
> maintainers using their own forge
> 
> 
> thx
> 

F


--phil
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Nicolas George via ffmpeg-devel]

Michael Niedermayer via ffmpeg-devel (HE12025-09-16):
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow

M of course.

We can try again in a year or two when the proponents have had time to
learn from the mistakes of this attempt.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Niklas Haas via ffmpeg-devel]

On Tue, 16 Sep 2025 10:49:00 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
>
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow

F, with strong preference.

I am neutral on the issue of where to have bug tracking for the time being.

I am also neutral on GitLab vs ForgeJo - I think both systems have their
strengths and weaknesses, although it appears simpler to smooth out ForgeJo's
bugs than to modify GitLab's monolithic codebase.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Zhao Zhili via ffmpeg-devel]

> On Sep 17, 2025, at 22:44, Niklas Haas via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> On Tue, 16 Sep 2025 10:49:00 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
>> Hi all
>> 
>> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
>> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
>> heres the "after testing" discussion and vote
>> 
>> do we want to keep Forgejo or switch back to the ML workflow
>> (or something else)
>> 
>> F. keep Forgejo as primary forge for patch/git workflow
>> M. switch back to the ML for patch/git workflow
> 
> F, with strong preference.

F.

> 
> I am neutral on the issue of where to have bug tracking for the time being.
> 
> I am also neutral on GitLab vs ForgeJo - I think both systems have their
> strengths and weaknesses, although it appears simpler to smooth out ForgeJo's
> bugs than to modify GitLab's monolithic codebase.

Me too.

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[softworkz . via ffmpeg-devel]

> -----Original Message-----
> From: Michael Niedermayer <michael@niedermayer.cc>
> Sent: Tuesday, September 16, 2025 10:49 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Cc: ga@ffmpeg.org
> Subject: [POLL] [VOTE] code.ffmpeg.org vs. ML
> 
> Hi all
> 
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not
> forgotten it)
> heres the "after testing" discussion and vote
> 
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
> 
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow

Haven't had time to work with it yet. But today I made the very first comment
on a PR. Made a screenshot and pasted it into the comment field - all within
just 2 seconds. For that little detail alone:

F


softworkz

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Gyan Doshi via ffmpeg-devel]

On 2025-09-16 02:19 pm, Michael Niedermayer via ffmpeg-devel wrote:
> Hi all
>
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
>
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
>
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow

Forgejo.

Regards,
Gyan

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Peter Ross via ffmpeg-devel]

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

On Tue, Sep 16, 2025 at 10:49:00AM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi all
> 
> 2 months ago we voted on testing Forgejo vs Gitlab, we picked and tested
> Forgejo. And as said in that vote, (and surprisingly, i have not forgotten it)
> heres the "after testing" discussion and vote
> 
> do we want to keep Forgejo or switch back to the ML workflow
> (or something else)
> 
> F. keep Forgejo as primary forge for patch/git workflow
> M. switch back to the ML for patch/git workflow

F.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

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

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org