From: Mark Brown <broonie@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
Fabio Aiuto <fabioaiuto83@gmail.com>,
Jie Yang <yang.jie@linux.intel.com>,
Takashi Iwai <tiwai@suse.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>
Subject: Re: [PATCH for-5.15 v3] ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP select
Date: Fri, 3 Sep 2021 17:26:39 +0100 [thread overview]
Message-ID: <20210903162639.GM4932@sirena.org.uk> (raw)
In-Reply-To: <YTI71k5EsyTgstkn@MSI.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Fri, Sep 03, 2021 at 08:14:30AM -0700, Nathan Chancellor wrote:
> For the record, the documentation for sending patches has the "Explicit
> In-Reply-To headers" section, which frowns on doing this for multi-patch
> series but never mentions this for single patches. I have never had a
> maintainer complain about me doing this in the over three years that I
I don't *mind*, there's just a chance I won't notice a patch that
appears in the middle of a thread which submitters tend to mind - the
issue is that I'm blissfully unaware. It was more that you were doing
the exact same thing again in response to it being explicitly identified
as an issue.
> changelog section. Maybe the documentation could be updated to frown
> upon adding In-Reply-To headers to new versions of patches period? I can
> draft up a patch to clarify that.
Not everyone has a process which causes issues here (and even for me I'd
only notice if the old thread was still in my inbox), but I certainly
wouldn't be against it. Note that if you're trying to make everything
super rules based you also need to cover the case of people trying to
incrementally fix a series by sending new versions of patches in the
middle of it which is an even worse mess.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Cezary Rojewski <cezary.rojewski@intel.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
Jie Yang <yang.jie@linux.intel.com>,
Takashi Iwai <tiwai@suse.com>,
Fabio Aiuto <fabioaiuto83@gmail.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>
Subject: Re: [PATCH for-5.15 v3] ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP select
Date: Fri, 3 Sep 2021 17:26:39 +0100 [thread overview]
Message-ID: <20210903162639.GM4932@sirena.org.uk> (raw)
In-Reply-To: <YTI71k5EsyTgstkn@MSI.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Fri, Sep 03, 2021 at 08:14:30AM -0700, Nathan Chancellor wrote:
> For the record, the documentation for sending patches has the "Explicit
> In-Reply-To headers" section, which frowns on doing this for multi-patch
> series but never mentions this for single patches. I have never had a
> maintainer complain about me doing this in the over three years that I
I don't *mind*, there's just a chance I won't notice a patch that
appears in the middle of a thread which submitters tend to mind - the
issue is that I'm blissfully unaware. It was more that you were doing
the exact same thing again in response to it being explicitly identified
as an issue.
> changelog section. Maybe the documentation could be updated to frown
> upon adding In-Reply-To headers to new versions of patches period? I can
> draft up a patch to clarify that.
Not everyone has a process which causes issues here (and even for me I'd
only notice if the old thread was still in my inbox), but I certainly
wouldn't be against it. Note that if you're trying to make everything
super rules based you also need to cover the case of people trying to
incrementally fix a series by sending new versions of patches in the
middle of it which is an even worse mess.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-09-03 16:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 19:03 [PATCH] ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP select Nathan Chancellor
2021-08-02 19:03 ` Nathan Chancellor
2021-08-02 21:05 ` Pierre-Louis Bossart
2021-08-02 21:05 ` Pierre-Louis Bossart
2021-08-02 21:24 ` [PATCH v2] " Nathan Chancellor
2021-08-02 21:24 ` Nathan Chancellor
2021-09-02 15:02 ` Pierre-Louis Bossart
2021-09-02 15:02 ` Pierre-Louis Bossart
2021-09-02 15:24 ` Mark Brown
2021-09-02 15:24 ` Mark Brown
2021-09-02 18:12 ` [PATCH for-5.15 v3] " Nathan Chancellor
2021-09-02 18:12 ` Nathan Chancellor
2021-09-03 10:27 ` Mark Brown
2021-09-03 10:27 ` Mark Brown
2021-09-03 15:14 ` Nathan Chancellor
2021-09-03 15:14 ` Nathan Chancellor
2021-09-03 16:26 ` Mark Brown [this message]
2021-09-03 16:26 ` Mark Brown
2021-09-03 15:18 ` Mark Brown
2021-09-03 15:18 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210903162639.GM4932@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=cezary.rojewski@intel.com \
--cc=fabioaiuto83@gmail.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.com \
--cc=yang.jie@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.