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