5 ms·

It's cool to see such an impactful project choose sovereignty. I hope more projects follow their example. If you're a backbone-of-the-internet project like FFm

It's cool to see such an impactful project choose sovereignty. I hope more projects follow their example. If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "FFmpeg contributor" on their CV (or whatever).

nine_k 1y ago
Typos may be quite impactful, don't discount them. My only contribution to node-grpc fixed missing quotes, but only because that produced real crashes.
- miohtama 1y ago
  But the parent does not refer to fixing crashes
- usr1106 1y ago
  In my previous work we were strict about typos, whitespace and general consistency in reviews. And even fixed them later if they slipped through. I found it a bit ridicolous a times. In my current company nobody cares. It can be seen in the whole code quality. Full of smaller and bigger bugs as well as horrible hacks. It can be seen whether coders look twice or more at their own stuff before putting it to review or not, just trying to avoid ridicolous comments. It's a whole attitude. I write good code in a messy source base is unlikely to work in practice. That said, I have submitted cleanup commits to open source projects only in the same MR with a real code change I wanted to make and only in vincinity of that change.
- nosioptar 1y ago
  A typo caused NASA'a Mariner I to fail. https://science.nasa.gov/mission/mariner-1/ https://science.nasa.gov/mission/mariner-1/
Aurornis 1y ago
Rejecting useless or white space-only PRs is quick and easy. It’s not as big of a problem as you’re suggesting. I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.
- account42 1y ago
  > Rejecting useless or white space-only PRs is quick and easy. No, it really is draining. > I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements. It's frustrating when people make "contributions" that take more effort to review than they put in and then get mad when they don't get thanked for it. This attitude is exactly why dealing with drive by pull requests is not "quick and easy" - suddenly you need to do social and public relations stuff when all you want to do is code.
- reconvene1290 1y ago
  It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.
  - BoredPositron 1y ago
    There are people hunting double spaces or typos in code? For what contributor credits?
    - RyJones 1y ago
      Yes. I have a lot of long, boring stories about exactly this.
jambutters 1y ago
Thousands is quite the exaggeration when there are only 379 on ffmpeg github. If you look through them, its actually 5-10% if not less
- picafrost 1y ago
  Another way to frame this is that even though the FFmpeg repository clearly indicates it's a mirror repository and has had a single open pull request titled "WARNING: PULL REQUESTS ON THIS REPOSITORY ARE IGNORED" [0] sitting in the pull requests page for 10 years, they've still had to close hundreds of pull requests. [0] https://github.com/FFmpeg/FFmpeg/pull/153 https://github.com/FFmpeg/FFmpeg/pull/153
  - mcintyre1994 1y ago
    That’s fair, but it would be trivial to use GitHub’s actions/API (and probably just an existing open source tool in either case) to automatically close them without anyone wasting their time. I think you’re definitely right that being a massive project on GitHub that accepts PRs there would be a nightmare though.
tzury 1y ago
This issue has only worsened with LLMs "assisting" contributors in submitting PRs that end up wasting maintainers' time. Tools like OpenAI Codex, which can connect directly to repositories, are likely to amplify this problem even further. That said, this is also the real measure of the actual value of LLMs and coding agents: the day we see top open-source projects having dozens of bugs effectively fixed per day by LLMs, we’ll know they’ve matured into a solid, reliable resource.
cdrini 1y ago
Is the version on Forgejo closed to public contribution?
pmontra 1y ago
FFmpeg seems to have dealt with that problem when they still were on github. This is the paragraph at the end of the readme: > Contributing > Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process and will be ignored. An agentic LLM bot is likely to have no problems at creating a patch and mailing it but it's a major pain for most human developers. Furthermore they can ban source email addresses and vet potential contributors before letting them in the mailing list.
- BlueTemplar 1y ago
  Why is it a major pain? Isn't it part of git workflow? Or is this because most developers got complacent in only using GitHub and similar?
  - pmontra 1y ago
    Because only a few people used that. The usual workflow I saw before GitHub made PRs popular was: one local repo per developer (or more repo if they wished so), one central shared repo, push a feature branch to the central repo, somebody pulls the branch, reviews the changes and poss the merge them in the preproduction branch, or go back to the developer, some test build deploy procedure, acceptance tests, pass or go back to development, merge in the production branch, test build deploy.
  - pm215 1y ago
    (I work on a project that uses an email workflow. "Should we switch to something else?" is a perennial topic.) I think the main pain points are: * unfamiliarity -- if you're not already set up then it's extra admin work. And the "obvious" approach (paste the patch into your usual email client and hit send) generally mangles the patch. * developers are no longer largely using local plain text based email clients -- if you are already doing email that way then sending patches like that is a natural extension. If your email client is gmail, or worse still some Microsoft mail server, now you have to figure out how to send email in a way that's not html and doesn't get mangled by your mail server. * how to set it up is not a single well documented path. Github has an incentive to do a decent tutorial/docs, and how to create an account and send a patch is the same for everyone. Using git send-email, there's a lot more variability: how to install it depends on your OS, and how to configure it to talk to your mail server depends on your mail server. In these days of two factor authentication and app specific passwords, it's no longer as easy as "put the server name and your account name and password into the config file". This has got better in that now you can point people at e.g. https://git-send-email.io/ https://git-send-email.io/ which has info on e.g. setting up gmail app specific passwords and what kind of authentication to use. If you're a regular developer on a project, this is a one-time pain and thereafter sending patches is straightforward (assuming you're not totally allergic to the command line). But for one-off or first time contributions it can be a barrier.
mmmmbbbhb 1y ago
I have to say you're exaggerating, ignoring prs isn't such a chore.
- dspillett 1y ago
  If you are ignoring all of them. Filtering PRs to see which are worth having might take time in a large popular project. Even if it isn't much time, it is more than zero. You also have to deal with all the other comms associated: people submitting genuinely useful patches which accidentally get rejected querying (maybe politely, maybe not) and people who submitted less useful ones bitching about their rejection, both to the project and in public forums.

nine_k 1y ago

Typos may be quite impactful, don't discount them. My only contribution to node-grpc fixed missing quotes, but only because that produced real crashes.

miohtama 1y ago
But the parent does not refer to fixing crashes
usr1106 1y ago
In my previous work we were strict about typos, whitespace and general consistency in reviews. And even fixed them later if they slipped through. I found it a bit ridicolous a times. In my current company nobody cares. It can be seen in the whole code quality. Full of smaller and bigger bugs as well as horrible hacks. It can be seen whether coders look twice or more at their own stuff before putting it to review or not, just trying to avoid ridicolous comments. It's a whole attitude. I write good code in a messy source base is unlikely to work in practice. That said, I have submitted cleanup commits to open source projects only in the same MR with a real code change I wanted to make and only in vincinity of that change.
nosioptar 1y ago
A typo caused NASA'a Mariner I to fail. https://science.nasa.gov/mission/mariner-1/ https://science.nasa.gov/mission/mariner-1/

Aurornis 1y ago

Rejecting useless or white space-only PRs is quick and easy. It’s not as big of a problem as you’re suggesting. I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.

account42 1y ago
> Rejecting useless or white space-only PRs is quick and easy. No, it really is draining. > I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements. It's frustrating when people make "contributions" that take more effort to review than they put in and then get mad when they don't get thanked for it. This attitude is exactly why dealing with drive by pull requests is not "quick and easy" - suddenly you need to do social and public relations stuff when all you want to do is code.
reconvene1290 1y ago
It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.
- BoredPositron 1y ago
  There are people hunting double spaces or typos in code? For what contributor credits?
  - RyJones 1y ago
    Yes. I have a lot of long, boring stories about exactly this.

jambutters 1y ago

Thousands is quite the exaggeration when there are only 379 on ffmpeg github. If you look through them, its actually 5-10% if not less

picafrost 1y ago
Another way to frame this is that even though the FFmpeg repository clearly indicates it's a mirror repository and has had a single open pull request titled "WARNING: PULL REQUESTS ON THIS REPOSITORY ARE IGNORED" [0] sitting in the pull requests page for 10 years, they've still had to close hundreds of pull requests. [0] https://github.com/FFmpeg/FFmpeg/pull/153 https://github.com/FFmpeg/FFmpeg/pull/153
- mcintyre1994 1y ago
  That’s fair, but it would be trivial to use GitHub’s actions/API (and probably just an existing open source tool in either case) to automatically close them without anyone wasting their time. I think you’re definitely right that being a massive project on GitHub that accepts PRs there would be a nightmare though.

tzury 1y ago

This issue has only worsened with LLMs "assisting" contributors in submitting PRs that end up wasting maintainers' time. Tools like OpenAI Codex, which can connect directly to repositories, are likely to amplify this problem even further. That said, this is also the real measure of the actual value of LLMs and coding agents: the day we see top open-source projects having dozens of bugs effectively fixed per day by LLMs, we’ll know they’ve matured into a solid, reliable resource.

cdrini 1y ago

Is the version on Forgejo closed to public contribution?

pmontra 1y ago

FFmpeg seems to have dealt with that problem when they still were on github. This is the paragraph at the end of the readme: > Contributing > Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process and will be ignored. An agentic LLM bot is likely to have no problems at creating a patch and mailing it but it's a major pain for most human developers. Furthermore they can ban source email addresses and vet potential contributors before letting them in the mailing list.

BlueTemplar 1y ago
Why is it a major pain? Isn't it part of git workflow? Or is this because most developers got complacent in only using GitHub and similar?
- pmontra 1y ago
  Because only a few people used that. The usual workflow I saw before GitHub made PRs popular was: one local repo per developer (or more repo if they wished so), one central shared repo, push a feature branch to the central repo, somebody pulls the branch, reviews the changes and poss the merge them in the preproduction branch, or go back to the developer, some test build deploy procedure, acceptance tests, pass or go back to development, merge in the production branch, test build deploy.
- pm215 1y ago
  (I work on a project that uses an email workflow. "Should we switch to something else?" is a perennial topic.) I think the main pain points are: * unfamiliarity -- if you're not already set up then it's extra admin work. And the "obvious" approach (paste the patch into your usual email client and hit send) generally mangles the patch. * developers are no longer largely using local plain text based email clients -- if you are already doing email that way then sending patches like that is a natural extension. If your email client is gmail, or worse still some Microsoft mail server, now you have to figure out how to send email in a way that's not html and doesn't get mangled by your mail server. * how to set it up is not a single well documented path. Github has an incentive to do a decent tutorial/docs, and how to create an account and send a patch is the same for everyone. Using git send-email, there's a lot more variability: how to install it depends on your OS, and how to configure it to talk to your mail server depends on your mail server. In these days of two factor authentication and app specific passwords, it's no longer as easy as "put the server name and your account name and password into the config file". This has got better in that now you can point people at e.g. https://git-send-email.io/ https://git-send-email.io/ which has info on e.g. setting up gmail app specific passwords and what kind of authentication to use. If you're a regular developer on a project, this is a one-time pain and thereafter sending patches is straightforward (assuming you're not totally allergic to the command line). But for one-off or first time contributions it can be a barrier.

mmmmbbbhb 1y ago

I have to say you're exaggerating, ignoring prs isn't such a chore.

dspillett 1y ago
If you are ignoring all of them. Filtering PRs to see which are worth having might take time in a large popular project. Even if it isn't much time, it is more than zero. You also have to deal with all the other comms associated: people submitting genuinely useful patches which accidentally get rejected querying (maybe politely, maybe not) and people who submitted less useful ones bitching about their rejection, both to the project and in public forums.