tools.linux.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Alex Elder <elder@ieee.org>,
	users@linux.kernel.org, tools@linux.kernel.org
Subject: Re: RFC: Superseded-by: follow-up trailer
Date: Wed, 14 Apr 2021 10:35:04 -0400	[thread overview]
Message-ID: <20210414143504.l3txdpd6xbcf6qh5@nitro.local> (raw)
In-Reply-To: <YHaaMaa2uaa6HM9c@hirez.programming.kicks-ass.net>

On Wed, Apr 14, 2021 at 09:30:57AM +0200, Peter Zijlstra wrote:
> > I'd rather folks used the following notation in the cover letter/patch
> > basement:
> > 
> >     Previous versions:
> > 
> >     Link: https://lore.kernel.org/r/foo # v2
> >     Link: https://lore.kernel.org/r/bar # v1
> > 
> > This is much more succinct, indicates the version number in the trailer, and
> > removes the need to remember how to spell "Superseded", as there seems to be
> > little consensus. :)
> 
> How would you handle the difference between the above and:
> 
> Depends on:
> 
> Link: https://lkml.kernel.org/r/foo
> 
> Which is also a semi common thing to do with larger work that comes in
> multiple dependent series.

It's the "# vX" at the end that we'd be looking for. There's no other reason
to put it there if you aren't linking to a previous revision of the series, so
it's a very unambiguous pattern. However, read below.

> That is; I supppse; a long winded way of saying that for parsing (both
> human and machine) it might be useful to have distinct tag names. Now I
> agree with you that Supersedes is a crap word to spell, but it has the
> distinction of being clear on intent.
> 
> So my 2ct go to adding Supercedes: and Depends-on:

Hmm... there is an officially sanctioned way to indicate patch
interdependencies using "prerequisite-patch-id:" footers (see
https://git-scm.com/docs/git-format-patch#_base_tree_information).

That said, I've never seen anyone actually use them, I guess for two reasons:

1. it's per-patch, not per-series
2. it requires running "git patch-id" on each patch in the dependencies

We could build upon that using "prerequisite-series-link", but I find that
unwieldy, especially if it will be followed by a long URL.

How about we borrow RPM-spec lingo, for stuff to go into the cover letter or
below ---, e.g.:

    Subject: [PATCH v3] frobdrv: improve frob latency

    Commit message here

    Signed-off-by: Dave Elloper <dave@example.net>
    ---
    Requires: https://link.to/required-patch
    Obsoletes: https://link.to/v1 # v1
    Obsoletes: https://link.to/v2 # v2
    ---
    Changes in v3:
    Style tweaks.

    [diffstat, patch, etc]

or:

    Subject: [PATCH v3 0/2] frobdrv: improve frob latency

    This series improves frob latency by 20%.

    Requires: https://link.to/required-patch
    Obsoletes: https://link.to/v1 # v1
    Obsoletes: https://link.to/v2 # v2

    [diffstat, etc]

Then I can add automation that will send "Obsoleted-by:" and maybe
"Required-by:" follow-ups to the linked series when it encounters these tags.

Does this work for others?

-K

  parent reply	other threads:[~2021-04-14 14:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 20:49 RFC: Superseded-by: follow-up trailer Konstantin Ryabitsev
2021-04-13 20:53 ` Alex Elder
2021-04-13 21:02   ` Jason A. Donenfeld
2021-04-13 21:29     ` Steven Rostedt
2021-04-13 21:40       ` Konstantin Ryabitsev
2021-04-14  0:02         ` Steven Rostedt
2021-04-14  7:30         ` Peter Zijlstra
2021-04-14 11:49           ` Jason Gunthorpe
2021-04-14 13:57             ` James Bottomley
2021-04-14 14:36               ` Jason Gunthorpe
2021-04-14 14:56                 ` Konstantin Ryabitsev
2021-04-14 15:57                   ` Jason Gunthorpe
2021-04-14 17:07                     ` Konstantin Ryabitsev
2021-04-14 17:24                       ` Jason Gunthorpe
2021-04-14 17:40                         ` Konstantin Ryabitsev
2021-04-14 18:46                         ` Mark Brown
2021-04-14 18:58                           ` Jason Gunthorpe
2021-04-14 15:01                 ` Steven Rostedt
2021-04-14 15:36                   ` Peter Zijlstra
2021-04-14 17:44                     ` Willy Tarreau
2021-04-14 14:44             ` Theodore Ts'o
2021-04-14 18:51               ` Geert Uytterhoeven
2021-04-14 14:35           ` Konstantin Ryabitsev [this message]
2021-04-14 15:10             ` Peter Zijlstra
2021-04-14 12:52         ` Alex Elder
2021-04-13 21:04   ` Konstantin Ryabitsev

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=20210414143504.l3txdpd6xbcf6qh5@nitro.local \
    --to=konstantin@linuxfoundation.org \
    --cc=Jason@zx2c4.com \
    --cc=elder@ieee.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tools@linux.kernel.org \
    --cc=users@linux.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;
as well as URLs for NNTP newsgroup(s).