Nixpkgs Architecture Team | 232 Members | |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 54 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Jun 2023 | ||
In reply to @k900:0upti.meHonestly, I'm not that happy with how it went. Will write something in the meta-RFC Discourse thread tomorrow or so | 20:08:51 | |
| K900: I mean, it ended up with just bikeshedding over one of the simplest aspects of the RFC, while the meat of the RFC was left without any comments 😅 | 20:09:15 | |
| I mean, I definitely wish it happened earlier | 20:09:31 | |
| Did the FCP work or distract from more important parts? | 20:09:33 | |
| But I think it did work | 20:09:46 | |
| Also, I'd like to have an RFC room even for RFCs from tge Architecture team. Not sure if it makes sense for 140 this late, bit for all the others | 20:09:47 | |
| I don't think it's important whether the issue is "important" or not | 20:10:11 | |
| piegames: Was there a problem with using this room? | 20:10:23 | |
| If people were willing to call off the FCP over it, it's important to them | 20:10:24 | |
In reply to @k900:0upti.meThat's my main complaint, yeah. Having two weeks of almost silence and then on the last day suddenly it explodes | 20:10:41 | |
| Eh I don't think that's a problem, FCP is 10 days, people are busy, you can complain at any time | 20:11:09 | |
| * Eh I don't think that's a problem, FCP is 10 days, people are busy, one can complain at any time | 20:11:34 | |
In reply to @infinisil:matrix.orgsy's insecurity reminded me of this. But also separation of concerns, people might want to follow one topic but not the other | 20:11:49 | |
| Fair enough. I don't think it's a big problem in this specific case since the RFC is the only thing that's been going on for a while | 20:12:42 | |
| Yes. But for the future | 20:13:39 | |
| I guess the future of the NAT is working groups, for which we already create specific separate channels (the only current working group going on is #wg-pkgs-modules:matrix.org) | 20:14:46 | |
| So that works out :) | 20:14:51 | |
| 21:06:58 | ||
| 10 Jun 2023 | ||
In reply to @piegames:matrix.org strictly speaking, my insecurity comes from a place of wanting to respect hierarchy and responsibility. even if there were a separate RFC room, I would have had the same apprehension. personally speaking, I'm still very new to Nix/NixOS and moreover I've never explicitly expressed interest to anyone about wanting to contribute to the shape and structure of the project. I wanted to respect the folks who have already devoted a lot of time thinking about the problem, have devoted a lot of time discussing the problem, and I wanted to respect those who have stood up to be personally named and responsible for solving this problem. additionally, I know that some aspects of this RFC were a little protracted and maybe even a little heated. I also have no interest in contributing to the bikeshedding component in this RFC. I understand that names are often a source of trouble and that a well intentioned decision could lead to unintended consequences which could be difficult to revert or even potentially infeasible to revert so I sympathize with and respect the fact that so much time has been spent on the issue. I don't speak for anyone else when I say this, of course. this is just how I feel and how I feel is not the result of what the Nix/NixOS project has suggested to me in any way. the community has been very kind and welcoming and I respect all of you and I also feel respected. as for whether having separate rooms for discussing separate topics is a good thing, I think it can be. I think it can make discovery of discussion also more difficult. it would probably be useful to have a way to remind folks of ongoing discussions in the main channel as a way of inviting people to join on conversations they care about. case in point: I didn't even know this room existed until I saw the Summer of Nix lecture. one final comment I have on the RFC though, and I'm sorry to repeat my point again, but I do think this RFC has been made more difficult than it should have been because it has been decided that Nixpkgs should work around GitHub's UI/UX issues. I know GitHub is an important tool for the Nix/NixOS community but I do not think that the engineering and design of Nix/NixOS should be subject to arbitrary peculiarities of a UI. | 13:10:35 | |
| * strictly speaking, my insecurity comes from a place of wanting to respect hierarchy and responsibility. even if there were a separate RFC room, I would have had the same apprehension. personally speaking, I'm still very new to Nix/NixOS and moreover I've never explicitly expressed interest to anyone about wanting to contribute to the shape and structure of the project. I wanted to respect the folks who have already devoted a lot of time thinking about the problem, have devoted a lot of time discussing the problem, and I wanted to respect those who have stood up to be personally named and responsible for solving this problem. additionally, I know that some aspects of this RFC were a little protracted and maybe even a little heated. I also have no interest in contributing to the bikeshedding component in this RFC. I understand that names are often a source of trouble and that a well intentioned decision could lead to unintended consequences which could be difficult to revert or even potentially infeasible to revert so I sympathize with and respect the fact that so much time has been spent on the issue. I don't speak for anyone else when I say this, of course. this is just how I feel and how I feel is not the result of what the Nix/NixOS project has suggested to me in any way. the community has been very kind and welcoming and I respect all of you and I also feel respected. as for whether having separate rooms for discussing separate topics is a good thing, I think it can be. I think it can make discovery of discussion also more difficult. it would probably be useful to have a way to remind folks of ongoing discussions in the main channel as a way of inviting people to join on conversations they care about. case in point: I didn't even know this room existed until I saw the Summer of Nix lecture. one final comment I have on the RFC though, and I'm sorry to repeat my point, but I do think this RFC has been made more difficult than it should have been because it has been decided that Nixpkgs should work around GitHub's UI/UX issues. I know GitHub is an important tool for the Nix/NixOS community but I do not think that the engineering and design of Nix/NixOS should be subject to arbitrary peculiarities of a UI. | 13:35:10 | |
| The GitHub limit of 1000 files is admittedly a bit arbitrary, but also a lot of other software handles folders with many items poorly (mostly in terms of performance degradation). Therefore I don't think putting everything into one flat folder would be a good idea, even when putting GitHub aside. | 14:05:27 | |
| Brainstorming some more: What about `unsorted` or `uncategorized`? | 17:35:38 | |
| About `by-name`: to me it invokes the association of `/dev/by-*`, which has the caveat that ours is not a "view" onto the package set and therefore not exhaustive. But in the end it is not worse than unit so idc too much | 17:37:35 | |
In reply to @piegames:matrix.orgWhat about _? :DI mean, it has no intrinsic meaning yet conveys the idea of "we decided to move some packages here" quite well | 17:38:52 | |
_ conveys nothing at best. Normally we only use it for "I don't want to name this because it's not used here" | 19:01:00 | |
un* is slightly better than no information at all, but naming something after what it isn't isn't super helpful | 19:02:33 | |
we could call nixpkgs unsingular | 19:03:51 | |
| 11 Jun 2023 | ||
I'd like to hear if there are any people strongly opposing by-name, especially from those who didn't like unit | 10:08:29 | |
| Also, a meeting might be a good idea | 10:08:38 | |
I don't like unit and don't mind by-name FWIW | 10:09:18 | |