In reply to @emilazy:matrix.org
I won't have time to do a full re-review before next weekend-ish but fwiw the last time I glanced at this there were review comments I left last time that hadn't been addressed

In reply to @emilazy:matrix.org
also like I said the easy way to land this without needing rebase/review of a huge monolithic PR is to split it up as read-only → convert existing users of useLLVM gradually → hook them up to bootstrap → make them writable and deprecate useLLVM

I think https://github.com/NixOS/nixpkgs/pull/365057#discussion_r1927841995 wasn't addressed? but like I said I haven't had time to go over the whole thing again

btw, there is overlap with https://github.com/NixOS/nixpkgs/pull/352629, so we'll need to decide what we want to do there

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

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

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

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

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.

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.