# 2024-06-05 Nix team meeting minutes #150
**URL:** https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583
**Category:** Nix
**Created:** [June 6, 2024, 8:25am UTC](https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583 "2024-06-06T08:25:57Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@fricklerhandwerk](https://discourse.nixos.org/u/fricklerhandwerk)
#### Post date: [June 6, 2024, 8:25am UTC](https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583/1 "2024-06-06T08:25:57Z")
Attendees: @edolstra @roberth @Ericson2314 @fricklerhandwerk @puckipedia @Mic92
Notes: @fricklerhandwerk
## STF sponsoring developer time
- @fricklerhandwerk talked with [Neighbourhoodie](https://neighbourhood.ie/), the contractor offering developer time as part of the [Sovereign Tech Fund Bug Resilience Program](https://www.sovereigntechfund.de/programs/bug-resilience)
- the opportunity was [mentioned on Matrix on 2024-05-16](https://matrix.to/#/!VRULIdgoKmKPzJZzjj:nixos.org/$PoRNkg-IQXIGHdpOr97TVu8Cn8RxzqCzFf-AbS4C7Xg) to get some maintainer quick feedback, since applications are first-come-first-serve
- the offer also includes funding for a bug bounty program ([asked the security team](https://matrix.to/#/!NBBFPbiuttRgTqbrcY:nixos.org/$_fCU9CltiBW_l-nEIT-6791LS0rTsbA4yL-m-2pzVxo), but @RaitoBezarius opposed the idea) and a security audit (not clear where it could be meaningfully applied)
- Neighborhoodie could hire a C++ expert to work with us over a couple of months
- For us it’s a trade-off, since accepting contributions also costs precious maintainer time, but this particular setup seems to be worth it
- @fricklerhandwerk’s wishlist, based on [last year’s proposal](https://github.com/NixOS/foundation/issues/107) developed with @tomberek and @Ericson2314:
- primary goal: [reduce time required](https://hydra.nixos.org/job/nix/master/coverage#tabs-charts) for (incremental) builds and testing, i.e. reduce friction for contributors
- [port the build setup to Meson](https://github.com/NixOS/nix/issues/2503), one derivation per component (can steal from Lix)
- upstream the Rust installer [as discussed months ago](https://discourse.nixos.org/t/2023-04-03-nix-team-meeting-minutes-46/27008#installer-2) (can steal from Lix)
- port [parser optimizations](https://github.com/NixOS/nix/pull/9989) from Lix
- [test and fix NIX\_PATH](https://github.com/NixOS/nix/issues/9574)
- add tests for the daemon
- refactor tests to be runnable in the devshell _and_ in NixOS VMs (where possible)
- run store tests in-memory
- run the same store tests on all store types
- maybe automate the [Nixpkgs-side testing](https://github.com/NixOS/nixpkgs/pull/314065#issuecomment-2146741385)
- @Ericson2314: most of the work is probably figuring out what to do, and is barely related to C++
- communication overhead would not be a good use of contributor’s time
- test evaluator against all stable Nixpkgs releases
- get rid of [global configuration](https://github.com/NixOS/nix/issues/5638), pass structs to library components
- [declarative signature specification for builtins](https://github.com/NixOS/nix/issues/10373)
- [allow building documentation independent of the binaries](https://github.com/NixOS/nix/issues/8518)
- automatic formatting and linting everywhere
- a bunch of refactorings and clean-ups
- nix-prefetch-url should use the fetcher cache
- make the eval cache available to stable Nix expressions
- separate out built-in fetchers to the level of plugins (and ideally document the plugin mechanism)
- maybe get rid of most of GitHub actions (those really amount to starting a VM and running `nix(-)build`])
- generally simplify the release process
- no additions to the wishlist by the team
- @Ericson2314 will take time over the weekend to help condense this into a statement of work to get approved by STF, and make sure the goals are up to date with current reality of the code base
## Improving Nix testing for Nixpkgs releases
- proposal by @edolstra
- [proposal by @raitobezarius](https://github.com/NixOS/nixpkgs/pull/315262#issuecomment-2139592225)
- @Mic92: could have a special branch for bumping Nix versions that Hydra observes
- discussed current state of the [Nix release manual](https://github.com/NixOS/nix/blob/b0283240a107d553981e5c7517ba0af6eb7e8e8a/maintainers/release-process.md)
---
### Author:  [@fricklerhandwerk](https://discourse.nixos.org/u/fricklerhandwerk)
#### Post date: [June 25, 2024, 11:17am UTC](https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583/2 "2024-06-25T11:17:22Z")
Update on the application to the STF bug resilience program:
Neighborhoodie wasn’t able to support us after all. STF suggested to apply for the [general investment program](https://www.sovereigntechfund.de/programs/applications) instead. @fricklerhandwerk and @RaitoBezarius had a call with Tara from STF to clarify boundary conditions. Meeting notes:
- Selection criteria:
- Is it important? Is it vulnerable?
- Do people depend on it? Will people miss it if it’s gone tomorrow?
- Is it used by a lot of people? Or if it’s a few, are they somehow critical?
- Power production, hospitals, academia, gymnjjournalists…
- Main criterion: Does it concern public interest?
- Not funding new features or prototypes
- Goal is to fund maintenance, or making maintenance of other tools easier
- Improving CI/CD for the project is in scope, if it would make maintenance easier or the supply chain more secure
- Improving resilience of the project may leave room for community work
- For example, Reproducible Builds has some community work
- The first proposal is considered as a whole, and details can be iterated on in the second proposal phase
- It’s not a grant, but more like a government procurement process
- Propose what you need to do, and we will look at the costs and if the plans are reasonable
- Too much work for too little time is not realistic
- It’s not comparable with the “contribute back challenges”, those were supposed to do heavy lifting
- Working with the same budget as last year, but with a lot more applications
- 1M EUR budget, as for GNOME, is an outlier
- You have to consider that those bigger investments supports several software projects simultaneously
- Median so far was 200-300k EUR over 1-1.5 years
- But it’s contextual. If you make a strong argument and strongly believe in what you’re proposing, try it and it can be discussed
- Things that are upstreamable or work across the ecosystem are particularly strong points
- The overarching goal is to make open source infrastructure more resilient as a whole
- The timeline can be up to 2 years, but a second year would be tentative
- One can also have shorter commitments and then apply for something else afterwards
- Depends on the project’s needs and the concrete proposal