Documentation: RISC-V: patch-acceptance: mention patchwork's role

Palmer suggested at some point, not sure if it was in one of the
weekly linux-riscv syncs, or a conversation at FOSDEM, that we
should document the role of the automation running on our patchwork
instance plays in patch acceptance.

Add a short note to the patch-acceptance document to that end.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://lore.kernel.org/r/20230606-rehab-monsoon-12c17bbe08e3@wendy
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
This commit is contained in:
Conor Dooley 2023-06-06 07:59:19 +01:00 committed by Palmer Dabbelt
parent 99a670b206
commit b104dbedbe
No known key found for this signature in database
GPG Key ID: 2E1319F35FBB1889
1 changed files with 18 additions and 0 deletions

View File

@ -16,6 +16,24 @@ tested code over experimental code. We wish to extend these same
principles to the RISC-V-related code that will be accepted for
inclusion in the kernel.
Patchwork
---------
RISC-V has a patchwork instance, where the status of patches can be checked:
https://patchwork.kernel.org/project/linux-riscv/list/
If your patch does not appear in the default view, the RISC-V maintainers have
likely either requested changes, or expect it to be applied to another tree.
Automation runs against this patchwork instance, building/testing patches as
they arrive. The automation applies patches against the current HEAD of the
RISC-V `for-next` and `fixes` branches, depending on whether the patch has been
detected as a fix. Failing those, it will use the RISC-V `master` branch.
The exact commit to which a series has been applied will be noted on patchwork.
Patches for which any of the checks fail are unlikely to be applied and in most
cases will need to be resubmitted.
Submit Checklist Addendum
-------------------------
We'll only accept patches for new modules or extensions if the