Nixpkgs Stdenv | 228 Members | |
| 74 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Mar 2025 | ||
| 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:
Link: https://jitsi.lassul.us/nixpkgs-stdenv | 02:40:12 | |
| 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 | 04:07:29 | |
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 | 04:08:22 | |
In reply to @emilazy:matrix.orgOh ok, idk what could be missing | 04:23:54 | |
In reply to @emilazy:matrix.orgOh, I didn't realize that's what you meant. | 04:24:06 | |
| 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 | 04:29:00 | |
I think the has in cases of multiple possible variants will just cause issues. | 05:09:41 | |
| I think I did address that or mostly did. | 05:10:31 | |
| ah, I see the assert now. that might work. the premature warnings are still there though. but I'll try to take a closer look next weekend | 05:31:06 | |
| I'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 | |
| they 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 properly | 05:53:01 | |
| Oh ok, I'll remove those tomorrow after work. I'm heading to bed. | 06:28:54 | |
| 18 Mar 2025 | ||
| I have removed those now | 05:20:24 | |
| 10:54:28 | ||
In reply to @rosscomputerguy:matrix.orgAside 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 | |
| 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 | 17:26:16 | |
| 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 | 17:26:48 | |
In reply to @emilazy:matrix.orgLast time I tried a crab fit, there was two responses | 17:26:55 | |
In reply to @emilazy:matrix.orgTom 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 | |
| Another thing is I'm thinking consistent regular meetings can help, along with having notes of what was discussed. | 17:30:08 | |
| 19 Mar 2025 | ||
In reply to @emilazy:matrix.orgI agree that synchronous calls are not a good fit. | 15:43:03 | |
| I have found that multiple rounds of shared documents may actually be better in gradually reaching consensus | 16:20:38 | |
| I 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 | |
| 21:12:11 | ||
| 20 Mar 2025 | ||
| What's the solution then? | 01:28:46 | |
| Ah, that might work. | 01:29:15 | |
| Would doing both a call and sharing documents work? There will be notes after the call. | 01:33:17 | |
In reply to @rosscomputerguy:matrix.org 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 | |
| IMO 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 things | 11:02:44 | |
| that 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 up | 11:02:52 | |