!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

222 Members
72 Servers

Load older messages


SenderMessageTime
17 Mar 2025
@rosscomputerguy:matrix.orgTristan RossI'm not sure how to handle the warnings since I don't think there's much of a delay between this PR coming and 25.05.05:36:45
@emilazy:matrix.orgemilythey shouldn't be deprecated/warned until we have replacements that are hooked up to bootstrap properly. it doesn't make sense to deprecate parameters before setting their replacements works properly05:53:01
@rosscomputerguy:matrix.orgTristan RossOh ok, I'll remove those tomorrow after work. I'm heading to bed.06:28:54
18 Mar 2025
@rosscomputerguy:matrix.orgTristan RossI have removed those now05:20:24
@yannis:mozilla.orgyannis|pto back oct 16 left the room.10:54:28
@rosscomputerguy:matrix.orgTristan Ross
In reply to @rosscomputerguy:matrix.org

This Thursday (2025-03-20) @ 9am - 10am PST will be the first meeting. I hope this will allow us to have a more coordinated effort towards development.

Goals:

  • Meet & greet
  • Determine overall plan (+ 25.05)
  • Highlight work done since Oct

Link: https://jitsi.lassul.us/nixpkgs-stdenv

Aside from the goals, what are some topics that should be discussed? One of which I can think of is getting our own Hydra set up.
17:13:36
@emilazy:matrix.orgemilyI have other commitments, I won't be able to make it. not sure synchronous calls are the best method of collaboration with a team as distributed as ours, but if we do them we should schedule them with something like Crab Fit and have someone to take minutes17:26:16
@emilazy:matrix.orgemilywhere would the build resources for a Hydra come from? if we can get more builder resources we should probably try and expand ofborg/hydra.nixos.org instead, we already run special jobsets on the central one for big rebuild projects sometimes17:26:48
@rosscomputerguy:matrix.orgTristan Ross
In reply to @emilazy:matrix.org
I have other commitments, I won't be able to make it. not sure synchronous calls are the best method of collaboration with a team as distributed as ours, but if we do them we should schedule them with something like Crab Fit and have someone to take minutes
Last time I tried a crab fit, there was two responses
17:26:55
@rosscomputerguy:matrix.orgTristan Ross
In reply to @emilazy:matrix.org
where would the build resources for a Hydra come from? if we can get more builder resources we should probably try and expand ofborg/hydra.nixos.org instead, we already run special jobsets on the central one for big rebuild projects sometimes
Tom Berek has brought up the idea to me and a part of the reason for having our own dedicated Hydra is so we don't disrupt the main one.
17:27:43
@rosscomputerguy:matrix.orgTristan RossAnother thing is I'm thinking consistent regular meetings can help, along with having notes of what was discussed.17:30:08
19 Mar 2025
@qyliss:fairydust.spaceAlyssa Ross
In reply to @emilazy:matrix.org
I have other commitments, I won't be able to make it. not sure synchronous calls are the best method of collaboration with a team as distributed as ours, but if we do them we should schedule them with something like Crab Fit and have someone to take minutes
I agree that synchronous calls are not a good fit.
15:43:03
@aleksana:mozilla.orgaleksana (force me to bed after 18:00 UTC)I have found that multiple rounds of shared documents may actually be better in gradually reaching consensus16:20:38
@reckenrode:matrix.orgRandy EckenrodeI am not available for calls during the daytime EST, and my night schedule is limited still. Calls would be hard for me.18:52:49
@xokdvium:matrix.orgSergei Zimmerman (xokdvium) changed their display name from xokdvium to Sergei Zimmerman (xokdvium).21:12:11
20 Mar 2025
@rosscomputerguy:matrix.orgTristan RossWhat's the solution then?01:28:46
@rosscomputerguy:matrix.orgTristan RossAh, that might work.01:29:15
@rosscomputerguy:matrix.orgTristan RossWould doing both a call and sharing documents work? There will be notes after the call.01:33:17
@qyliss:fairydust.spaceAlyssa Ross
In reply to @rosscomputerguy:matrix.org
What's the solution then?

Playing to the strengths of the people involved. People working on Nixpkgs stdenv are clearly very able and available with asynchronous, text-based communication, but there's no reason to assume that they'll be good with synchronous voice, or that it will even be possible for them.

If the problem is getting PRs reviewed, then one thing that could be done without increasing everybody's workload would be for a volunteer to try to act as a shepherd — go through PRs that are stuck, figure out whose review is needed, and contact them personally to try to get it — maybe they haven't realised, have been overwhelmed by notifications, etc. Focus should be on supporting volunteers rather than creating new commitments for them.

08:24:03
@emilazy:matrix.orgemilyIMO the problems with stdenv work are just the usual Nixpkgs things of lack of available time from the most knowledgable parties and burnout, especially with a lot of the most qualified people having quit the project. even if calls were workable it would take away from the scarce time available to actually review and work on things11:02:44
@emilazy:matrix.orgemilythat said, I don't think I've seen stdenv work be more stalled/blocked on average than any other work in Nixpkgs… big hard-to-review PRs without clearly-defined scope and with unaddressed tricky design points are hard to land in general, which is why I've made recommendations on how to split stuff up11:02:52
@emilazy:matrix.orgemilyI agree that triage/shepherding would help though, since contributions falling through the cracks is really common throughout the project. unfortunately forgetting about things is the inevitable consequence of trying to balance a huge scope of things falling upon a small number of contributors without avoiding burnout, so I err on the side of having an unreliable SLA over having one fewer person involved in this work entirely :/11:04:55
@philiptaron:matrix.orgPhilip Taron (UTC-8)

I'll echo everyone else and note that regularly scheduled calls are difficult for me, though I aim to make the one today if it happens.

I aim to steward a small number of PRs through -- or leave them in a known state of "these things remain" -- each month. My observation is that steady if slight presence keeps the Nixpkgs train a-rolling. This is basically the same as emily's observation about an "unreliable SLA" -- if there's steady effort somewhere, it's better than bursty attention everywhere, then nowhere.

There are a lot of models of how to maintain something. Some are more authorial and creative. Others are more negative, rejecting complexity and refining and emphasizing proper scope. Yet others are about stewardship and connection to community and people. I fall into the last camp.

15:55:47
@rosscomputerguy:matrix.orgTristan Ross

though I aim to make the one today if it happens.

It is still going to happen, 3 minutes.

15:57:55
@rosscomputerguy:matrix.orgTristan Ross

If the problem is getting PRs reviewed, then one thing that could be done without increasing everybody's workload would be for a volunteer to try to act as a shepherd

I think in this capacity, it would be good if someone does volunteer to do review stuff that there be "office" hours. This would be so the reviewer and PR author could work in real time in tandem. Tom Berek has done this a lot and it's proven to work well it seems.

16:00:12
@rosscomputerguy:matrix.orgTristan Rosshttps://jitsi.lassul.us/nixpkgs-stdenv meeting started here16:01:09
@rosscomputerguy:matrix.orgTristan Rosshttps://pad.lassul.us/k_EnCfiJT6ykaiAaNjIYnA# notes will be here16:02:14
@rosscomputerguy:matrix.orgTristan Ross I really like @[Philip Taron (UTC-8)]'s idea of non-shell builders. It's an interesting concept I feel like we should explore more. I think it could make bootstrapping easier if we didn't need something like coreutils and we could only bootstrap from specific compiler toolchain components we fetch. He also pointed out how Nix itself provides a BusyBox shell so this concept could be flushed out more to where we have the nixpkgs derivation builder bundled inside nix. 17:10:43
@k900:0upti.meK900No17:18:13
@k900:0upti.meK900No no no no no no no17:18:15

Show newer messages


Back to Room ListRoom Version: 9