From: Dominique Martinet <asmadeus@codewreck.org>
To: Dan Carpenter <error27@gmail.com>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Eric Van Hensbergen <ericvh@kernel.org>,
Latchesar Ionkov <lucho@ionkov.net>,
Christian Schoenebeck <linux_oss@crudebyte.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
v9fs@lists.linux.dev
Subject: Re: [PATCH] fs/9p: Fix a datatype used with V9FS_DIRECT_IO
Date: Wed, 26 Apr 2023 09:35:22 +0900 [thread overview]
Message-ID: <ZEhxygpFsFstKlrX@codewreck.org> (raw)
In-Reply-To: <CA+_b7DK1s87y-_-D3sQxteqJ+78uvKza-vgWGv9SmGm-tqz7DA@mail.gmail.com>
Dan Carpenter wrote on Tue, Apr 25, 2023 at 02:14:52PM +0100:
> The hash is constant unless Eric does a rebase. When a maintainer rebases
> then updating the fixes tags is just part of the process. Often they end up
> folding the fix into the original patch at that point so the Fixes tag is not
> required. If a maintainer doesn't update the tags then the linux-next
> maintainers will notice and complain.
Good to know this is checked as part of the linux-next tree checks.
> #GitMagic
This isn't magic, this is painful to update manually and easy to forget,
which is why as a maintainer I'd appreciate having a heads up here and
why I mentioned it.
(I'm sure Eric would have noticed anyway given this is fixing one of the
patchs he really wants to get in this merge window... But, well, in
general)
Re: folding into the original patch or not is also tricky as it weakens
recognition to the contributor, so I tend to keep such fixes separate
unless the tree becomes completely unusable (e.g. doesn't build) for
bisectability.
(I really, really wish there was a more mainlined maintainer process
though, so each maintainer wouldn't have to come up with their own rules
and tricks for everything... But I think that's a lost battle at this
point)
--
Dominique Martinet | Asmadeus
prev parent reply other threads:[~2023-04-26 0:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-25 6:47 [PATCH] fs/9p: Fix a datatype used with V9FS_DIRECT_IO Christophe JAILLET
2023-04-25 7:08 ` Dominique Martinet
2023-04-25 9:18 ` Christian Schoenebeck
2023-04-25 10:40 ` Dominique Martinet
2023-04-25 12:19 ` Christian Schoenebeck
2023-04-25 13:14 ` Dan Carpenter
2023-04-26 0:35 ` Dominique Martinet [this message]
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=ZEhxygpFsFstKlrX@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=ericvh@kernel.org \
--cc=error27@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=v9fs@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox