| 15 Jul 2024 |
 willbush | I was trying to try to help out in the nix.dev repo by going through old issues and seeing if any can be closed or easily fixed. Should I ping someone from the issue if I think it can be closed or just leave a comment or something? | 00:23:44 |
| willbush | Redacted or Malformed Event | 01:38:24 |
| willbush | * I was thinking to try to help out in the nix.dev repo by going through old issues and seeing if any can be closed or easily fixed. Should I ping someone from the issue if I think it can be closed or just leave a comment or something? | 02:14:13 |
| willbush | Download issues.md | 05:58:11 |
| willbush | I commented on some issues. Here's a list of what I went through:
| 05:58:14 |
 fricklerhandwerk | In reply to @willbush:matrix.org
I was thinking to try to help out in the nix.dev repo by going through old issues and seeing if any can be closed or easily fixed. Should I ping someone from the issue if I think it can be closed or just leave a comment or something? Hey, thanks for taking the tour! This stuff is very helpful. It’s best to comment on the issue though. Everyone can see it there and follow up. And for me personally it’s easiest to handle because I get notifications and can take it from there. | 06:05:55 |
|  @drupol:matrix.org left the room. | 17:39:40 |
| 16 Jul 2024 |
|  @alex3829:matrix.org left the room. | 23:17:06 |
| 23 Jul 2024 |
|  Ezzobir Bezziou joined the room. | 08:22:40 |
| 24 Jul 2024 |
|  R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝ changed their display name from redstone-menace to Redstone. | 10:14:59 |
| 26 Jul 2024 |
|  shivaraj-bh set a profile picture. | 06:40:20 |
 Philip Taron (UTC-8) | Hey folks -- I'd like to make the NixOS manual and the Nixpkgs manual be exposed in pkgs as a normal package. I made some initial work in this draft PR https://github.com/NixOS/nixpkgs/pull/311459 and got positive feedback from Johannes Kirschbauer @hsjobeki. I'm planning on picking it up again today and driving for completion.
Any objections or redirections before I do that?>
| 16:59:40 |
| Philip Taron (UTC-8) | * Hey folks -- I'd like to make the NixOS manual and the Nixpkgs manual be exposed in pkgs as a normal package. I made some initial work in this draft PR https://github.com/NixOS/nixpkgs/pull/311459 and got positive feedback from Johannes Kirschbauer @hsjobeki. I'm planning on picking it up again today and driving for completion.
Any objections or redirections before I do that?
| 16:59:42 |
| fricklerhandwerk | In reply to @philiptaron:matrix.org
Hey folks -- I'd like to make the NixOS manual and the Nixpkgs manual be exposed in pkgs as a normal package. I made some initial work in this draft PR https://github.com/NixOS/nixpkgs/pull/311459 and got positive feedback from Johannes Kirschbauer @hsjobeki. I'm planning on picking it up again today and driving for completion.
Any objections or redirections before I do that?
Great stuff, thanks a lot! | 17:07:06 |
 Sandro | Will this trigger one rebuild for every PR touching modules in any way? | 17:07:55 |
| Philip Taron (UTC-8) | Only if the documentation changes, I think. | 17:10:16 |
| Philip Taron (UTC-8) | * Only if the documentation changes, I think. But I don't know. | 17:10:31 |
| Philip Taron (UTC-8) | fricklerhandwerk: regarding your comment, note that doc/default.nix and doc/shell.nix remain: the guts of how they're implemented move over. | 17:11:14 |
| Philip Taron (UTC-8) | I think that's the way it ought to be. | 17:11:25 |
| Sandro | like nixos-install-tools and tests.nixos-functions.nixos-test already do | 17:11:45 |
| fricklerhandwerk | In reply to @philiptaron:matrix.org
fricklerhandwerk: regarding your comment, note that doc/default.nix and doc/shell.nix remain: the guts of how they're implemented move over. I understand, and splitting that into two parts doesn't make much sense to me. I suggest not breaking locality | 17:12:10 |
| Philip Taron (UTC-8) | Hmmm, I really liked how doc/ was now the actual documentation and there wasn't what I considered to be an awkward doc-support directory that wasn't documentation. But I'll take your feedback. | 17:14:31 |
| fricklerhandwerk | In reply to @philiptaron:matrix.org
Hmmm, I really liked how doc/ was now the actual documentation and there wasn't what I considered to be an awkward doc-support directory that wasn't documentation. But I'll take your feedback. I understand, but arguably none of that content should actually live in there, and instead be right in or next to the code it's documenting | 17:18:56 |
| fricklerhandwerk | And also the glue code is hardly separable from the content structure that it helps produce | 17:19:24 |
| fricklerhandwerk | In reply to @philiptaron:matrix.org
Hmmm, I really liked how doc/ was now the actual documentation and there wasn't what I considered to be an awkward doc-support directory that wasn't documentation. But I'll take your feedback. * I understand, but arguably most of that content should actually live in there, and instead be right in or next to the code it's documenting | 17:19:39 |
| fricklerhandwerk | * I understand, but arguably barely any of that content should actually live in there, and instead be right in or next to the code it's documenting | 17:19:47 |
 @johannes.kirschbauer:scs.ems.host | Yeah good work appreciate it.
I also agree to the locality point of fricklerhandwerk | 17:22:47 |
| @johannes.kirschbauer:scs.ems.host | But also could be another PR | 17:22:59 |
| fricklerhandwerk | In reply to @johannes.kirschbauer:scs.ems.host
But also could be another PR Sure, moving around lots of stuff is a completely different thing. I'm just saying let's leave everything there, but make the package more conventional | 17:24:21 |
| Philip Taron (UTC-8) | In reply to @fricklerhandwerk:matrix.org
And also the glue code is hardly separable from the content structure that it helps produce I think I have the opposite intuition -- most of nixpkgs is code to orchestrate builds that is separated from the origin (i.e. upstream.) So when there's orchestration of builds within nixpkgs, my intuition is that separating it is normal and expected.
Since nixpkgs building on nixpkgs is a rare occurrence (mostly maintainers/, doc/, and nixos/) I doubt there's a pattern to it.
I'll follow your guidance, though.
| 17:26:42 |
