Date:   Thu, 18 Nov 2021 00:34:18 +0000
From:   Vincent Pelletier <plr.vincent@gmail.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Qiu Wenbo <qiuwenbo@kylinos.com.cn>,
        devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org,
        David Abdurachmanov <david.abdurachmanov@sifive.com>
Subject: Re: [PATCH v2 1/6] riscv: dts: sifive unmatched: Name gpio lines
Message-ID: <20211118003418.2edd1913@gmail.com>
In-Reply-To: <1444ff08-24a6-afbe-1512-9ea24ad5b32d@canonical.com>
References: <bb7e8e36425a2c243cfbf03a23af525499268822.1637107062.git.plr.vincent@gmail.com>
 <1444ff08-24a6-afbe-1512-9ea24ad5b32d@canonical.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 17 Nov 2021 10:28:59 +0100, Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> On 17/11/2021 00:57, Vincent Pelletier wrote:
> > Follow the pin descriptions given in the version 3 of the board schematics.
> > 
> > Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
> > 
> > --
> > Changes since v1:
> > - Remove trailing "." on subject line.
> > ---  
> 
> This is not a correct changelog placement - you have to use '---' just
> like git uses it. Just test it yourself and you will see the problem.

Indeed, thanks for catching this.

Is there a recommended way for managing these not-for-commit-message
chunks automatically ?
I obviously compose them by hand so far, and put them in my local git
working copy commit messages, but I would be happier if I did not have
to make (bad) decisions on such mechanical detail.

On a related topic, is there a way to automate "git send-email"
recipient list using get_maintainer.pl (plus some more magic lines,
for example to exclude bouncing addresses) ?

While process/submitting-patches.rst describes what the result should
look like, it feels to me that it (or another related file) could be
more directive on what commands/workflows help to get such result, for
casual contributors like myself. Have I missed such documentation ?

Regards,
-- 
Vincent Pelletier
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1