[PATCH] docs: submitting-patches: Suggest a longer expected time for responses

[PATCH] docs: submitting-patches: Suggest a longer expected time for responses

[Mark Brown]

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 <broonie@kernel.org>
---
 Documentation/process/submitting-patches.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

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::

---
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
change-id: 20230912-submitting-patches-delay-a9224ba2b784

Best regards,
-- 
Mark Brown <broonie@kernel.org>

Re: [PATCH] docs: submitting-patches: Suggest a longer expected time for responses

[Javier Martinez Canillas]

Hello Mark,

On Wed, Sep 13, 2023 at 4:57 PM Mark Brown <broonie@kernel.org> wrote:
>
> 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 <broonie@kernel.org>
> ---
> Mark Brown <broonie@kernel.org>
>

Agreed that 2-3 weeks is more realistic.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Re: [PATCH] docs: submitting-patches: Suggest a longer expected time for responses

[Jonathan Corbet]

Mark Brown <broonie@kernel.org> writes:

> 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 <broonie@kernel.org>
> ---
>  Documentation/process/submitting-patches.rst | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

I was hoping to see some more comments on this; it is a fairly
significant change in the expectations we put on our reviewers.  Oh
well, I've applied it.  I wonder if we should add a note saying to look
at the maintainer profile for the subsystem in question for more
specific guidance?  Of course, it would be good to have more of those...

Thanks,

jon

Re: [PATCH] docs: submitting-patches: Suggest a longer expected time for responses

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Tue, Oct 03, 2023 at 09:33:34AM -0600, Jonathan Corbet wrote:

> I was hoping to see some more comments on this; it is a fairly
> significant change in the expectations we put on our reviewers.  Oh
> well, I've applied it.  I wonder if we should add a note saying to look
> at the maintainer profile for the subsystem in question for more
> specific guidance?  Of course, it would be good to have more of those...

It's the sort of thing that's going to vary quite a lot with things like
the point in the release cycle as well (as the existing text already
gestures towards) plus the complexity of the change, I'm not sure that
setting explicit QoS guarantees is going to work out well.  The list of
variables gets long and complicated, and the more explicit things are
the more likely someone is to be disappointed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]