Nix Documentation | 422 Members | |
| Discussion about documentation improvements around the Nix ecosystem | 87 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Dec 2023 | ||
| Oh, I just ran into this today: https://github.com/NixOS/nix/issues/7981 | 10:20:05 | |
| So, that's something I definitely can do. | 10:20:21 | |
| Or...should I just re-write the nix-build CLI? 🤔 | 10:20:46 | |
In reply to @bzzm3r:matrix.orgThat's a good one, it should be fairly limited in scope. | 12:12:35 | |
In reply to @bzzm3r:matrix.orgPlease don't do that to yourself | 12:13:03 | |
In reply to @bzzm3r:matrix.org It is meant to be used, but given the very limited amount of time we have, we usually prioritise group reviews to get things merged that have happened in between meetings. We should probably have a formalised meeting agenda that gives the board a couple of minutes of attention. | 12:16:54 | |
| One practical problem I've observed in the Nix maintainer team, where we have a very formalised meeting structure and in fact curate the board very nicely, is that the process nudges us to delegate tasks we don't actually have time to follow through with. So the tail end of the pipeline is broken due to limited capacity and the challenges to estimate workload. The front end works fairly well though, because we do triaging to determine whether something fits current priorities and direction, or make design decisions to help produce sustainable solutions. Some contributors follow up, many don't, due to lack of time to actually finish tasks that very often blow up in size once you take a close look at them. We have the exact same problem in documentation, except we stopped assigning tasks as we were all fully booked at some point. And since contributions tend to be either very small or very large, triaging doesn't seem to serve much of a purpose. We should probably try to find some middle ground, to really get an up-to-date grasp on who's currently working on what, how complex a given task is (and which rabbit holes it uncovers), which resources are available to finish it, etc. -- simply to know what to focus the effort on getting over the finish line. | 12:24:50 | |
| * One practical problem I've observed in the Nix maintainer team, where we have a very formalised meeting structure and in fact curate the board very nicely, is that the process nudges us to delegate tasks we don't actually have time to follow through with. So the tail end of the pipeline is broken due to limited capacity and the challenges to estimate workload. The front end works fairly well though, because we do triaging to determine whether something fits current priorities and direction, or make design decisions to help produce sustainable solutions. Some contributors follow up, many don't, due to lack of time to actually finish tasks that very often blow up in size once you take a close look at them. We have the exact same problem in documentation, except we stopped assigning tasks as we were all fully booked at some point. And since contributions tend to be either very small or very large, triaging doesn't seem to serve much of a purpose. We should probably try to find some middle ground, to really get an up-to-date grasp on who's currently working on what, how complex a given task is (and which rabbit holes it uncovers), which resources are available to finish it, etc. -- simply to know what to focus the effort on to get it over the finish line. | 12:25:09 | |
| And then aggressively push to finish whatever was started and is still in active progress... | 12:26:38 | |
In reply to @fricklerhandwerk:matrix.orgcould a relatively simple solution be using tags which assign priorities as guesses (we can't know the true priority)? | 18:39:46 | |
In reply to @fricklerhandwerk:matrix.org* could a relatively simple solution be using github tags which assign priorities as guesses (we can't know the true priority)? | 18:39:55 | |
| I often see the "hit 👍️ to mark as a priority" | 18:40:16 | |
| but...no one's actually hitting that 🫠 | 18:40:32 | |
In reply to @fricklerhandwerk:matrix.orgYes, I think this would be helpful. Especially as we do encourage people to make issues | 18:43:36 | |
| a lot happens through the weekly meeting 😮💨 which is only fair | 18:44:39 | |
| 19 Dec 2023 | ||
In reply to @bzzm3r:matrix.orgyou know you can nix build -f . someAttr on non flakes yeah? | 00:04:04 | |
In reply to @jade_:matrix.orgYeah, I just don't like the nix3 cli. | 03:15:47 | |
| usability or personal? | 03:35:33 | |
| does anyone know how to run the individual phases in the nix.dev repo? i tried:
but it doesn't work, and | 13:56:14 | |
asymmetric: phases=buildPhase genericBuild should work | 14:22:18 | |
| asymmetric: See also https://nixos.org/manual/nixpkgs/stable/#sec-building-stdenv-package-in-nix-shell | 14:22:45 | |
| Ah I see you also commented in https://discourse.nixos.org/t/nix-build-phases-run-nix-build-phases-interactively/36090, which I also wanted to link :) | 14:23:46 | |
| fricklerhandwerk: can you help me understand the redirects file? so for example, here i see a redirect, but if i try to go to the redirected url, it 404s. the same doesn't happen with for exapmle this line | 15:57:28 | |
| * fricklerhandwerk: can you help me understand the redirects file? so for example, here i see a redirect, but if i try to go to the redirected url, it 404s. the same doesn't happen with for exapmle this line, which redirects correctly | 15:57:48 | |
| * fricklerhandwerk: can you help me understand the redirects file? so for example, here i see a redirect, but if i try to go to the redirected url, it 404s. the same doesn't happen with for exapmle this line, which redirects correctly | 15:58:26 | |
Download redirect.png | 15:59:20 | |
oic, it needs an extrension, /package-management/basic-package-management.html | 16:02:13 | |
it's a bit confusing, since the web server won't provide the redirect without the .html, but the netlify syntax doesn't require one | 16:03:26 | |
* it's a bit confusing, since the redirect won't work without the .html, but the netlify syntax doesn't require one | 16:05:46 | |
So basically, a url like https://nixos.org/manual/nix/stable/package-management/basic-package-mgmt will not redirect correctly, it has to have a .html at the end. is this known behavior? Or are there urls like this one that are now link-rotting? | 16:20:42 | |