workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alejandro Colomar <alx@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Mark Brown <broonie@kernel.org>,  Sasha Levin <sashal@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Yeking@red54.com, kuba@kernel.org,
	Jonathan Corbet <corbet@lwn.net>, Theodore Ts'o <tytso@mit.edu>,
	Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>,
	Dwaipayan Ray <dwaipayanray1@gmail.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	 linux-kernel@vger.kernel.org,
	tech-board-discuss@lists.linux.dev, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH] Add short author date to Fixes tag
Date: Wed, 25 Feb 2026 14:47:19 -0500	[thread overview]
Message-ID: <5f5f0f87bfd000a46987a08ad2a7505851bbb424.camel@HansenPartnership.com> (raw)
In-Reply-To: <aZ87Z24f9HZsofGl@devuan>

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

On Wed, 2026-02-25 at 19:20 +0100, Alejandro Colomar wrote:
> > Commit date also doesn't matter.  If I commit a fix to one of my
> > branches today, but Linus pulls it in in 2 years from now, what
> > would that date really show to anyone?
> 
> I think this is a bit confused.

Let me try another explanation: we only change tag formats for what
most people agree is a compelling reason (because of the script
breakage it causes among other things).  Your reasons so far aren't
compelling.

> If you commit a fix for a commit that is in Linus's tree, your Fixes
> tag will refer to the mainline commit, and the Fixes tag will remain
> valid if the fix is pulled by Linus in the future, because it will
> continue to refer to the same commit with the same hash and date.
> 
> The case where it would matter is if you commit a fix for a commit
> that is only in your stable branch.  However, since the stable
> branches are not real branches, but actually a set of patches, I
> expect you would just drop the faulty patch, right?

I think this is a bit confused.  The decision to rebase or revert is a
balancing act which depends how many people have seen (and possibly
rely on) the branch with the original commit in it.

> I expect any Fixes tag refers to commits in Linus's tree, right?
> Otherwise, they are dangling references, except to those who know
> where to find the commit.  If all Fixes tags refer to commits in
> Linus's tree, then all Fixes tags are stable.

I believe one of the prerequisites for changing current process should
be actually understanding how it works today.

> The commit date is tied to a commit and its hash, and the date will
> remain valid as much as the hash itself.

The argument isn't about validity, it's about utility.  Most of the
tasks we do don't care about the date and for the odd occasion we do
care we can follow the hash to get it.

Regards,

James



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

  reply	other threads:[~2026-02-25 19:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25  0:56 Alejandro Colomar
2026-02-25  0:57 ` Alejandro Colomar
2026-02-25 18:00 ` Greg Kroah-Hartman
2026-02-25 18:20   ` Alejandro Colomar
2026-02-25 19:47     ` James Bottomley [this message]
2026-02-25 21:23     ` Greg Kroah-Hartman
2026-02-25 21:45       ` Alejandro Colomar
2026-02-25 22:35         ` Theodore Tso
2026-02-25 23:27         ` Sasha Levin
2026-02-25 23:46         ` Greg Kroah-Hartman
2026-02-26  0:20           ` Alejandro Colomar
2026-02-25 20:08 ` Sasha Levin
2026-02-26  0:08 ` Steven Rostedt
     [not found] <tencent_6CF6E720909156A227D23AE8CFE4F9BA5D05@qq.com>
2025-01-10 12:20 ` Yeking
2025-01-10 12:32   ` Greg Kroah-Hartman
2025-01-10 13:03   ` Steven Rostedt
2025-01-11  0:21     ` Jacob Keller
2025-01-11  5:48       ` Greg Kroah-Hartman
2025-01-11 17:09       ` Steven Rostedt
2025-01-12 10:54         ` Geert Uytterhoeven
2025-01-13 14:51           ` Steven Rostedt
2025-01-13 15:08             ` Mark Brown

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=5f5f0f87bfd000a46987a08ad2a7505851bbb424.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=Yeking@red54.com \
    --cc=akpm@linux-foundation.org \
    --cc=alx@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=apw@canonical.com \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dwaipayanray1@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacob.e.keller@intel.com \
    --cc=joe@perches.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=sashal@kernel.org \
    --cc=tech-board-discuss@lists.linux.dev \
    --cc=tytso@mit.edu \
    --cc=workflows@vger.kernel.org \
    /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