[RFC 0025] Nix Core Team

[grahamc]

Introducing the Nix Core Team.

Rendered.

Voting

Please register your approval or disapproval with the "Review Changes" feature. Obviously:

• Approval = Approval
• Request Changes = ... Not ... approval ...

and place any final feedback in the body of that review.

[Mic92]

So the Nix core team would not decide on RFCs like the musl pull request?

[shlevy]

Correct. If this goes through and works out well we may replicate it or expand it to cover a wider scope.

[grahamc]

Gosh.

I just want to say thank you to everyone who helped put this together. This has been a long running project and it wouldn't have been possible without a lot of help from a lot of people.

• @rbvermaa for regular moral support and some "on the ground" help
• @zimbatm for the sanity-checking and push to do the right things
• @shlevy for sticking through, thick and thin, to get this done
• the members of the proposed core team (@copumpkin, @edolstra, @peti, @shlevy, and @vcunat) for being open to this project and reading numerous drafts
• literally the entire Nix community for their patience
• @gilligan for pinging me like every other day asking when I was going to finish replying to Feature freeze for nix 1.12? nix#1806
• My mom, actually, whose ministerial experience has helped me gain perspective on community building and how to negotiate sometimes very tricky community issues
• I can't even remember, actually, everyone who has helped, but thank you a lot!

and, of course, @edolstra who put up with a lot of emails, PMs, video chats, and really came to the table to work together on this project. This RFC is a big change. Nix has been Eelco's baby for fifteen years. I can only imagine how scary and hard it is to let go of some control of such a long running, substantial part of his life. Thank you, Eelco. Thank you. I owe you many fine meals.

Wow! I can't believe this is posted -- right before posting it I felt like I was going to pop with excitement!

[shlevy]

A huge thank you to @grahamc, who is truly the author of this entire effort, not just the RFC. Getting this whole group to the table, let alone in agreement on the final direction, was no easy feat. Whatever the outcome here, he's singlehandedly helped our community take a huge leap in organizational maturity.

[Profpatsch]

@grahamc, a nomenclature thing: How would you call the team of “core” maintainers that manage the e.g. 250 core packages for nixpkgs?

In my first ideas about nixpkgs support I’ve also called them Core, but that would obviously be confusing.

Instead of Nix Core Team, what do you think about Nix Stewards?

According to Wictionary:

steward (noun): In information technology, somebody who is responsible for managing a set of projects, products or technologies and how they affect the IT organization to which they belong.

When I hear of “core” concerning a package manager, I think of core packages (similar to Archlinux).

[grahamc]

I've received a bunch of questions (mostly in private) about why I'm not on this list. To start with, I'm not sure why I should be on the list: this isn't really in my wheel-house. My role on putting this team together was primarily as a consensus-builder and trusted neutral party. I'm happy to continue helping in that capacity as the team sees fit.

[polynomial]

While I appreciate the sentiment outlined here with respect to your inclusion, I would posit that as a community advocate your position on such a team would certainly have very valuable input.

[Mic92]

I think the RFC still leave open to have a similar arrangement for Nixpkgs/NixOS itself.
So the current team should be fine.

[shlevy]

For those subscribed to this thread, note the change to the description indicating how to vote.

[grahamc]

@Profpatsch @peti mentioned that IIRC SUSE uses "rings" to describe critical packages, so we could have ring-0 packages and ring-0 maintainers, ring-1 {packages,maintainers} etc. I think you writeup is very good, and something to consider. However this RFC isn't about that proposal, so I don't want to get in to too much detail there. Other teams we could have for Nixpkgs could be the "Nixpkgs Technical Committee" or "NixOS Technical Committee" or "NixOS Steering Committee" etc. I don't feel that the momentous progress this RFC makes should be blocked on the name of the team, though.

[shlevy]

There is a lot I like about this plan, largely collected in the motivation section. In particular, having a process means we have a clear path toward making decisions, and having a team means we can scale and be available without putting impossible burdens on any one person. I'm not sure whether anything about this specific design will be recognizable down the road, but I am sure that any future flourishing Nix community will have its roots in this experiment.

[7c6f434c]

Thanks to everyone involved.

This is a larger, better and more promising process-related experiment than I could believe a month ago.

[Profpatsch]

mentioned that IIRC SUSE uses "rings" to describe critical packages,

I like the ring idea!

[shlevy]

I've been asked what specific perspective and expertise I bring to the team. In general, of course, when acting as a member of the team I'll be acting in the interests of the community as a whole as best I can determine. And on a personal level, most of what goes on in Nix and the related projects is interesting to me and something I want to get involved in on some level. With respect to Nix I'm especially focused on 3 things:

• Improvements to the core capabilities of the nix store
• Extensibility and customizability, pushing for exposing general mechanism with sound semantics on top of which specific policy can be implemented
• Nix as a basis for reproducible development environments and deployment infrastructure for industrial software development

As for expertise, I've been part of the Nix community for a little over 7 years now and contributed heavily to Nix, nixpkgs, NixOS, and hydra as well as having contributions to nixops. Professionally I work in infrastructure/systems engineering and operations, where I've been using Nix on-the-job since 2013, primarily focusing on Haskell-based teams.

[gilligan]

@shlevy Thank you for this introduction and display of interests! Maybe this would even be something that would be valuable to get from others, regardless of how prominent they already are in the community. Might also be useful in terms of whom to talk to for what topics.

Just a thought. I don’t have any formal suggestions based on that.

[grahamc]

@gilligan I've messaged each member of the team and asked them to provide a similar message :)

[copumpkin]

Thanks @grahamc for making this happen!

My main interests in the Nix space are related to Darwin support. I implemented the original sandbox support for it, as well as much of the Darwin stdenv, and would like to continue to improve the user experience for Darwin users in particular, as well as improving the viability of supporting Darwin in the long run (so for example, improving testability of Darwin stuff for Linux users so our stuff doesn't break all the time).

Other (non-Darwin) things that fascinate me in the Nix space are largely about pushing the boundary of what's possible in the Nix model of builds/computation. Also, someday I'll bootstrap GHC from C 😁

[mbbx6spp]

👍 +1

[mbbx6spp]

To expand on my opinions for reference:

I read it last night and thought it made a lot of sense, especially the trial period with a defined period plus the scope of this core team is not far-reaching but also scoped to be filling a void that needs filling on the project. The team listed is also tried and tested in our ecosystem. Thanks!

[polynomial]

I love the direction this is taking Nix. Thank you @grahamc for driving these changes. ❤️

[polynomial]

While I appreciate the sentiment outlined here with respect to your inclusion, I would posit that as a community advocate your position on such a team would certainly have very valuable input.

[polynomial]

This is great, I would also love to add that -1's need to have reasons such as:

• community impact
• security concerns
• overall design mismatch

While I would hope that members of this group would always do this, it seems helpful to codify that a negation of a proposal needs to come with the motivations that went into that response for transparency and discussion.

[polynomial]

Is the longer term goal here to distribute consensus for vision/scope changes of NixOS to a wider group than just one person? Can we rephrase it so it isn't about the negative perception of a specific person? Perhaps: "Will approve Nix changes and steering for the long term vision"?

[vcunat]

Further future could be wished-for here, but I understand the intention as an incremental process: let's try this first and after some time we'll better see where to go next.

[cransom]

I like the aspect where this is called out as a year long experiment where it can be re-evaluated after some real world testing.

[peti]

It feels like our community reaches an important milestone by establishing a formally organized group of volunteers with a mandate to plan, coordinate, and decide the future development of Nix. On one hand, this development comes out of practical necessity. Nix and Nixpkgs have grown in scope and complexity to an extend that makes it impossible for any single person to manage the project in its entirety. This has been obvious for a while, and now we're addressing that issue by joining our forces and by organizing ourselves so that we can be more effective.

On the other hand, we're not taking these steps just because of necessity. We also organize ourselves, because we want to. I have contributed to Nix in one way or another for 10+ years and during that time this project and its community have become a part of my life. I feel like being a "Nix contributor" is a part of my identity. I feel that way because of the social component of the whole effort. I have come to know men and women from all around the world through this project and my life has become richer because of it. Therefore, I perceive the formation of this Core Team also as a declaration of intent. We recognize that Nix has become bigger than any one of us individually and we want to make sure the project thrives without depending on any one single person exclusively. To that end, we created a non-profit organization already, and now we're setting up a formal body that can make decisions according to well-defined rules and procedures. That step crosses an evolutionary threshold, IMHO, because now the Nix project has the potential to achieve an identity of its own. Up until now, it felt like the Nix project is a part of me. But from now on, it's the other way round: I am a part of the Nix project.

I hope this little experiment we're conducting here works out really well. 😃

[vcunat]

I must also thank Graham for his push to better organize the community, which can be seen in multiple instances, e.g. the PR bot @GrahamcOfBorg. The community seems to have multiplied during the past few years, so these aspects are growing very important.

I identify a lot with Peti's comment. I've been a frequent NixPkgs contributor for over five years non-stop, mostly just in my free time, and it has become a significant part of my life. I have preferred to focus on NixPkgs changes affecting its own larger parts, but Nix – that is what makes it even possible.

My perspective... is relatively conservative. Most of "business logic" is outside Nix, e.g. inside stdenv, so the tool itself can be smaller, more universal, and it doesn't need to change so rapidly. This split between NixPkgs and Nix seems a good design decision, but there's still a lot that remains in Nix itself. I shall strive to help bootstrapping the "experiment" described in this RFC and to keep moving Nix forward carefully, primarily with NixPkgs and NixOS use cases in mind.

I do believe that the proposed team can improve the way Nix evolves and make it even better support the complex ecosystem that's growing around it.

[cbarrett]

This is truly huge. I hope that future versions of this continue to include voting. While it may seem silly or redundant, having a community ratify who its leaders are is very important for its long-term health.