3 ms·

Anyone who's paying attention will update the readme in the stale fork to make it really obvious. People don't sometimes because they're lazy, but this is an ap

Anyone who's paying attention will update the readme in the stale fork to make it really obvious. People don't sometimes because they're lazy, but this is an application of the more general "people suck" rule, and not very specific to Github.

zedshaw 16y ago
Oh, in the README? Duh. I totally didn't think of that awesome way to communicate to all the package management build systems out there that the repository has moved. I'll get right on building the Turing Oracle so I can solve that "README File English As Redirect" problem.
- pyre 16y ago
  Right, because package management build systems have obsoleted the need to package managers to be actual people that keep track of the packages that they manage...
  - bradleyland 16y ago
    It's not a "people" issue. How does one discern the canonical source of a package on GitHub? Take GitX as an example: The "top parent" project: https://github.com/pieter/gitx https://github.com/pieter/gitx Andre Berg's fork: https://github.com/andreberg/gitx https://github.com/andreberg/gitx The Brotherbard fork: https://github.com/brotherbard/gitx https://github.com/brotherbard/gitx Which is "the project"? The answer is all of them AND none of them. That's the nature of GitHub. Zed's point is that for a sysadmin, all this obscurity is unacceptable. Having a canonical source for a package is important. That source should obscure away who the actors are making the package happen. If Pieter wants to hand the project off to Andre, who in turn hands it off to Nathan, that's great, but the sysadmin doesn't really want to track that for every package he/she installs on their server. That is why launchpad is better for sysadmins. Not because it is better in any general sense. Just because it meets a different set of needs. These are not criticisms of GitHub, these are statements of the reality. The closest thing GitHub has to a "project" abstraction is the organization: https://github.com/blog/674-introducing-organizations https://github.com/blog/674-introducing-organizations One could, conceivably, create an organization to manage a project's code, but that doesn't address all of the other package ecosystems that Launchpad executes more deftly.
    - pyre 16y ago
      I was responding to Zed complaining about automatic build systems knowing where to pull their sources/builds from.

zedshaw 16y ago

Oh, in the README? Duh. I totally didn't think of that awesome way to communicate to all the package management build systems out there that the repository has moved. I'll get right on building the Turing Oracle so I can solve that "README File English As Redirect" problem.

pyre 16y ago
Right, because package management build systems have obsoleted the need to package managers to be actual people that keep track of the packages that they manage...
- bradleyland 16y ago
  It's not a "people" issue. How does one discern the canonical source of a package on GitHub? Take GitX as an example: The "top parent" project: https://github.com/pieter/gitx https://github.com/pieter/gitx Andre Berg's fork: https://github.com/andreberg/gitx https://github.com/andreberg/gitx The Brotherbard fork: https://github.com/brotherbard/gitx https://github.com/brotherbard/gitx Which is "the project"? The answer is all of them AND none of them. That's the nature of GitHub. Zed's point is that for a sysadmin, all this obscurity is unacceptable. Having a canonical source for a package is important. That source should obscure away who the actors are making the package happen. If Pieter wants to hand the project off to Andre, who in turn hands it off to Nathan, that's great, but the sysadmin doesn't really want to track that for every package he/she installs on their server. That is why launchpad is better for sysadmins. Not because it is better in any general sense. Just because it meets a different set of needs. These are not criticisms of GitHub, these are statements of the reality. The closest thing GitHub has to a "project" abstraction is the organization: https://github.com/blog/674-introducing-organizations https://github.com/blog/674-introducing-organizations One could, conceivably, create an organization to manage a project's code, but that doesn't address all of the other package ecosystems that Launchpad executes more deftly.
  - pyre 16y ago
    I was responding to Zed complaining about automatic build systems knowing where to pull their sources/builds from.