I think there’s several things to unpack to answer.
- First, we have had some trial and error about our approach to the package set, for quite some time. We tried a hard nixpkgs fork, we tried re-using its structure, and eventually created a new package set from scratch, because the previous two approaches failed. They failed because we didn’t have the sheer manpower necessary to maintain something as huge as nixpkgs (or even a small subset), nor the infrastructure to run the associated CI and binary cache. But it still took a lot of energy and thus time to sunset (and recover) these.
- Also at the beginnings, a lot of SIGs where created without actionable things to do. SIG docs was the most active from my point of view, and has the most minutes posted on the forum compared to all other SIGs. SIG security, which was naturally concerned with infra, did have some immediate things to work on and so was active too, as well as SIG core for the package set.
The other ones basically had to wait for the package set before doing anything (again, even what kind of package set we would end up having was not set in stone). - Activity declined as people burnt out or prevented spending too much energy on something that was hitting hard problems and didn’t look like it could be solved. There are a lot of other smaller reasons, which I think can be dug up from this forum (though it would be hard), but the takeaway is that there was a point at which there was no visible activity from aux.
- After a while, @jakehamilton put up lib, then foundation and tidepool, which is to date our current package set (new, from scratch). It looks like this is sticking, and because it didn’t need a lot of people to maintain (an empty package set is pretty low stakes), work on it has been pretty ad-hoc and outside SIGs. There was also few people that showed interest in it that the SIG structure was not put to use: if you look at these repos’ history before 3 months ago that’s 6 people. And really it’s jake, authoring 85% of the commits, I don’t remember real collaboration between all of us, it was more ad-hoc building upon jake’s work.
An important detail is that these repos are a full-source binary bootstrap, inspired by guix’ work. Which is pretty minimal: we basically have the most basic GNU tools and that’s it (notably, we don’t have Lix, cmake, or trivial builders yet). So you can’t do much with this for now. And given this was more proof-of-concept work that was promoted to de-facto “current aux package set” (but mainly because this was the only thing happening), it may significantly change or be re-architectured, we can’t put all our eggs in its basket yet imo. - Now we’re at a point where activity is picking up. It’s barely visible on the forum, but our matrix channel had never seen one message a day for a whole week (or it feels like it), and we have a lot of PRs and issues coming (at least, a lot more than 0 or 1).
With all these events, and new people coming in, we have been questioning the current governance structure, which:
- has not been properly maintained
- have not met in over a year
- are full of people that may not be there anymore, while new people want to participate to the project.
So to recap, SIGs have become irrelevant, so we are left with pretty much no governance (but we’re working on that), we don’t have the tools to build Lix (yet), and we have not had the people to think about more than a core part of the package set for a long time.
I tried to be factual here, focusing on the events that led to such a SIG not appearing, so the above is not meant as an opinion. It starts from now:
I think we should not try to bite more than we can chew (we have in the past, and it was bad). We’re pretty much saturated for now with just a simple package set. More and more people show up on matrix, so I expect this sentence will quickly become obsolete, but I think there are quite a few steps before planning for a distro. I would have at least the following requisites:
- A package set. I don’t think we qualify.
We need this because what kind of distro we have depends a lot on what kind of package set we have and what it focuses on. Does it include as many packages as it can, nixpkgs-style ? what’s the policy around non-free, non-redistributable software ? Other anti-features ? What’s the stability guarantees ? What’s the review process if any ?
I think we’re far from answering those questions, and I don’t think we have the proper governance structure to begin tackling them (yet, again). - A CI infra. We don’t have one.
Even if we decide to be a source-based distro and not provide a binary cache, we need to extensively test both our packages and our system configuration.
All we have for now is an hydra instance that @srtcd424 maintains voluntarily alone. We’re basically borrowing his. - Not-a-distro configuration system à la home-manager/nix-darwin. Maybe more of a hot take but imo a nixos-like distro is actually a two-fold project: figuring out user environment configuration, setting up a DE, configuring services apps, etc. (even if it’s just saying “everything goes into
~/.local!”). This varies a lot distro-by-distro and nixos historically has been quite powerful at it. And the gory system administration that is what all distros do: boot setup, init systems, where are your drivers, configure (unix) users, etc.
I see the former has a way simpler yet useful stepping stone. I’d really want us to focus on that and getting that right before thinking about a full-blown distro, even if we end up doing much less than something like home-manager, which is very powerful and expressive (I don’t think we have to). - Actual governance :^)
I hope this clarifies things, feel free to ask if not. I’ve been quite lazy with links because I wanted to write all that, but if you’re looking for something I can try to dig it up 