NotAShelf/nvf
2
1
Fork 0
mirror of https://github.com/NotAShelf/nvf.git synced 2025-10-31 02:52:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

meta: include hacking guidelines in PR template

Browse source
This commit is contained in:
raf 2025-01-28 16:17:02 +03:00
commit 90abd270a6
No known key found for this signature in database
GPG key ID: EED98D11B85A2819
1 changed files with 12 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

17
.github/PULL_REQUEST_TEMPLATE/pull_request_template.md vendored
View file

@ -7,14 +7,17 @@ or dependency in this section.
If your pull request aims to fix an open issue or a please bug, please also link the relevant issue If your pull request aims to fix an open issue or a please bug, please also link the relevant issue
below this line. You may attach an issue to your pull request with `Fixes #<issue number>` outside below this line. You may attach an issue to your pull request with `Fixes #<issue number>` outside
this comment, and it will be closed when your pull request is merged. this comment, and it will be closed when your pull request is merged.
A developer package template is provided in flake/develop.nix. If working on a module, you may use
it to test your changes with minimal dependency changes.
--> -->
## Sanity Checking ## Sanity Checking
<!-- <!--
Please check all that apply. As before, this section is not a hard requirement but checklists with more checked Please check all that apply. As before, this section is not a hard requirement but checklists with more checked
items are likely to be merged faster. You may save some time in maintainer review by performing self-reviews here items are likely to be merged faster. You may save some time in maintainer reviews by performing self-reviews
before submitting your pull request. here before submitting your pull request.
If your pull request includes any change or unexpected behaviour not covered below, please do make sure to include If your pull request includes any change or unexpected behaviour not covered below, please do make sure to include
it above in your description. it above in your description.
@ -22,9 +25,11 @@ it above in your description.
[editorconfig]: https://editorconfig.org [editorconfig]: https://editorconfig.org
[changelog]: https://github.com/NotAShelf/nvf/tree/main/docs/release-notes [changelog]: https://github.com/NotAShelf/nvf/tree/main/docs/release-notes
[hacking nvf]: https://notashelf.github.io/nvf/index.xhtml#sec-guidelines
- [ ] I have updated the [changelog] as per my changes - [ ] I have updated the [changelog] as per my changes
- [ ] I have tested, and self-reviewed my code - [ ] I have tested, and self-reviewed my code
- [ ] My changes fit guidelines found in [hacking nvf]
- Style and consistency - Style and consistency
- [ ] I ran **Alejandra** to format my code (`nix fmt`) - [ ] I ran **Alejandra** to format my code (`nix fmt`)
- [ ] My code conforms to the [editorconfig] configuration of the project - [ ] My code conforms to the [editorconfig] configuration of the project
@ -34,9 +39,10 @@ it above in your description.
- [ ] I have added a section in the manual - [ ] I have added a section in the manual
- [ ] _(For breaking changes)_ I have included a migration guide - [ ] _(For breaking changes)_ I have included a migration guide
- Package(s) built: - Package(s) built:
- [ ] `.#nix` (default package) - [ ] `.#nix` _(default package)_
- [ ] `.#maximal` - [ ] `.#maximal`
- [ ] `.#docs-html` (manual, must build) - [ ] `.#docs-html` _(manual, must build)_
- [ ] `.#docs-linkcheck` _(optional, please build if adding links)_
- Tested on platform(s) - Tested on platform(s)
- [ ] `x86_64-linux` - [ ] `x86_64-linux`
- [ ] `aarch64-linux` - [ ] `aarch64-linux`
@ -46,7 +52,8 @@ it above in your description.
<!-- <!--
If your changes touch upon a portion of the codebase that you do not understand well, please make sure to consult If your changes touch upon a portion of the codebase that you do not understand well, please make sure to consult
the maintainers on your changes. In most cases, making an issue before creating your PR will help you avoid duplicate the maintainers on your changes. In most cases, making an issue before creating your PR will help you avoid duplicate
efforts in the long run. efforts in the long run. `git blame` might help you find out who is the "author" or the "maintainer" of a current
module by showing who worked on it the most.
--> -->
--- ---