3 ms·

They are using GitHub for their intended purpose, hosting their code. That is perfectly fine. What is not perfectly fine is using GitHub as your package host,

They are using GitHub for their intended purpose, hosting their code. That is perfectly fine. What is not perfectly fine is using GitHub as your package host, CocoaPods/Specs is the equivalent of Debians APT using one big GitHub repo to host all their packages. It has 92567 commits and 6872 contributors.

masklinn 11y ago
OTOH Homebrew also uses github as its package host and has a respectable 62000 commits and 5600 contributors and github seems to be just fine with it. The big differences seems to be in the way they do their thing: I'm reasonably sure homebrew just git clones then updates the local repository normally[0], it has "only" 2500 files in Library/Formula, and because of its different subject it is way less write-active, CocoaPod has 1k commits/week which look to be increasing pretty much constantly, homebrew is around 350 with ups and downs. Also not sure it matters, but homebrew has lots of commits updating existing formula, cocoapod changes are almost solely addition (publishing a new version of a package adds a new spec and doesn't touch the old one) [0] which is exactly the bread and butter of github
- D4AHNGM 11y ago
  Thankfully, none of Homebrew's binaries are stored on GitHub. Most of the changes committed to Homebrew are formulae-based; of the ~5600 contributors in Homebrew's lifetime only ~430 have contributed to the core code.
  - masklinn 11y ago
    cocoapod's binaries are not stored in the problematic specs repository, cocoapods/specs only stores the equivalent of homebrew formulas (podspecs).
- plorkyeran 11y ago
  The fact that Github added an API specifically to reduce the server load from Homebrew suggests that it wasn't "just fine". One of the Homebrew maintainers works for GH so they just had a much more direct route to solving the problem than with CocoaPods.
  - mikemcquaid 11y ago
    In this case it's actually more that there's a Homebrew maintainer who works for GitHub (me) who has been working on a bunch of improvements to Homebrew's update system (in my spare time). The desire for the API came from Homebrew's side rather than GitHub's and, as it reduces load for GitHub, it was a net win for both parties.

masklinn 11y ago

OTOH Homebrew also uses github as its package host and has a respectable 62000 commits and 5600 contributors and github seems to be just fine with it. The big differences seems to be in the way they do their thing: I'm reasonably sure homebrew just git clones then updates the local repository normally[0], it has "only" 2500 files in Library/Formula, and because of its different subject it is way less write-active, CocoaPod has 1k commits/week which look to be increasing pretty much constantly, homebrew is around 350 with ups and downs. Also not sure it matters, but homebrew has lots of commits updating existing formula, cocoapod changes are almost solely addition (publishing a new version of a package adds a new spec and doesn't touch the old one) [0] which is exactly the bread and butter of github

D4AHNGM 11y ago
Thankfully, none of Homebrew's binaries are stored on GitHub. Most of the changes committed to Homebrew are formulae-based; of the ~5600 contributors in Homebrew's lifetime only ~430 have contributed to the core code.
- masklinn 11y ago
  cocoapod's binaries are not stored in the problematic specs repository, cocoapods/specs only stores the equivalent of homebrew formulas (podspecs).
plorkyeran 11y ago
The fact that Github added an API specifically to reduce the server load from Homebrew suggests that it wasn't "just fine". One of the Homebrew maintainers works for GH so they just had a much more direct route to solving the problem than with CocoaPods.
- mikemcquaid 11y ago
  In this case it's actually more that there's a Homebrew maintainer who works for GitHub (me) who has been working on a bunch of improvements to Homebrew's update system (in my spare time). The desire for the API came from Homebrew's side rather than GitHub's and, as it reduces load for GitHub, it was a net win for both parties.