Sender | Message | Time |
---|---|---|
21 Feb 2024 | ||
(which interestingly is not an option you've listed? it seems obvious to me, but it's interesting to notice that it's not even being considered in those discussions) | 22:33:52 | |
voting is often a contentious matter because people cannot agree (or we don't even try?) to agree to a constitutency | 22:34:13 | |
* voting is often a contentious matter because people cannot agree (or we don't even try?) to agree to a constituency | 22:34:25 | |
(not saying this is impossible, just rehashing some of the objections that often come up with the 'let's vote on X') | 22:34:40 | |
you don't need to vote to elect a constituency, you can vote on decisions directly | 22:34:46 | |
i meant the set of people who can vote, the constituency, is unclear to bootstrap | 22:35:09 | |
and selecting committers/maintainers/everyone seems arbitrary (?) | 22:35:22 | |
it's fair to say that we should add 0. vote .... but even if you vote, it doesn't assign a single person to get it done. There are several popular proposals, PRs, issues, RFCs, that "have the vote" but are not getting done. | 22:37:00 | |
In reply to @tomberek:matrix.orgI think in this topic ^ interestingly, we could have a "vote among nix team representatives", announce there would be a vote and let everyone who doesn't feel represented by the announced participants to join, this is obviously incomplete for many reasons and the vote could be thrown away, but this would provide a first step towards trying to use a vote mechanism | 22:38:05 | |
Always remember authority/responsibility. If you give too wide a group the authority/vote for a decision, you then need a way to give them responsibility to implement it was well..... quite hard when the vote is too wide. | 22:38:28 | |
Nixpkgs has done this to some extent. | 22:38:42 | |
Another approach: you vote for the prioritization of a policy, and another vote for people to execute those policies. This is starts to be much more complicated. (see the considerations above by others) | 22:44:45 | |
tbf I think that if we have a good process for having consensus on the direction / decisions, having a process for finding someone to execute seems less important | 22:46:10 | |
first of all because I expect people will organically show up if the decision is made and has consensus, second because it's open source and unless you pay people for contract work you can't really make them execute stuff anyway | 22:46:43 | |
22 Feb 2024 | ||
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. | 10:29:36 | |
I think I like the idea of a bat signal. I was wondering, given the size of everything, who is keeping a list of all the deadlocked issues? | 12:15:50 | |
see https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc :) | 16:08:16 | |
In reply to @zimbatm:numtide.comoh yes, that is a nice list. Very pragmatic approach to making it too! | 16:43:51 | |
In reply to @delroth:delroth.netSorry just catching up. Wanted to ++ on this item | 17:32:21 | |
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:
One can't go without the other... and each have a high reliance in all avenues on the other. | 17:34:46 | |
Total example one without a lot of thought behind but might be a good exercise to brainstorm on: | 17:41:39 | |
Download 1000051542.jpg | 17:42:07 | |
(sorry for lack of proper rotation or artistic capabilities) | 17:42:54 | |
23 Feb 2024 | ||
In reply to @delroth:delroth.net (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. | 13:23:01 | |
I don't really understand what makes this different from many, many other packages in nixpkgs that require specific hardware to test and use. | 13:26:21 | |
Do we have similarly complicated package set with specific hardware needs without any simulator? (genuine question) | 13:27:01 | |
For example, hostapd can be tested in NixOS tests via 80211 hw simulators | 13:27:12 | |
not sure, but you're raising the bar significantly above the usual maintenance level of a nixpkgs package | 13:27:45 | |
that's fair | 13:27:54 | |
a good example would be home-assistant | 13:28:02 |