3 ms·

That's obviously fine for you to do but it's worth noting that we remove software that no-one uses where "no-one" is defined by "no-one using analytics". That's

That's obviously fine for you to do but it's worth noting that we remove software that no-one uses where "no-one" is defined by "no-one using analytics". That's actually our main use-case for analytics.

bm5k 10y ago
Still not a good enough reason for analytics to be opt-out.
falcolas 10y ago
> we remove software Why? Personally, the only reason I would remove software from a repository is if it didn't work, impacted performance, or cost me an unreasonable amount of money/time. There's a really long tail for software packages.
- mikemcquaid 10y ago
  In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.
  - heuermh 10y ago
    Are the usage analytics available to package maintainers? What about in downstream taps such as Homebrew-Versions and Homebrew-Science? Would be nice to know when it comes to grant writing time.
    - mikemcquaid 10y ago
      We can make them available on request. Email me.
  - a-no-n 10y ago
    How did the "royal we" arrive at this "reasoning?" If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but-really-fucking-important packages. Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which has matured to the point stability; there's zero functional value added in refactored code being "new." Ongoing support, adding features and keeping pace with platform compatibility are separate issues from judging code to be "inferior" despite working because it's "old." What may seem "dead" to people whom don't know about particular packages but may well just be stable and resting very quietly because it just works.
    - mikemcquaid 10y ago
      If projects are portable and continue to work without patching indefinitely: we don't consider them dead. What we're unwilling to do is to apply patch after patch to unmaintained and undeveloped projects to keep them working on macOS; at that point we're forking the project and lack either the desire nor people power to do so.
davexunit 10y ago
Opt-out tracking is unjustifiable no matter how convenient it may be for the developer.
tedmiston 10y ago
You could do that with anonymous stats instead of tracking an advertising ID to each user.
kawsper 10y ago
Couldn't you just look at the download numbers instead?
- mikemcquaid 10y ago
  We don't host any non-binary downloads so: no.

bm5k 10y ago

Still not a good enough reason for analytics to be opt-out.

falcolas 10y ago

> we remove software Why? Personally, the only reason I would remove software from a repository is if it didn't work, impacted performance, or cost me an unreasonable amount of money/time. There's a really long tail for software packages.

mikemcquaid 10y ago
In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.
- heuermh 10y ago
  Are the usage analytics available to package maintainers? What about in downstream taps such as Homebrew-Versions and Homebrew-Science? Would be nice to know when it comes to grant writing time.
  - mikemcquaid 10y ago
    We can make them available on request. Email me.
- a-no-n 10y ago
  How did the "royal we" arrive at this "reasoning?" If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but-really-fucking-important packages. Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which has matured to the point stability; there's zero functional value added in refactored code being "new." Ongoing support, adding features and keeping pace with platform compatibility are separate issues from judging code to be "inferior" despite working because it's "old." What may seem "dead" to people whom don't know about particular packages but may well just be stable and resting very quietly because it just works.
  - mikemcquaid 10y ago
    If projects are portable and continue to work without patching indefinitely: we don't consider them dead. What we're unwilling to do is to apply patch after patch to unmaintained and undeveloped projects to keep them working on macOS; at that point we're forking the project and lack either the desire nor people power to do so.

davexunit 10y ago

Opt-out tracking is unjustifiable no matter how convenient it may be for the developer.

tedmiston 10y ago

You could do that with anonymous stats instead of tracking an advertising ID to each user.

kawsper 10y ago

Couldn't you just look at the download numbers instead?

mikemcquaid 10y ago
We don't host any non-binary downloads so: no.