4 ms·

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 b

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.
Aurornis 1y ago
The paragraph at the end of the README was letting people know that the GitHub PRs are unmonitored, not suggesting it was a problem.

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.

Aurornis 1y ago

The paragraph at the end of the README was letting people know that the GitHub PRs are unmonitored, not suggesting it was a problem.