Reviewers may not receive new versions of patches via the lists.
Without a directed notification to them they might miss those new
versions.

This is frustrating for the patch developers as they don't receive their
earned Reviewed-by.
It is also frustrating for the reviewers, as they might think their
review got ignored or they have to dig up new versions from the archive
manually.

So encourage patch submitters to make sure that all reviewers get
notified also when no Reviewed-by was issued yet.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 Documentation/process/submitting-patches.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index efac910e2659..8dca82dfcd69 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -327,6 +327,8 @@ politely and address the problems they have pointed out.  When sending a next
 version, add a ``patch changelog`` to the cover letter or to individual patches
 explaining difference against previous submission (see
 :ref:`the_canonical_patch_format`).
+Notify reviewers and other involved people about new versions of your patch by
+adding them to the patches CC list.
 
 See Documentation/process/email-clients.rst for recommendations on email
 clients and mailing list etiquette.

---
base-commit: 633b47cb009d09dc8f4ba9cdb3a0ca138809c7c7
change-id: 20230926-docs-cc-reviewer-023b3730af23

Best regards,
-- 
Thomas Weißschuh <linux@weissschuh.net>

NAK.

This does not scale.  Please read the mailinglist, that's the whole
point of having it.

Hi Christoph,

On 2023-09-28 02:13:35-0700, Christoph Hellwig wrote:
> NAK.

That's honestly surprising.

I mentioned this process in various reviews before and nobody
had issues with it so far.

> This does not scale.

Could you elaborate in which way it doesn't scale?

> Please read the mailinglist, that's the whole
> point of having it.

When reviewing things in various subsystem this would require reading
all of LKML, which is impractical.

The goal of this patch was to make life easier for occasional reviewers.
If it negatively impacts the maintainers then that's not gonna work.


Thomas

On Fri, Sep 29, 2023 at 09:24:57AM +0200, Thomas Weißschuh wrote:
> > This does not scale.
> 
> Could you elaborate in which way it doesn't scale?

If I send a modest cross-subsystem series it often touches 20+
subsystems.  Between mailing lists and maintainers that's usually
already 60+ recipients.  If you now add a another 2-3 maintainers
we're just going to hit limits in mail servers.

> > Please read the mailinglist, that's the whole
> > point of having it.
> 
> When reviewing things in various subsystem this would require reading
> all of LKML, which is impractical.

Works with your maintainers to have useful lists for their subsystems.
That's again the point.

On Sun, 01 Oct 2023, Christoph Hellwig <hch@infradead.org> wrote:
> On Fri, Sep 29, 2023 at 09:24:57AM +0200, Thomas Weißschuh wrote:
>> > This does not scale.
>> 
>> Could you elaborate in which way it doesn't scale?
>
> If I send a modest cross-subsystem series it often touches 20+
> subsystems.  Between mailing lists and maintainers that's usually
> already 60+ recipients.  If you now add a another 2-3 maintainers
> we're just going to hit limits in mail servers.

I thought this was about adding people who have commented on previous
versions to Cc. That's usually a very limited number.

BR,
Jani.


-- 
Jani Nikula, Intel

On Mon, Oct 02, 2023 at 10:36:01AM +0300, Jani Nikula wrote:
> On Sun, 01 Oct 2023, Christoph Hellwig <hch@infradead.org> wrote:
> > On Fri, Sep 29, 2023 at 09:24:57AM +0200, Thomas Weißschuh wrote:
> >> > This does not scale.
> >> 
> >> Could you elaborate in which way it doesn't scale?
> >
> > If I send a modest cross-subsystem series it often touches 20+
> > subsystems.  Between mailing lists and maintainers that's usually
> > already 60+ recipients.  If you now add a another 2-3 maintainers
> > we're just going to hit limits in mail servers.
> 
> I thought this was about adding people who have commented on previous
> versions to Cc. That's usually a very limited number.

Oh, that absolutely makes sense.  But maybe we need to stop overloading
the term reviewer :)

On 2023-10-02 01:50:11-0700, Christoph Hellwig wrote:
> On Mon, Oct 02, 2023 at 10:36:01AM +0300, Jani Nikula wrote:
> > On Sun, 01 Oct 2023, Christoph Hellwig <hch@infradead.org> wrote:
> > > On Fri, Sep 29, 2023 at 09:24:57AM +0200, Thomas Weißschuh wrote:
> > >> > This does not scale.
> > >> 
> > >> Could you elaborate in which way it doesn't scale?
> > >
> > > If I send a modest cross-subsystem series it often touches 20+
> > > subsystems.  Between mailing lists and maintainers that's usually
> > > already 60+ recipients.  If you now add a another 2-3 maintainers
> > > we're just going to hit limits in mail servers.
> > 
> > I thought this was about adding people who have commented on previous
> > versions to Cc. That's usually a very limited number.
> 
> Oh, that absolutely makes sense.  But maybe we need to stop overloading
> the term reviewer :)

Thanks Jani for fixing the misunderstanding!

I'll try to find some better wording.

On Thu, Sep 28, 2023 at 02:13:35AM -0700, Christoph Hellwig wrote:
> NAK.
> 
> This does not scale.  Please read the mailinglist, that's the whole
> point of having it.

Can lei help here, would there be a way to match on new versions of a
series based on who was in the mail thread for previous versions ?

-- 
Regards,

Laurent Pinchart