This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/devenv-1-4-generating-nix-developer-environments-using-ai/60235/2

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5207

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2250

Hey @GaetanLepage why was this merged without my consent? I'm the maintainer of the package and this doesn't allow the users to allow telemetry data to be processed, which is the only way we can improve the generation.

❯ git grep DO_NOT_TRACK
nixos/modules/services/misc/open-webui.nix:          DO_NOT_TRACK = "True";
nixos/modules/services/monitoring/netdata.nix:        DO_NOT_TRACK = "1";

I see only two NixOS modules setting this, not even at the package level. I'm not sure this is "with a proven history".

I'm against this change since those people that don't care won't ever enable it and we won't be able to improve making it easier to generate devenvs.

That's why do not track standard exists, that those that don't want to participate can enable it globally.

I've reverted it in #381981

❯ git grep DO_NOT_TRACK
nixos/modules/services/misc/open-webui.nix:          DO_NOT_TRACK = "True";
nixos/modules/services/monitoring/netdata.nix:        DO_NOT_TRACK = "1";

I see only two NixOS modules setting this, not even at the package level. I'm not sure this is "with a proven history".

That is an oversimplification. Packages manage telemetry in different ways and hence enabling, disabling it is handled in different ways.

I'm against this change since those people that don't care won't ever enable it and we won't be able to improve making it easier to generate devenvs.

While this is true, it's also an invalid argument in my opinion. You may ship telemetry as an upstream project, but you are not the steward of nixpkgs and the purpose of nixpkgs is not to foster your commercial interest.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/should-commercial-actors-ship-telemetry-in-nixpkgs/60279/1

Hey @GaetanLepage why was this merged without my consent? I'm the maintainer of the package and this doesn't allow the users to allow telemetry data to be processed, which is the only way we can improve the generation.

Sorry @domenkozar. This was indeed a mistake on my part. I thought that the change made sense for the nixpkgs repo. The correct thing would have been to wait for your approval.
Feel free to revert this commit.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/should-commercial-actors-ship-telemetry-in-nixpkgs/60279/11

+1 on allowing the maintainer(s) time to review a PR (excluding cases where maintainers are unavailable for extended periods or it's a critical vuln fix). In an open-source community being a maintainer doesn't mean being the boss or having sole ownership of the package but you are putting your time on the line to keep a thing working. It's not particularly fun to have a package you look after change without the courtesy of getting a bit of time to look at the change and weigh in.
Looks like that's happily resolved/addressed in this case 🚀

but also

+1 to being an opt-in prefer-er and to discussing the topic further in discourse

(maybe similar to the first point we could discuss in a topic some kind of SLA/SLO for maintainer review opportunity before getting to merge a change or adopt a package)

we could discuss in a topic some kind of SLA/SLO for maintainer review opportunity before getting to merge a change

It is already in the doc:

We also allow other non-maintainer committers to merge changes to the package,
provided enough time and priority has been given to the maintainer.

For most packages, we expect committers to wait at least a week before merging
changes not endorsed by a package maintainer (which may be themselves). This should leave enough time
for the maintainers to provide feedback.