!UNVBThoJtlIiVwiDjU:nixos.org

Staging

396 Members
Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/128 Servers

Load older messages

SenderMessageTime
28 Jun 2026
@opandddd:matrix.orgSapii/Sapersonmaybe these can be moved up in the contrib.md so its the first thing seen? 21:28:22
@emilazy:matrix.orgemilyI think it's more like even with consensus we don't have people putting the effort into fixing things21:28:33
@grimmauld:m.grimmauld.deGrimmauld (any/all) if documentation were all in files, that'd be one thing. But sending newbies to years-ongoing technical discussions is bad 21:28:33
@emilazy:matrix.orgemilymyself included, it's just a rabbit hole I don't have time for21:28:45
@emilazy:matrix.orgemilyand nobody owns our contributing docs really21:28:52
@grimmauld:m.grimmauld.deGrimmauld (any/all)sure21:29:01
@emilazy:matrix.orgemilyit would be very high-value work if people wanted to improve them21:29:18
@grimmauld:m.grimmauld.deGrimmauld (any/all)everyones workflow is different. I have ideas how i would want contributing docs to be structured, but collecting all the things that need to be documented is tedious and making it work for everyone is basically impossible21:30:37
@emilazy:matrix.orgemilywell, right now they work for nobody :)21:32:39
@grimmauld:m.grimmauld.deGrimmauld (any/all) I'd want:

  1. a directory of contributing docs

  2. markdown, same format as our other docs

  3. nix code blocks are syntax-checked

- bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow

  1. one file per common pattern, potentially with examples

  2. a list of useful tools and when to use them

- git-merge-base master staging
- tell people to STOP WASTING COMPUTE with nixpkgs-review without thinking
- tell people to think? XD

  1. explicitly document what we expect from

- a new contributor
- a new package/module
- exiting packages/modules
- existing contributors/committers
- how to do (good) reviews that are useful, even if the reviewer is not a committer
- includes security considerations

  1. where/how to find

- help
- examples
- "inspiration" from how other distros do things (and how that translates to nix)< 		21:37:37
@grimmauld:m.grimmauld.deGrimmauld (any/all) I'd want:

  1. a directory of contributing docs

  2. markdown, same format as our other docs

  3. nix code blocks are syntax-checked

- bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow

  1. one file per common pattern, potentially with examples

  2. a list of useful tools and when to use them

- git-merge-base master staging
- tell people to STOP WASTING COMPUTE with nixpkgs-review without thinking
- tell people to think? XD

  1. explicitly document what we expect from

- a new contributor
- a new package/module
- exiting packages/modules
- existing contributors/committers
- how to do (good) reviews that are useful, even if the reviewer is not a committer
- includes security considerations

  1. where/how to find

- help
- examples
- "inspiration" from how other distros do things (and how that translates to nix)

  1. a proper style guide

21:37:56
@grimmauld:m.grimmauld.deGrimmauld (any/all)okay formatting got butchered in my matrix client....21:38:08
@grimmauld:m.grimmauld.deGrimmauld (any/all) I'd want:
-  a directory of contributing docs
-  markdown, same format as our other docs
-  nix code blocks  are syntax-checked
  - bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow
-  one file per common pattern, potentially with examples
-  a list of useful tools *and when to use them*
  - `git-merge-base master staging`
  - tell people to STOP WASTING COMPUTE with `nixpkgs-review` without thinking
  - tell people to think? XD
-  explicitly document what we expect from
  - a new contributor
  - a new package/module
  - exiting packages/modules
  - existing contributors/committers
  - how to do (good) reviews that are useful, even if the reviewer is not a committer
  - includes security considerations
-  where/how to find
  - help
  - examples
  - "inspiration" from how other distros do things (and how that translates to nix)
-  a proper style guide
21:38:19
@grimmauld:m.grimmauld.deGrimmauld (any/all)ther,e thats a bit less awful+21:38:34
@grimmauld:m.grimmauld.deGrimmauld (any/all)* there, thats a bit less awful21:38:39
@emilazy:matrix.orgemilyI somewhat like having the contributor docs "right there" on GitHub in a way but I also feel like it might be more discoverable if we just had a "Nixpkgs contributors manual" alongside the others21:38:58
@emilazy:matrix.orgemilyI get the sense that people are often surprised that we have a bunch of relevant docs that don't appear in the manuals at all21:39:09
@grimmauld:m.grimmauld.deGrimmauld (any/all) manual is just markdown anyways 21:39:15
@grimmauld:m.grimmauld.deGrimmauld (any/all)it'd be in github, in some sense21:39:22
@emilazy:matrix.orgemilyI think these ideas are good, I honestly think the top challenge is just organizing things hierarchically in a way that's useful. you ideally want a top-level document that covers "if you only have 5 minutes to read things, here are the most important things to know", and then you can drill down from there to "if you only have 10 minutes to read about this specific task, …" and so on21:40:41
@grimmauld:m.grimmauld.deGrimmauld (any/all) I'd want:
-  a directory of contributing docs
-  markdown, same format as our other docs
-  nix code blocks  are syntax-checked
  - bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow
-  one file per common pattern, potentially with examples
-  a list of useful tools *and when to use them*
  - `git-merge-base master staging`
  - tell people to STOP WASTING COMPUTE with `nixpkgs-review` without thinking
  - tell people to think? XD
- common workflows
  - staging
  - backport
  - bot update
  - bot merge
  - channel bumps?
-  explicitly document what we expect from
  - a new contributor
  - a new package/module
  - exiting packages/modules
  - existing contributors/committers
  - how to do (good) reviews that are useful, even if the reviewer is not a committer
  - includes security considerations
-  where/how to find
  - help
  - examples
  - "inspiration" from how other distros do things (and how that translates to nix)
-  a proper style guide
21:40:53
@emilazy:matrix.orgemilydelivering the core principles upfront and then getting into rules-lawyering further down21:41:01
@grimmauld:m.grimmauld.deGrimmauld (any/all)i suspect if i start working on something like this, i'll just end up strongly suggesting my own preferences to everyone XD21:42:05
@emilazy:matrix.orgemilysounds like you have the drive and the vision, you're hired :p21:45:29
@grimmauld:m.grimmauld.deGrimmauld (any/all)
In reply to @emilazy:matrix.org
sounds like you have the drive and the vision, you're hired :p
If only it were that easy to actually do it 		21:48:35
@hexa:lossy.networkhexaI mean, nixpkgs core has authority21:49:24
@hexa:lossy.networkhexaand someone needs to make a proposal to get us startd21:49:34
@grimmauld:m.grimmauld.deGrimmauld (any/all) Okay that is a fair point. Getting started should just be the "5min version" with links going to stubs, and some ci on it. Doesn't sound that bad.... 21:51:18
@grimmauld:m.grimmauld.deGrimmauld (any/all)But please don't hold me to that, its late and I haven't slept much in recent days, I am sure I'll regret my folly in due time21:52:09
@hexa:lossy.networkhexa 
> -- Could NOT find Manette (missing: Manette_INCLUDE_DIR Manette_LIBRARY) (Required is at least version "0.2.4"
> CMake Error at Source/cmake/OptionsGTK.cmake:267 (message):
>   libmanette is required for ENABLE_GAMEPAD
> Call Stack (most recent call first):
>   Source/cmake/WebKitCommon.cmake:250 (include)
>   CMakeLists.txt:16 (include)
21:59:02

Show newer messages

Back to Room ListRoom Version: 6