.github: markdown syntax fixes and new section on code signing

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit is contained in:
Joachim Wiberg
2025-11-20 10:45:45 +01:00
parent c2e422a91b
commit b65aa32fbb
2 changed files with 181 additions and 93 deletions
+27 -29
View File
@@ -3,41 +3,39 @@ Checklists for Pull Requests and Releases
Maintainer checklists for reviewing pull requests and doing releases.
Pull Requests
-------------
- If applicable, is there a readable ChangeLog entry?
- If any LICENSE file has been updated, has the `.hash` file been updated?
- If any change to a Finit `.svc` file, does any run/task linger?
I.e., is there a runlevel and/or condition defined to prevent them
from running outside of their intended runlevel?
- If any change to grub or qemu/qeneth setup, has it been tested in GNS3?
- If any change to u-boot/buildroot, has it been tested with `<booloader>_defconfig`
- If any change to logging, have the resulting logs been audited?
- Check for duplicate entries, misspellings
- Check for sneaky severity changes, e.g., error vs note, error vs warning
- If new subsystem, or major changes to a subsystem, have the docs been updated?
- If change to mDNS, has it been tested with netbrowse?
- If change to `_defconfig`, verify `local.mk` and sync with other archs
- Test manually as well, e.g., CLI changes do not have ha regression tests
- Build from distclean, or use artifacts built by build servers, for manual tests
- If applicable, is there a readable ChangeLog entry?
- If any LICENSE file has been updated, has the `.hash` file been updated?
- If any change to a Finit `.svc` file, does any run/task linger?
I.e., is there a runlevel and/or condition defined to prevent them
from running outside of their intended runlevel?
- If any change to grub or qemu/qeneth setup, has it been tested in GNS3?
- If any change to u-boot/buildroot, has it been tested with `<booloader>_defconfig`
- If any change to logging, have the resulting logs been audited?
- Check for duplicate entries, misspellings
- Check for sneaky severity changes, e.g., error vs note, error vs warning
- If new subsystem, or major changes to a subsystem, have the docs been updated?
- If change to mDNS, has it been tested with netbrowse?
- If change to `_defconfig`, verify `local.mk` and sync with other archs
- Test manually as well, e.g., CLI changes do not have ha regression tests
- Build from distclean, or use artifacts built by build servers, for manual tests
Releases
--------
Recommended checkpoints, use at your own discretion:
- Make at least one -betaN release to verify the GitHub workflow well in time release day
- Stuff happens, remember kernelkit/infix#735
- Make at least one -rcN to flush out any issues in customer repos
- Easy to forget adaptations/hacks in customer repos -- may need Infix change/support
- Verify release artifacts (checksums, completeness, no corrupted files)
- Test on actual hardware for at least one architecture
- Review ChangeLog for completeness
- Check for release-blocking issues
- Verify generated GNS3 appliance, no marketplace update on -rc builds
- Ensure the markdown link for the release diff is updated
- Ensure subrepos are tagged (can be automated, see kernelkit/infix#393)
- Sync tags for all repo. sync activities
- Make at least one -betaN release to verify the GitHub workflow well in time release day
- Stuff happens, remember kernelkit/infix#735
- Make at least one -rcN to flush out any issues in customer repos
- Easy to forget adaptations/hacks in customer repos -- may need Infix change/support
- Verify release artifacts (checksums, completeness, no corrupted files)
- Test on actual hardware for at least one architecture
- Review ChangeLog for completeness
- Check for release-blocking issues
- Verify generated GNS3 appliance, no marketplace update on -rc builds
- Ensure the markdown link for the release diff is updated
- Ensure subrepos are tagged (can be automated, see kernelkit/infix#393)
- Sync tags for all repo. sync activities