From: "Theodore Ts'o" <tytso@mit.edu>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Linus Torvalds <torvalds@linuxfoundation.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
tools@linux.kernel.org, users@linux.kernel.org
Subject: Re: b4-0.9.0 available
Date: Thu, 23 Jun 2022 19:33:00 -0400 [thread overview]
Message-ID: <YrT4LIq6ssD1mhMQ@mit.edu> (raw)
In-Reply-To: <YrI3W46GUS/Dap5J@ripper>
On Tue, Jun 21, 2022 at 02:25:47PM -0700, Bjorn Andersson wrote:
> On Tue 21 Jun 11:45 PDT 2022, Jason A. Donenfeld wrote:
> > - Don't add `Link:` if the URL hasn't been hand selected as being
> > particularly relevant; the lkml patch email alone doesn't cut it. This
> > suggests that automatically adding `Link:` is invariably wrong, since
> > automatic != "hand selected", so maybe there's no point in
> > `-l,--add-link`, and you can just remove that option.
>
> FWIW I find it very helpful to have the lore-Link in patches, as that
> allow me to quickly find and share a pointer to already landed
> patch/patchset - in particular when the recipient doesn't have
> linux-next synced and checked out locally.
I'll also note that a number of maintainers (including myself) are
adding the Link to the lore via a git hook:
#!/bin/sh
# For .git/hooks/applypatch-msg
#
. git-sh-setup
perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"
test -x "$GIT_DIR/hooks/commit-msg" &&
exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
:
This predates my use of b4, because it means that I can save a message
from my inbox, and then run "git am -s /tmp/patch-mbox" and the Link
line is added. No one has really complained, and I've found it useful
on occasion when doing code archeology when I'm trying to figure out
why a patch was added, or to pick up discussion *about* the patch that
happened during the code review.
It's not perfect, especially for large patch series where there is
say, a v27 patch series before it finally gets accepted, unless the
cover letter of v27 has a URL link to all of the previous patch
series. In some ways, this is why the Gerrit scheme of having a
ChangeId trailer is so helpful. It's an invariant across different
versions of the patch, and it means that assuming the Gerrit server is
still up, you can see the entire code review history in a single web
page.
It would be ***great*** if the lore/b4/git workflow had a similar
functionality. Perhaps that means some kind of tool to automate
generation of the cover letter, or hiding the previous URL link after
the --- line in the e-mailed version of the patch?
> And I don't mind there being multiple Link: tags to different resources,
> as the various automation use cases I've run into have been easily
> solved by just filtering the tags by domain...
I don't mind because when I *have* had to go back in time to do code
archeology ("what *was* I thinking two years ago...") having an easy
way to do that has been worth its weight in gold.
That being said, it isn't easy to distinguish between a Link to a bug
report that was submitted to a vger mailing list, and as I've
mentioned, there isn't a good way to find the previous versions of the
patch, since previous versions of the patch or patch series tend be on
separate e-mail threads, and some of the more critical code review
discussions happen on earler versions of the patch/patch series, not
the final version where it's mostly about fixing the final nits, as
opposed to the design/architectural discussions.
Cheers,
- Ted
next prev parent reply other threads:[~2022-06-23 23:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 19:01 b4-0.9.0 available Konstantin Ryabitsev
2022-06-20 8:40 ` Geert Uytterhoeven
2022-06-21 23:38 ` Linus Walleij
2022-06-22 5:49 ` Vinod Koul
2022-06-21 15:20 ` Geert Uytterhoeven
2022-06-21 15:29 ` Konstantin Ryabitsev
2022-06-21 15:41 ` Geert Uytterhoeven
2022-06-21 15:55 ` Linus Torvalds
2022-06-21 16:03 ` Jason A. Donenfeld
2022-06-21 16:59 ` Konstantin Ryabitsev
2022-06-21 17:49 ` Jason A. Donenfeld
2022-06-21 18:29 ` Konstantin Ryabitsev
2022-06-21 18:45 ` Jason A. Donenfeld
2022-06-21 19:27 ` Konstantin Ryabitsev
2022-06-21 19:42 ` Jason A. Donenfeld
2022-06-21 19:43 ` Geert Uytterhoeven
2022-06-21 19:50 ` Jason A. Donenfeld
2022-06-21 20:06 ` Konstantin Ryabitsev
2022-06-21 20:29 ` Jason A. Donenfeld
2022-06-21 21:25 ` Bjorn Andersson
2022-06-23 23:33 ` Theodore Ts'o [this message]
2022-06-24 13:51 ` Jason Gunthorpe
2022-06-24 15:29 ` Theodore Ts'o
2022-06-24 15:34 ` Mark Brown
2022-06-24 16:05 ` Theodore Ts'o
2022-06-24 15:52 ` Konstantin Ryabitsev
2022-06-24 16:05 ` James Bottomley
2022-06-24 16:16 ` Konstantin Ryabitsev
2022-06-24 16:29 ` James Bottomley
2022-06-24 16:06 ` Jason Gunthorpe
2022-06-24 16:16 ` Mark Brown
2022-06-24 17:51 ` Chuck Lever
2022-06-24 8:34 ` Nicolas Ferre
2022-06-21 15:53 ` Jason A. Donenfeld
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=YrT4LIq6ssD1mhMQ@mit.edu \
--to=tytso@mit.edu \
--cc=Jason@zx2c4.com \
--cc=bjorn.andersson@linaro.org \
--cc=geert@linux-m68k.org \
--cc=konstantin@linuxfoundation.org \
--cc=tools@linux.kernel.org \
--cc=torvalds@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.