Re: [PATCHED][RFC][CFT] mount-related stuff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 27 Aug 2025 at 15:49, Konstantin Ryabitsev
<konstantin@xxxxxxxxxxxxxxxxxxx> wrote:
>
> I have recommended that Link: trailers indicating the provenance of the series
> should use a dedicated domain name: patch.msgid.link. This should clearly
> indicate to you that following this link will take you to the original
> submission, not to any other discussion.

That doesn't fix anything. It only reinforces the basic stupidity of
marking the WRONG DIRECTION.

The fact is, YOU CANNOT SANELY MARK THE COMMIT. Dammit, why do people
ignore this *fundamental* issue? You literally cannot add information
to the commit that doesn't exist yet, and the threads that refer to
bugs etc quite fundamentally WILL NOT EXIST YET when the commit is
posted.

The actual *useful* information about a commit is the discussions it
resulted in, not the posting of the patch.

And those will almost invariably be unrelated to the patch submission,
since they either talked about the problems that the patch *fixed*, or
talk about the problems that the patch *caused* (ie the thread starts
with some random "My machine no longer boots", and then goes on from
there as people try to figure out what caused it.

So the *relevant* links are pretty much by definition not the link to
the posting of the patch.

Is it really so hard to understand and accept this fundamental issue?

It's the *message* that should be indexed and marked, not the commit.

What you want to find is messages on the mailing list that mention the
commit, not the other way around. The other way around is completely
pointless and CANNOT BE AUTOMATED. Any automation by definition will
only add noise, not "information".

Really. The only valid link is a link to *pre-existing* discussion,
not to some stupid "this is where I posted this patch", which is
entirely and utterly immaterial.

And dammit, lore could do this. Here's one suggested model that at
least gets the direction of indexing right (I'm not claiming it's the
only model, or the best model, but it sure as hell beats getting the
fundamentals completely wrong):

 (a) messages with patches can be indexed by the patch-id of said patch

This might well be useful in its own right ("search for this patch"),
and would be good for the series where the same patch ends up being
re-posted because the whole series was re-posted.

IOW, just that trivial thing would already allow the lore web
interface to link to "this patch has been posted before", which is
useful information on its own, totally aside from any future
archeology.

But it's not the end goal, it's only a small step to *get* to the end goal:

 (b) messages that mention a commit ID (or a subject line) could then
have referrals to the patch-id of said commit.

No, you don't want to do a whole-text search every time you look for a
commit. That's fine for manual stuff, but it's much too expensive for
any sane automation. But you *can* (and lore already does) scan
messages at message posting time, and find when people refer to a
commit, and then index that message *once* by the patch ID of the
commit.

Now, this *is* fundamentally useful in a very different way: if you
have somebody who bisected something and mentions a commit as a
result, you'd now *find* that kind of message, and the history leading
up to it.

So when people read threads on lore about bugs being bisected, think
how useful it would be if that thread would basically auto-populate
with "this message refers to this patch".

And the final step is

 (c) have some 'b4' infrastructure to look up emails pertaining to a
commit - by doing the patch ID and then looking up the indexing above

Look, now you have a "open web browser with the history of not just
where the patch was originally posted, but where that commit was
*mentioned*".

Notice how fundamentally more useful this is from some link to where
the patch was posted? And absolutely nothing in the above implies
tagging the commit with useless information.

I look at the "Link:" tags quite regularly, and I can tell you that
when it's a posting tag, it almost invariably is completely and
totally useless. We *have* people who add those, and they only add
noise and very little value.

Do not add more of those useless garbage links in the name of
"automation". It's not automating anything useful, it's only
automating garbage.

Because the *commit* already has all the information that is relevant
- it's not the commit that is missing a link. It's the other side.

Which is why those links to lore patch submission events are so
STUPID. They add nothing. Doing them in the name of "automation" is
crazy. It's entirely pointless. It's garbage and it's mis-designed,
because it's not understanding the problem.

                   Linus




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux