-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Funding]: Nix team funding for RFC134 and C-API #107
Comments
👍 for getting that kind of process sorted out. Some points I have in my head: |
With #103 addressed the team could take care of funding itself, at least to some degree. We'd still need help from e.g. marketing with outreach. Ideally we'd have a combination of base funding by the foundation with direct corporate and community donations. |
Related: NixOS/teams-collaboration#2 If we agree on a funding scheme for teams, we should probably have a dedicated budget in the foundation's Open Collective, as well as teams having access to their own projects. |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/is-summer-of-nix-worth-the-money/43856/1 |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583/1 |
(this is currently still in-progress and will be updated/edited)
Team funding
Whereas, there is not a process for funding of teams,
and the Nix team has an identifiable and approved need;
in order to help establish a formal team budgeting process,
this is a request for funding from the NixOS Foundation.
Purpose
Details
isolating and polishing a store-only Nix (RFC 134)
Split out the Nix store as a stand-alone tool, complete with
A separate command-line executable which doesn’t depend on the Nix language implementation proving it is story-only.
“functional tests” of that CLI
These can be in our existing style of simple shell scripts exercising the CLI.
documentation
CLI documentation is already auto-generated, and so rending just a subset of commands/features is rote. But we should improve the prose documentation of store layer concepts, which would be part of the store-layer manual and full Nix manual alike.
Add a C API to the Nix store
The goal is to provide a simpler ABI for FFI for bindings in other languages, easing the barrier for high-performance projects built atop the store layer.
(note: The Nix store layer isn’t just for interacting with local-file-system /nix/store, but also includes interacting with the daemon, binary caches, and many associated tasks. Interfaces in the code already exist reflecting the fact that these are the same conceptional tasks implemented many different ways.)
Deliverables
Split out the Nix store as a stand-alone tool:
Add a C API to the Nix store (~2weeks)
Common tasks
Additionally, there are some code quality / “state of good repair” tasks that are not specific to either initiative but heavily relied upon by both:
total: 47d
Expected benefits
Budget amount
30,000 EUR for 300 hours of work
Conflicts of interest and Notices
Process and expectations
References
Proposal repository
The text was updated successfully, but these errors were encountered: