ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Theodore Ts'o <tytso@mit.edu>, Sasha Levin <sashal@kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit@lists.linux.dev
Subject: Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches
Date: Wed, 17 Jul 2024 17:05:06 -0500	[thread overview]
Message-ID: <ad9720d8-6b4e-4f7c-bf72-b3c2db8887d4@suswa.mountain> (raw)
In-Reply-To: <87frs91qat.wl-tiwai@suse.de>

On Tue, Jul 16, 2024 at 02:20:42PM +0200, Takashi Iwai wrote:
> > > > The one question I have is for patches which pre-date git.  I was told
> > > > to leave the Fixes tag off in that case, but I think that's out of date.
> > > > It's more useful to say "Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")".
> > > 
> > > If a thing was there since before git and only now is being discovered
> > > it either needs to be explicitly marked for stable with cc: or we can
> > > just keep the fix in newer kernels. IMO this particular "Fixes" tag does
> > > not bring any value.
> > 
> > On the contrary, if I see just a "cc: stable" and no "Fixes:" tag, I do
> > a "best effort" to backport to all current stable/lts trees.  If it
> > fails on 5.15 and older, great, I don't warn anyone about that as there
> > was no Fixes: tag for me to know how far back it should go.
> 
> That's what I expected for the cases I put only Cc-to-stable; they
> have been mostly some trivial quirks only for new devices, and the
> stuff that can be taken safely when applicable -- otherwise just
> skip.
> 

That's the same thing that happens if you add the Fixes: 1da177e4c3f4
("Linux-2.6.12-rc2") tag.  Greg and Sasha aren't manually backporting
patches unless they seem security related.  When a patch doesn't
backport cleanly, the stable maintainers rely on other people to backport
patches they care about.

Eventually, if patches don't apply then they're manually reviewed.  I
find it really frustrating to review stable patches without a Fixes tag.
When I see it I think that probably I wouldn't have had to manually
review the failed patch at all if they had used a Fixes tag.  (I just
naturally start assuming the worst about people after I've spent five
hours backporting patches.  I'm not going to investigate it either
because it's not security related.  I'm just going to assume the worse,
say some curse words, and move on.)

Of course, for security related stuff the Fixes tag is absolutely
essential.  For example, this patch does not backport cleanly to 4.14
kernels.
https://lore.kernel.org/all/20240501125448.896529-1-edumazet@google.com/
It's really nice that Eric Dumazet added a Fixes: 1da177e4c3f4
("Linux-2.6.12-rc2").

As a upstream reviewer, I think the Fixes tag is important as well.  I
don't think I've ever used the Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
tag because I know it annoys people but I write that "This bug has been
there since before git" because the information is useful.

regards,
dan carpenter

  reply	other threads:[~2024-07-17 22:05 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-14 12:31 Sasha Levin
2024-07-14 13:35 ` James Bottomley
2024-07-14 15:35   ` Andrew Lunn
2024-07-14 16:34     ` James Bottomley
2024-07-14 18:38   ` Sasha Levin
2024-07-14 19:20     ` James Bottomley
2024-07-14 20:18       ` Sasha Levin
2024-07-15 18:00         ` Theodore Ts'o
2024-07-15 18:07           ` Mark Brown
2024-07-15 19:06           ` Dan Carpenter
2024-07-15 19:23             ` Steven Rostedt
2024-07-15 19:24             ` James Bottomley
2024-07-15 19:28               ` Steven Rostedt
2024-07-15 19:30                 ` James Bottomley
2024-07-15 19:39               ` Dan Carpenter
2024-07-16  6:30                 ` Greg KH
2024-07-15 20:25               ` Mauro Carvalho Chehab
2024-07-15 20:47             ` Dmitry Torokhov
2024-07-16  6:28               ` Greg KH
2024-07-16 12:20                 ` Takashi Iwai
2024-07-17 22:05                   ` Dan Carpenter [this message]
2024-07-18  7:34                     ` Takashi Iwai
2024-07-18 14:48                       ` Dan Carpenter
2024-07-18 14:56                         ` James Bottomley
2024-07-18 16:36                           ` Dan Carpenter
2024-07-19  0:49                             ` NeilBrown
2024-07-19  1:35                               ` Dan Carpenter
2024-07-19 11:55                                 ` Vegard Nossum
2024-07-23 14:14                                   ` Jiri Kosina
2024-07-16 14:51       ` Jason Gunthorpe
2024-07-16 19:38         ` Dan Carpenter
2024-07-15  6:15     ` Mauro Carvalho Chehab
2024-07-14 17:07 ` Linus Torvalds
2024-07-14 18:47   ` Sasha Levin
2024-07-14 19:27     ` Linus Torvalds
2024-07-14 20:27       ` Sasha Levin
2024-07-14 23:05         ` James Bottomley
2024-07-14 23:09           ` Linus Torvalds
2024-07-15  8:02             ` Greg KH
2024-07-15  8:53               ` Mauro Carvalho Chehab
2024-07-15 12:48               ` Mimi Zohar
2024-07-15 12:52                 ` Mimi Zohar
2024-07-15 14:34                   ` Alexandre Belloni
2024-07-15 14:40                     ` Greg KH
2024-07-15 15:00                       ` Jonathan Corbet
2024-07-15 15:07                         ` James Bottomley
2024-07-15 15:19                           ` Sasha Levin
2024-07-15 15:31                             ` James Bottomley
2024-07-15 15:42                             ` Dan Carpenter
2024-07-15 15:10                         ` Greg KH
2024-07-15 17:45                           ` Mauro Carvalho Chehab
2024-07-15 18:04                       ` Mark Brown
2024-07-15 20:51                         ` Dmitry Torokhov
2024-07-16  6:25                         ` Greg KH
2024-07-16 15:00                           ` Mark Brown
2024-07-14 23:29           ` NeilBrown
2024-07-14 23:29         ` Steven Rostedt

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=ad9720d8-6b4e-4f7c-bf72-b3c2db8887d4@suswa.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=tiwai@suse.de \
    --cc=tytso@mit.edu \
    /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