2022-11-25 Nix team meeting minutes #11

2022-11-25 Nix team meeting minutes #11

Attendees: @fricklerhandwerk @regnat @Ericson2314 @edolstra @infinisil


  • look at No Status column (30 min)
  • discuss procedure (20min)



  • @fricklerhandwerk: should focus on PRs first
    • @edolstra: can also discuss issues to decide whether to implement them and tell those who propose it whether it’s worthwhile before they go off and implement them
    • @regnat: ideally we should not discuss pull requests, because we will have already discussed the issue and thus we and the author will know whether the Nix team approves of the idea.
    • @fricklerhandwerk: should document what to do in which situation - make a PR if it’s a small obvious change that we can look at and judge immediately, make an issue if the implementation would be more involved
    • @regnat: we should not review PRs together here in the first place, this can be done by individuals
      • @fricklerhandwerk: the point of reviews is also to share knowledge, and doing them collaboratively would help a lot to eventually increase throughput
      • @Ericson2314: in the short term we should discuss PRs together, also to build trust, but in the long term we should do what @regnat and @edolstra propose
  • @regnat: To Discuss column is way too long
    • @fricklerhandwerk: yes, how do we determine what’s on top?
    • @regnat: also, how do we make sure it doesn’t grow without bounds and come to conclusions with each of those items?
    • @Ericson2314: this is what should force us to confront the bigger issues. If we can tackle bigger issues.
      • maybe rather than having to discuss smaller issues individually, the bigger issues can make the decision on the smaller issues be automatic, because the bigger isssues determine the answer to smaller ones.
    • @fricklerhandwerk: @infinisil how do you manage concluding discussions on the Nixpkgs Architecture Team?
      • @infinisil: we don’t have the pressure to get things merged. the Nix team is the only group of people who can tackle the big issues, so you definitely should
  • @fricklerhandwerk: There will always be an “infinite backlog”
    • The idea is to prioritize what to discuss. The issue should be:
      • important
      • finite
    • @infinisil: The elephant in the room is Flakes.
    • @fricklerhandwerk: Flakes discussion has the potential to be non-terminating
  • @Ericson2314: polishing the store-only “plumbing” commands and stabilizing them is finite and has the potential for some controversy, so that could be something that the team could tackle and actually finish
  • @infinisil: something to focus on could be fixing errors instead of implementing new features
  • @regnat: would like to keep a tight scope; don’t discuss in this meeting RFC-like changes or long-running projects
    • that is, the small-ish issues are all worthwile, but we need to timebox the discussions
      • @fricklerhandwerk: how to determine what to do when we run out of time then?
      • @regnat: assign it to someone who will take the decision
        • @fricklerhandwerk: I don’t see that happening, I wouldn’t want to take on that kind of responsibility. anyone else?
      • @infinisil: agree, Nix team should delegate decisions on large issues to e.g RFC shepherds
      • @fricklerhandwerk: agree with the delegation part, work group should present results to the team
        • would like to compile an Eisenhower Matrix or effort/value diagram together to make an overview
          • agreement
  • @regnat: agenda for next time?
    • to discuss:
      • how to limit issue discussion time
      • @fricklerhandwerk: wanted to boil down the vision draft to what may be mergeable, but while the brainstorming draft took a good direction, it it is ill-structured and hard to work through
        • will have more input from the UX workshop, and will then come up with a new draft to discuss
    • to review:
      • (no decision)