From 02f9998754b05d417b0ebe6334d0ce5b84a31f44 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Wed, 13 Sep 2023 15:56:27 +0100 Subject: docs: submitting-patches: Suggest a longer expected time for responses While some subsystems do typically have very fast turnaround times on review this is far from standard over the kernel and is likely to set unrealistic expectations for submitters. Tell submitters to expect 2-3 weeks instead, this will cover more of the kernel. Signed-off-by: Mark Brown Reviewed-by: Javier Martinez Canillas Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20230913-submitting-patches-delay-v1-1-a2d48c5ca205@kernel.org --- Documentation/process/submitting-patches.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation/process') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index efac910e2659..3fcfa029c9b3 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -366,10 +366,10 @@ busy people and may not get to your patch right away. Once upon a time, patches used to disappear into the void without comment, but the development process works more smoothly than that now. You should -receive comments within a week or so; if that does not happen, make sure -that you have sent your patches to the right place. Wait for a minimum of -one week before resubmitting or pinging reviewers - possibly longer during -busy times like merge windows. +receive comments within a few weeks (typically 2-3); if that does not +happen, make sure that you have sent your patches to the right place. +Wait for a minimum of one week before resubmitting or pinging reviewers +- possibly longer during busy times like merge windows. It's also ok to resend the patch or the patch series after a couple of weeks with the word "RESEND" added to the subject line:: -- cgit v1.2.3