I would like to volunteer some of my time to help with the “release management” process. By that I mean tasks like approving PR’s and troubleshooting CI issues. I am a Devops Engineer for a living and use NixOS and Nix extensively.
I have a few questions:
Are you folks even looking for help ? Is there a better way to volunteer to help the project?
What is the “onboarding” process for such a volunteer? Are there simpler tasks I can start with?
What is your git strategy?
Is there a doc or blog post that I’m missing that explains all of this for me already?
Note: I’m not a Nix guru like some people here, but here are some advices while waiting for the big names.
Actually, I believe we should create a kind of “beginner friendly” task list to do tasks that should be relatively easy to do (like “review this PR”, or “package this package in nixpkgs”, “add documentation for XXX”…) and might help to get started with Nix’s contributions. As far as I know for now we don’t have such thing.
But first, welcome and thanks a lot for proposing your help! To answer your questions:
yes, Nix’s community is always happy to get help! I can think of a few ways to help nix:
Help with reviewing as you propose. This is great as people are struggling to find reviewers and encounter a “PR crisis” with too many open PR.
Help newcomers by answering their question on this forum/matrix’s live chat/… You can learn a lot from that as well.
Help with documentation (you may need to read a bit the code of the modules etc… to document what is not yet documented), or help improving the wiki
Help to fix bugs (it may not be the simplest thing to start with)
Help to upgrade or package new packages.
but reviewing is I think the simplest and most useful way to help.
I guess the simplest thing is to go through the list of PR (or even simpler, first through this post that lists all PR waiting for reviewers) and see if you can find one that seems like easy to test (like a new package, an upgrade of a package without further dependencies…). Note that the great tool GitHub - Mic92/nixpkgs-review: Review pull-requests on https://github.com/NixOS/nixpkgs automatically compiles all binaries, so you typically want to run this tool, then run the produced binary to check if they work flawlessly, and check the code to see if it seems reasonable (note that people can use nixfmt to format the code in a unified way). Once you tested the programs changed by this PR (by running it and testing a few functionalities like saving files…, or if it’s a library by running basic code), just add a message saying that you tested it (ideally with your aarch and if you run linux or darwin) and that it looks okay to you (it’s nothing special, see for instance this PR). You might also want to check OfBorg’s automatic check (at the end of the PR) to see if it compiles fine on all platforms. If you see that a PR got enough reviews, you can add it to PRs already reviewed - #725 by Luflosi to help people see that this PR is just waiting to be merged. That’s all!
Uhm, nothing special I’d say. When anyone feels that something can be improved/updated/… they do the change and submit a PR. Then other people review it, and some people with higher priviledge will merge the change if the review went fine.
For general contribution hints, I can think of Nixpkgs - NixOS Wiki and the wiki contains various pages on how to reach for help (see main page) but it does not contain much more information (and I’m not sure you need much more :-P). Of course there is also the 3 manuals and the wiki for more technical help. If you actually want to contribute directly to nixpkgs, rg yourText (ripgrep) and find . | rg yourText in nixpkgs’s repo might be of precious help to quickly find the code that does a given task (if you don’t know what to put in yourText, typing the name of the program/library, potentially followed by = if you search for its definition, or a message that is printed by the code you wish to improve is usually a good starting point… yeah having a whole OS in a simgle repo is quite practical). I also created some tutorials to get started with packaging (and you can find various other similar resources online or on the wiki), but I’m not sure if it’s what you are asking for.
I know the title says “Release Management”, but from the rest of their text it didn’t seem to really mean what our release managers do. (a clash of terms, no problem really)
? Is there a better way to volunteer to help the project?