[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZEhxygpFsFstKlrX@codewreck.org>
Date: Wed, 26 Apr 2023 09:35:22 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Dan Carpenter <error27@...il.com>
Cc: Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Eric Van Hensbergen <ericvh@...nel.org>,
Latchesar Ionkov <lucho@...kov.net>,
Christian Schoenebeck <linux_oss@...debyte.com>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
v9fs@...ts.linux.dev
Subject: Re: [PATCH] fs/9p: Fix a datatype used with V9FS_DIRECT_IO
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
Powered by blists - more mailing lists