-
-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Clean up contributing documentation #245243
Conversation
36278ed
to
ac80f7d
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-07-27-documentation-team-meeting-notes-67/30998/1 |
6f37135
to
cedc57b
Compare
cd21c47
to
8d4d808
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-08-08-nixpkgs-architecture-team-meeting-42/31454/1 |
Feel free to cherry-pick #248013 onto this PR and close it. 👍 |
I want to take ownership of this part of the documentation, especially with the cleanup in NixOS#245243. Doing so before that PR is merged also allows me to get notified about any potential future merge conflicts before they happen.
Not used anymore after b3fa79b
Nice work! Good to see this happening. As an example, where would the Python-specific contributing part go to? Maybe after that we could use a tool (e.g. sphinx or whatever we use now for the manual) to compile the various |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is moving in the right direction and is clearly better than what we had before.
Users are now able to navigate the repository and find out about the related documentation, instead of going to a hidden nixpkgs manual URL.
assert system == "i686-linux"; | ||
stdenv.mkDerivation { ... | ||
``` | ||
This section has been moved to [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These types of links, while useful when browsing through a browser, now hardcode the branch. I think you can just use relative links.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't use relative links because this is the rendered manual to be shown on nixos.org
where the source isn't available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff, thanks a lot!
1. [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo#forking-a-repository) the [Nixpkgs repository](https://github.com/nixos/nixpkgs/). | ||
1. [Clone the forked repository](https://docs.github.com/en/get-started/quickstart/fork-a-repo#cloning-your-forked-repository) into a local `nixpkgs` directory. | ||
1. [Configure the upstream Nixpkgs repository](https://docs.github.com/en/get-started/quickstart/fork-a-repo#configuring-git-to-sync-your-fork-with-the-upstream-repository). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
works when rendered in through GitHub, but I think you meant 1.
, 2.
, 3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's intentional, I don't really mind either way, but that's an explicitly supported GitHub Markdown feature (and I think effectively all markdown flavors support this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok good to know. I was just confused when reading through the source code.
CONTRIBUTING.md
Outdated
checkout staging-next | ||
commit id:"fixup " | ||
checkout master | ||
merge staging-next type:HIGHLIGHT id:"manual (PR)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice diagram, much clearer. Thanks!
CONTRIBUTING.md
Outdated
| branch | `master` | `staging` | `staging-next` | | ||
| --- | --- | --- | --- | | ||
| Used for development | :heavy_check_mark: | :heavy_check_mark: | :x: | | ||
| Built by Hydra | :heavy_check_mark: | :x: | :heavy_check_mark: | | ||
| [Mass rebuilds](#mass-rebuilds) | :x: | :heavy_check_mark: | :warning: Only to fix Hydra builds | | ||
| Critical security fixes | :heavy_check_mark: for non-mass-rebuilds | :x: | :heavy_check_mark: for mass-rebuilds | | ||
| Automatically merged into | `staging-next` | - | `staging` | | ||
| Manually merged into | - | `staging-next` | `master` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow, some heavy_check_mark
s gets replaced with the green one (image), and some other with the black one (emoji), which is harder to run with the dark theme. Not sure what's happening
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I saw that too, super weird. Switching to emoji's seems to make it work correctly though, so I did that: eb75810 😄
CONTRIBUTING.md
Outdated
|
||
#### Meets Nixpkgs contribution standards | ||
|
||
The last checkbox is fits the guidelines in this `CONTRIBUTING.md` file. The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really nice writup for the PR template checkboxes. I think it would be nice to change the PR template itself to indicate that there's this documentation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I am intending to update the pull request template with future PRs, let's not do it in this PR though
CONTRIBUTING.md
Outdated
|
||
It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests. | ||
- When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people’s installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from \@edolstra. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a bit weird to have this point in the "Commit conventions" section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I initially wasn't sure where it would fit, but now I'm realizing that nixos/README.md
would be great: f22e4a3 (of course, that document also desperately needs more content and a cleanup, but that's future work)
- Run package-internal tests with `nix-build --attr pkgs.PACKAGE.passthru.tests` | ||
- Run [NixOS tests](https://nixos.org/manual/nixos/unstable/#sec-nixos-tests) with `nix-build --attr nixosTest.NAME`, where `NAME` is the name of the test listed in `nixos/tests/all-tests.nix` | ||
- Run [global package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests) with `nix-build --attr tests.PACKAGE`, where `PACKAGE` is the name of the test listed in `pkgs/test/default.nix` | ||
- See `lib/tests/NAME.nix` for instructions on running specific library tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be a good place to mention nixpkgs-review
again, for completeness' sake
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I'd like to defer that to the future when I get to cleaning up the pull request template and the its corresponding section
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-08-14-documentation-team-meeting-notes-72/31722/1 |
@FRidh This would fit into the new
I like the idea! It's a bit ironic to move away from rendering the docs ourselves only to render them ourselves again later, but it does make sense when looking at the whole thing :P |
- Contributing without a GitHub account - Mention OfBorg - nix.useSandbox -> nix.settings.sandbox - nixpkgs-review is good for not just version updates Co-authored-by: Rémi NICOLE <minijackson@users.noreply.github.com>
- Fix sentence about meeting contributing standards - pkgs -> packages - Use emoji's because GitHub renders the :*: things weird sometimes - Move a dot Co-authored-by: Rémi NICOLE <minijackson@users.noreply.github.com>
This needs a rewrite at some point..
f22e4a3
to
de5a39f
Compare
I did a minor Git history cleanup by squashing all the single typo commits and other minor changes together. This is ready to be merged imo (with a merge commit ideally). |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-08-17-documentation-team-meeting-notes-73/31853/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-08-21-documentation-team-meeting-notes-74/32083/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/this-month-in-nix-docs-4-july-august-2023/32502/4 |
Motivation
For RFC 140 (implementation part 1) I want to update documentation on how to contribute packages, see here.
However, after taking a closer look, contributing documentation is currently missing, unorganized, scattered and/or duplicated throughout various documents:
README.md
containing some minimal info about branchesCONTRIBUTING.md
file, which GitHub prominently links to when you open a pull request, containing some duplicated but also updated copies from the contributing section in the manual.pkgs
. In fact that section sometimes assumes everybody just wants to make changes topkgs
#contributing
anchor..), or this one for RInstead of trying to shoehorn the documentation for RFC 140 into this mess, it would be better to first clean up the overall structure. Part of this was already discussed in #244056, and this PR will attempt to implement this roughly.
Goal
The following organization is proposed:
README.md
: A non-technical contribution introduction, links toCONTRIBUTING.md
CONTRIBUTING.md
: General contribution guidelines that apply to all of Nixpkgs, such as:README.md
's for individual parts**/README.md
: Contributing documentation specific to other parts of Nixpkgs, also linking toCONTRIBUTING.md
. This should include how to modify, test and document each part of the code base.pkgs/README.md
: Contribution documentation for packages (creating, updating, testing packages, etc.)doc/README.md
: Contribution documentation for the user manuallib/README.md
: Contributing tolib
, already done with Create a Readme inlib
#244044CONTRIBUTING.md
and only include user-level documentation:This PR will attempt to set the baseline for this by at least moving the existing documentation to the right place and making it work together.
Best reviewed commit-by-commit!
Todo
CONTRIBUTING.md
CONTRIBUTING.md
pkgs
into a newpkgs/README.md
CONTRIBUTING.md