In reply to @tomberek:matrix.org

Jonas Chevalier: but we're back to the original problem.... if you want someone to take on the responsibility of making such a decision and driving it, then the desire for such an outcome needs to be clearly stated at the project-level. This is not an isolated thing that a few people can independently decide on, because of the cross-cutting concerns and impacts.

To answer your original question: "who can make the decision whenever we allow unfree packages to be built on Hydra or not?" you have a few options:

1. an individual - not ideal, because making them responsible for fallout would be a poor outcome
2. a team - infra is in the best position to do so (@infinisil: they have the technical permissions to make the changes and fix issues or clean up violations), but are unlikely to make this decision without a decision from elsewhere in the ecosystem.
3. the board - would require making a "direction"-style decision, which they have stated as out of their scope
4. RFC - making the shepherds responsible for fallout is also poor
5. The Nix Teams Representatives group - perhaps the best out of the above options? It's new, but has started to make similar decisions.

on some level, I feel like having a shared understanding of how decisions are made, and increasing that rate, is more important than who is making them (assuming actors with good intent).

I like delroth's idea of just posting: hey, I want to do XYZ, are there any blockers? In that sense, this particular issue could be driven by the CUDA team, as they are interested in having the unfree+redistributable built.

Another idea would be to introduce a bat signal that people can raise when they see a deadlocked issue, and then have a couple of us not making a decision, but triaging who should be making the decision.

In reply to @zimbatm:numtide.com
see https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc :)

In reply to @delroth:delroth.net
really imo this just needs someone willing to start a discourse thread asking for objections, leaving enough time for contributors and active community members to participate, then figure out how to handle the eventual objections - the whole discussion about infra and the foundation are red herrings here, at least from infra we'll figure out how to execute the decision

Maybe we should brainstorm a decision tree process?

A lot of what I'm reading throughout this thread and generally strongly agreeing with seems to end in two areas:

1. Making Decisions
2. Executing on Decisions

One can't go without the other... and each have a high reliance in all avenues on the other.
i.e. Ideally the team/individual making a decision is then also the one to execute. Execution should provide a level of empowerment to make decisions. In my mind == doacracy (the act of doing gives the individual/team the power to decide)

In reply to @delroth:delroth.net
really imo this just needs someone willing to start a discourse thread asking for objections, leaving enough time for contributors and active community members to participate, then figure out how to handle the eventual objections - the whole discussion about infra and the foundation are red herrings here, at least from infra we'll figure out how to execute the decision

(Following a conversation with Jonas Chevalier) The CUDA team might be a candidate to come out with this proposal.

I'll also note that there's an entangled issue of the less controversial ROCm/OpenCL[/Vulkan] functionality also not being tested because it requires special hardware. This concerns both cuda-maintainers and rocm-maintainers, possibly the "geospatial" team and some "unowned" subsystems ("HPC", meaning e.g. slurm and mpi, maintained by single individuals). The issues are similar in that they are about nixpkgs keeping around an amount of untested code of unknown "expiry date", and in that this happens because whether to provision (and pay for) this hardware is a decision to be made by somebody.