5 ms·

I support this fully and I'm very disappointed that the maintainers of these projects are hesitant to adopting it, many citing that they'd be interested only if

I support this fully and I'm very disappointed that the maintainers of these projects are hesitant to adopting it, many citing that they'd be interested only if other major players adopt it first. Cmon, it's such a minor change. Getting these PR's in means _you are_ a major player (atleast to some) and you might be able to drive change in a positive way. Why not jump on the opportunity?

HappyTypist 5y ago
Let's add some competitive pressure: start forking projects that don't support it.
- chrisseaton 5y ago
  Have you got the time, expertise, and network to maintain Homebrew?
  - renewiltord 5y ago
    Considering the Homebrew PR they are so eager to merge was untested and won’t work according to the maintainer, I have some hypotheses.
    - dpcx 5y ago
      Looking at the code I can't see why it wouldn't work. It's an extra || condition. Can someone enlighten me?
      - arp242 5y ago
        The maintainer just stated it without further explanation. Searching for "HOMEBREW_NO_ANALYTICS" does reveal some other references[1], and it seems that there are some other places where this may need to be added such as "Library/Homebrew/env_config.rb", but I don't know anything about homebrew. I do think it's very much a minimal-effort PR. It's hardly a PR at all: at the very least the tests and documentation should have been updated, and actually writing out some more rationale would help as well. I certainly wouldn't send a PR like this, at least not without the text "this is a proposal, and if accepted I will update the tests and documentation as well". [1]: https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYTICS https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYT...
      - xyst 5y ago
        Probably the homebrew maintainers have hard coded usage of “HOMEBREW_NO_ANALYTICS”. The PR likely only fixes one instance. Lack of unit tests in PR support this hypothesis. Could be wrong though and the maintainer simply needed a vague excuse to not merge it. Haven’t completed a deep dive. I couldn’t be bothered to compare repository at the time of PR 2 yrs ago on mobile.
noname120 5y ago
This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-554317746 https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...
- Hackbraten 5y ago
  Also: https://github.com/Homebrew/brew/pull/6745#issuecomment-554526607 https://github.com/Homebrew/brew/pull/6745#issuecomment-5545...
- _jal 5y ago
  "You're not important. We might do this if you were someone who mattered." Sad to see such, ah, well-socialized people in open in source projects.
- soraminazuki 5y ago
  From the link: > I would rather see the different packager managers sit together and work on that standard. And especially big players should get involved, like the debian/ubuntu apt people, the fedora people, the nixpkg people, pip, node and all the others. It’s almost as if any of the mentioned package managers has opt-out tracking code embedded in their CLIs.
  - wizzwizz4 5y ago
    To be fair, Debian has popularity-contest. (You have to install the package manually – or via a prompt in the installer; if you don't, you don't even have the tracking code on your system.)
    - kgwxd 5y ago
      THIS is the way telemetry should be. A completely separate opt-in only add-on. I don't trust flags, I've accidentally forgotten to check them myself countless time.
- vultour 5y ago
  The best part of that discussion is how one Homebrew maintainer says "I'd like to see package managers implement this first", and when someone from Arch goes "we don't track at all" the big chief comes in and says "Run your package manager how you want/need and we'll do the same.". The guy also seems quite rude for someone with "Rude people blocker" in his bio.
chrisseaton 5y ago
These PRs are like bad dating app messages - they get threatening so quickly when the author is rejected.
Igelau 5y ago
Two reasons: 1) It's not a standard at all. Some guy made a webpage and used the word "we". Even in the GitHub issues there was debate about what having this variable set would mean (e.g. should a call to a formatting service be blocked). 2) One maintainer pointed out that being an early adopter would force them into advocacy that they aren't prepared to do. Judging from how argumentative Sneak was being, there's probably an element of "we don't want to be the vanguard for this bully and his variable"

HappyTypist 5y ago

Let's add some competitive pressure: start forking projects that don't support it.

chrisseaton 5y ago
Have you got the time, expertise, and network to maintain Homebrew?
- renewiltord 5y ago
  Considering the Homebrew PR they are so eager to merge was untested and won’t work according to the maintainer, I have some hypotheses.
  - dpcx 5y ago
    Looking at the code I can't see why it wouldn't work. It's an extra || condition. Can someone enlighten me?
    - arp242 5y ago
      The maintainer just stated it without further explanation. Searching for "HOMEBREW_NO_ANALYTICS" does reveal some other references[1], and it seems that there are some other places where this may need to be added such as "Library/Homebrew/env_config.rb", but I don't know anything about homebrew. I do think it's very much a minimal-effort PR. It's hardly a PR at all: at the very least the tests and documentation should have been updated, and actually writing out some more rationale would help as well. I certainly wouldn't send a PR like this, at least not without the text "this is a proposal, and if accepted I will update the tests and documentation as well". [1]: https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYTICS https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYT...
    - xyst 5y ago
      Probably the homebrew maintainers have hard coded usage of “HOMEBREW_NO_ANALYTICS”. The PR likely only fixes one instance. Lack of unit tests in PR support this hypothesis. Could be wrong though and the maintainer simply needed a vague excuse to not merge it. Haven’t completed a deep dive. I couldn’t be bothered to compare repository at the time of PR 2 yrs ago on mobile.

noname120 5y ago

This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-554317746 https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...

Hackbraten 5y ago
Also: https://github.com/Homebrew/brew/pull/6745#issuecomment-554526607 https://github.com/Homebrew/brew/pull/6745#issuecomment-5545...
_jal 5y ago
"You're not important. We might do this if you were someone who mattered." Sad to see such, ah, well-socialized people in open in source projects.
soraminazuki 5y ago
From the link: > I would rather see the different packager managers sit together and work on that standard. And especially big players should get involved, like the debian/ubuntu apt people, the fedora people, the nixpkg people, pip, node and all the others. It’s almost as if any of the mentioned package managers has opt-out tracking code embedded in their CLIs.
- wizzwizz4 5y ago
  To be fair, Debian has popularity-contest. (You have to install the package manually – or via a prompt in the installer; if you don't, you don't even have the tracking code on your system.)
  - kgwxd 5y ago
    THIS is the way telemetry should be. A completely separate opt-in only add-on. I don't trust flags, I've accidentally forgotten to check them myself countless time.
vultour 5y ago
The best part of that discussion is how one Homebrew maintainer says "I'd like to see package managers implement this first", and when someone from Arch goes "we don't track at all" the big chief comes in and says "Run your package manager how you want/need and we'll do the same.". The guy also seems quite rude for someone with "Rude people blocker" in his bio.

chrisseaton 5y ago

These PRs are like bad dating app messages - they get threatening so quickly when the author is rejected.

Igelau 5y ago

Two reasons: 1) It's not a standard at all. Some guy made a webpage and used the word "we". Even in the GitHub issues there was debate about what having this variable set would mean (e.g. should a call to a formatting service be blocked). 2) One maintainer pointed out that being an early adopter would force them into advocacy that they aren't prepared to do. Judging from how argumentative Sneak was being, there's probably an element of "we don't want to be the vanguard for this bully and his variable"