Formalize creation of the stdenv team

Announcements
1

For too long, stdenv has had no real coordination.

11 Likes
2

I’m interested but haven’t interacted with pkgs/stdenv nor lib/systems. Would love to learn and help nonetheless. Can help with reviewing PRs with my current level of confidence.

1 Like
3

Previously:

There are likely more, and I’d appreciate it if they were linked.

I’m interested in this topic, both as a reviewer, contributor, and stakeholder in Nixpkgs’ stability and continued evolution.

It’s not clear to me that it can or should be detangled from:

  1. Compilers and their build and use cycles.
  2. Flakes and their use of nixpkgs throughout the ecosystem.
  3. Bootstrapping, especially bootstrapping from source.
  4. Language ecosystems and their expectations.

So I’m expecting that even with a team that we’re going to have deeply cross-cutting concerns without the ability to speak with authority, due to the numbers of unknowns and the sorts of dependencies that are taken.

1 Like
4

Yeah, I’m sure the LLVM team and GCC maintainers will be working closely with stdenv but if we get core teams for platforms (eg Darwin, Linux) then those people will be involved too. The big thing I’m wanting to see from this is less chaos, more organizations and communication. This should hopefully lead to fixing issues and getting PR’s through that could benefit nixpkgs.

I’d think this would stem from either a different team or remain as is. I’d rather let the Steering Committee figure this out.

This is definitely something the stdenv team would probably be responsible for since bootstrapping is heavily tied into stdenv.

Like mentioned earlier, communication. I think the main thing would at least be languages and ecosystems like GCC, LLVM, Rust, and Python. Anything nixpkgs or NixOS relies on to be actually functional.

I think we cannot avoid this at all and shouldn’t be seeing as a bad thing. There needs to be communication in order to make progress.

5

I think your introductory post would benefit from writing down some of what you see as being inside a “stdenv” team’s purview, while you still have time to edit it. :slight_smile:

In particular:

  1. What do you think the values of the team ought to be?
  2. What’s absolutely inside the purview of the team? Are there any existing teams that ought to be subsumed into a “stdenv” team?
  3. What’s definitely outside of the purview of the team? Based on your thinking about flakes above, in particular, what responsibilities to you think the stdenv and a team that stewards it owe to out-of-tree users and derivations?
  4. What’s in this liminal space between the edges of related teams.

I appreciate the engagement with my list of on-the-boundary stuff!

2 Likes
6

I think the Steering Committee would have more of a clearer idea than myself heh. @tomberek along with my experience with nixpkgs kinda inspired me wanting to see more coordination between individuals.

I’m not sure what you mean by values but my main thing is communication. Being able to work with language frameworks and ecosystems but also being a resource for the community. People interested in how this core section of nixpkgs works could ask the stdenv team about how things work.

The main thing is reviewing PR’s in my mind. Things related to the stdenv that can shift how we do things. A good example would be hardening options, let’s say if someone wanted to completely rework that. The stdenv team would review and coordinate the effort of the rework, especially since this affect literally everyone.

I’d think some components of lib, CI, and NixOS as a whole. Their point is to mainly be responsible for the stdenv which essentially is the core of nixpkgs.

I’d say different platforms, the stdenv team is somewhat responsible for the platform specific stdenvs. However, it might be good for platforms to get their own teams to manage their stdenv, bootstrapping, and core packages.

You’re welcome.

2 Likes