# What would you do if you were the BDFL of Nix?
**URL:** https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949
**Category:** Uncategorized
**Created:** [April 29, 2020, 8:43pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949 "2020-04-29T20:43:14Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@zimbatm](https://discourse.nixos.org/u/zimbatm)
#### Post date: [April 29, 2020, 8:43pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/1 "2020-04-29T20:43:14Z")
Just for fun š
Imagine that you had all the powers on the NixOS project. You could decide the decide what to do and even direct the rest of the community to help you out.
What would be the top 5 things that you would change?
---
### Author:  [@zimbatm](https://discourse.nixos.org/u/zimbatm)
#### Post date: [April 29, 2020, 8:53pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/2 "2020-04-29T20:53:01Z")
Here are the top things that pop in my head right now:
1. Merge home-manager into nixpkgs, with a generic `nix-rebuild` script that would work across both and be installable from the pkgs/ packages.
2. Re-create the file hierarchy in nixpkgs. It would be 4 levels deep at most. All the pkgs derivation names would have an enforced 1:1 mapping with their filenames to make lookups trivial.
3. Create a new documentation system that follows the new nixpkgs file hierarchy. Each packages and modules can have their own README.md in their folder that would be collected into a central documentation.
4. Something we discussed with @flokli today: create a new website that acts as a meta-layer on top of GitHub. Each package and nixos modules would have their own page that contain the maintainer, versions per channel, and open issues and PRs. It would be possible to create new issues for the selected package from that page.
5. And finally, create a constitution that specifies an election system and governance model so that when I am done with all of this I can leave the position š
---
### Author:  [@worldofpeace](https://discourse.nixos.org/u/worldofpeace)
#### Post date: [April 29, 2020, 10:02pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/3 "2020-04-29T22:02:46Z")
Iād probably do a similar thing (maybe not an election system) and try to remove myself as BDFL š.
It just seems to have as many downsides as upsides:
- probably stressful
- people expect a lot from you
- major changes have to get your approval
- people care what I think too much
- āwith the power comes the great responsibilityā
and thereās always the risk of coup dāĆ©tat.
But with all that in mind š¤, Iām thinking I could do the most damage by ruining the Nix codebase because I donāt know C++.
---
### Author:  [@cdepillabout](https://discourse.nixos.org/u/cdepillabout)
#### Post date: [April 30, 2020, 3:12am UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/4 "2020-04-30T03:12:20Z")
@worldofpeace I feel like your answer was waaay too realistic š
* * *
One of my annoyances with the Nix ecosystem is that there is no formal leadership in a lot of nixpkgs. If you donāt have commit rights and you want something merged in, you basically just have to know who to bug to get it merged in.
There isnāt a single person who is responsible for making a yes/no call to merge something in.
For instance, there was recently a PR for bumping pytorch from @stites:
[python3Packages.pytorch: 1.2.0 -\> 1.4.1, python3Packages.ignite: 0.2.1 -\> 0.3.0 by stites Ā· Pull Request #75827 Ā· NixOS/nixpkgs Ā· GitHub](https://github.com/NixOS/nixpkgs/pull/75827)
I think Sam put a lot of work into this, but there were small suggestions from a bunch of different people. Normally this would be okay, but no one ever said something along the lines of āIf you do X, Y, Z, then we will merge this in.ā
So it appears that Sam just got burnt out from the lack of a clear goal, and no one having explicit responsibility to decide yes/no for merging this in.
I think it is really unfortunate we donāt have someone in a BDFL position with the responsibility to make these yes/no calls.
This leads me to my answer. If I were BDFL of nixpkgs, I would setup some sort of clear responsibility hierarchy for deciding whether or not to merge PRs. There should be a given person who has the responsibility to say yes/no to any given PR. People contributing to nixpkgs should be able to easily figure out who is responsible for their PR.
* * *
However, to be honest, Iām not sure how this would work in practice:
- I think it could be easy for some of the subsystems in nixpkgs. For instance, I think it would be relatively easy to decide on BDFLs for the Haskell subsystem or Python subsystem. But there are lots of packages in nixpkgs that donāt clearly fall into a given subsystem. How do you decide who is responsible for giving a decisive yes/no for them? Maybe with @zimbatmās suggestion of a more clear nixpkgs package hierarchy, this would be easier.
- What do you do when a subsystem BDFL starts making bad decisions? Or merging in things that donāt build?
- What would be the interaction between package maintainers and the BDFL? Should package maintainers be removed automatically if they stop responding to PR for their packages?
- I think there are some nixpkgs commiters that only review a small portion of all the nixpkgs PRs. For instance, I almost exclusively review PRs for the Haskell subsystem. However, there are other reviewers that review all sorts of PRs. Maybe this subsystem BDFL wouldnāt make sense for them?
- Would other people be less likely to review PRs if they are not officially responsible for the final yes/no decision? In Samās pytorch PR from above, I think it is really great that so many people were willing to do a review. Reviewing PRs is often very challenging. I think it is amazing so many people were willing to give their time to review a non-trivial PR like this.
Iām not very familiar with it, but I think the Linux kernel development happens in a similar BDFL-fashion. Iād be interested if anyone here has experience for how this works in practice. (I feel like Iāve also heard that a lot of the core Linux kernel developers are paid, which is probably not the case for the nixpkgs developers.)
---
### Author:  [@worldofpeace](https://discourse.nixos.org/u/worldofpeace)
#### Post date: [April 30, 2020, 3:44am UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/5 "2020-04-30T03:44:12Z")
> [@cdepillabout](#):
>
> @worldofpeace I feel like your answer was waaay too realistic
š¹ I guess youāre right. Perhaps my interpretation of @zimbatmās ājust for funā is creating chaos.
* * *
When I was release manager, it was probably the only position where I could see people looking to me for a clear yes/no because I was the gate keeper to the releases.
I thought it was weird, at first, but the more I did that the better things would get.
> [@cdepillabout](#):
>
> One of my annoyances with the Nix ecosystem is that there is no formal leadership in a lot of nixpkgs. If you donāt have commit rights and you want something merged in, you basically just have to know who to bug to get it merged in.
Contributing to nixpkgs, in my experience, is navigating a bunch of cliques.
While thankfully, these cliques are next level legit and let me sit with them, not everyone is going to work best with that. Iām not sure whatās better, usually if youāre in the clique youāre silently happy.
> [@cdepillabout](#):
>
> I think it could be easy for some of the subsystems in nixpkgs. For instance, I think it would be relatively easy to decide on BDFLs for the Haskell subsystem or Python subsystem. But there are lots of packages in nixpkgs that donāt clearly fall into a given subsystem. How do you decide who is responsible for giving a decisive yes/no for them? Maybe with @zimbatmās suggestion of a more clear nixpkgs package hierarchy, this would be easier.
A growing thing, that was an idea @jtojnar and I shared (and was implemented by him), is maintainer teams [nixpkgs/maintainers/team-list.nix at 3a1e8bdcd9a9e13ccd3f298bf598acc8b35caa4d Ā· NixOS/nixpkgs Ā· GitHub](https://github.com/NixOS/nixpkgs/blob/3a1e8bdcd9a9e13ccd3f298bf598acc8b35caa4d/maintainers/team-list.nix).
Itās not automated yet, but weāve added them for GitHub too [Sign in to GitHub Ā· GitHub](https://github.com/orgs/NixOS/teams/acme) [Sign in to GitHub Ā· GitHub](https://github.com/orgs/NixOS/teams/gnome). I see the future, at least for subsystems, is that these teams make a yes/no collectively. So there isnāt one person, and I think thatās healthier at least for subsystems.
> [@cdepillabout](#):
>
> I think there are some nixpkgs commiters that only review a small portion of all the nixpkgs PRs. For instance, I almost exclusively review PRs for the Haskell subsystem. However, there are other reviewers that review all sorts of PRs. Maybe this subsystem BDFL wouldnāt make sense for them?
I think the answer is those people would form the nixpkgs packaging committee, or something. I happen to be one of those people who are fine reviewing whatever, and can find a happy medium of a yes/no call, or who to ask to make a more informed decision. I go šæ when we burn out contributors.
> [@cdepillabout](#):
>
> Would other people be less likely to review PRs if they are not officially responsible for the final yes/no decision? In Samās pytorch PR from above, I think it is really great that so many people were willing to do a review. Reviewing PRs is often very challenging. I think it is amazing so many people were willing to give their time to review a non-trivial PR like this.
Iāve found that the social aspect of nixpkgs is not to turn away anyone as long as they interact fair and kindly.
---
### Author:  [@anon20203487](https://discourse.nixos.org/u/anon20203487)
#### Post date: [April 30, 2020, 10:45am UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/6 "2020-04-30T10:45:09Z")
- NixOS/kNetBSD
- Emacs integration all over the way! Including documentation in org mode (README in ORG)
- Spend everything I can in documentation
- ~~Every big project being put in overlays, from X11 and Wayland to XFCE and KDE~~ Now I prefer the monorepo approach
- ~~Create an init system, or some~~ abstraction for an init system
- Getting rid of systemd dependency
- A nix evaluator in pure Zig!
- Lisp Flavored Nix
- A Parliament š
---
### Author:  [@danieldk](https://discourse.nixos.org/u/danieldk)
#### Post date: [April 30, 2020, 12:03pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/7 "2020-04-30T12:03:01Z")
Probably not too much, I like Nix and NixOS and as an outsider, the RFC process seems to work well.
1. Clearly separate dependencies from build options in derivations. I guess that a straightforward implementation would be to let each derivation take two attribute sets, one with dependencies and one with (usually compile-time) configuration options. Make package configuration options easy to query/document.
2. Maintainer teams like @worldofpeace suggests. As an occasional contributor it is sometimes hard to know who to poke to get reviews/merges.
3. Set up a clear overview on where `nixpkgs` stands in various areas. Something along the lines of Rustās _are we X yet_, with clear fine-grained status + pointers. Examples: _Wayland support_, _ROCm support_, _FreeBSD status_, _Video playback acceleration_. Currently figuring these things our requires hunting through issues, PRs and the Wiki.
4. Implement a basic curses installer a la Slackware or BSD. Most installs that I do start out pretty standard, an installer with some basic choices would make it simpler/faster.
5. Controversial: make `allowUnfree` the default. People who are principled know where to find the knob, 95% of the users probably install something that is unfree and it will make life easier for them. (And would anyone care on a Mac, most of the system is unfree already š )
---
### Author:  [@anon20203487](https://discourse.nixos.org/u/anon20203487)
#### Post date: [April 30, 2020, 2:04pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/8 "2020-04-30T14:04:29Z")
Point 4: I know there is someone trying it!
Point 5 above: I would make something like āwarnUnfreeā. It would point out if and what packages you are using that arenāt free, but would be installed anyway.
---
### Author:  [@jonringer](https://discourse.nixos.org/u/jonringer)
#### Post date: [April 30, 2020, 5:27pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/9 "2020-04-30T17:27:03Z")
> [@cdepillabout](#):
>
> For instance, there was recently a PR for bumping pytorch from @stites:
>
> [https://github.com/NixOS/nixpkgs/pull/75827](https://github.com/NixOS/nixpkgs/pull/75827)
Iāve tried reviewing this PR several times, it can take \>64GB of ram to do a `nixpkgs-review`, and itās often broken because machine learning packages are notorious for breaking changes.
Edit: I agree that he put in a lot of hardwork, and did a lot of good. But the nature of the package makes it difficult to test pratically (not to mention the integration of mkl, cuda, and other optional libraries)
Edit2: Actually takes \>100GB
---
### Author:  [@t184256](https://discourse.nixos.org/u/t184256)
#### Post date: [May 7, 2020, 7:36pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/10 "2020-05-07T19:36:15Z")
Two words: LTS releases.
---
### Author:  [@7c6f434c](https://discourse.nixos.org/u/7c6f434c)
#### Post date: [May 7, 2020, 8:36pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/11 "2020-05-07T20:36:29Z")
> Controversial: make allowUnfree the default. People who are principled know where to find the knob, 95% of the users probably install something that is unfree and it will make life easier for them.
Where we probably agree: make `allowUnfree` actually mean anything when default is `true`ā¦
I have some very specific unfree packages and want to control that list tightly, and as there are many slightly different contexts in which different things are evaluated, having a full guarantee that each of them except exactly one Nix expression gets nondefault `allowUnfree = false` is hard.
Obviously, the complicated interplay of details matters not only for unfree packagesā¦
---
### Author:  [@7c6f434c](https://discourse.nixos.org/u/7c6f434c)
#### Post date: [May 7, 2020, 9:14pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/12 "2020-05-07T21:14:41Z")
I assume that one cannot really magic resources out of thin air, but can do what amounts to convincing all the people to accept the core principle of some RFCs (which then get slowly debated on details as things do not get written perfectly the first time, and later accepted).
I guess I risk ending up driving an anti-perfectionism + anti-SPOF campaignā¦
Core principles:
1. If something is important in principle and an ugly proposal works, accept it and use until it breaks (or until a cleaner one _fully_ covers what the ugly version does).
This obviously applies to things like new test types, but alsoā¦
1. If we _can_ swap out a component and get the basics working, then we _need_ this capability.
Be it NixOS/k\*BSD, libc choice, alternative Nix evaluation options if they arise, init, service supervisionā¦ or running just a few services on another distribution without installing a full NixOS.
And I guess the way to do it without sinking everything into a complete mess is better override options and better separation of substantial from dependency-choice specificā¦
-=-=-=-
ā¦ and I guess if I started defining the BDFL powers in comparison to the current RFC process, maybe doing all this by abusing influence in RFC discussions, then becoming more careful to avoid abusing influence is a way to step down without even a clear step-down event.
---
### Author:  [@symphorien](https://discourse.nixos.org/u/symphorien)
#### Post date: [May 8, 2020, 10:54am UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/13 "2020-05-08T10:54:19Z")
- Migrate the explanations from [http://howoldis.herokuapp.com/](http://howoldis.herokuapp.com/) onto [https://status.nixos.org/](https://status.nixos.org/)
- Re-enable emails from hydra to maintainers when their packages break
---
### Author:  [@blaggacao](https://discourse.nixos.org/u/blaggacao)
#### Post date: [July 25, 2020, 6:22pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/14 "2020-07-25T18:22:39Z")
Iād broaden the userbase to attract different roles into the ecosystem and seak salvation in letting sort out complexity by itself.
Therefore, leveraging flakes:
1. `nix develop` ā the most notorious tool in the world to attract contributors and community to about _any_ repository across _any_ language. Strongly appeals to the maintainers.
2. `nix run` ā having done the above, the maintainer might choose to make his baby discoverable through the nix package manager
3. All the rest.
Then Iād take the hat and resort to RFCs for governance.
---
### Author:  [@milahu](https://discourse.nixos.org/u/milahu)
#### Post date: [March 7, 2022, 6:37pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/15 "2022-03-07T18:37:38Z")
> [@cdepillabout](#):
>
> If you donāt have commit rights and you want something merged in, you basically just have to know who to bug to get it merged in.
- auto-merge ātrivialā pull requests after one week, except one maintainer says āvetoā
- ātrivialā means the diff is shorter than 20 lines (for example), so it is cheap to review
- rate-limit is 1 PR per user per week
- if something breaks, we can always revert a merged PR, similar to wikipedia āedit warsā. this is better than stale PRs
- this should encourage contributors to [keep diffs small](https://www.youtube.com/watch?v=-W_VsLXmjJU#title=Top%20signs%20of%20an%20inexperienced%20programmer.%20by%20TechLead)
- more maintainers = more users with commit privilege
- [automate](https://www.youtube.com/watch?v=wwbM63-LFD4&t=220s#title=Why%20You%20Should%20Not%20Learn%20to%20Code.%20by%20TechLead) updating of packages
- automate adding new packages, similar to github copilot (AI pair programmer)
- integrate projects like [python on nix](https://github.com/on-nix/python) which are just workarounds for the undermaintained nixpkgs
- find a shorter way to say `tensorflow.overridePythonAttrs (old: { version = "1.2.3"; })`, for example `tensorflow."v1.2.3"`. by default, maintain multiple versions per package. problem? we would have to say `tensorflow.latest`. maybe solve this in Nix, by implementing the `@` operator. then `tensorflow` is the default version, and `tensorflow@1.2.3` is a pinned version. the `@` operator would override the derivationās `version` attribute. related: [Concept: use any package version](https://discourse.nixos.org/t/concept-use-any-package-version/6515)
- rename all `pname/default.nix` to `pname/pname.nix` so i dont have a million `default.nix` tabs in vscodium. upstream issue [Provide API to access and change editor tab labels Ā· Issue #41909 Ā· microsoft/vscode Ā· GitHub](https://github.com/microsoft/vscode/issues/41909)
- fix the live DVD, so it has a dark mode splash screen. im still traumatized by that 90% white splash screen in the middle of the night \*\_\_\*
---
### Author:  [@samuela](https://discourse.nixos.org/u/samuela)
#### Post date: [March 10, 2022, 12:41am UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/16 "2022-03-10T00:41:47Z")
> [@cdepillabout](#):
>
> - Should package maintainers be removed automatically if they stop responding to PR for their packages?
Yes.
> [@danieldk](#):
>
> - Implement a basic curses installer a la Slackware or BSD. Most installs that I do start out pretty standard, an installer with some basic choices would make it simpler/faster.
I implemented something like this, [nixos-up](https://github.com/samuela/nixos-up).
Lots of great suggestions already, I would add:
- [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) and integrations with `meta.maintainers`. If you are a maintainer, you are responsible for reviewing and merging the relevant PRs. If you donāt attend to PRs then you are removed so someone else can come in and take up the reins.
- More focus on server-side usage for NixOS, less emphasis on desktop. Desktop users are great (I am one), but in my experience itās on the server where NixOS really shines. We should leverage that as a beachhead towards more adoption. In a similar vein, Nix-on-macOS should be a continued area of investment as thatās the #1 most popular platform for developers these days.
- home-manager should be part of NixOS.
- [Better Nvidia/CUDA support](https://discourse.nixos.org/t/announcing-the-nixos-cuda-maintainers-team-and-a-call-for-maintainers/18074) š
- Moonshot: start moving Nix away from C++ and into Rust since thatās the direction the universe is headed now.
---
### Author:  [@davidak](https://discourse.nixos.org/u/davidak)
#### Post date: [March 13, 2022, 1:39pm UTC](https://discourse.nixos.org/t/what-would-you-do-if-you-were-the-bdfl-of-nix/6949/17 "2022-03-13T13:39:24Z")
> [@danieldk](#):
>
> Implement a basic curses installer a la Slackware or BSD. Most installs that I do start out pretty standard, an installer with some basic choices would make it simpler/faster.
There is a PR that adds a graphical installer in the work. A basic install already works.
>
>
> \###### Motivation for this change
>
> Currently, installing NixOS is rather diffiā¦cult for new users, and the new experience when booting into one of the graphical ISOs is a blank GNOME or Plasma desktop with no super obvious indication of what to do next. Even though following the guide is not all that hard, I believe that integrating Calamares into the current NixOS isos would help make the installation experience better for new users.
>
> Closes #15573
> Closes #21662
> Closes #100475
>
> \###### Things done
>
> This draft PR contains 3 things:
>
> 1) Updates the calamares package to fix the functionality of multiple modules.
> 2) Adds a package for \[calamares-nixos-extensions\](https://github.com/vlinkz/calamares-nixos-extensions), which implements NixOS backend for some calamares modules
> 3) Adds configuration for a GNOME and Plasma5 ISOs with calamares installer
>
> The GNOME test ISO can be downloaded here \[nixos-gnome-22.05pre375061.c777cdf5c56-x86\_64-linux.iso\](https://releases.nixos.org/nixos/unstable/nixos-22.05pre375061.c777cdf5c56/nixos-gnome-22.05pre375061.c777cdf5c56-x86\_64-linux.iso)
> The Plasma5 test ISO is also available here: \[nixos-plasma5-22.05pre375061.c777cdf5c56-x86\_64-linux.iso\](https://releases.nixos.org/nixos/unstable/nixos-22.05pre375061.c777cdf5c56/nixos-plasma5-22.05pre375061.c777cdf5c56-x86\_64-linux.iso).
>
> All feedback is appreciated!
>
>
>
> \- Built on platform(s)
> - \[x\] x86\_64-linux
> - \[\] aarch64-linux
> - \[\] x86\_64-darwin
> - \[\] aarch64-darwin
> \- \[\] For non-Linux: Is \`sandbox = true\` set in \`nix.conf\`? (See \[Nix manual\](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
> \- \[x\] Tested, as applicable:
> - \[NixOS test(s)\](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside \[nixos/tests\](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
> - and/or \[package tests\](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
> - or, for functions and "core" functionality, tests in \[lib/tests\](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or \[pkgs/test\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
> - made sure NixOS tests are \[linked\](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
> \- \[\] Tested compilation of all packages that depend on this change using \`nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"\`. Note: all changes have to be committed, also see \[nixpkgs-review usage\](https://github.com/Mic92/nixpkgs-review#usage)
> \- \[x\] Tested basic functionality of all binary files (usually in \`./result/bin/\`)
> \- \[22.05 Release Notes (or backporting 21.11 Release notes)\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2205-release-notes)
> - \[\] (Package updates) Added a release notes entry if the change is major or breaking
> - \[x\] (Module updates) Added a release notes entry if the change is significant
> - \[\] (Module addition) Added a release notes entry if adding a new NixOS module
> - \[x\] (Release notes changes) Ran \`nixos/doc/manual/md-to-db.sh\` to update generated release notes
> \- \[x\] Fits \[CONTRIBUTING.md\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
>
> \# Current Issues
> \- ~~No way to enable unfree drivers~~
> - ~~Laptops with Broadcom wifi cards will not have it enabled after installation~~