b4 Link: trailer disambiguation poll

b4 Link: trailer disambiguation poll

[Konstantin Ryabitsev]

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

Hello, all:

It is common practice to use Link: trailers in commits to provide a way to
view the series as original patches sent to the list; "b4 am" will do this
automatically in the presence of the -l flag.

Recently, Linus suggested that this should be disambiguated in order to help
maintainers distinguish pure archival links from actual list discussion
threads where the feature/fix is discussed. See this conversation for context:

https://lore.kernel.org/CAHk-=wj9zKJGA_6SJOMPiQEoYke6cKX-FV3X_5zNXOcFJX1kOQ@mail.gmail.com

One of the suggested solutions is to use "PatchLink: " which is similar to
"BugLink" already used for linking to bug reports. 

However, other options were also suggested, and I want to survey everyone's
general preference.

So, please vote on this poll to help decide what the trailer for linking to
patch series should be:

https://docs.google.com/forms/d/e/1FAIpQLSf8fiT3Q_9LhqEvE2K8n22HZ0B2t7kpEK_XapoGK_kE0SOb4A/viewform?usp=sf_link

The winning option will go into b4 v0.9.

Thanks,
-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: b4 Link: trailer disambiguation poll

[Konstantin Ryabitsev]

On Tue, Jun 14, 2022 at 11:44:07PM +0200, Jason A. Donenfeld wrote:
> The option I don't see in the poll just not automatically adding any Link
> trailer, and leaving that up to humans to decide a relevant link exists vs
> not.

That is accomplished by not passing the -l switch to "b4 am", so it's already
a choice left to the human.

However, tying commits to their exact list message is extremely useful for a
lot of automation -- e.g. I rely on them heavily in integrations such as
patchwork. I don't want to discourage people from adding these links in.

-K

Re: b4 Link: trailer disambiguation poll

[Jason A. Donenfeld]

The option I don't see in the poll just not automatically adding any
Link trailer, and leaving that up to humans to decide a relevant link
exists vs not.

Jason

Re: b4 Link: trailer disambiguation poll

[Paolo Bonzini]

On 6/14/22 23:39, Konstantin Ryabitsev wrote:
> 
> https://lore.kernel.org/CAHk-=wj9zKJGA_6SJOMPiQEoYke6cKX-FV3X_5zNXOcFJX1kOQ@mail.gmail.com
> 
> One of the suggested solutions is to use "PatchLink: " which is similar to
> "BugLink" already used for linking to bug reports.
> 
> However, other options were also suggested, and I want to survey everyone's
> general preference.
> 
> So, please vote on this poll to help decide what the trailer for linking to
> patch series should be:
> 
> https://docs.google.com/forms/d/e/1FAIpQLSf8fiT3Q_9LhqEvE2K8n22HZ0B2t7kpEK_XapoGK_kE0SOb4A/viewform?usp=sf_link
> 
> The winning option will go into b4 v0.9.

Why not just add "Message-id: <...>" like "git am -m" does?  It is an 
easy step from there to a lore URL.

Paolo

Re: b4 Link: trailer disambiguation poll

[Konstantin Ryabitsev]

On Wed, Jun 15, 2022 at 10:58:36AM +0200, Paolo Bonzini wrote:
> Why not just add "Message-id: <...>" like "git am -m" does?  It is an easy
> step from there to a lore URL.

I think mostly because if we're already sticking a long string into a commit,
then we might as well prepend it with https://lore.kernel.org/ to make it
trivially clickable.

-K

Re: b4 Link: trailer disambiguation poll

[Linus Torvalds]

On Tue, Jun 14, 2022 at 2:40 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> One of the suggested solutions is to use "PatchLink: " which is similar to
> "BugLink" already used for linking to bug reports.

Ugh.

I think both of those names are horrible.

We don't do random CaMelCaSe in the kernel for other things, and we
sure as hell shouldn't do it for these things.

We say "Reported-by:" not "ReportedBy:".

CamelCase is a disease. Just stop it.

I think "BugLink:" is silly, because that's just a regular link.
What's the upside of saying "Bug" in there? If you're fixing a bug,
and are linking to reports and discussions by people, what does that
"bug" buy you apart from another ugly CamelCase thing?

In other words, in "BugLink:", neither "Bug" nor "Link" is actually meaningful.

The current "Link:" tag exists AS A GENERIC WAY TO SAY "look, here's
more information". That's the point. The word "Link" has no other
meaning, and trying to then combine it with other things is worthless.

And a bug report is exactly that kind of "look, here's more
information". There's no point in saying "look, this was a bug
report". It's bogus. The link may well point to the original bug
report, but the important part is likely the *discussion* in that
thread. Should we call it "DiscussionLink:"? Hell no.

So stop combining random words that have no worth in themselves. Two
non-informative words does not make for more information. One word is
just a generic placeholder, and the other word is likely misleading
and pointless. Putting them together makes it even *less* useful, not
more so, and usign CamElcAsE takes it from "worthless" to "crazy".

Again, "Link" is just that neutral word that has no meaning in itself.
It's a syntactic thing to give people some very neutral tag with no
meaning on its own. Why would you ever combine it with anything else?

So if we want a new tag for things, just make that new tag.

   Patch:

would at least make SENSE for a link to a patch submission. Although
it's honestly just a big sign that "this link is not worthwhile".

And no, "Bug:" does not make sense for a bug report. That's just "Link:".

The commit message should have enough of an explanation on its own
("Reported-by:" and the regular "Link:" to the report) that there's
*no* excuse to try to make a bug report link special.

We are not going to replace good commit messages with links to
external things, and as such those links should never be important on
their own. They are there for extra context, and a "this was the
original report and the discussion about it" is _excellent_ extra
context.

The only thing that makes that original patch submission special is
that it's generally so *worthless*.  The thing that makes me want
those marked is that they are useless garbage 99% of the time, and if
you want more context for a patch they are usually the last thing you
actually want to see.

Honestly, I still think that patch submission link should probably
just not exist at all.

Are there other links that might be worthwhilte?

Yes: if people want to make patch submission give more information,
then I think b4 should encourage taking the *COVER*LETTER* and make it
into a merge commit, and at that point it's probably worth having the
link to the patch series in that merge commit.

Because then maybe you get discussion about the whole series, which is
more likely to be interesting and worthwhile.

There really is a big difference between "data" and "information". I
think some per-patch link to a random patch submission that is just
the same thing as the commit is worthless ("data"), but something
higher-level may actually give you something useful ("information").

                     Linus

Re: b4 Link: trailer disambiguation poll

[Konstantin Ryabitsev]

On Wed, Jun 15, 2022 at 10:41:19AM -0700, Linus Torvalds wrote:
> So if we want a new tag for things, just make that new tag.
> 
>    Patch:
> 
> would at least make SENSE for a link to a patch submission. Although
> it's honestly just a big sign that "this link is not worthwhile".

Well, it's not intended to be worthwhile to maintainers -- maybe just to
lawyers, researchers, and automation tooling. :)

> Yes: if people want to make patch submission give more information,
> then I think b4 should encourage taking the *COVER*LETTER* and make it
> into a merge commit, and at that point it's probably worth having the
> link to the patch series in that merge commit.

We're mostly there already with "b4 shazam" (in the upcoming 0.9). It
makes it possible to work with patch series as if they were pull requests,
complete with a prepared merge commit message that uses the cover letter for
most of the content.

That said, I think we can still really use direct patch links in commits,
because leaving that just in the merge message does significantly complicate
automated provenance matching, especially in cases when the maintainer applies
partial series.

Apropos, we can also disambiguate Link: trailers by using a separate domain
for pure archival links, e.g.:

    Link: https://msgid.link/20220614213955.eyex4bekp44iroud@meerkat.local

This way if you see lore.kernel.org, you know it's probably a discussion link,
but if it's msgid.link, then it's just a link to the patch series.

(that domain already works, btw -- it's a simple redirect to lore.kernel.org)

-K

Re: b4 Link: trailer disambiguation poll

[Linus Torvalds]

On Wed, Jun 15, 2022 at 11:17 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Well, it's not intended to be worthwhile to maintainers -- maybe just to
> lawyers, researchers, and automation tooling. :)

Honestly, I really despise that argument.

If you are a researcher or whatever else, you need to do this by patch
ID *ANYWAY*.

Please.

Why can't we just have a nice sane patch-ID gateway, and get rid of
this silly thing?

That would be *SUPERIOR*.

It would give you the different versions of the same patch that got
posted multiple times and maybe got discussion.

The whole argument that the "original submission" is special is pure
and utter garbage. It's not special, and trying to make it so only
takes real information away.

Really. You are making things worse, not better.

b4 already depends on lore automation, so why not improve that
automation so that you can look up things by commit ID, which looks up
patch ID, which is indexed by lore when it sees patches?

Then you will automatically also see things like "oh, look, this same
patch was then submitted to stable after it was committed". Things
that you literally *CANNOT* do in the commit itself as a link, because
it would require time travel.

And no, the whole "but people edit patches and the patch ID might
change" isn't an argument either. At that point it's no longer a "b4"
thing to add a link.

               Linus

Re: b4 Link: trailer disambiguation poll

[Konstantin Ryabitsev]

On Wed, Jun 15, 2022 at 11:22:59AM -0700, Linus Torvalds wrote:
> Why can't we just have a nice sane patch-ID gateway, and get rid of
> this silly thing?
> 
> That would be *SUPERIOR*.

This is already an accepted upstream feature:
https://public-inbox.org/meta/20220512193859.M526956@dcvr/

It's not in the code yet and will require a full reindex, so I don't yet have
an ETA when searching by git-patch-id will become available.

> It would give you the different versions of the same patch that got
> posted multiple times and maybe got discussion.
> 
> The whole argument that the "original submission" is special is pure
> and utter garbage. It's not special, and trying to make it so only
> takes real information away.
> 
> Really. You are making things worse, not better.
> 
> b4 already depends on lore automation, so why not improve that
> automation so that you can look up things by commit ID, which looks up
> patch ID, which is indexed by lore when it sees patches?

Well, b4 doesn't actually depend on lore that much -- it can work with a local
maildir just as well. I am trying hard not to add too many features that would
make kernel development fully dependent on lore being up and running.

> Then you will automatically also see things like "oh, look, this same
> patch was then submitted to stable after it was committed". Things
> that you literally *CANNOT* do in the commit itself as a link, because
> it would require time travel.
> 
> And no, the whole "but people edit patches and the patch ID might
> change" isn't an argument either. At that point it's no longer a "b4"
> thing to add a link.

My problem is that maintainers still want automation to properly recognize
that it's the same patch and its status on patchwork should be moved to
"Accepted".

Maybe the better answer is to integrate patchwork API into b4, so that I have
to do less guessing on the git-patchwork-bot side of things.

-K