2023-02-20 Nixpkgs Architecture Team Meeting #30


  • @infinisil: Have a team to make decisions and multiple teams doing the work

  • @wanja: Rust community has MCP as a middle ground between RFC’s and PR’s

  • @infinisil: proposals that are “internal” shouldn’t require RFC, or the RFC should be limited to the effected developers. Proposals that effect end users can be open to a wider audience.

  • rfcbot on PR’s, automating approval, FCP, etc.

  • @wanja: reaching scaling limit both for managing PRs in Nixpkgs.

    • A bot for auto-merging based on CODEOWNER subtrees could help alleviate this effort.
  • @infinisil: how to organize working groups for issues?

    • @Ericson2314: should we move the nixpkgs-architecture issue tracker into nixpkgs?
      • @infinisil: there’s a flood of issues in nixpkgs, it would be hard to find the one’s we’re interested in.
      • maybe label nixpkgs-architecture issues to make them more searchable; but unsure if there’s a way to limit permissions so that only team members can use this label.
      • @infinisil: would prefer to keep it separate.
    • @tomberek: smaller working groups focused on individual issues separate from RFCs could be productive.
      • this will help us scale up to managing multiple projects.
    • @infinisil: want to find a way to allow non-team members to contribute to solutions.
      • limiting factor today is number of available hours for current team members.
      • crowdsourcing help from the community without necessarily requiring that they attend meetings/RFCs for “decision making”.
  • @tomberek: discussion for project, grafts (staging,security)

  • @tomberek: another discussion for rust packages: https://github.com/NixOS/nixpkgs/pull/217084

  • Next project to focus on?

  • Priorities:

    • RFC 140
    • If @Ericson2314 also agrees, modules for package declarations
      • @infinisil: Let’s try to find a working group via Discourse?
        • Set up weekly meetings
        • Have everybody say the time they have available
        • Have one person of the NAT be part of the working group

Action items


Does the discussion of the possibility of a Nix implementation of Guix-like grafts here mean that y’all feel the Nix store capabilities for that are ready or near-ready? I recall at some point hearing (IIRC from @Ericson2314) that the notion of interchangeability used for content-addressed store paths could provide the foundation for that.

I think that is such a killer feature for avoiding mass rebuilds, and I’m really happy to see that it’s at least on the Nixpkgs architecture team’s agenda!