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

So concretely, if you find enough people to make a decent initiative appear very harmful, everything just stalls.

If a noticeable group of people who won't be dismissed as not having much of the demonstrated commitment to the project is willing to claim the change is very harmful, I find stalling a feature (possibly unstalling later if a majority of the group withdraws under a better explanation!)

For smaller things, I would much prefer for people to write up their vision, submit it for approval/rejection, than going trough that grueling process.

We have «Develop» category on Discourse and we do sometimes link Discourse discussions in PRs. I agree this is a better way for things that do not try to establsh norms for everyone and don't meet strong opposition.

If there is a disagreement, well, there is a reason design by committee happens again and again, it is actually best of the achievable for the goal of preserving unity

In reply to @zimbatm:numtide.com
What do you think if the CUDA team wrote a Nix Improvement Proposal (just made up that name), which is like a RFC in terms of structure, but just posted to Discourse? This could be a trial run for something more liteweight than the RFC process.

This would be a trial run similar to what happened for the wiki on the foundation repo, but posted more widely

In reply to @delroth:delroth.net
(By the way, the irony is not lost on me that this is, literally, a "request for comments". Except without the baggage that comes attached with the Nix* RFC process and the tacit expectation of producing a formal document proposing a design and implementation.)