Hi Jens,
On 6/07/23 09:44, Jens Axboe wrote:
On 7/5/23 3:41?PM, Michael Schmitz wrote:
Hi Jens,
On 6/07/23 08:42, Jens Axboe wrote:
On 7/4/23 5:38?PM, Michael Schmitz wrote:
Reported-by: Christian Zigotzky <chzigotzky@xxxxxxxxxxx>
Fixes: b6f3f28f60 ("block: add overflow checks for Amiga partition support")
Cc: <stable@xxxxxxxxxxxxxxx> # 5.2
This is confusing - it's being marked for stable, but also labeled as
fixing a commit that isn't even a release yet?
True - but as you had pointed out, the commit this fixes is set in
stone. How do we ensure this bugfix is picked up as well when the
other patches are backported? Does that happen automatically, or do I
need to add a Link: tag to the patch being fixed?
This:
Cc: <stable@xxxxxxxxxxxxxxx> # 5.2
should be enough for it to go into stable from 5.2 and onwards.
OK - I wasn't certain whether you wanted the Fixes or stable tag dropped.
(Greg didn't seem to object to the Fixes: as such, just to the
incorrect version prereq)
I think it's really confusing... A patch should only have a Fixes tag if
it's fixing a specific bug in that patch. Either it is, in which case
you would not need Cc stable at all since it's only in 6.5-rc, or it
It is fixing a bug in b6f3f28f60. I should have checked whether the
patch series had already gone to release, not just -rc, instead of just
adding the stable tag out of caution.
isn't and you should just have the stable tag with 5.2+ as you already
have.
I'll apply this and remove the Fixes line, and the message id thing
too.
Thanks - whatever is least confusing is fine, as long as it's backported
to stable in the end.
Won't be sending v5 then...
Cheers,
Michael
