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.

In reply to @delroth:delroth.net
(to be clear, I'm not saying the status quo is optimal, I'm saying that maybe it's a separate issue and not something entangled to whether we distribute CUDA / ROCm / ... stuff)

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

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