[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72nrPiTmuFStm5fmOZZM8e_4TGHFyC_77+cSqPp8yC8nUQ@mail.gmail.com>
Date: Mon, 5 Jan 2026 11:39:50 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Danilo Krummrich <dakr@...nel.org>, sashal@...nel.org, Marko Turk <mt@...koturk.info>,
Dirk Behme <dirk.behme@...il.com>, dirk.behme@...bosch.com, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 2/2] rust: pci: fix typo in Bar struct's comment
On Mon, Jan 5, 2026 at 7:25 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> It all depends, sometimes we can handle file moves easily, sometimes we
> can not.
>
> But really, why is a comment typo being needed in stable kernels?
It isn't (well, it is not just a comment since it does end up in the
rendered docs, so it is a bit more "visible" than in a comment, and I
imagine some projects reasonably treat them as a fix, but still, it is
just a typo).
We discussed this years ago when I noticed a typo being picked up by
stable since I wondered why. On my side, I am happy either way -- what
I currently do is explicitly tag the ones that appear in docs. That
way you can decide on your side.
For the others (the ones in comments), I think it is not really worth
it to even figure out a Fixes: tag etc.
Of course, this is for trivial typos -- for something that e.g.
completely changes the requirements of a `# Safety` precondition the
story is different.
Cheers,
Miguel
Powered by blists - more mailing lists