[FFmpeg-devel] [RFC] Experiment: enable github pull requests

[FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Michael Niedermayer]

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

Hi all

I propose, that we enable github pull requests

github is the most widely used development platform and has the lowest barrier
of entry.

after ~1-3 Month, we then evaluate how many new developers this attracted,
how many new contributions it attracted.
What the ratios of reviewed vs ignored vs applied vs rejected patches are compared to the ML

This information should help the community make decissions about the use of
web based git development vs the mailing list.

Thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

[-- 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] [RFC] Experiment: enable github pull requests

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1490 bytes --]

On 12/02/2025 19:06, Michael Niedermayer wrote:
> Hi all
> 
> I propose, that we enable github pull requests
> 
> github is the most widely used development platform and has the lowest barrier
> of entry.
> 
> after ~1-3 Month, we then evaluate how many new developers this attracted,
> how many new contributions it attracted.
> What the ratios of reviewed vs ignored vs applied vs rejected patches are compared to the ML

Those are rather arbitrary statistics.

> This information should help the community make decissions about the use of
> web based git development vs the mailing list.

Every one of us is already familiar with the benefits of having a platform.
This is just slowing down and delaying what we ought to do, which is to 
switch as soon as possible.
Finally, without CI, it doesn't really show the potential.

We all know that github will not be the platform we move to, so instead 
of getting used to a temporary workflow, I'd rather we test a likely 
final workflow that we could potentially be using.

Instead of github, I want to use the current test Forgejo instance. It 
already has CI working and over 10 developers have registered.
Some have doubts about whether it would slow down with more users, or 
bugs would appear, and it would be good to demonstrate the platform can 
handle our workflow, and fix any remaining issues.

Users can already login to the instance with their github accounts, so 
there's no barrier to entry.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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] [RFC] Experiment: enable github pull requests

[Romain Beauxis]

Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>
> On 12/02/2025 19:06, Michael Niedermayer wrote:
> > Hi all

Hi!

>
> > I propose, that we enable github pull requests
> >
> > github is the most widely used development platform and has the lowest barrier
> > of entry.
> >
> > after ~1-3 Month, we then evaluate how many new developers this attracted,
> > how many new contributions it attracted.
> > What the ratios of reviewed vs ignored vs applied vs rejected patches are compared to the ML
>
> Those are rather arbitrary statistics.
>
> > This information should help the community make decissions about the use of
> > web based git development vs the mailing list.
>
> Every one of us is already familiar with the benefits of having a platform.
> This is just slowing down and delaying what we ought to do, which is to
> switch as soon as possible.
> Finally, without CI, it doesn't really show the potential.
>
> We all know that github will not be the platform we move to, so instead
> of getting used to a temporary workflow, I'd rather we test a likely
> final workflow that we could potentially be using.
>
> Instead of github, I want to use the current test Forgejo instance. It
> already has CI working and over 10 developers have registered.
> Some have doubts about whether it would slow down with more users, or
> bugs would appear, and it would be good to demonstrate the platform can
> handle our workflow, and fix any remaining issues.
>
> Users can already login to the instance with their github accounts, so
> there's no barrier to entry.

Would you mind sharing the url? A quick search didn't reveal anything.

Thanks,
-- Romain
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1810 bytes --]



On 12/02/2025 19:53, Romain Beauxis wrote:
> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>>
>> On 12/02/2025 19:06, Michael Niedermayer wrote:
>>> Hi all
> 
> Hi!
> 
>>
>>> I propose, that we enable github pull requests
>>>
>>> github is the most widely used development platform and has the lowest barrier
>>> of entry.
>>>
>>> after ~1-3 Month, we then evaluate how many new developers this attracted,
>>> how many new contributions it attracted.
>>> What the ratios of reviewed vs ignored vs applied vs rejected patches are compared to the ML
>>
>> Those are rather arbitrary statistics.
>>
>>> This information should help the community make decissions about the use of
>>> web based git development vs the mailing list.
>>
>> Every one of us is already familiar with the benefits of having a platform.
>> This is just slowing down and delaying what we ought to do, which is to
>> switch as soon as possible.
>> Finally, without CI, it doesn't really show the potential.
>>
>> We all know that github will not be the platform we move to, so instead
>> of getting used to a temporary workflow, I'd rather we test a likely
>> final workflow that we could potentially be using.
>>
>> Instead of github, I want to use the current test Forgejo instance. It
>> already has CI working and over 10 developers have registered.
>> Some have doubts about whether it would slow down with more users, or
>> bugs would appear, and it would be good to demonstrate the platform can
>> handle our workflow, and fix any remaining issues.
>>
>> Users can already login to the instance with their github accounts, so
>> there's no barrier to entry.
> 
> Would you mind sharing the url? A quick search didn't reveal anything.

Sure
https://code.ffmpeg.org/

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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] [RFC] Experiment: enable github pull requests

[Michael Niedermayer]

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

On Wed, Feb 12, 2025 at 07:49:20PM +0100, Lynne wrote:
> On 12/02/2025 19:06, Michael Niedermayer wrote:
> > Hi all
> > 
> > I propose, that we enable github pull requests
> > 
> > github is the most widely used development platform and has the lowest barrier
> > of entry.
> > 
> > after ~1-3 Month, we then evaluate how many new developers this attracted,
> > how many new contributions it attracted.
> > What the ratios of reviewed vs ignored vs applied vs rejected patches are compared to the ML
> 
> Those are rather arbitrary statistics.

Some people claimed these statistics would improve. I do think we should
compare some statistics (obviously not limited to these)


[...]

> Users can already login to the instance with their github accounts, so
> there's no barrier to entry.

Thats cool, then forgejo is probably better for this experiment (if we do it)

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] [RFC] Experiment: enable github pull requests

[Stephen Hutchinson]

On 2/12/25 2:23 PM, Lynne wrote:
> 
> 
> On 12/02/2025 19:53, Romain Beauxis wrote:
>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>>>
>>> Users can already login to the instance with their github accounts, so
>>> there's no barrier to entry.
>>
>> Would you mind sharing the url? A quick search didn't reveal anything.
> 
> Sure
> https://code.ffmpeg.org/
> 

Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 22:22, Stephen Hutchinson wrote:
> On 2/12/25 2:23 PM, Lynne wrote:
>>
>>
>> On 12/02/2025 19:53, Romain Beauxis wrote:
>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>>>>
>>>> Users can already login to the instance with their github accounts, so
>>>> there's no barrier to entry.
>>>
>>> Would you mind sharing the url? A quick search didn't reveal anything.
>>
>> Sure
>> https://code.ffmpeg.org/
>>
> 
> Are all accounts restricted to owning a maximum of 0 repositories by
> default, or is it set to 0 only for those that sign up through one of
> the external logins?

It's set to 0 by default, to avoid spammers uploading junk, or just 
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/

The repo limit can manually be lifted per user. I preferred that 
approach vs. the Videolan approach of completely locking down the 
instance, and requiring admin approval for every single new user, which 
imo is more detrimental to new contributors than a ML.




Timo
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > On 2/12/25 2:23 PM, Lynne wrote:
> >>
> >>
> >> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
> >>>>
> >>>> Users can already login to the instance with their github accounts, so
> >>>> there's no barrier to entry.
> >>>
> >>> Would you mind sharing the url? A quick search didn't reveal anything.
> >>
> >> Sure
> >> https://code.ffmpeg.org/
> >>
> >
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
> 
> It's set to 0 by default, to avoid spammers uploading junk, or just
> people (ab)using it for non-ffmpeg things.
> 
> You can open issues and comment on existing PRs.
> And also create PRs using the AGit workflow:
> https://forgejo.org/docs/latest/user/agit-support/
> 
> The repo limit can manually be lifted per user. I preferred that
> approach vs. the Videolan approach of completely locking down the
> instance, and requiring admin approval for every single new user, which
> imo is more detrimental to new contributors than a ML.

Hi Timo,

Does that mean that you cannot create forks and create PRs from that forked repo like on GitHub?

sw
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 22:37, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
>> Rothenpieler
>> Sent: Mittwoch, 12. Februar 2025 22:33
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
>>> On 2/12/25 2:23 PM, Lynne wrote:
>>>>
>>>>
>>>> On 12/02/2025 19:53, Romain Beauxis wrote:
>>>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>>>>>>
>>>>>> Users can already login to the instance with their github accounts, so
>>>>>> there's no barrier to entry.
>>>>>
>>>>> Would you mind sharing the url? A quick search didn't reveal anything.
>>>>
>>>> Sure
>>>> https://code.ffmpeg.org/
>>>>
>>>
>>> Are all accounts restricted to owning a maximum of 0 repositories by
>>> default, or is it set to 0 only for those that sign up through one of
>>> the external logins?
>>
>> It's set to 0 by default, to avoid spammers uploading junk, or just
>> people (ab)using it for non-ffmpeg things.
>>
>> You can open issues and comment on existing PRs.
>> And also create PRs using the AGit workflow:
>> https://forgejo.org/docs/latest/user/agit-support/
>>
>> The repo limit can manually be lifted per user. I preferred that
>> approach vs. the Videolan approach of completely locking down the
>> instance, and requiring admin approval for every single new user, which
>> imo is more detrimental to new contributors than a ML.
> 
> Hi Timo,
> 
> Does that mean that you cannot create forks and create PRs from that forked repo like on GitHub?
> 
Not sure what you mean, you need "admin approval" to be allowed to 
create repos, including forks.
Just to avoid abuse. Obviously you can then PR from that fork once you 
got one.
Or you can submit PRs without a fork as stated above.
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 22:51
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 22:37, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>> On 2/12/25 2:23 PM, Lynne wrote:
> >>>>
> >>>>
> >>>> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
> >>>>>>
> >>>>>> Users can already login to the instance with their github accounts, so
> >>>>>> there's no barrier to entry.
> >>>>>
> >>>>> Would you mind sharing the url? A quick search didn't reveal anything.
> >>>>
> >>>> Sure
> >>>> https://code.ffmpeg.org/
> >>>>
> >>>
> >>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>> default, or is it set to 0 only for those that sign up through one of
> >>> the external logins?
> >>
> >> It's set to 0 by default, to avoid spammers uploading junk, or just
> >> people (ab)using it for non-ffmpeg things.
> >>
> >> You can open issues and comment on existing PRs.
> >> And also create PRs using the AGit workflow:
> >> https://forgejo.org/docs/latest/user/agit-support/
> >>
> >> The repo limit can manually be lifted per user. I preferred that
> >> approach vs. the Videolan approach of completely locking down the
> >> instance, and requiring admin approval for every single new user, which
> >> imo is more detrimental to new contributors than a ML.
> >
> > Hi Timo,
> >
> > Does that mean that you cannot create forks and create PRs from that forked
> repo like on GitHub?
> >
> Not sure what you mean, you need "admin approval" to be allowed to
> create repos, including forks.

I don't think it's a good idea to build such entry bars. 

> Just to avoid abuse. Obviously you can then PR from that fork once you
> got one.
> Or you can submit PRs without a fork as stated above.

That's a workflow I've never heard about - same like most other contributors. Again, that is building an entry bar.

I think people should be able to use a procedure they are familiar with.
Is it possible to create PRs from a fork on GitHub?

Thanks
sw



_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 23:01, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
>> Rothenpieler
>> Sent: Mittwoch, 12. Februar 2025 22:51
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> On 12.02.2025 22:37, Soft Works wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Timo
>>>> Rothenpieler
>>>> Sent: Mittwoch, 12. Februar 2025 22:33
>>>> To: ffmpeg-devel@ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>>>
>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
>>>>> On 2/12/25 2:23 PM, Lynne wrote:
>>>>>>
>>>>>>
>>>>>> On 12/02/2025 19:53, Romain Beauxis wrote:
>>>>>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>>>>>>>>
>>>>>>>> Users can already login to the instance with their github accounts, so
>>>>>>>> there's no barrier to entry.
>>>>>>>
>>>>>>> Would you mind sharing the url? A quick search didn't reveal anything.
>>>>>>
>>>>>> Sure
>>>>>> https://code.ffmpeg.org/
>>>>>>
>>>>>
>>>>> Are all accounts restricted to owning a maximum of 0 repositories by
>>>>> default, or is it set to 0 only for those that sign up through one of
>>>>> the external logins?
>>>>
>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
>>>> people (ab)using it for non-ffmpeg things.
>>>>
>>>> You can open issues and comment on existing PRs.
>>>> And also create PRs using the AGit workflow:
>>>> https://forgejo.org/docs/latest/user/agit-support/
>>>>
>>>> The repo limit can manually be lifted per user. I preferred that
>>>> approach vs. the Videolan approach of completely locking down the
>>>> instance, and requiring admin approval for every single new user, which
>>>> imo is more detrimental to new contributors than a ML.
>>>
>>> Hi Timo,
>>>
>>> Does that mean that you cannot create forks and create PRs from that forked
>> repo like on GitHub?
>>>
>> Not sure what you mean, you need "admin approval" to be allowed to
>> create repos, including forks.
> 
> I don't think it's a good idea to build such entry bars.
> 
>> Just to avoid abuse. Obviously you can then PR from that fork once you
>> got one.
>> Or you can submit PRs without a fork as stated above.
> 
> That's a workflow I've never heard about - same like most other contributors. Again, that is building an entry bar.
> 
> I think people should be able to use a procedure they are familiar with.
> Is it possible to create PRs from a fork on GitHub?
> 
I'm really not sure what you're asking.
PRs are not restricted. Creating repos is.
And there is no way to NOT restrict it, unless you want to pay several 
hundred Euros a month in hosting fees extra, and constantly be on the 
lookout for hosting illegal/harmful things.
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Romain Beauxis]

Le mer. 12 févr. 2025 à 15:32, Timo Rothenpieler <timo@rothenpieler.org> a
écrit :
>
> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > On 2/12/25 2:23 PM, Lynne wrote:
> >>
> >>
> >> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
> >>>>
> >>>> Users can already login to the instance with their github accounts,
so
> >>>> there's no barrier to entry.
> >>>
> >>> Would you mind sharing the url? A quick search didn't reveal anything.
> >>
> >> Sure
> >> https://code.ffmpeg.org/
> >>
> >
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
>
> It's set to 0 by default, to avoid spammers uploading junk, or just
> people (ab)using it for non-ffmpeg things.
>
> You can open issues and comment on existing PRs.
> And also create PRs using the AGit workflow:
> https://forgejo.org/docs/latest/user/agit-support/
>
> The repo limit can manually be lifted per user. I preferred that
> approach vs. the Videolan approach of completely locking down the
> instance, and requiring admin approval for every single new user, which
> imo is more detrimental to new contributors than a ML.

I totally understand the concern.

The procedure for creating PRs using AGit is a bit arcane but I'll give it
a try.

It would be nice to have this document big and bold when users register, I
was quite lost after registration seeing I couldn't fork.

I'm gonna try to think about how to split patches from the ML perspective
to a PR perspective.

Is there any opinion on this? Typically the series I have has a section for
flac and one for opus, do y'all think one general PR for the base work then
one PR for flac and one PR for opus or one single PR with the patch series
like in the ML?

Thanks,
-- romain
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 23:05
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 23:01, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:51
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 12.02.2025 22:37, Soft Works wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Timo
> >>>> Rothenpieler
> >>>> Sent: Mittwoch, 12. Februar 2025 22:33
> >>>> To: ffmpeg-devel@ffmpeg.org
> >>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> >>>>
> >>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>>>> On 2/12/25 2:23 PM, Lynne wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>>>>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
> >>>>>>>>
> >>>>>>>> Users can already login to the instance with their github accounts, so
> >>>>>>>> there's no barrier to entry.
> >>>>>>>
> >>>>>>> Would you mind sharing the url? A quick search didn't reveal
> anything.
> >>>>>>
> >>>>>> Sure
> >>>>>> https://code.ffmpeg.org/
> >>>>>>
> >>>>>
> >>>>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>>>> default, or is it set to 0 only for those that sign up through one of
> >>>>> the external logins?
> >>>>
> >>>> It's set to 0 by default, to avoid spammers uploading junk, or just
> >>>> people (ab)using it for non-ffmpeg things.
> >>>>
> >>>> You can open issues and comment on existing PRs.
> >>>> And also create PRs using the AGit workflow:
> >>>> https://forgejo.org/docs/latest/user/agit-support/
> >>>>
> >>>> The repo limit can manually be lifted per user. I preferred that
> >>>> approach vs. the Videolan approach of completely locking down the
> >>>> instance, and requiring admin approval for every single new user, which
> >>>> imo is more detrimental to new contributors than a ML.
> >>>
> >>> Hi Timo,
> >>>
> >>> Does that mean that you cannot create forks and create PRs from that
> forked
> >> repo like on GitHub?
> >>>
> >> Not sure what you mean, you need "admin approval" to be allowed to
> >> create repos, including forks.
> >
> > I don't think it's a good idea to build such entry bars.
> >
> >> Just to avoid abuse. Obviously you can then PR from that fork once you
> >> got one.
> >> Or you can submit PRs without a fork as stated above.
> >
> > That's a workflow I've never heard about - same like most other
> contributors. Again, that is building an entry bar.
> >
> > I think people should be able to use a procedure they are familiar with.
> > Is it possible to create PRs from a fork on GitHub?
> >
> I'm really not sure what you're asking.
> PRs are not restricted. Creating repos is.
> And there is no way to NOT restrict it, unless you want to pay several
> hundred Euros a month in hosting fees extra, and constantly be on the
> lookout for hosting illegal/harmful things.

I wasn't asking, I'm stating that not being able to use an established workflow like 

fork >> clone >> develop >> push >> PR

...would be an entry-bar for new contributors.

But here comes a question: I've read that the "AGit flow" work by creating a branch for each submission in the original repo. Doesn't the repo get "polluted" over time this way? In case of merged PRs, the branch might get deleted, but what about unmerged ones?
And when one clones the whole repo, don't they get all those branches downloaded locally as well? (as long as one doesn’t specify which branches to download)

Thanks
sw
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
> 
> It's set to 0 by default, to avoid spammers uploading junk, or just
> people (ab)using it for non-ffmpeg things.
> 
> You can open issues and comment on existing PRs.
> And also create PRs using the AGit workflow:
> https://forgejo.org/docs/latest/user/agit-support/

For those who are too lazy to look it up:

The "Agit workflow" requires you to use non-standard Git "push-options"
(either -o or --push-options):

git push origin HEAD:refs/for/master -o topic="topic-branch" \
  -o title="Title of the PR" \
  -o description="# The PR Description
This can be **any** markdown content.\n
- [x] Ok"

This means essentially that our attempt to move away from the e-mail-based submission procedure to something easy and user-friendly, would end up in replacing the current rarely-known mechanism with another even more rare and obscure procedure which would (again) force everybody to use the Git command line because it's (again) not supported by any tooling except Git CLI.

I'm afraid, but from my point of view, this doesn't match the objective.

Best
sw




_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Romain Beauxis
> Sent: Mittwoch, 12. Februar 2025 23:13
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> Le mer. 12 févr. 2025 à 15:32, Timo Rothenpieler <timo@rothenpieler.org> a
> écrit :
> >
> > On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > > On 2/12/25 2:23 PM, Lynne wrote:
> > >>
> > >>
> > >> On 12/02/2025 19:53, Romain Beauxis wrote:
> > >>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
> > >>>>
> > >>>> Users can already login to the instance with their github accounts,
> so
> > >>>> there's no barrier to entry.
> > >>>
> > >>> Would you mind sharing the url? A quick search didn't reveal anything.
> > >>
> > >> Sure
> > >> https://code.ffmpeg.org/
> > >>
> > >
> > > Are all accounts restricted to owning a maximum of 0 repositories by
> > > default, or is it set to 0 only for those that sign up through one of
> > > the external logins?
> >
> > It's set to 0 by default, to avoid spammers uploading junk, or just
> > people (ab)using it for non-ffmpeg things.
> >
> > You can open issues and comment on existing PRs.
> > And also create PRs using the AGit workflow:
> > https://forgejo.org/docs/latest/user/agit-support/
> >
> > The repo limit can manually be lifted per user. I preferred that
> > approach vs. the Videolan approach of completely locking down the
> > instance, and requiring admin approval for every single new user, which
> > imo is more detrimental to new contributors than a ML.
> 
> I totally understand the concern.

Thinking about it, I do not quite understand.

When I had the choice between whether spammers can create their own repos or create branches in my original repo (AGit flow), I would surely prefer the former.

I hope I didn't misunderstand anything (apologies in that case).

 sw


_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 23:16, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
>> Rothenpieler
>> Sent: Mittwoch, 12. Februar 2025 23:05
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> On 12.02.2025 23:01, Soft Works wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Timo
>>>> Rothenpieler
>>>> Sent: Mittwoch, 12. Februar 2025 22:51
>>>> To: ffmpeg-devel@ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>>>
>>>> On 12.02.2025 22:37, Soft Works wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>>>> Timo
>>>>>> Rothenpieler
>>>>>> Sent: Mittwoch, 12. Februar 2025 22:33
>>>>>> To: ffmpeg-devel@ffmpeg.org
>>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
>> requests
>>>>>>
>>>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
>>>>>>> On 2/12/25 2:23 PM, Lynne wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/02/2025 19:53, Romain Beauxis wrote:
>>>>>>>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
>>>>>>>>>>
>>>>>>>>>> Users can already login to the instance with their github accounts, so
>>>>>>>>>> there's no barrier to entry.
>>>>>>>>>
>>>>>>>>> Would you mind sharing the url? A quick search didn't reveal
>> anything.
>>>>>>>>
>>>>>>>> Sure
>>>>>>>> https://code.ffmpeg.org/
>>>>>>>>
>>>>>>>
>>>>>>> Are all accounts restricted to owning a maximum of 0 repositories by
>>>>>>> default, or is it set to 0 only for those that sign up through one of
>>>>>>> the external logins?
>>>>>>
>>>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
>>>>>> people (ab)using it for non-ffmpeg things.
>>>>>>
>>>>>> You can open issues and comment on existing PRs.
>>>>>> And also create PRs using the AGit workflow:
>>>>>> https://forgejo.org/docs/latest/user/agit-support/
>>>>>>
>>>>>> The repo limit can manually be lifted per user. I preferred that
>>>>>> approach vs. the Videolan approach of completely locking down the
>>>>>> instance, and requiring admin approval for every single new user, which
>>>>>> imo is more detrimental to new contributors than a ML.
>>>>>
>>>>> Hi Timo,
>>>>>
>>>>> Does that mean that you cannot create forks and create PRs from that
>> forked
>>>> repo like on GitHub?
>>>>>
>>>> Not sure what you mean, you need "admin approval" to be allowed to
>>>> create repos, including forks.
>>>
>>> I don't think it's a good idea to build such entry bars.
>>>
>>>> Just to avoid abuse. Obviously you can then PR from that fork once you
>>>> got one.
>>>> Or you can submit PRs without a fork as stated above.
>>>
>>> That's a workflow I've never heard about - same like most other
>> contributors. Again, that is building an entry bar.
>>>
>>> I think people should be able to use a procedure they are familiar with.
>>> Is it possible to create PRs from a fork on GitHub?
>>>
>> I'm really not sure what you're asking.
>> PRs are not restricted. Creating repos is.
>> And there is no way to NOT restrict it, unless you want to pay several
>> hundred Euros a month in hosting fees extra, and constantly be on the
>> lookout for hosting illegal/harmful things.
> 
> I wasn't asking, I'm stating that not being able to use an established workflow like
> 
> fork >> clone >> develop >> push >> PR
> 
> ...would be an entry-bar for new contributors.
> 
> But here comes a question: I've read that the "AGit flow" work by creating a branch for each submission in the original repo. Doesn't the repo get "polluted" over time this way? In case of merged PRs, the branch might get deleted, but what about unmerged ones?
> And when one clones the whole repo, don't they get all those branches downloaded locally as well? (as long as one doesn’t specify which branches to download)

So do forks, cause they all live in the same underlying repo as well.
Unless a user deltes the repo/branch/PR, stuff pushed there will hang 
around forever.
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13.02.2025 00:07, Soft Works wrote:
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
>> Rothenpieler
>> Sent: Mittwoch, 12. Februar 2025 22:33
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
>>> Are all accounts restricted to owning a maximum of 0 repositories by
>>> default, or is it set to 0 only for those that sign up through one of
>>> the external logins?
>>
>> It's set to 0 by default, to avoid spammers uploading junk, or just
>> people (ab)using it for non-ffmpeg things.
>>
>> You can open issues and comment on existing PRs.
>> And also create PRs using the AGit workflow:
>> https://forgejo.org/docs/latest/user/agit-support/
> 
> For those who are too lazy to look it up:
> 
> The "Agit workflow" requires you to use non-standard Git "push-options"
> (either -o or --push-options):
> 
> git push origin HEAD:refs/for/master -o topic="topic-branch" \
>    -o title="Title of the PR" \
>    -o description="# The PR Description
> This can be **any** markdown content.\n
> - [x] Ok"
> 
> This means essentially that our attempt to move away from the e-mail-based submission procedure to something easy and user-friendly, would end up in replacing the current rarely-known mechanism with another even more rare and obscure procedure which would (again) force everybody to use the Git command line because it's (again) not supported by any tooling except Git CLI.
> 
> I'm afraid, but from my point of view, this doesn't match the objective.

The only alternative is to completely lock down the instance, and not 
allow new users at all without manual approval of each and every one.

People can just ask to be allowed to fork, but by default, allowing it 
is not feasible.

Videolan apparently even went away from the current approach on our 
instance, cause there was still too much spam. So they're 
manual-approval-only now.
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Kieran Kunhya via ffmpeg-devel]

On Wed, 12 Feb 2025, 23:29 Timo Rothenpieler, <timo@rothenpieler.org> wrote:

> On 12.02.2025 23:16, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 23:05
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> >>
> >> On 12.02.2025 23:01, Soft Works wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Timo
> >>>> Rothenpieler
> >>>> Sent: Mittwoch, 12. Februar 2025 22:51
> >>>> To: ffmpeg-devel@ffmpeg.org
> >>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> >>>>
> >>>> On 12.02.2025 22:37, Soft Works wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >>>> Timo
> >>>>>> Rothenpieler
> >>>>>> Sent: Mittwoch, 12. Februar 2025 22:33
> >>>>>> To: ffmpeg-devel@ffmpeg.org
> >>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >> requests
> >>>>>>
> >>>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>>>>>> On 2/12/25 2:23 PM, Lynne wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>>>>>>>> Le mer. 12 févr. 2025 à 12:49, Lynne <dev@lynne.ee> a écrit :
> >>>>>>>>>>
> >>>>>>>>>> Users can already login to the instance with their github
> accounts, so
> >>>>>>>>>> there's no barrier to entry.
> >>>>>>>>>
> >>>>>>>>> Would you mind sharing the url? A quick search didn't reveal
> >> anything.
> >>>>>>>>
> >>>>>>>> Sure
> >>>>>>>> https://code.ffmpeg.org/
> >>>>>>>>
> >>>>>>>
> >>>>>>> Are all accounts restricted to owning a maximum of 0 repositories
> by
> >>>>>>> default, or is it set to 0 only for those that sign up through one
> of
> >>>>>>> the external logins?
> >>>>>>
> >>>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
> >>>>>> people (ab)using it for non-ffmpeg things.
> >>>>>>
> >>>>>> You can open issues and comment on existing PRs.
> >>>>>> And also create PRs using the AGit workflow:
> >>>>>> https://forgejo.org/docs/latest/user/agit-support/
> >>>>>>
> >>>>>> The repo limit can manually be lifted per user. I preferred that
> >>>>>> approach vs. the Videolan approach of completely locking down the
> >>>>>> instance, and requiring admin approval for every single new user,
> which
> >>>>>> imo is more detrimental to new contributors than a ML.
> >>>>>
> >>>>> Hi Timo,
> >>>>>
> >>>>> Does that mean that you cannot create forks and create PRs from that
> >> forked
> >>>> repo like on GitHub?
> >>>>>
> >>>> Not sure what you mean, you need "admin approval" to be allowed to
> >>>> create repos, including forks.
> >>>
> >>> I don't think it's a good idea to build such entry bars.
> >>>
> >>>> Just to avoid abuse. Obviously you can then PR from that fork once you
> >>>> got one.
> >>>> Or you can submit PRs without a fork as stated above.
> >>>
> >>> That's a workflow I've never heard about - same like most other
> >> contributors. Again, that is building an entry bar.
> >>>
> >>> I think people should be able to use a procedure they are familiar
> with.
> >>> Is it possible to create PRs from a fork on GitHub?
> >>>
> >> I'm really not sure what you're asking.
> >> PRs are not restricted. Creating repos is.
> >> And there is no way to NOT restrict it, unless you want to pay several
> >> hundred Euros a month in hosting fees extra, and constantly be on the
> >> lookout for hosting illegal/harmful things.
> >
> > I wasn't asking, I'm stating that not being able to use an established
> workflow like
> >
> > fork >> clone >> develop >> push >> PR
> >
> > ...would be an entry-bar for new contributors.
> >
> > But here comes a question: I've read that the "AGit flow" work by
> creating a branch for each submission in the original repo. Doesn't the
> repo get "polluted" over time this way? In case of merged PRs, the branch
> might get deleted, but what about unmerged ones?
> > And when one clones the whole repo, don't they get all those branches
> downloaded locally as well? (as long as one doesn’t specify which branches
> to download)
>
> So do forks, cause they all live in the same underlying repo as well.
> Unless a user deltes the repo/branch/PR, stuff pushed there will hang
> around forever.
>

Yes but surely if users do a simple clone of the main repository, they will
get all the branches of hundred of different pull requests?

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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> Rothenpieler
> Sent: Donnerstag, 13. Februar 2025 00:34
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13.02.2025 00:07, Soft Works wrote:
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>> default, or is it set to 0 only for those that sign up through one of
> >>> the external logins?
> >>
> >> It's set to 0 by default, to avoid spammers uploading junk, or just
> >> people (ab)using it for non-ffmpeg things.
> >>
> >> You can open issues and comment on existing PRs.
> >> And also create PRs using the AGit workflow:
> >> https://forgejo.org/docs/latest/user/agit-support/
> >
> > For those who are too lazy to look it up:
> >
> > The "Agit workflow" requires you to use non-standard Git "push-options"
> > (either -o or --push-options):
> >
> > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> >    -o title="Title of the PR" \
> >    -o description="# The PR Description
> > This can be **any** markdown content.\n
> > - [x] Ok"
> >
> > This means essentially that our attempt to move away from the e-mail-based
> submission procedure to something easy and user-friendly, would end up in
> replacing the current rarely-known mechanism with another even more rare
> and obscure procedure which would (again) force everybody to use the Git
> command line because it's (again) not supported by any tooling except Git CLI.
> >
> > I'm afraid, but from my point of view, this doesn't match the objective.
> 
> The only alternative is to completely lock down the instance, and not
> allow new users at all without manual approval of each and every one.
> 
> People can just ask to be allowed to fork, but by default, allowing it
> is not feasible.

Hm, please help me understand what kind of spam we're talking about here. I can't imagine somebody would take the effort for selling some pills to ffmpeg developers. When it's about advertising anything, that's not the kind of reach those people are typically looking for.

Or is it about misusing repos for storage of illegal content? The largest file currently is just 953kB, so we could enforce a limit small enough to make it unattractive for this purpose (unlike GitHub with 100MB per file).

We could also disallow repos with custom content (i.e. only forks of ffmpeg are allowed as repo content).

Then I wonder, where would be the harm? Some thousand unused forks of ffmpeg shouldn't be a problem - but maybe I'm overseeing something?

Thanks
sw



_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Romain Beauxis]

Le mer. 12 févr. 2025 à 18:17, Soft Works
<softworkz-at-hotmail.com@ffmpeg.org> a écrit :
>
>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> > Rothenpieler
> > Sent: Donnerstag, 13. Februar 2025 00:34
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >
> > On 13.02.2025 00:07, Soft Works wrote:
> > >
> > >> -----Original Message-----
> > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Timo
> > >> Rothenpieler
> > >> Sent: Mittwoch, 12. Februar 2025 22:33
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> > >>
> > >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > >>> Are all accounts restricted to owning a maximum of 0 repositories by
> > >>> default, or is it set to 0 only for those that sign up through one of
> > >>> the external logins?
> > >>
> > >> It's set to 0 by default, to avoid spammers uploading junk, or just
> > >> people (ab)using it for non-ffmpeg things.
> > >>
> > >> You can open issues and comment on existing PRs.
> > >> And also create PRs using the AGit workflow:
> > >> https://forgejo.org/docs/latest/user/agit-support/
> > >
> > > For those who are too lazy to look it up:
> > >
> > > The "Agit workflow" requires you to use non-standard Git "push-options"
> > > (either -o or --push-options):
> > >
> > > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> > >    -o title="Title of the PR" \
> > >    -o description="# The PR Description
> > > This can be **any** markdown content.\n
> > > - [x] Ok"
> > >
> > > This means essentially that our attempt to move away from the e-mail-based
> > submission procedure to something easy and user-friendly, would end up in
> > replacing the current rarely-known mechanism with another even more rare
> > and obscure procedure which would (again) force everybody to use the Git
> > command line because it's (again) not supported by any tooling except Git CLI.
> > >
> > > I'm afraid, but from my point of view, this doesn't match the objective.
> >
> > The only alternative is to completely lock down the instance, and not
> > allow new users at all without manual approval of each and every one.
> >
> > People can just ask to be allowed to fork, but by default, allowing it
> > is not feasible.
>
> Hm, please help me understand what kind of spam we're talking about here. I can't imagine somebody would take the effort for selling some pills to ffmpeg developers. When it's about advertising anything, that's not the kind of reach those people are typically looking for.
>
> Or is it about misusing repos for storage of illegal content? The largest file currently is just 953kB, so we could enforce a limit small enough to make it unattractive for this purpose (unlike GitHub with 100MB per file).
>
> We could also disallow repos with custom content (i.e. only forks of ffmpeg are allowed as repo content).
>
> Then I wonder, where would be the harm? Some thousand unused forks of ffmpeg shouldn't be a problem - but maybe I'm overseeing something?

There are all sorts of copyrightable material that can be embedded
into a git repo.

Also payloads for malicious software.

etc.

Given that this all amounts to manpower from the operator, it's
totally understandable that they would like to be conservative about
opening it up.

-- Romain
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13.02.2025 00:34, Kieran Kunhya via ffmpeg-devel wrote:
> Yes but surely if users do a simple clone of the main repository, they will
> get all the branches of hundred of different pull requests?

No, why would they?
That's all abstracted away. Pretty much just an optimization on storage, 
making all forks share the actual git object files.
Which has the side-effect that even on Github you can fork the FFmpeg 
repo, push something, and then link to the hash of what you pushed on 
the actual FFmpeg repo:
> https://github.com/FFmpeg/FFmpeg/commit/4904c8861b1b52c50199e83620fbabfad4733a2b

This commit is only on a branch of mine, not on any FFmpeg branch.
Github warns about that these days, but Gitlab/Gitea/Forgejo/... don't 
for what I'm aware.
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Romain Beauxis
> Sent: Donnerstag, 13. Februar 2025 01:25
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> Le mer. 12 févr. 2025 à 18:17, Soft Works
> <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
> >
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Timo
> > > Rothenpieler
> > > Sent: Donnerstag, 13. Februar 2025 00:34
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> > >
> > > On 13.02.2025 00:07, Soft Works wrote:
> > > >
> > > >> -----Original Message-----
> > > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Timo
> > > >> Rothenpieler
> > > >> Sent: Mittwoch, 12. Februar 2025 22:33
> > > >> To: ffmpeg-devel@ffmpeg.org
> > > >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> > > >>
> > > >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > > >>> Are all accounts restricted to owning a maximum of 0 repositories by
> > > >>> default, or is it set to 0 only for those that sign up through one of
> > > >>> the external logins?
> > > >>
> > > >> It's set to 0 by default, to avoid spammers uploading junk, or just
> > > >> people (ab)using it for non-ffmpeg things.
> > > >>
> > > >> You can open issues and comment on existing PRs.
> > > >> And also create PRs using the AGit workflow:
> > > >> https://forgejo.org/docs/latest/user/agit-support/
> > > >
> > > > For those who are too lazy to look it up:
> > > >
> > > > The "Agit workflow" requires you to use non-standard Git "push-
> options"
> > > > (either -o or --push-options):
> > > >
> > > > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> > > >    -o title="Title of the PR" \
> > > >    -o description="# The PR Description
> > > > This can be **any** markdown content.\n
> > > > - [x] Ok"
> > > >
> > > > This means essentially that our attempt to move away from the e-mail-
> based
> > > submission procedure to something easy and user-friendly, would end up
> in
> > > replacing the current rarely-known mechanism with another even more
> rare
> > > and obscure procedure which would (again) force everybody to use the Git
> > > command line because it's (again) not supported by any tooling except Git
> CLI.
> > > >
> > > > I'm afraid, but from my point of view, this doesn't match the objective.
> > >
> > > The only alternative is to completely lock down the instance, and not
> > > allow new users at all without manual approval of each and every one.
> > >
> > > People can just ask to be allowed to fork, but by default, allowing it
> > > is not feasible.
> >
> > Hm, please help me understand what kind of spam we're talking about here.
> I can't imagine somebody would take the effort for selling some pills to ffmpeg
> developers. When it's about advertising anything, that's not the kind of reach
> those people are typically looking for.
> >
> > Or is it about misusing repos for storage of illegal content? The largest file
> currently is just 953kB, so we could enforce a limit small enough to make it
> unattractive for this purpose (unlike GitHub with 100MB per file).
> >
> > We could also disallow repos with custom content (i.e. only forks of ffmpeg
> are allowed as repo content).
> >
> > Then I wonder, where would be the harm? Some thousand unused forks of
> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> 
> There are all sorts of copyrightable material that can be embedded
> into a git repo.

That's why I mentioned that a file size limit could prevent this. With a 2 MB limit per file, it becomes totally unattractive for this kind of abuse.

> Given that this all amounts to manpower from the operator

AFAIK, you are only responsible to take stuff down once you get notified, you don't need to actively look for anything.

> Also payloads for malicious software.

Okay, but when it's in a repo, what happens next? I mean why would somebody store that in a repo? What would be the goal?

Also, I wonder how this would be different from attachments on https://trac.ffmpeg.org ? There's no requirement for user "approval" as well..

sw
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13.02.2025 01:40, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Romain Beauxis
>> Sent: Donnerstag, 13. Februar 2025 01:25
>> To: FFmpeg development discussions and patches <ffmpeg-
>> devel@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> Le mer. 12 févr. 2025 à 18:17, Soft Works
>> <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Timo
>>>> Rothenpieler
>>>> Sent: Donnerstag, 13. Februar 2025 00:34
>>>> To: ffmpeg-devel@ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>>>
>>>> On 13.02.2025 00:07, Soft Works wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>>>> Timo
>>>>>> Rothenpieler
>>>>>> Sent: Mittwoch, 12. Februar 2025 22:33
>>>>>> To: ffmpeg-devel@ffmpeg.org
>>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
>> requests
>>>>>>
>>>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
>>>>>>> Are all accounts restricted to owning a maximum of 0 repositories by
>>>>>>> default, or is it set to 0 only for those that sign up through one of
>>>>>>> the external logins?
>>>>>>
>>>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
>>>>>> people (ab)using it for non-ffmpeg things.
>>>>>>
>>>>>> You can open issues and comment on existing PRs.
>>>>>> And also create PRs using the AGit workflow:
>>>>>> https://forgejo.org/docs/latest/user/agit-support/
>>>>>
>>>>> For those who are too lazy to look it up:
>>>>>
>>>>> The "Agit workflow" requires you to use non-standard Git "push-
>> options"
>>>>> (either -o or --push-options):
>>>>>
>>>>> git push origin HEAD:refs/for/master -o topic="topic-branch" \
>>>>>     -o title="Title of the PR" \
>>>>>     -o description="# The PR Description
>>>>> This can be **any** markdown content.\n
>>>>> - [x] Ok"
>>>>>
>>>>> This means essentially that our attempt to move away from the e-mail-
>> based
>>>> submission procedure to something easy and user-friendly, would end up
>> in
>>>> replacing the current rarely-known mechanism with another even more
>> rare
>>>> and obscure procedure which would (again) force everybody to use the Git
>>>> command line because it's (again) not supported by any tooling except Git
>> CLI.
>>>>>
>>>>> I'm afraid, but from my point of view, this doesn't match the objective.
>>>>
>>>> The only alternative is to completely lock down the instance, and not
>>>> allow new users at all without manual approval of each and every one.
>>>>
>>>> People can just ask to be allowed to fork, but by default, allowing it
>>>> is not feasible.
>>>
>>> Hm, please help me understand what kind of spam we're talking about here.
>> I can't imagine somebody would take the effort for selling some pills to ffmpeg
>> developers. When it's about advertising anything, that's not the kind of reach
>> those people are typically looking for.
>>>
>>> Or is it about misusing repos for storage of illegal content? The largest file
>> currently is just 953kB, so we could enforce a limit small enough to make it
>> unattractive for this purpose (unlike GitHub with 100MB per file).
>>>
>>> We could also disallow repos with custom content (i.e. only forks of ffmpeg
>> are allowed as repo content).
>>>
>>> Then I wonder, where would be the harm? Some thousand unused forks of
>> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
>>
>> There are all sorts of copyrightable material that can be embedded
>> into a git repo.
> 
> That's why I mentioned that a file size limit could prevent this. With a 2 MB limit per file, it becomes totally unattractive for this kind of abuse.

That doesn't seem feasible to implement, given it's git.
Not even sure how to implement such a limit at all with git.
Some hook would need to check every file on push, which I don't think is 
something that readily exists.

And even then, there will be ways around it if someone is motivated enough.

>> Given that this all amounts to manpower from the operator
> 
> AFAIK, you are only responsible to take stuff down once you get notified, you don't need to actively look for anything.

I still wouldn't want to be the one hosting who knows what of illegal 
shit on our servers.

Also keep in mind that if they fork the FFmpeg repo, and then push 
something big and bad into that fork, it ends up in the same backing 
storage of git objects.
So it's not even trivial to just delete it again, and bar access to it.

You can ask Videolan about how a fully open Gitlab instance went for them.

>> Also payloads for malicious software.

> Okay, but when it's in a repo, what happens next? I mean why would somebody store that in a repo? What would be the goal?
> 
> Also, I wonder how this would be different from attachments on https://trac.ffmpeg.org ? There's no requirement for user "approval" as well..

We're just relatively lucky that trac is pretty uncommon and spambots 
targetting are more rare.
Also, our custom-baked captcha for trac has so far remained undefeated.

Before it was implemented, trac also had a lot of spambots.


> sw
> _______________________________________________
> 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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
> Rothenpieler
> Sent: Donnerstag, 13. Februar 2025 02:52
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13.02.2025 01:40, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Romain Beauxis
> >> Sent: Donnerstag, 13. Februar 2025 01:25
> >> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> Le mer. 12 févr. 2025 à 18:17, Soft Works
> >> <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Timo
> >>>> Rothenpieler
> >>>> Sent: Donnerstag, 13. Februar 2025 00:34
> >>>> To: ffmpeg-devel@ffmpeg.org
> >>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> >>>>
> >>>> On 13.02.2025 00:07, Soft Works wrote:
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >>>> Timo
> >>>>>> Rothenpieler
> >>>>>> Sent: Mittwoch, 12. Februar 2025 22:33
> >>>>>> To: ffmpeg-devel@ffmpeg.org
> >>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >> requests
> >>>>>>
> >>>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>>>>>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>>>>>> default, or is it set to 0 only for those that sign up through one of
> >>>>>>> the external logins?
> >>>>>>
> >>>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
> >>>>>> people (ab)using it for non-ffmpeg things.
> >>>>>>
> >>>>>> You can open issues and comment on existing PRs.
> >>>>>> And also create PRs using the AGit workflow:
> >>>>>> https://forgejo.org/docs/latest/user/agit-support/
> >>>>>
> >>>>> For those who are too lazy to look it up:
> >>>>>
> >>>>> The "Agit workflow" requires you to use non-standard Git "push-
> >> options"
> >>>>> (either -o or --push-options):
> >>>>>
> >>>>> git push origin HEAD:refs/for/master -o topic="topic-branch" \
> >>>>>     -o title="Title of the PR" \
> >>>>>     -o description="# The PR Description
> >>>>> This can be **any** markdown content.\n
> >>>>> - [x] Ok"
> >>>>>
> >>>>> This means essentially that our attempt to move away from the e-mail-
> >> based
> >>>> submission procedure to something easy and user-friendly, would end
> up
> >> in
> >>>> replacing the current rarely-known mechanism with another even more
> >> rare
> >>>> and obscure procedure which would (again) force everybody to use the
> Git
> >>>> command line because it's (again) not supported by any tooling except
> Git
> >> CLI.
> >>>>>
> >>>>> I'm afraid, but from my point of view, this doesn't match the objective.
> >>>>
> >>>> The only alternative is to completely lock down the instance, and not
> >>>> allow new users at all without manual approval of each and every one.
> >>>>
> >>>> People can just ask to be allowed to fork, but by default, allowing it
> >>>> is not feasible.
> >>>
> >>> Hm, please help me understand what kind of spam we're talking about
> here.
> >> I can't imagine somebody would take the effort for selling some pills to
> ffmpeg
> >> developers. When it's about advertising anything, that's not the kind of
> reach
> >> those people are typically looking for.
> >>>
> >>> Or is it about misusing repos for storage of illegal content? The largest file
> >> currently is just 953kB, so we could enforce a limit small enough to make it
> >> unattractive for this purpose (unlike GitHub with 100MB per file).
> >>>
> >>> We could also disallow repos with custom content (i.e. only forks of
> ffmpeg
> >> are allowed as repo content).
> >>>
> >>> Then I wonder, where would be the harm? Some thousand unused forks
> of
> >> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> >>
> >> There are all sorts of copyrightable material that can be embedded
> >> into a git repo.
> >
> > That's why I mentioned that a file size limit could prevent this. With a 2 MB
> limit per file, it becomes totally unattractive for this kind of abuse.
> 
> That doesn't seem feasible to implement, given it's git.
> Not even sure how to implement such a limit at all with git.
> Some hook would need to check every file on push, which I don't think is
> something that readily exists.

GitHub does it. I think a pre-receive hook can do it. AI spits out a 10 line
Bash script. Might be wrong as usual, but the principle should work.


> > AFAIK, you are only responsible to take stuff down once you get notified,
> you don't need to actively look for anything.
> 
> I still wouldn't want to be the one hosting who knows what of illegal
> shit on our servers.

The nature of illegal shit these days involves a certain size - as said, I don't believe that it's attractive for anybody when you can store max 2 MB files. Splitting it into a RAR set like in earlier days is also not something worth the effort, give that so many better alternatives exist.
 
> Also keep in mind that if they fork the FFmpeg repo, and then push
> something big and bad into that fork, 

^^ File size limit 

> it ends up in the same backing storage of git objects.
> So it's not even trivial to just delete it again, and bar access to it.

If these are just branches, why would it be non-trivial to delete them?
I would expect that from forgejo to be handled when a forked repo gets deleted, don't you think they would do so?


> > Also, I wonder how this would be different from attachments on
> https://trac.ffmpeg.org ? There's no requirement for user "approval" as well..
> 
> We're just relatively lucky that trac is pretty uncommon and spambots
> targetting are more rare.
> Also, our custom-baked captcha for trac has so far remained undefeated.
> 
> Before it was implemented, trac also had a lot of spambots.

That sounds like a good idea to me.
I could also imagine other measures to make it less attractive for any automated account creations, for example with regards to timing:

- Don't allow more than 1 account creation per 15 minutes 
  (a real person can wait and try again when told so, and automated sign-ups are unable to create many accounts at once)
- State that the e-mail confirmation may take up to an hour and let it take that long
  (an automated signup doesn't have the time to wait)
- Require new users to wait 24h before being allowed to push something (or create a fork repo)

These things are acceptable for real persons but no spammer likes something that needs to be scripted in multiple parts which need to run at different times.
Albeit annoying, this is still far better than requiring that people have to "apply" in order to be granted access. That's extreme fencing again and might even appear as if things have become worse than before (for posting patches to the ML you don't need to ask anybody for being granted access).

If it's too difficult to handle it via self-hosting, my preference would go back to using GitHub instead.

Thanks
sw






_______________________________________________
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] [RFC] Experiment: enable github pull requests

[martin schitter]

On 2/12/25 23:05, Timo Rothenpieler wrote:
> PRs are not restricted. Creating repos is.
> And there is no way to NOT restrict it, unless you want to pay several 
> hundred Euros a month in hosting fees extra, and constantly be on the 
> lookout for hosting illegal/harmful things.

Hosting tons of forks can be done very efficiently if you storage 
solution provides adequate *deduplication* support. That's only one of 
the typical issues that you'll have to face, if you try to imitate the 
big ones by using utterly inadequate means. Tools which only look 
similar on their outer surface.

Fighting notification spam, which plagued codeberg (=forgejo) users the 
last days in a very unpleasant way, are a similar problem. Ignoring the 
importance of these less obvious maintenance requirements looks to me 
like setting up an email server resp. gateway without any mature spam 
protection facilities these days.

But I also wouldn't be happy if GitHub would be simply chosen at the end 
because of all this challenging troubles and dangers.

Anyway -- CI workflow, automatic PR checks and satisfying comment and 
documentation support are IMHO much more important aspects than just 
hosting a git repo on the web.

martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 8329 bytes --]

On 13/02/2025 03:59, Soft Works wrote:
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Timo
>> Rothenpieler
>> Sent: Donnerstag, 13. Februar 2025 02:52
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> On 13.02.2025 01:40, Soft Works wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>>>> Romain Beauxis
>>>> Sent: Donnerstag, 13. Februar 2025 01:25
>>>> To: FFmpeg development discussions and patches <ffmpeg-
>>>> devel@ffmpeg.org>
>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>>>
>>>> Le mer. 12 févr. 2025 à 18:17, Soft Works
>>>> <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>>>> Timo
>>>>>> Rothenpieler
>>>>>> Sent: Donnerstag, 13. Februar 2025 00:34
>>>>>> To: ffmpeg-devel@ffmpeg.org
>>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
>> requests
>>>>>>
>>>>>> On 13.02.2025 00:07, Soft Works wrote:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
>> Of
>>>>>> Timo
>>>>>>>> Rothenpieler
>>>>>>>> Sent: Mittwoch, 12. Februar 2025 22:33
>>>>>>>> To: ffmpeg-devel@ffmpeg.org
>>>>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
>>>> requests
>>>>>>>>
>>>>>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
>>>>>>>>> Are all accounts restricted to owning a maximum of 0 repositories by
>>>>>>>>> default, or is it set to 0 only for those that sign up through one of
>>>>>>>>> the external logins?
>>>>>>>>
>>>>>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
>>>>>>>> people (ab)using it for non-ffmpeg things.
>>>>>>>>
>>>>>>>> You can open issues and comment on existing PRs.
>>>>>>>> And also create PRs using the AGit workflow:
>>>>>>>> https://forgejo.org/docs/latest/user/agit-support/
>>>>>>>
>>>>>>> For those who are too lazy to look it up:
>>>>>>>
>>>>>>> The "Agit workflow" requires you to use non-standard Git "push-
>>>> options"
>>>>>>> (either -o or --push-options):
>>>>>>>
>>>>>>> git push origin HEAD:refs/for/master -o topic="topic-branch" \
>>>>>>>      -o title="Title of the PR" \
>>>>>>>      -o description="# The PR Description
>>>>>>> This can be **any** markdown content.\n
>>>>>>> - [x] Ok"
>>>>>>>
>>>>>>> This means essentially that our attempt to move away from the e-mail-
>>>> based
>>>>>> submission procedure to something easy and user-friendly, would end
>> up
>>>> in
>>>>>> replacing the current rarely-known mechanism with another even more
>>>> rare
>>>>>> and obscure procedure which would (again) force everybody to use the
>> Git
>>>>>> command line because it's (again) not supported by any tooling except
>> Git
>>>> CLI.
>>>>>>>
>>>>>>> I'm afraid, but from my point of view, this doesn't match the objective.
>>>>>>
>>>>>> The only alternative is to completely lock down the instance, and not
>>>>>> allow new users at all without manual approval of each and every one.
>>>>>>
>>>>>> People can just ask to be allowed to fork, but by default, allowing it
>>>>>> is not feasible.
>>>>>
>>>>> Hm, please help me understand what kind of spam we're talking about
>> here.
>>>> I can't imagine somebody would take the effort for selling some pills to
>> ffmpeg
>>>> developers. When it's about advertising anything, that's not the kind of
>> reach
>>>> those people are typically looking for.
>>>>>
>>>>> Or is it about misusing repos for storage of illegal content? The largest file
>>>> currently is just 953kB, so we could enforce a limit small enough to make it
>>>> unattractive for this purpose (unlike GitHub with 100MB per file).
>>>>>
>>>>> We could also disallow repos with custom content (i.e. only forks of
>> ffmpeg
>>>> are allowed as repo content).
>>>>>
>>>>> Then I wonder, where would be the harm? Some thousand unused forks
>> of
>>>> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
>>>>
>>>> There are all sorts of copyrightable material that can be embedded
>>>> into a git repo.
>>>
>>> That's why I mentioned that a file size limit could prevent this. With a 2 MB
>> limit per file, it becomes totally unattractive for this kind of abuse.
>>
>> That doesn't seem feasible to implement, given it's git.
>> Not even sure how to implement such a limit at all with git.
>> Some hook would need to check every file on push, which I don't think is
>> something that readily exists.
> 
> GitHub does it. I think a pre-receive hook can do it. AI spits out a 10 line
> Bash script. Might be wrong as usual, but the principle should work.
> 
> 
>>> AFAIK, you are only responsible to take stuff down once you get notified,
>> you don't need to actively look for anything.
>>
>> I still wouldn't want to be the one hosting who knows what of illegal
>> shit on our servers.
> 
> The nature of illegal shit these days involves a certain size - as said, I don't believe that it's attractive for anybody when you can store max 2 MB files. Splitting it into a RAR set like in earlier days is also not something worth the effort, give that so many better alternatives exist.
>   
>> Also keep in mind that if they fork the FFmpeg repo, and then push
>> something big and bad into that fork,
> 
> ^^ File size limit
> 
>> it ends up in the same backing storage of git objects.
>> So it's not even trivial to just delete it again, and bar access to it.
> 
> If these are just branches, why would it be non-trivial to delete them?
> I would expect that from forgejo to be handled when a forked repo gets deleted, don't you think they would do so?
> 
> 
>>> Also, I wonder how this would be different from attachments on
>> https://trac.ffmpeg.org ? There's no requirement for user "approval" as well..
>>
>> We're just relatively lucky that trac is pretty uncommon and spambots
>> targetting are more rare.
>> Also, our custom-baked captcha for trac has so far remained undefeated.
>>
>> Before it was implemented, trac also had a lot of spambots.
> 
> That sounds like a good idea to me.
> I could also imagine other measures to make it less attractive for any automated account creations, for example with regards to timing:
> 
> - Don't allow more than 1 account creation per 15 minutes
>    (a real person can wait and try again when told so, and automated sign-ups are unable to create many accounts at once)
> - State that the e-mail confirmation may take up to an hour and let it take that long
>    (an automated signup doesn't have the time to wait)
> - Require new users to wait 24h before being allowed to push something (or create a fork repo)
> 
> These things are acceptable for real persons but no spammer likes something that needs to be scripted in multiple parts which need to run at different times.
> Albeit annoying, this is still far better than requiring that people have to "apply" in order to be granted access. That's extreme fencing again and might even appear as if things have become worse than before (for posting patches to the ML you don't need to ask anybody for being granted access).
> 
> If it's too difficult to handle it via self-hosting, my preference would go back to using GitHub instead.

Literally, all that users have to do if they want to submit a PR is to 
ask one of the admins that they plan to submit PRs.

They can still submit issues and comments. It's better than having to 
wait for days for an admin to approve you.
We can setup a repository that users can make an issue on if they want 
to submit a PR. Surely, we won't get more than a few users a day 
registering, so it wouldn't take long to give them access. I think this 
is a better option than having spammers and increasing the load on admins.

Finally, with federation, there's are no restriction. If users have an 
account on another Forgejo instance, such as codeberg, they can clone 
and submit PRs to FFmpeg without having to register, and without needing 
to use agit.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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] [RFC] Experiment: enable github pull requests

[martin schitter]

On 2/13/25 07:14, Lynne wrote:
> Finally, with federation, there's are no restriction. If users have an 
> account on another Forgejo instance, such as codeberg, they can clone 
> and submit PRs to FFmpeg without having to register, and without needing 
> to use agit.

This will not work very well together with more advanced CI based PR 
checks and feedback if the used software platform doesn't provide mature 
support for these kinds of distributed setups. Ignoring this limitation 
you'll quickly face inconsistent repository-states and chaos as 
consequence. Until now none of the well known software options is able 
to play well in federated mode.

Using the other "federated" instances just as old fashioned identity 
providers isn't a very convincing solution to solve any of the real 
challenges of setting up a more efficient and somehow future-proof 
collaborative development workflow.

martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Lynne
> Sent: Donnerstag, 13. Februar 2025 07:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13/02/2025 03:59, Soft Works wrote:
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Donnerstag, 13. Februar 2025 02:52
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 13.02.2025 01:40, Soft Works wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >>>> Romain Beauxis
> >>>> Sent: Donnerstag, 13. Februar 2025 01:25
> >>>> To: FFmpeg development discussions and patches <ffmpeg-
> >>>> devel@ffmpeg.org>
> >>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> >>>>
> >>>> Le mer. 12 févr. 2025 à 18:17, Soft Works
> >>>> <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >>>> Timo
> >>>>>> Rothenpieler
> >>>>>> Sent: Donnerstag, 13. Februar 2025 00:34
> >>>>>> To: ffmpeg-devel@ffmpeg.org
> >>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >> requests
> >>>>>>
> >>>>>> On 13.02.2025 00:07, Soft Works wrote:
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> Behalf
> >> Of
> >>>>>> Timo
> >>>>>>>> Rothenpieler
> >>>>>>>> Sent: Mittwoch, 12. Februar 2025 22:33
> >>>>>>>> To: ffmpeg-devel@ffmpeg.org
> >>>>>>>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >>>> requests
> >>>>>>>>
> >>>>>>>> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>>>>>>>> Are all accounts restricted to owning a maximum of 0 repositories
> by
> >>>>>>>>> default, or is it set to 0 only for those that sign up through one of
> >>>>>>>>> the external logins?
> >>>>>>>>
> >>>>>>>> It's set to 0 by default, to avoid spammers uploading junk, or just
> >>>>>>>> people (ab)using it for non-ffmpeg things.
> >>>>>>>>
> >>>>>>>> You can open issues and comment on existing PRs.
> >>>>>>>> And also create PRs using the AGit workflow:
> >>>>>>>> https://forgejo.org/docs/latest/user/agit-support/
> >>>>>>>
> >>>>>>> For those who are too lazy to look it up:
> >>>>>>>
> >>>>>>> The "Agit workflow" requires you to use non-standard Git "push-
> >>>> options"
> >>>>>>> (either -o or --push-options):
> >>>>>>>
> >>>>>>> git push origin HEAD:refs/for/master -o topic="topic-branch" \
> >>>>>>>      -o title="Title of the PR" \
> >>>>>>>      -o description="# The PR Description
> >>>>>>> This can be **any** markdown content.\n
> >>>>>>> - [x] Ok"
> >>>>>>>
> >>>>>>> This means essentially that our attempt to move away from the e-
> mail-
> >>>> based
> >>>>>> submission procedure to something easy and user-friendly, would end
> >> up
> >>>> in
> >>>>>> replacing the current rarely-known mechanism with another even
> more
> >>>> rare
> >>>>>> and obscure procedure which would (again) force everybody to use
> the
> >> Git
> >>>>>> command line because it's (again) not supported by any tooling except
> >> Git
> >>>> CLI.
> >>>>>>>
> >>>>>>> I'm afraid, but from my point of view, this doesn't match the
> objective.
> >>>>>>
> >>>>>> The only alternative is to completely lock down the instance, and not
> >>>>>> allow new users at all without manual approval of each and every one.
> >>>>>>
> >>>>>> People can just ask to be allowed to fork, but by default, allowing it
> >>>>>> is not feasible.
> >>>>>
> >>>>> Hm, please help me understand what kind of spam we're talking about
> >> here.
> >>>> I can't imagine somebody would take the effort for selling some pills to
> >> ffmpeg
> >>>> developers. When it's about advertising anything, that's not the kind of
> >> reach
> >>>> those people are typically looking for.
> >>>>>
> >>>>> Or is it about misusing repos for storage of illegal content? The largest
> file
> >>>> currently is just 953kB, so we could enforce a limit small enough to make
> it
> >>>> unattractive for this purpose (unlike GitHub with 100MB per file).
> >>>>>
> >>>>> We could also disallow repos with custom content (i.e. only forks of
> >> ffmpeg
> >>>> are allowed as repo content).
> >>>>>
> >>>>> Then I wonder, where would be the harm? Some thousand unused
> forks
> >> of
> >>>> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> >>>>
> >>>> There are all sorts of copyrightable material that can be embedded
> >>>> into a git repo.
> >>>
> >>> That's why I mentioned that a file size limit could prevent this. With a 2 MB
> >> limit per file, it becomes totally unattractive for this kind of abuse.
> >>
> >> That doesn't seem feasible to implement, given it's git.
> >> Not even sure how to implement such a limit at all with git.
> >> Some hook would need to check every file on push, which I don't think is
> >> something that readily exists.
> >
> > GitHub does it. I think a pre-receive hook can do it. AI spits out a 10 line
> > Bash script. Might be wrong as usual, but the principle should work.
> >
> >
> >>> AFAIK, you are only responsible to take stuff down once you get notified,
> >> you don't need to actively look for anything.
> >>
> >> I still wouldn't want to be the one hosting who knows what of illegal
> >> shit on our servers.
> >
> > The nature of illegal shit these days involves a certain size - as said, I don't
> believe that it's attractive for anybody when you can store max 2 MB files.
> Splitting it into a RAR set like in earlier days is also not something worth the
> effort, give that so many better alternatives exist.
> >
> >> Also keep in mind that if they fork the FFmpeg repo, and then push
> >> something big and bad into that fork,
> >
> > ^^ File size limit
> >
> >> it ends up in the same backing storage of git objects.
> >> So it's not even trivial to just delete it again, and bar access to it.
> >
> > If these are just branches, why would it be non-trivial to delete them?
> > I would expect that from forgejo to be handled when a forked repo gets
> deleted, don't you think they would do so?
> >
> >
> >>> Also, I wonder how this would be different from attachments on
> >> https://trac.ffmpeg.org ? There's no requirement for user "approval" as
> well..
> >>
> >> We're just relatively lucky that trac is pretty uncommon and spambots
> >> targetting are more rare.
> >> Also, our custom-baked captcha for trac has so far remained undefeated.
> >>
> >> Before it was implemented, trac also had a lot of spambots.
> >
> > That sounds like a good idea to me.
> > I could also imagine other measures to make it less attractive for any
> automated account creations, for example with regards to timing:
> >
> > - Don't allow more than 1 account creation per 15 minutes
> >    (a real person can wait and try again when told so, and automated sign-ups
> are unable to create many accounts at once)
> > - State that the e-mail confirmation may take up to an hour and let it take
> that long
> >    (an automated signup doesn't have the time to wait)
> > - Require new users to wait 24h before being allowed to push something (or
> create a fork repo)
> >
> > These things are acceptable for real persons but no spammer likes something
> that needs to be scripted in multiple parts which need to run at different times.
> > Albeit annoying, this is still far better than requiring that people have to
> "apply" in order to be granted access. That's extreme fencing again and might
> even appear as if things have become worse than before (for posting patches
> to the ML you don't need to ask anybody for being granted access).
> >
> > If it's too difficult to handle it via self-hosting, my preference would go back
> to using GitHub instead.

Hi Lynne,

> Literally, all that users have to do if they want to submit a PR is to
> ask one of the admins that they plan to submit PRs.

That's easily said when viewing it from an inside position. But for people outside this will appear to be a kind of closed circle and many will be too shy to even consider asking.


> They can still submit issues and comments. It's better than having to
> wait for days for an admin to approve you.

In issues and comments, you can spam as well and much easier. It doesn't need be in the main repo, but it could be in a repo from someone who has been less active recently. There, one can easily store things in comment attachments. There's a reason why GitHub has a 100 MB limit for files in a repo, but only 10 MB for attachments in comments/posts.
Hence, I'm not sure whether it's repo-ownership what spammers are primarily looking for. When it's about posting links to advertise something like it often happens in our forums, then the procedure is always:

- Create account
- Make one or two posts
- Never come back again

That's exactly the scenario which would still be possible.


> Finally, with federation, there's are no restriction. If users have an
> account on another Forgejo instance, such as codeberg, they can clone
> and submit PRs to FFmpeg without having to register, and without needing
> to use agit.

That sounds interesting. How can I create a fork of ffmpeg (https://code.ffmpeg.org/) on Codeberg? And how can I then create a PR from the Codeberg repo on https://code.ffmpeg.org/? 
Does that really work - and with which account? (Codeberg or ffmpeg account)

Thanks
sw
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Lynne
> Sent: Donnerstag, 13. Februar 2025 07:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13/02/2025 03:59, Soft Works wrote:
> >
> Finally, with federation, there's are no restriction. If users have an
> account on another Forgejo instance, such as codeberg, they can clone
> and submit PRs to FFmpeg without having to register, and without needing
> to use agit.

Two more thoughts:

I'm a bit surprised to hear that Spammers would be such a big problem. On GitHub, I'm subscribed to dozens of repos and surely more than a thousand conversations, but over the past 10 years I have received less than 5 spam messages in total. That makes we wonder how GH is doing it, because notifications are sent out instantly and I would have seen those in the inbox even when they would have been cleaned up later.
What's their recipe?


And regarding Codeberg: When spam is such a big concern that we must require user to apply even for creating a fork (unlike almost any other open-source software project in the world) - why then even bother with self-hosting? If we think it causes too much trouble, why do it in the first place? There are other organizations for which hosting Git repos is their daily and primary business. Maybe it's better to have it professionally hosted and call it a day... 
Why not Codeberg actually?

Best
sw 



 
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Leo Izen]

On 2/12/25 5:05 PM, Timo Rothenpieler wrote:
>>
> I'm really not sure what you're asking.
> PRs are not restricted. Creating repos is.
> And there is no way to NOT restrict it, unless you want to pay several 
> hundred Euros a month in hosting fees extra, and constantly be on the 
> lookout for hosting illegal/harmful things.

My understanding as a Github and Gitlab user is the usual way to make a 
PR is to first fork the repository, then commit changes to a branch on 
your fork, and then send a PR which compares the fork to the master 
branch of upstream.

If you can't make a repository, I'm not sure how you would do a PR. It 
sounds like you're saying there's another way to do it, but I'm not 
familiar with it and I expect many other people are not either.

- 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] [RFC] Experiment: enable github pull requests

[Tanay Manerikar]

On Thu, Feb 13, 2025 at 2:20 PM Leo Izen <leo.izen@gmail.com> wrote:

> On 2/12/25 5:05 PM, Timo Rothenpieler wrote:
> >>
> > I'm really not sure what you're asking.
> > PRs are not restricted. Creating repos is.
> > And there is no way to NOT restrict it, unless you want to pay several
> > hundred Euros a month in hosting fees extra, and constantly be on the
> > lookout for hosting illegal/harmful things.
>
> My understanding as a Github and Gitlab user is the usual way to make a
> PR is to first fork the repository, then commit changes to a branch on
> your fork, and then send a PR which compares the fork to the master
> branch of upstream.
>
> If you can't make a repository, I'm not sure how you would do a PR. It
> sounds like you're saying there's another way to do it, but I'm not
> familiar with it and I expect many other people are not either.
>
> - Leo Izen (Traneptora)
>
I just created an account with  Forgejo, but I can't fork the main FFmpeg
repo. Who do I have to ask for access to create a repo? I am not sure if
this is the correct place to ask this.
- Tanay Manerikar
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Gyan Doshi]

On 2025-02-13 02:19 pm, Leo Izen wrote:
> On 2/12/25 5:05 PM, Timo Rothenpieler wrote:
>>>
>> I'm really not sure what you're asking.
>> PRs are not restricted. Creating repos is.
>> And there is no way to NOT restrict it, unless you want to pay 
>> several hundred Euros a month in hosting fees extra, and constantly 
>> be on the lookout for hosting illegal/harmful things.
>
> My understanding as a Github and Gitlab user is the usual way to make 
> a PR is to first fork the repository, then commit changes to a branch 
> on your fork, and then send a PR which compares the fork to the master 
> branch of upstream.

For some time, Github has allowed in-place editing. What that means is 
once you finished editing the file in the upstream repo, GH will fork 
the repo for you, or if already forked, create a new branch, with your 
changes incorporated, and give you an option to send a PR.

Regards,
Gyan

_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Gyan
> Doshi
> Sent: Donnerstag, 13. Februar 2025 10:49
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> 
> 
> On 2025-02-13 02:19 pm, Leo Izen wrote:
> > On 2/12/25 5:05 PM, Timo Rothenpieler wrote:
> >>>
> >> I'm really not sure what you're asking.
> >> PRs are not restricted. Creating repos is.
> >> And there is no way to NOT restrict it, unless you want to pay
> >> several hundred Euros a month in hosting fees extra, and constantly
> >> be on the lookout for hosting illegal/harmful things.

Hi Leo,

> > My understanding as a Github and Gitlab user is the usual way to make
> > a PR is to first fork the repository, then commit changes to a branch
> > on your fork, and then send a PR which compares the fork to the master
> > branch of upstream.

Yes exactly!


Hi Gyan,

> For some time, Github has allowed in-place editing. What that means is
> once you finished editing the file in the upstream repo, GH will fork
> the repo for you, or if already forked, create a new branch, with your
> changes incorporated, and give you an option to send a PR.

That's right. It still does that (for clarification: this is about making edits in the GH WEB UI).
It's pretty convenient for small edits at times. Yet, it's not a different procedure, it just creates a fork and a branch in the fork for you plus a commit with your changes automatically in one go on a single Save button click.
The fork it creates (if you don't have one) is a normal fork like any other fork you create manually.

Best
sw

_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Tobias Rapp]

On 13/02/2025 01:24, Romain Beauxis wrote:

> Le mer. 12 févr. 2025 à 18:17, Soft Works
> <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
>> Hm, please help me understand what kind of spam we're talking about here. I can't imagine somebody would take the effort for selling some pills to ffmpeg developers. When it's about advertising anything, that's not the kind of reach those people are typically looking for.
>>
>> Or is it about misusing repos for storage of illegal content? The largest file currently is just 953kB, so we could enforce a limit small enough to make it unattractive for this purpose (unlike GitHub with 100MB per file).
>>
>> We could also disallow repos with custom content (i.e. only forks of ffmpeg are allowed as repo content).
>>
>> Then I wonder, where would be the harm? Some thousand unused forks of ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> There are all sorts of copyrightable material that can be embedded
> into a git repo.
>
> Also payloads for malicious software.
>
> etc.
>
> Given that this all amounts to manpower from the operator, it's
> totally understandable that they would like to be conservative about
> opening it up.

I'd like to add that with CI enabled there is the possibility that users 
of the platform abuse it to get some processing resources for free 
(crypto mining). From what I remember this was an issue for the GitLab 
instance at FreeDesktop.org.

Regards, Tobias

_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Tomas Härdin]

ons 2025-02-12 klockan 22:16 +0000 skrev Soft Works:
> > > I think people should be able to use a procedure they are
> > > familiar with.
> > > Is it possible to create PRs from a fork on GitHub?

We explicitly don't want that. Also github doesn't federate. None of
these git hosting sites do I think. You should learn git instead of
relying on github silliness.

> > 
> > I'm really not sure what you're asking.
> > PRs are not restricted. Creating repos is.
> > And there is no way to NOT restrict it, unless you want to pay
> > several
> > hundred Euros a month in hosting fees extra, and constantly be on
> > the
> > lookout for hosting illegal/harmful things.
> 
> I wasn't asking, I'm stating that not being able to use an
> established workflow like 
> 
> fork >> clone >> develop >> push >> PR

clone >> develop >> push == PR is far simpler

> ...would be an entry-bar for new contributors.
> 
> But here comes a question: I've read that the "AGit flow" work by
> creating a branch for each submission in the original repo. Doesn't
> the repo get "polluted" over time this way? In case of merged PRs,
> the branch might get deleted, but what about unmerged ones?

Just delete them

> And when one clones the whole repo, don't they get all those branches
> downloaded locally as well? (as long as one doesn’t specify which
> branches to download)

Yeah, so? Two people might want to work on a branch. This is standard
git stuff. It's even worse with github's fork feature, because most
forks don't have any actual new code. They just pollute the list with
no way to clean it.

/Tomas
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Tobias Rapp
> Sent: Donnerstag, 13. Februar 2025 12:05
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13/02/2025 01:24, Romain Beauxis wrote:
> 
> > Le mer. 12 févr. 2025 à 18:17, Soft Works
> > <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
> >> Hm, please help me understand what kind of spam we're talking about
> here. I can't imagine somebody would take the effort for selling some pills to
> ffmpeg developers. When it's about advertising anything, that's not the kind
> of reach those people are typically looking for.
> >>
> >> Or is it about misusing repos for storage of illegal content? The largest file
> currently is just 953kB, so we could enforce a limit small enough to make it
> unattractive for this purpose (unlike GitHub with 100MB per file).
> >>
> >> We could also disallow repos with custom content (i.e. only forks of ffmpeg
> are allowed as repo content).
> >>
> >> Then I wonder, where would be the harm? Some thousand unused forks of
> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> > There are all sorts of copyrightable material that can be embedded
> > into a git repo.
> >
> > Also payloads for malicious software.
> >
> > etc.
> >
> > Given that this all amounts to manpower from the operator, it's
> > totally understandable that they would like to be conservative about
> > opening it up.

Hi Tobias,

> I'd like to add that with CI enabled there is the possibility that users
> of the platform abuse it to get some processing resources for free
> (crypto mining). From what I remember this was an issue for the GitLab
> instance at FreeDesktop.org.

That's indeed a problem, also with GitHub actions for which reasons, CI builds on PRs are disabled by default (and enabling it is a very hidden option). It becomes risky because multiple factors come into play:

- The definitions for CI builds are part of the repo content, so it was easy to change that for doing something entirely different and submitting this as PR
- The build runners are aiming to give you full control and abilities to make them useful for all cases, so you have root access, passwordless sudo, full network access at high bandwidths (at least in case of GH Actions and Azure DevOps)
- The hosters cannot make any assumptions about your CI builds: how long it usually takes, which resources are required and whch kind of things you're executing, so the only thing they are doing is to isolate those VMs and let each job run on a fresh VM image.
- As a user of these services you actually don't need to care much about it, except for one thing: when you have any secrets in place that are needed to accessing other services or when the that the job uses for repo access has other permissions that could be used in some malicious way

In case of ffmpeg it's not that risky, because we know exactly what's needed and whatnot, so constraints can be applied to build machines like:

- limiting the maximum execution time
  on a super-slow (free tier) Google cloud VM, ffmpeg build plus FATE takes about 20min, so it can be limited to 30min
- restricting network access
  an ffmpeg build doesn't require network access to arbitrary destinations, so this can be locked down as well

With these two measures, the CI builds are pretty useless already for any malicious operations.


Oh, just while writing this reminded me that for the ffstaging (GitHub-sync-to-ML) setup I had applied and been granted 10 parallel build jobs without (monthly total) limit on Azure DevOps. Each job can run for 6h max, but you can start a new one then. This means 10 build machines can run in parallel 24/7 all time.
Since the application was "for building ffmpeg PRs" it would be perfectly fine to use this capacity for our CI builds. 
That way, we also do not need to be that much concerned about potential abuse. 😉 

sw




_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Tomas Härdin]

ons 2025-02-12 klockan 23:07 +0000 skrev Soft Works:
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Timo
> > Rothenpieler
> > Sent: Mittwoch, 12. Februar 2025 22:33
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> > requests
> > 
> > On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > > Are all accounts restricted to owning a maximum of 0 repositories
> > > by
> > > default, or is it set to 0 only for those that sign up through
> > > one of
> > > the external logins?
> > 
> > It's set to 0 by default, to avoid spammers uploading junk, or just
> > people (ab)using it for non-ffmpeg things.
> > 
> > You can open issues and comment on existing PRs.
> > And also create PRs using the AGit workflow:
> > https://forgejo.org/docs/latest/user/agit-support/
> 
> For those who are too lazy to look it up:
> 
> The "Agit workflow" requires you to use non-standard Git "push-
> options"
> (either -o or --push-options):
> 
> git push origin HEAD:refs/for/master -o topic="topic-branch" \
>   -o title="Title of the PR" \
>   -o description="# The PR Description
> This can be **any** markdown content.\n
> - [x] Ok"
> 
> This means essentially that our attempt to move away from the e-mail-
> based submission procedure to something easy and user-friendly, would
> end up in replacing the current rarely-known mechanism with another
> even more rare and obscure procedure which would (again) force
> everybody to use the Git command line because it's (again) not
> supported by any tooling except Git CLI.

I see this as a plus. More stuff should be done with git alone. This is
one case where fossil shines, because it combines code, tickets and
wiki into one single CLI tool.

/Tomas
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Soft
> Works
> Sent: Donnerstag, 13. Februar 2025 13:08
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests


> Oh, just while writing this reminded me that for the ffstaging (GitHub-sync-to-
> ML) setup I had applied and been granted 10 parallel build jobs without
> (monthly total) limit on Azure DevOps. Each job can run for 6h max, but you
> can start a new one then. This means 10 build machines can run in parallel
> 24/7 all time.
> Since the application was "for building ffmpeg PRs" it would be perfectly fine
> to use this capacity for our CI builds.
> That way, we also do not need to be that much concerned about potential
> abuse. 

This is set up as a separate "DevOps organization", which means that I'd be able to transfer ownership to ffmpeg.

sw 
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Leo Izen]

On 2/13/25 4:49 AM, Gyan Doshi wrote:
> 
> For some time, Github has allowed in-place editing. What that means is 
> once you finished editing the file in the upstream repo, GH will fork 
> the repo for you, or if already forked, create a new branch, with your 
> changes incorporated, and give you an option to send a PR.
> 

Under the hood this is just the process I described. Also I don't 
believe Forgejo has a web UI editor (and if it did I wouldn't want to 
send PRs with it, I'd rather use my own code editing workflow).

- 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] [RFC] Experiment: enable github pull requests

[martin schitter]

On 2/13/25 13:10, Tomas Härdin wrote:
> More stuff should be done with git alone. This is
> one case where fossil shines, because it combines code, tickets and
> wiki into one single CLI tool.

'radicle' does the same with git! :)

But it's still much to immature to use it as real alternative to the 
well known platforms resp. as main public interface. But it's at least 
possible to mirror, merge and sync the state of common github/gitlab 
instances and most of their included social metadata with radicle 
seeding by help of cron jobs.

I know, that's not the answer for ffmpegs near future, but it would be 
at least a more consistent solution as believing in vague promises about 
"federation" support in forgejo. It's an old topic, which was already 
requested, debated and expected on gitlab user boards more than ten 
years ago.

martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Leo Izen]

On 2/13/25 4:27 AM, Tanay Manerikar wrote:
> On Thu, Feb 13, 2025 at 2:20 PM Leo Izen <leo.izen@gmail.com> wrote:
> 
>> On 2/12/25 5:05 PM, Timo Rothenpieler wrote:
>>
>> My understanding as a Github and Gitlab user is the usual way to make a
>> PR is to first fork the repository, then commit changes to a branch on
>> your fork, and then send a PR which compares the fork to the master
>> branch of upstream.
>>
>> If you can't make a repository, I'm not sure how you would do a PR. It
>> sounds like you're saying there's another way to do it, but I'm not
>> familiar with it and I expect many other people are not either.
>>
>> - Leo Izen (Traneptora)
>>
> I just created an account with  Forgejo, but I can't fork the main FFmpeg
> repo. Who do I have to ask for access to create a repo? I am not sure if
> this is the correct place to ask this.
> - Tanay Manerikar

At the moment you'd have to ask on IRC, or on the ffmpeg-devel mailing 
list (which you just did). I'm CCing Timo, who is currently managing the 
trial instance.

Apparently you can also send a PR without a fork but I don't know how 
and this is exactly the problem I expect will arise in the future.

- 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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13/02/2025 08:24, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Lynne
>> Sent: Donnerstag, 13. Februar 2025 07:15
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
>>
>> On 13/02/2025 03:59, Soft Works wrote:
>>>
>> Finally, with federation, there's are no restriction. If users have an
>> account on another Forgejo instance, such as codeberg, they can clone
>> and submit PRs to FFmpeg without having to register, and without needing
>> to use agit.
> 
> Two more thoughts:
> 
> I'm a bit surprised to hear that Spammers would be such a big problem. On GitHub, I'm subscribed to dozens of repos and surely more than a thousand conversations, but over the past 10 years I have received less than 5 spam messages in total. That makes we wonder how GH is doing it, because notifications are sent out instantly and I would have seen those in the inbox even when they would have been cleaned up later.
> What's their recipe?
> 
> 
> And regarding Codeberg: When spam is such a big concern that we must require user to apply even for creating a fork (unlike almost any other open-source software project in the world) - why then even bother with self-hosting? If we think it causes too much trouble, why do it in the first place? There are other organizations for which hosting Git repos is their daily and primary business. Maybe it's better to have it professionally hosted and call it a day...

The majority of Open Source projects that self-host some form of 
Github-Clone are imposing similar or even harsher restrictions.
See Videolan, who don't even let you register without an admin approving 
you.
ISC and Freedesktop on their Gitlabs have the same restrictions of 
disallowing the creation of repos until admin approval.

Just hosting something that allows free users uploads to anyone who 
signs up is just not something you can do these days.
It WILL get abused, and if you're unlucky, you can end up legally 
responsible for the abuse and/or it can cause the hoster to terminate you.
_______________________________________________
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] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13/02/2025 09:49, Leo Izen wrote:
> On 2/12/25 5:05 PM, Timo Rothenpieler wrote:
>>>
>> I'm really not sure what you're asking.
>> PRs are not restricted. Creating repos is.
>> And there is no way to NOT restrict it, unless you want to pay several 
>> hundred Euros a month in hosting fees extra, and constantly be on the 
>> lookout for hosting illegal/harmful things.
> 
> My understanding as a Github and Gitlab user is the usual way to make a 
> PR is to first fork the repository, then commit changes to a branch on 
> your fork, and then send a PR which compares the fork to the master 
> branch of upstream.
> 
> If you can't make a repository, I'm not sure how you would do a PR. It 
> sounds like you're saying there's another way to do it, but I'm not 
> familiar with it and I expect many other people are not either.

The docs have been linked to twice now:
https://forgejo.org/docs/latest/user/agit-support/

Again, it's not the intention to ONLY support this workflow, but it's an 
alternative for people who don't want to wait for admin approval for 
their own fork.

Having your own fork still has merit, since you can develop and share 
your own changes that aren't necessarily intended for merge (yet).
But allowing repo creation without approval is too wide open of a door 
to allow it by default.
With the AGit workflow we at least immediately see the spam since it 
plopps up as PR that can then be swiftly dealt with.

If anyone wants to be allowed to fork, just let me know with an account 
name and I'll up the limit.
_______________________________________________
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".