We’ve been making some solid progress lately - lots of discussion here on the forums, and we even have a working stdenv (huge thanks to @VlinkZ!!). Given the progress we’re making, I think it’s a good point for us to call a meeting, so we can all touch base and get in sync on where we want to start heading next.
Here’s a draft outline for a possible agenda (updating as suggestions come in):
How should we address security advisories in Core?
Any other miscellaneous items
Next meeting - when? how often?
Definitely not final - please drop a comment if there’s anything else you want to discuss (or just bring it up in the meeting!).
As for potential meeting times, please drop your availability over here: SIG Core Meeting - Crab Fit (i do apologize in advance for my availability - my timezone probably does not align very well with most people here ). I’ll pick out a final date on May 15, 2024, so please log your availability before then if you plan to join in.
The meeting time has been decided: 2024-05-18T13:00:00Z
Join the meeting on Jitsi: <removed, no longer using this meeting link>
Yeah, I know I said it somewhere else but its worth repeating, awesome job @VlinkZ you’re definitely leading the way for Aux IMO.
I’d love to get on a voice and/or video call.
It terms of short term planning though, I’m going to be traveling this next week. In particular May 16,17,18 I am likely to have no internet 95-100% of the day.
Long term My normal schedule is usually pretty flexible, so I’ll likely be able to fit in whatever times you guys pick. My timezone is CST but I’m usually up ~6:30am so we can probably find a time that overlaps with you @srxl.
From what I can see a lot of those issues are coming from tests, rather then shipped packages. Its still important to fix those, but not as imperative if it breaks the packages’ tests.
Good catch, I somehow missed that in the wall of text… might have needed some more
Maybe we could prioritize:
Fix non-test first, after that test issues
For each category fix in critical → low order
The other topic for discussion would be to see if we can use the PR workflow to check new code before committing for know vulnerabilities.
That would cover the aspect dependabot doesnt cover.
Looks like we managed to get one block where everyone’s available, so we’ll be going with that one - We’ll hold our meeting at 2024-05-18T13:00:00Z! I’ll setup a Jitsi call closer to the day that we can all jump in on.
I have a couple points I noticed while working on Core. I will put them here and join the meeting (unless something massive happens in the next 4 hours)
When a dev is iterating on Core, what is the feedback device? What do you run to know if you broke something? There’s no clear indication.
Relatedly, do we want some CI to build those jobs?
Maybe we want code formatting? I like Alejandra but it’s a bit opinionated so maybe nixpkgs-fmt is betternixfmt-rfc-style more relevant in SIG Doc
Linters while we’re at it? I have never used a Nixlang linter
Still related: is it intended to have AAAAAASomeThingsFailToEvaluate long term? Assuming Core stays relatively small it seems counterproductive
My mad little experiments in binary caching might be getting to the point where they could back something like this, but realistically none of my machines is going to survive doing proper builds. Might be just about usable all the while we’re just evaluating but not ultimately changing the derivations. Someone on matrix did tentatively volunteer a rather beefier machine!
The steering committee have discussed formatting, etc. a little bit, and there’s been a thread on the forum. The outcome was that we should stick with nixfmt-rfc-style. The documentation special interest group (who created that thread and subsequently asked steering) are planning to write contributor guides based on this, so I’ll happily link you to them when we’ve got them.
Oh dang! I must’ve done my timezones completely wrong I was thinking it was yesterday at 9am for me.
Anyways great! I’ve got like a spotty 500Kbs internet right now, so i probably wont try to talk but I’ll try to listen in on the call. Recording would be appreciated if participants are willing.
Quick thing I think is important for the agenda; PR review process.
For example, it looks like I’ve got permission to just merge one of the PR’s into main. I think a soft/subjective policy is fine for PR’s but we should probably talk about what is appropriate to just merge unilaterally and what needs a reviewreview/discussion
I’m unfortunately not going to be at the meeting (traveling so none of the times worked ).
But a few points for my perspective
Progress
Core now builds nix and lix on Linux (and Darwin once my prs are merged).
There are some extra packages needed for optional dependencies not needed for nix/lix. We should consider trimming them down while maintaining successful builds for nix/lix
build-support and common-updaters have a lot of extra not needed by core right now, they should be trimmed down.
Language packages like perl, haskell, and python have only necessary packages uncommented, the rest are commented right now to preserve structure but should be removed.
Decisions
what should be done with lib? Should it stay in core or be split?
how should we deal with language packages required by core? (Python, Haskell, perl, etc)
language packages should be in SIG repos, but what if core depends on them? I’m thinking have a minimal set of packages in core, and then the rest of the packages in a SIG repo. But that does end up splitting maintainers between core and SIG repo.
how do we want to implement testing?
how will we track maintainers? (Link with community through flake? Or have individual maintainer lists per sig?)
My opinions
I think it would be nice to split lib from core, but only if we have a good way of having the tests not cause a circular dependency. I haven’t seen a format I’ve particularly liked yet, but open to either way.
Core should contain necessary packages for building nix/lix. I’m unsure whether we should extend that to everything needed to build a minimal ISO. In order to decide we also need to make a plan on where to store NixOS modules. Since modules depend on core, if we have them in a separate repo, should that repo contain packages needed to build minimal ISO, or should core?
For meeting schedule, once every two weeks, or even every week for now would work fine with me. Hopefully I can make the next one
). I’ll pick out a final date on May 15, 2024, so please log your availability before then if you plan to join in.
I’ll add them to this post once the meeting is wrapped up.
).