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

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

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