From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Fri, 06 Mar 2026 12:58:54 GMT
Subject: Re: [PATCH] Documentation: extend guidance for submitting patches
Message-ID: <aarPjlYv0H10rNKJ@fruit.crustytoothpaste.net>
In-Reply-To: <20260305193836.973122-1-jltobler@gmail.com>

On 2026-03-05 at 19:38:36, Justin Tobler wrote:
> +It is also a good idea to check whether your topic has been discussed
> +previously on the mailing list, or whether similar work is already in
> +progress.  Prior discussions may contain useful context, design
> +considerations, or earlier attempts at solving the same problem. Being
> +aware of such discussions can help you avoid duplicating work and may
> +allow you to coordinate with other contributors working in the same
> +area.

This seems reasonable.  We've had cases of patch series that have
stalled due to a minor issue and someone wanting to send a patch may
find that they really could fix that minor issue on top of the existing
patch and have their problem solved.  Or at least, they might be
inclined to not get stuck in the same way.

I try to do this anyway, but it's much easier on forge-style systems
than it is on a mailing list, so mentioning it may help refresh people's
memories.

You could, if you wanted to, link to `{gitml}` after the phrase “the
mailing list,” which might help folks find the right location.  Or you
could link to the https://lore.kernel.org/git/ archives instead via a
footnote.

> +It is often beneficial to allow some time for reviewers to provide
> +feedback before sending a new version, rather than sending an updated
> +series immediately after receiving a review. This helps collect broader
> +input and avoids unnecessary churn from many rapid iterations.

I think this is a good idea, too.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA