drashna/qmk_firmware
1
0
Fork 0
Code Activity Actions

Initial deprecation policy documentation. (#19908)

Browse source
This commit is contained in:
Nick Brassel 2023-03-03 14:16:32 +11:00 • committed by GitHub
parent 7ebb8c2dec
commit d1a430b348
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 51 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/pr_checklist.md
View file

@ -145,7 +145,13 @@ Also, specific to ChibiOS:
## Core PRs :id=core-pr
- must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
- all core PRs must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
- as indicated above, the smallest set of changes to core components should be included in each PR
- PRs containing multiple areas of change will be asked to be split up and raised separately
- keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `via`, `default_????` keymaps etc.
- keymap modifications for anything other than the default-like keymaps **should not be included in the initial PR** in order to simplify the review process
- the core PR submitter should submit a followup PR affecting other keymaps after initial PR merge
- large-scale refactoring or consolidation PRs that affect other keymaps (such as renaming keycodes) should always be raised separately
- any new boards adding support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey`
- for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified
- for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided