Re: [PATCH] Documentation: extend guidance for submitting patches

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 6, 2026, 12:58 UTC
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:

Show 7 quoted lines

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