Make an explicit suggestion how to post user space side of kernel patches to avoid reposts when patchwork groups the wrong patches.
Signed-off-by: Jakub Kicinski <k...@kernel.org> --- Documentation/networking/netdev-FAQ.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 21537766be4d..553eda8da9c7 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -254,6 +254,26 @@ you will have done run-time testing specific to your change, but at a minimum, your changes should survive an ``allyesconfig`` and an ``allmodconfig`` build without new warnings or failures. +Q: How do I post corresponding changes to user space components? +---------------------------------------------------------------- +A: Kernel patches often come with support in user space tooling +(e.g. `iproute2`). It's best to post both kernel and user space +code at the same time, so that reviewers have a chance to see how +user space side looks when reviewing kernel code. +If user space tooling lives in a separate repository kernel and user +space patches should form separate series (threads) when posted +to the mailing list, e.g.:: + + [PATCH net-next 0/3] net: some feature cover letter + └─ [PATCH net-next 1/3] net: some feature prep + └─ [PATCH net-next 2/3] net: some feature do it + └─ [PATCH net-next 3/3] selftest: net: some feature + + [PATCH iproute2-next] ip: add support for some feature + +Posting as one thread is discouraged because it confuses patchwork +(as of patchwork 2.2.2). + Q: Any other tips to help ensure my net/net-next patch gets OK'd? ----------------------------------------------------------------- A: Attention to detail. Re-read your own work as if you were the -- 2.26.2
